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

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Kyle Zentner]

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.

Comment 1

[Daniel Holbert [:dholbert]]

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"

Comment 2

[Tab Atkins Jr.]

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.)

Comment 3

[Daniel Holbert [:dholbert]]

(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.)

Comment 4

[Daniel Holbert [:dholbert]]

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.)

[0] https://lists.w3.org/Archives/Public/www-style/2015Jul/0462.html
[1] https://lists.w3.org/Archives/Public/www-style/2015Aug/0015.html
[2] https://lists.w3.org/Archives/Public/www-style/2015Aug/0016.html

Comment 5

[Daniel Holbert [:dholbert]]

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