Request to add default display type to HTML Reference Elements

[sheriffderek (derek@sheriffderek.consulting)]

The MDN HTML Elements Reference has been indispensable while teaching my students - but there is one area that causes them the most confusion. They don’t always know what an element’s default properties are. I am going to focus on the ‘display’ property.

For historically good reasons - elements like iframe and img are display: inline;. People who are new to layout often get tripped up trying to add a margin to inline elements because they don’t know they are inline. Even 10 years in, I still get tripped up trying to remember things like “what is the default display type for custom elements?”

Please include “as far as I know” - before the following ; )

In chrome’s dev tools - there is no sign of any default display property.

My first thought was to check the MDN reference - and point the students to that table / but there isn’t any note on the default display.

and so I needed a way to check on some elements and show the default to the students: https://codepen.io/sheriffderek/pen/RwNRPyO?editors=1001 (link independent of codepen UI: https://cdpn.io/sheriffderek/debug/RwNRPyO)

Firefox dev tools do show defaults in the box-model section - which is really cool.

So - what I’m suggesting, is that we identify the few default properties that cause the “gotchas.” I think there might be a few, but display is the one we have been seeing the most confusion around. position is always static by default, so that’s an example of something that isn’t unique to any element and wouldn’t be included in this table.

HTML: Elements Reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Element

topic: Planning and coordinating changes to the site > specifically HTML element reference

Please let me know if you have any questions and maybe I can come up with better examples. At the end of the day, my goal is to fill in what I see as a hole in the elements reference so that people don’t need to memorize what can seem like quirks.

[chrisdavidmills]

Hi @sheriffderek,

Thanks for your post — this is a really interesting topic, and not one that I’ve really thought of before (I’m in charge of all the begnner’s docs on MDN, so it is of particular interest to me ).

When I first read the post, I thought “whoa, this’ll be a lot of work”! And indeed, it would be a lot of work to try to go and include this on every HTML element reference page. But you are right, if we just looked at the specific subset that’s causing the gotchas, that might make it manageable.

Default CSS styles per element is an interesting one — it’s not really defined in the HTML specs, and I suspect it might be a kind of defacto agreement between the browser vendors. Of course, I could be wrong; I’ll have to do a more thorough search some time later.

Perhaps we could add a column to the tables on the HTML elements reference, and start to fill in these details. Is this a project you fancy helping with?

(Looks like W3Schools already has a page that provides this information, although I’m not sure how accurate it is: https://www.w3schools.com/cssref/css_default_values.asp)

I also did a bit of fiddling, and came up with a tester function similar to yours, which will work for any combination of element and property:

function returnComputedStyle(elem, prop) {
  let element = document.createElement(elem);
  document.body.appendChild(element);
  return window.getComputedStyle(element)[prop];
}

You’d then call it with, for example

returnComputedStyle('img', 'display')

Of course, this is not perfect. If for example you ran returnComputedStyle('img', 'background-color'), it’d return rgba(0,0,0,0) ratehr than “nothing”, because that’s the default applied if nothing is set explicitly.

But yeah, definitely worth discussing.

[sheriffderek (derek@sheriffderek.consulting)]

Thanks for taking the time to think about this, @chrisdavidmills. I’m out of town, but I’ll happily put some time into this when I get back. I don’t have a lot of trust for w3schools - but I bet you’re right that it landed in a loose way between venders.

I feel like there are patterns - such as this way of dealing with img parents vs the seldom-used inline or inline-block uses.

img {
  display: block;
  width: 100%;
  height: auto;
}

.my-cat {
  max-width: 400px;
}

<picture class="my-cat">
  <img src="cat-2.jpg">
</picture>

If not key: value table note about default display types - then maybe adding information about these types of “patterns” could also be helpful.

[sheriffderek (derek@sheriffderek.consulting)]

I’m trying to note the elements as I run across them. (I’m starting a fresh/big project)

body is probably the most basic gotcha - with its default margin. figure and picture have interesting choices. Custom elements are inline by default - even though they are definitely going to have children.

Example: https://jsfiddle.net/sheriffderek/ewz2tsdv @chrisdavidmills

- just one visual example: authors would expect a picture element to properly contain it’s img element. This is a common misunderstanding - and a great many stack overflow questions can be answered with the suggestion to “put a border on it” - at which time they can see it’s “Broken” - as they say.

This happens a lot.

1. “put a border on it”
2. look at the dev tools to see its display property (you might not be able to see it…)
3. go learn about display types
4. realize that block things can’t go in inline things… (maybe)
   or
5. set display block and forget what happened until next time you run into it

Being more transparent about these the quirks that history has left us with could help.

I think that each of (what I’m going to call “gotchas” until something better…) - is different. So, instead of a key in a table for ‘display’ - maybe there is a “things to note” type of box. “Modern considerations” or something.

(JK)

One way to think about this is “what are things like this necessary” - https://meyerweb.com/eric/tools/css/reset/ (I know why) - but maybe that’s something we can use to guide us to find the weird parts.

[chrisdavidmills]

I think “CSS gotchas” is a reasonable title for such a page until we think of something better. It is hard to think of something that works equally well for an international audience, as “Gotchas” does for a US audience (also known as pitfalls, traps, etc…)

I like the idea for each “gotcha” of explaining what the typical weird behavior is that you might see, why this behavior occurs, historically why it is that way, and how to fix it.

I even like the warning box design

I think i’d be most in favor of having this page hanging off of this part of the learning area:

CSS building blocks

[sheppy (Eric Shepherd)]

I agree; this sounds like a good idea, in more ways than one.

chrisdavidmills

[sheriffderek (derek@sheriffderek.consulting)]

ooh. Name all the ways! ; )

[sheriffderek (derek@sheriffderek.consulting)]

Maybe “commonly unexpected behavior” - or something? “Unexpected behavior of certain elements and their quirks”

RE: building blocks page — I could see that here:

and then the page it leads to - could have an ID for each section… - and maybe a little note in the copy of the element’s detail page could lead to that anchor on the gotcha page.

You could have a dedicated detail page for each gotcha - but I think that a little section would probably do the trick.

Let me know what else I can do to help / or what would be the next most useful step.

: )