Define root element (as a term, and its display type)

[fantasai]

Addresses

• [css-display-3] Clarify whether the initial containing block establishes a block formatting context #7207
• [CSS2] Clarify how the root element is laid out. #6480
• [css-display] "root element" is undefined #7786

by

• defining "root element" as a term in the glossary
• defining that the root element's box always creates an independent formatting context
• adding a subheading over the paragraph about root element special behavior
• defining the ICB to establish a block formatting context so that the root element's box is fully defined to be a block-level box

This last bit is implemented (as demonstrated by float) in WebKit and Blink; Firefox seems to have special layout for the root that doesn't honor float, but is otherwise like block layout. We could say that float is ignored or whatever, but definitely most of the behavior (margins, alignment, sizing) matches block layout.

[css-meeting-bot]

The CSS Working Group just discussed Define root element (as a term, and its display type), and agreed to the following:

• RESOLVED: Merge this PR

The full IRC log of that discussion

<fantasai> https://github.com//pull/8095/files
<TabAtkins> q+ about use for top-level stuff
<TabAtkins> q+
<flackr> fantasai: there's various things about root element that are underdefined. The PR introduces the term root element, clarifies the principal doc always establishes an independent block, ??. It also defines the ICB establishes a block formatting context
<flackr> fantasai: this is a new concept. For the most part, browser behave as if it is a BFC. The only thing I found different was the firefox could? float the root box
<fantasai> s/could?/couldn't/
<astearns> ack TabAtkins
<dbaron> q+
<flackr> fantasai: the other differences are some honor float or don't
<flackr> TabAtkins: the text of the PR looks good
<flackr> TabAtkins: it looks like this should be appropriate to apply to things in the top level as well, do you have an opinion?
<flackr> fantasai: makes sense, as a separate PR
<flackr> TabAtkins: agree, still need to pull out to a separate thing
<flackr> s/top-level/top layer
<astearns> ack dbaron
<flackr> dbaron: anything weird with blocks doing things differently in block axis vs inline axis that would mix things up with grid or flex on the root?
<flackr> fantasai: it all seems to behave as expected, percentages resolve against ICB if ICB is definite
<fantasai> s/if/since/
<flackr> astearns: assume there should be some wpt tests
<flackr> fantasai: yes, tests not there yet
<flackr> astearns: add tests-needed once we accept
<flackr> astearns: any other comments?
<flackr> RESOLVED: Merge this PR
<flackr> fantasai: do we want to make float compute to none?
<flackr> astearns: is there an issue?
<flackr> fantasai: no, in various discussions related to PR
<flackr> astearns: ikilpatrick is not on call but believe his opinion was that it should not compute to none
<flackr> astearns: I believe it's only gecko that does?
<flackr> fantasai: yes, and one or two of the print impls
<dbaron> I remember there being spec text about this at some point...
<flackr> smfr: webkit does not (according to issue)
<flackr> astearns: let's merge this and later on decide whether to do something special for floats