Re: [csswg-drafts] [css-contain] Becoming a formatting context

So, this issue has two problems tangled in:
1. Should layout containment and paint containment apply to non-atomic inline-level boxes (`inline ruby`, `inline flow`,  `run-in flow`, and `run-in ruby`), and if so, how?
2. Should we have an anchor term (so far: **becomes a formatting context root**, could be something else) that defines which formatting context elements establish when they're told they have to establish one?

    2.1. If yes to 2 does that work by altering the computed value of the `display` property (in a way that involves `flow-root` / `ruby-root`, as suggested in @Loirooriol 's tables)

I believe that fantasai's position is:
1. No: there are no identified use cases
2. No: it's clear enough already by just saying "must establish a formatting context"

My latest position is:
1. No: there are no identified use cases
2. Yes: we're re-defining this in an ad-hoc manner in a number of places, and that this has caused confusion (here) and spec bugs (multicol in #1071, or an [older version of css-overflow](https://github.com/w3c/csswg-drafts/blob/c17c4bb04629e2bb48edda76ccff99f72f14db9e/css-overflow-3/Overview.bs#L397), both accidentally turning flex containers, grid containers, or tables into BFCs). 

    2.1. No: at least not at computed value time, as that is not compatible with existing uses. 

If we take fantasai's approach, I should:
* Drop the **becomes a formatting context root**
* state that layout and paint containment have no effects on non-atomic inline-level boxes (`inline ruby`, `inline flow` and `inline run-in`)
* state that layout and paint containment cause block containers to establish a BFC (with no effect on the computed value of the display property) (and the other type of things it applies to already establish an FC of some kind, so there's no need to say more)

If we take my approach, I should:
* Rename and rewrite the **becomes a FC root** section to something like this, to be included in css-display (probably at the end of https://drafts.csswg.org/css-display-3/#formatting-context):
  > Specifications may call for an element or box to <dfn export>establish a formatting context</dfn> without further precision as to the type of formatting context or how to do so.
  > This operation is not applicable to non-atomic inline-level boxes nor to boxes with a layout-internal display-type. Specifications that invoke this must either exclude such boxes, or to blockify them first.
  > If the box is a block container that does not establish a BFC, it is made to establish a BFC. Otherwise, the box already establishes a formatting context, and this operation is a no-op.
  >
  > Note: This has no effect on the computed value of the `display` property, and does not change `flow` to `flow-root`.
  >
  > Note: If a specification defines a new type of box which are neither non atomic inline level, layout-internal, block containers, or some other display type that establishes a FC, then that specification must define the meaning of this operation for that type of box.
* state that layout and paint containment have no effects on non-atomic inline-level boxes (`inline ruby`, `inline flow` and `inline run-in`)
* Also use and link to that terminology:
  - in css-contain to in state that layout and paint containment cause the box they apply estblish a formatting context
  - in css-multicol for `column-span`
  - in css-overflow for `overflow`
  - in grid and flexbox for the definition of  grid items and flex items instead of "[...] establishes a new formatting context for its contents. The type of this formatting context is determined by its display value, as usual"

Agenda+F2F to hopefully resolve on either of these two proposals (I prefer mine but won't object to fantasai's).

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1457#issuecomment-379156461 using your GitHub account

Received on Friday, 6 April 2018 06:00:41 UTC