Closed Bug 1179349 Opened 6 years ago Closed 2 years ago

CSS 'contain' behavior may not match CSS definition of formatting context.


(Core :: CSS Parsing and Computation, defect)

Not set



Tracking Status
firefox42 --- affected


(Reporter: zentner.kyle, Unassigned)




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:

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[0], which resulted in me[1] & Tab[2] each leaning towards more aggressive "display"-value conversion than that discussed above. (Converting table parts to be "display:block", at least.)

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"...
...which is a term defined here:

 - 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":
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.