[css-contain] Clarify style containment effect 1

[Loirooriol]

I don't understand what the first effect of style containment is supposed to do.

The following properties must have no effect on descendants of the element:

• break-* (and the related aliases)
• bookmark-*
• string-set

For starters, the definitions of bookmark-* and string-set don't make sense (see #1830 and #1829). In fact I think the whole CSS Content spec should be marked as "Not ready for implementation" or something until it is rewritten. So I don't think these properties should be mentioned in CSS Contain, which is a CR.

So let's focus on break-*. I don't understand the effect. Does it mean that break-* properties in selectors that match descendants do not have any effect? Or that break-* property values on the contained element don't affect descendants? For example, from unforced breaks,

if all of them are auto and a common ancestor of all the elements has a break-inside value of avoid, then breaking here is not allowed.

If this ancestor is the contained element, does it mean that break-inside: avoid has no effect, is treated as auto, and thus a break between its descendants is allowed?

If so please clarify the sentence to something like

The following properties, when set on the contained element or one of its ancestors, must have no effect on descendants of the element

But then I'm not much sure about how this is different from scoped properties described in effect 2.

[css-meeting-bot]

The Working Group just discussed clarify style containment.

The full IRC log of that discussion

<fantasai> topic: clarify style containment
<fantasai> Github: https://github.com//issues/1872
<fantasai> TabAtkins: question is, why does style containment restrict break properties?
<fantasai> TabAtkins: Reason why I have these things set is I want to ignore a style tree for style computation purposes
<fantasai> TabAtkins: Should be able to completely ignore that subtree
<fantasai> TabAtkins: break property if allowed to work would violate that
<fantasai> TabAtkins: break properties propagate up
<fantasai> fantasai: They don't affect computation tho
<fantasai> TabAtkins: but they affect layout further up the tree
<fantasai> fantasai: break-inside doesn't propagate up, only forced breaks do
<fantasai> fantasai: Also sounds pretty bad in terms of fragmentation if you can't honor 'break-before: avoid'
<fantasai> TabAtkins: Avoiding breaks should work, yeah...
<fantasai> fantasai: ...
<fantasai> florian: Since contain property is ahead of css-content, should put the bookmark-* / string-set prose into the css-content spec
<fantasai> dbaron: I'm trying to understnand model of possible optimizations here
<fantasai> dbaron: I don't see anything for which this is relevant
<fantasai> dbaron: Still doesn't feel like style containment tome
<fantasai> fantasai: Also if disallowing break-*, then why not margin-*?
<fantasai> dbaron: It seems like you're trying to introduce soemething but not really worked out what
<fantasai> dbaron: Maybe write out what that optimization is to make that clear
<fantasai> dbaron: and discuss others
<fantasai> fantasai: also pretty sure if break-* needs to be disallowed the margin-* collapsing should also... but that sounds more like layout containment

[frivoal]

I've made the editorial changes based on the previous discussion (move some effects of style containement from css-contain to css-content, clarify that break-* means break-after and break-before, not break-inside), but we still need to resolve whether or not style containment affects break-before and break-after.

Based on the discussion minitued above, I think a good case has been made that it should not, and that we should remove that from the spec, but @tabatkins seemed to think that maybe it should.

Agenda+ to sort this out. @tabatkins if you have not changed your mind, please have some arguments ready.

[frivoal]

(also adding "needs testcase" label to track the need for writing a test about break-inside not being affected, as that was previously ambigious).

[css-meeting-bot]

The Working Group just discussed [css-contain] Clarify style containment effect 1, and agreed to the following resolutions:

• RESOLVED: have the break properties not effected by style containment

The full IRC log of that discussion

<dael> Topic: [css-contain] Clarify style containment effect 1
<dael> github: https://github.com//issues/1872
<dael> florian: There's a thing called style containment with 2 groups of effect. #2 isn't under discussion, that's fine. What's under discussion is how style containment shouldshouldn't effect break-before and break-after.
<dael> florian: A number of people said effecting made no sence. TabAtkins wasn't sure. TabAtkins are you now sure?
<dael> TabAtkins: I think we can remove it.
<dael> astearns: Proposal is to have the break properties not effected by style containment?
<dael> florian: Or drop the part that claims they are.
<dael> astearns: Obj?
<dael> RESOLVED: have the break properties not effected by style containment
<liam> regrets+ Liam
<dael> florian: Part 2 talks about flow-from and flow-into. I think that should be moved to regions spec given relative maturity.
<dael> astearns: I think that's fine. Can you open an issue on regions to add that?
<dael> florian: I can open a PR that changes both specs?
<dael> astearns: Even better.