Why browsers treat HTML5 elements as inline
Occasionally someone pipes up on the twitter #html5 hashtag asking why the nav element has a height and width of zero, or why browser X refuses to render a section properly.
The reason is that the browsers are conforming to the CSS spec which says
Note that although the initial value of ‘display’ is ‘inline’, rules in the user agent’s default style sheet may override this value.
Browsers have default stylesheets. That’s where the “unstyled” HTML is styled. You don’t think it’s styled because it’s not using your lovely CSS, but actually there is a rudimentary stylesheet in the browser that sets things like div {display:block;} or the default fonts, margins and paddings for headings.
The browsers don’t “know” about most new HTML5 elements (except canvas and video), so they don’t define section, nav as display:block and thus they remain as inline, as the spec says.
The way round it is to define them all in your stylesheet. Simple as that.
This raises two vaguely interesting philosophical points.
The first is about CSS reset stylesheets. A true CSS reset would set every element to be display:inline. (Personally I see little value in reset stylesheets except as a debugging/ educational tool, however.)
The second is the question of what it actually means for a browser to “know about” an element. In the case of an element like abbr or input, there are certain inherent behaviours.
But with something like div or span, or even i and b, the only thing the browser needs to “know” is how to style it. Any arbitrary element is already findable by JavaScript getElementByTagName (whether it be a new HTML5 element or something entirely arbitrary like a cheescake element) because JavaScript can be equally used with other markup languages such as XML which can have user-defined elements.
So now you know.
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
7 Responses to “ Why browsers treat HTML5 elements as inline ”
Mmmm, cheesecake…
Thank you Bruce for your HTML5 posts and articles in various places across the web. I have to say you are the biggest driving force in me changing my site and making it HTML5.
Was nice to take the plunge and get it out there. Especially as I started it as “messing around” then deciding it was better than my old theme.
Keep up the good work.
Andy
This brings up a question I’ve wondered about for a while. If the display of an element is inline by default, how do validators decide that something is valid or not valid if the spec states that an element may only contain block or inline content? For instance, a <dt> element may only have inline content inside it (http://www.w3.org/TR/html401/struct/lists.html#h-10.3). It seems that the validation of an HMTL document is then dependent on the display property of the element, rather than something intrinsic to the element itself. Do the validators contain their own internal stylesheet rules, or do they have some other set of rules that say these items are block, these are inline?
Thanks for the response Bruce. That’s the link I needed to understand how they set what was allowed in what. I’m going to have to read about content models in HTML5 and I’ll be back with more questions, I’m sure. You and the other doctors are a great resource.
This isn’t strictly true of course. The browser also has to add the DOM interfaces for the new elements too.