Repository navigation
[css-display] Becoming a formatting context without display types #1563
Description
Becoming a formatting context is defined as follows:
If the element already establishes a formatting context of any kind, this condition is satisfied. Otherwise, it is made to establish a BFC by changing its inner display type to flow-root.
But what happens if an element that does not have inner nor outer display types (i.e. it has display: none or display: contents) becomes a formatting context? Such an element won't establish a formatting context, so its inner display type should be changed to flow-root, but it doesn't have an inner display type!
I think "this condition is satisfied" should also apply in that case.
Activity
SelenIT commentedon Jun 26, 2017
I suppose that becoming a formatting context implies creating a box. Maybe it's better to add a Note to the definition of these display values that they never establish a formatting context?
But it's an interesting case what happens if an element with
display:contentsgetscontain:layoutor some other property that usually causes an element to establish a FC. Should that property be ignored at all, should it apply to anonymous wrapper box, or something else should happen?frivoal commentedon Jun 26, 2017
https://drafts.csswg.org/css-contain/#containment-layout :
In other word, "becoming a formatting context" is not invoked by the contain property on
display: contentselements. So from the point of view of that spec at least, it does not matter what the definition of "becoming a formatting context" is for that case.Loirooriol commentedon Jun 26, 2017
And the same for
column-span, which only applies to in-flow block-level elements.But the definition of "becoming a formatting context" should not rely on not being invoked with
display: noneordisplay: contents.frivoal commentedon Jun 27, 2017
Sure. I am just saying that form the point of view of these specs, it doesn't matter what we define it to be.
tabatkins commentedon Jul 11, 2017
Boxes generate formatting contexts, not elements. I've at least patched that section of the "becoming a formatting context" definition.
The question is thus moot -
noneorcontentsprevents the element from generating a box at all, so there's no box to create a formatting context in the first place.Loirooriol commentedon Jul 11, 2017
Well, before 71cfe56, it were elements what could "become a formatting context". Changing it to boxes fixes this issue, but now "becoming a formatting context" is not well-defined, because boxes don't have display types (#1480). If you plan "become a formatting context" to affect computed
display, it needs to happen on the element, otherwise there could be nodisplayvalue which generates the resulting boxes.tabatkins commentedon Jul 11, 2017
Yes, the section as a whole needs to be rewritten - it's currently marked for discussion at the F2F next month.