Bruce Lawson’s personal site

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.

14 Responses to “ Why browsers treat HTML5 elements as inline ”

Leave a Reply