While updating my reset stylesheet last week, I realized that if I wanted to reset the new HTML5 elements I would have to determine precisely how they were supposed to be styled. Which proved to be a challenge, since no browser yet supports anything like the full array of new elements and styles.

Luckily, the current HTML5 specification contains extremely detailed descriptions of how browsers should render HTML documents. These are not requirements, of course, but rather “a set of suggestions.” These descriptions, found in §11 Rendering, are of reasonable expectations; and thus it seems reasonable, in turn, that I base my expectations for the future behavior of browsers on them. (Realizing full well how deeply foolhardy that might be.)

Within the many suggestions listed in §11 – and they are many and detailed – there is one in particular that is relevant here: §11.2 The CSS user agent style sheet and presentational hints. This section walks through the varieties of default styles and describes how each HTML element is to be handled. Specific CSS is provided, and additional instructions and suggestions are noted. From time to time, the additional notes refer to styles best handled by CSS, though for the most part they don’t.

Regarding the new HTML5 elements, my goals are to:

1. Set up the appropriate display properties, so that blocks display as blocks by default.
2. Make sure that any elements that shouldn’t be visible are not.
3. Counteract, in a speculative, preventative manner, any styling that browsers are likely to apply.

§11 contains all the information I need to meet these goals. It describes the display types of the elements, including their visibility, and it describes all the other styling that should be applied by the browsers, once they support HTML5 more completely.

Therefore I compiled all the recommended CSS into one stylesheet. In doing so, I realized that the styles recommended are entirely too comprehensive. Styles for deprecated elements and elements modified by deprecated attributes are listed, so I removed them from my stylesheet. CSS bindings for each element are listed in §11.4 – but only Gecko supports that functionality, and it currently only supports it in a proprietary way; so I left out the bindings styles too.

In other ways, the recommended CSS does not go far enough. Two sets of styles, describing the appearance of h1 elements nested within the new semantic content elements, are so complicated that the draft standard only summarizes how they are supposed to work. Both §11.2.3 and §11.2.5 note that the styling of an h1 element varies depending on its context. Of course, h1 has its own default styling – font-size: 2.00em, for instance. But when you have an h1 nested within a section element – section h1, that is – it should receive font-size: 1.50em. And if you have another heading, nested even further - article section aside h1, for example – that should have font-size: 1.00em applied. This is important, since HTML5 has radically redefined how we are supposed to use headings.

Sadly, the draft standard authors have left it as an exercise to the reader to actually write the relevant styles, for all the nesting depths. I have done so, though I’m not entirely sure I’ve done so correctly. The permutations involved are reasonably complicated, particularly since section elements can nest within each other, though none of the others can.

There is only one additional change that I’ve made, a quite small one, but potentially useful. §11.2.2 Display types describes how each element should be displayed by default – head is hidden, blockquote is a block, table is a table, ruby elements are displayed like ruby characters, et cetera. The list of block level elements, however, does not include the details element.

An element new to HTML5, “the details element represents a disclosure widget from which the user can obtain additional information or controls”, according to §4.11.1. It is what the standard calls an interactive element, and is meant to act as a wrapper for other content which may be displayed or hidden as the reader prefers. The usage example provided – as well as the description of how to use the details element – suggests wrapping it around a dt and a dd, as if it were a special type of definition list. As such, it seems appropriate to style the details element as a block, and I’ve done so.

You can see the stylesheet that resulted from my compilation and editing on GitHub, along with some notes. You’re free to use it as you like. As always, please do let me know if you notice any problems or have any suggestions.