Friday 18 February 2005

root element: html

CONFUSED ABOUT ROOT? Apparently, so are people trying to interpret the W3C CSS 2.1 specification as it relates to the root element and containing blocks. Let’s help clarify the concern.

The root element in HTML and XHTML is always the html element. This is because it is the element that has no ancestors, only descendants.

What seems to be confusing the issue is this language from the CSS 2.1 spec:

The containing block in which the root element lives is chosen by the user agent. (It could be related to the viewport.) This containing block is called the initial containing block.

That it “could be related to the viewport” is the language I think is confusing and very vague on the part of the W3C. However, the fact remains that the root element is still html. To support that, here’s the W3C’s definition of the document tree and root element:

Document tree: The tree of elements encoded in the source document. Each element in this tree has exactly one parent, with the exception of the root element, which has none.

The viewport is not an element, but I suppose if one sees it as the “containing block in which the root element lives” a browser developer could conceivably interpret that to mean the viewport rather than the root element.

But to my way of thinking, if there is no other defined containing block, the root element must be html and not the viewport, because it is the root of the document.

Darned confusing, and in this case I blame the W3C terminology. I’d love to hear more thoughts and opinions on this.

Filed under:   general
Posted by:   Molly | 11:52 | Comments (27)

Comments (27)

  1. I think the confusion arises around the term, “containing block” rather than the “related to the viewport” section. I didn’t think it was ambiguous until you pointed it out, which either goes to show how ambiguous language can be, or that I only think I understand what they mean.

    If I understand it correctly, the containing block in this instance doesn’t relate to the document tree, other than where the root element of the document tree will be placed. It’s quite reasonable for the containing block for the document tree to be decided by the user agent, so that user agents can support split views, or other types of customisation, which would be placed relative to the viewport. The reason I think containing block is the confusing term, is that it’s also used to refer to elements in the document tree that act as containing blocks for other elements.

  2. Interesting issue, Molly. I think this language confuses the two technologies a bit. For one thing, an XHTML (or any XML) element is not a containing “block” by its own nature, but is given one by default when displayed in CSS. When the spec says that the root element lives within a containing block, it seems to suggest that there is something going on above the root element, that somehow the XHTML hierarchy is being affected. When, all it is really saying is that CSS defines some sort of initial, visual containing block when applied to XHTML.

  3. My quandary involves the use of the phrase “containing block”. As it stands, it almost connotes to the reader that the <html> element also adheres to the box model and can have, as such, margins, padding, etc. specific to it in addition to what may be applied to the <body> element. Maybe it’s just me (again, as Gez, the choice of wording is ambiguous), but it does seem odd that this should be introduced in the CSS 2.1 specifications instead of the HTML or XHTML specifications (time for me to go check and see what IS in those specifications).

  4. Wow… I just realized that what I thought was “connoted” is actually “fact” in Firefox. I just tried a page where I applied margins and a background-color to the <html> element and it did it. However, as usual, IE does not handle it quite the same. They assume, like I did, that the box model does not apply to the <html> element; thus, the margins were not implemented. However, if the content of the <body> does not span the entire height of the <html> element’s containing block, then where it ends, the background-color applied to the <html> element shows. My example is shown here. Probably off-topic, but I never cease to learn stuff.

  5. When reading the whole passage about the definition of containing block it becomes clear that the initial containing block has no relation to the document tree.

    I understand this initial containing block being equivalent to the canvas in visual user agents, where the canvas is restricted by the dimensions of the viewport.

  6. Outside the HTML element there is an initial containing block element. It is not specified by CSS 2.1 what exactly that element represents because that is outside the scope of the specification.

  7. I have no idea what the confusion is all about. The viewport is the window in which all content is rendered and, in CSS terms, is the containing block for the root element. This initial containing block is not an element, it is simply a box within the CSS box model (although a ::viewport, or similar, pseudo-element may be defined in the future to refer to it). In (X)HTML, as you said, the root element is html which gets rendered within the viewport, so I don’t see what is at all confusing about the two different concepts.

  8. Thanks, G Evans. I did actually start playing around with things and sent an email to Molly for her input on some items I came across. Hopefully she’ll respond to my email soon and give me her opinion(s).

  9. Charles,

    I’m in a perpetual state of email backlog so please by all means post your items here – I’m sure we can all learn from your input!


  10. Based on your request, here is the email in its entirety (minus sig):

    I suddenly had a hunch to try out some style settings in addition to what I had done with the HTML element in the example I posted under “Root Element: HTML”. I made an interesting “discovery” when I applied some styles to the “head”, “title”, “style” and “script” elements of a page. Nothing happens in IE, but if viewed in FireFox, the styles I applied work. To see an example of this, go to:

    I only say “discovery” because you or someone else may have already found this out and I just missed the boat as usual. However, I do find that this could be extremely useful. Especially when you need to print the page and want the title of the page to be displayed in a more visually bold way. Or, while developing, you need to see what scripts are being placed in the page without having to view source (especially if it is a complex page).

    I only realized that in some sense, you may need to be able to apply styles to items such as the “title” element because of the need for aural stylesheets. Especially if you want additional emphasis placed on the speaking of the title or you want it to display for those with poor vision in a larger font than just the title bar allows.

    I figured you’re one of the best authorities to ask about this and would be more familiar with current “discoveries” and what areas have already been explored. If I have struck on something new, I may consider putting this into some sort of ALA article. Just kinda don’t know who else to ask about this. ­čÖé

  11. funny enough, if you wanted to style everything on the page, you would use the star (*) in your css rather than the html element.

  12. There is a lot of confusion about the use of the terms “block” and “inline” in the (X)HTML and CSS specifications. CSS doesn’t worry about block-level or inline-level elements at all; it deals with block-level and inline-level boxes. There is a default box type for each rendered element type, but that is defined in the user agent style sheet, not in the CSS specification.

  13. Charles,

    I would like to draw your attention to the user mode stylesheets in Opera. There you find a stylesheet named Showstructure.css which does actually style elements inside the head section to display the available information.

    Alas, as you noticed, Internet Explorer does not support any styling of these elements. How other user agents despite Opera and Firefox handle this I, regretfully, do not know.

  14. If something has to be explained this much, then it is wrongly conceived. That’s the Zen of it.

  15. To confuse the viewport as the root, is to not know what ‘viewport’ means (its definition). I agree, the root should always be the HTML in such cases.

    p.s. Molly, your comments form URL textbox doesn’t declare if the ‘http://’ is required or not for the text field, and the lowercase ‘L’ in the label looks like an ‘I’….(‘URI’ rather than ‘URL’). Just saying.

  16. Pingback: Max Design - standards based web design, development and training » Blog Archive » Some links for light reading (20/2/05)

  17. Pingback: el factor humano

  18. Thanks for shedding light on the ‘root’ of the problem hehe.

Upcoming Travels