Closed Bug 1179349 Opened 6 years ago Closed 2 years ago
CSS 'contain' behavior may not match CSS definition of formatting context
The CSS WG recently defined what a formatting context is. However, it is not clear from the specification precisely what happens to an element if it must become a formatting context. Currently, the behavior of 'contain: paint' and 'contain: layout' are possibly wrong in this regard, especially when applied to inline elements (which currently become block elements, but should probably become inline-block elements). This bug is for tracking if that has been specified, and if so what code may need to be updated.
This was discussed a bit in this www-style thread: https://lists.w3.org/Archives/Public/www-style/2015Jun/0114.html Kyle's initial patches on bug 1170781 & bug 1178895 use EnsureBlockDisplay (the "blockify" function), but I think that's more severe than what the spec actually wants. (Hence this bug.) Here's my current understanding of what FCify means, as far as the "display" value goes: * No change to block-level containers (display:[block|table|flex|grid]). * No change to "display:inline-XYZ". * Promote "display:inline" to "display:inline-block" * UNKNOWN for "display:ruby"/"display:ruby-XYZ" * UNKNOWN for "display:table-XYZ" * UNKNOWN for "display:list-item"
display:block will become a BFC, so it's not quite "no change". Yes, unknown how ruby will work. Need to discuss this with fantasai. table-* types will do nothing. list-item will just become a BFC. (The block and list-item behavior will fall out of the new Display spec stuff; FCify will force "flow" to become "flow-root". This also handles the inline->inline-block transform automatically.)
(In reply to Tab Atkins Jr. from comment #2) > display:block will become a BFC, so it's not quite "no change". (Yup -- I'm just focusing on what tweaks we need to perform on the computed "display" value. For display:block, it will remain "block" -- hence, no change to display value.) > table-* types will do nothing. (Per IRC discussion just now, "do nothing" here is just about the "must be a formatting context" requirement. The other contain:paint requirements -- clipping & being a CB for fixed/abspos descendants -- are still applicable.)
For the record, there was more discussion of this on a recent www-style thread, which resulted in me & Tab each leaning towards more aggressive "display"-value conversion than that discussed above. (Converting table parts to be "display:block", at least.)  https://lists.w3.org/Archives/Public/www-style/2015Jul/0462.html  https://lists.w3.org/Archives/Public/www-style/2015Aug/0015.html  https://lists.w3.org/Archives/Public/www-style/2015Aug/0016.html
OK, I think the spec & our impl have both evolved since this was filed, and we can close this out (as fixed by bug 1472919 mostly). In particular: - The containment spec now says that "contain:paint" and "contain:layout" have no effect on non-atomic inline-level frames, table parts, or ruby parts. (And our impl honors this.) That simplifies some of the complexity/uncertainty here. - For elements where these contain values *do* have an effect, the spec says they cause the element to establish "an independent formatting context"... https://drafts.csswg.org/css-contain/#containment-layout ...which is a term defined here: https://drafts.csswg.org/css-display-3/#formatting-context - It sounds like e.g. flex and grid formatting contexts are "independent" by definition. ("Unless otherwise specified, however, establishing a new formatting context creates an independent formatting context.") The non-independent case is for blocks (and probably table parts and similar where contain:paint/layout have no effect). And we handle blocks [making the BFC "independent"] via nsBlockFrame::Init() calling AddStateBits(NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS) if we're "contain:paint" or "contain:layout": https://searchfox.org/mozilla-central/rev/49e78df13e7a505827a3a86daae9efdf827133c6/layout/generic/nsBlockFrame.cpp#6725-6726
Status: NEW → RESOLVED
Closed: 2 years ago
Depends on: 1472919
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.