[css-contain] contain: style does not seem useful.

[emilio]

This is about https://drafts.csswg.org/css-contain/#containment-style.

I wonder what's the use-case for this. In particular, the following optimization that the spec describes:

Whenever a property is changed on a descendant of the containing element, calculating what part of the DOM tree is "dirtied" and might need to have its style recalculated can stop at the containing element.

Is just not true, since you need to compute the style of ancestors in order to inherit from them.

It's also hard to envision any kind of style-recalc optimization, since any style change may make that element become or stop-being style-contained, and you need to handle stuff like contain: inherit.

Given:

• contain: style is broken on Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=855798
• The complexity of implementing it correctly in Firefox is high.
• There's no potential optimization to be had out of this (if only, you could optimize counter updates, but that benefit is IMO overruled by the complexity of "unscoping" the counters when contain: style stops applying dynamically, and the fact that counters are uncommon).

I wonder what's the point of implementing it.

[emilio]

cc @dholbert

[emilio]

In particular, by definition, optimizing style recalc based on a CSS property value is just impossible.

cc @frivoal as well.

[mrego]

Note that in Chromium there are several bugs related to contain: style:

• https://bugs.chromium.org/p/chromium/issues/detail?id=855798 (already linked by @emilio)
• https://bugs.chromium.org/p/chromium/issues/detail?id=869296
• https://bugs.chromium.org/p/chromium/issues/detail?id=882383
• https://bugs.chromium.org/p/chromium/issues/detail?id=882385

[ewilligers]

My understanding was that the motivation was counters.

In particular, the following optimization that the spec describes:

Whenever a property is changed on a descendant of the containing element, calculating what part of the DOM tree is "dirtied" and might need to have its style recalculated can stop at the containing element.

Is just not true, since you need to compute the style of ancestors in order to inherit from them.

The spec is not talking about computing the style of ancestors.

Assume the ancestor has contain: style. If a descendant is added or removed, or has a style change to introduce or remove a counter increment, you don't need to update counters in the ancestor's subsequent siblings (or any element outside the ancestor subtree).

[emilio]

The spec is not talking about computing the style of ancestors.

Well, that's what I read given "might need to have its style recalculated can stop at the containing element". If it's not talking about style recalc then it should not mention style recalc and should be reworded.

In any case I understand that the only feasible optimization here is counter updates (see the first comment where I mention "if only, you could optimize counter updates"). I just don't think I agree adding a feature like this is useful if this is the only optimization you can get out of it. Are counters in general (and dynamically inserted counter increments / resets in particular) used enough / enough of a bottleneck to justify the complexity of this? My guess is not.

[tabatkins]

While counters are the primary use-case here, any further features we develop where one property defines a (global) name and another property references it will benefit similarly.

contain: style isn't necessarily meant as a perf win, but as an understandability win when composing things, as you don't have to worry about colliding values. If you style-isolate your component, you can increment counters freely within it, safe in the knowledge that you won't accidentally increment a counter from the outside document, or even create a counter scope that'll be visible in siblings.

Is just not true, since you need to compute the style of ancestors in order to inherit from them.

The text you quoted is explicitly talking about dirty-bit propagation, not a more generic "there's no style connection between the inside and outside". As far as I can tell, this objection is thus invalid?

[emilio]

The text you quoted is explicitly talking about dirty-bit propagation, not a more generic "there's no style connection between the inside and outside". As far as I can tell, this objection is thus invalid?

I'm not sure which dirty-bit propagation you're talking about, can you elaborate? But when something in the DOM changes you may need to flag ancestors / siblings for recalc (due to :empty / :nth-child / etc).

[css-meeting-bot]

The CSS Working Group just discussed contain: style doesn't seem very suseful, and agreed to the following:

• RESOLVED: remove style containment from keywords that aren't 'style'
• RESOLVED: mark 'style' at risk
• RESOLVED: Republish CR of css-contain once edits are in

The full IRC log of that discussion

<fantasai> Topic: contain: style doesn't seem very suseful
<fantasai> s/suseful/useful/
<fantasai> emilio: Very confused what use case contain: style is supposed to solve.
<astearns> github: https://github.com//issues/3280
<fantasai> emilio: It's hard to implement. Very broken in the only implementation that's shipping.
<fantasai> emilio: I can't see any potential advantage except *maybe* update counters faster in the page?
<futhark> q+
<fantasai> emilio: But that's usually not a perf issue.
<fantasai> TabAtkins: My answer in the issue was that the 'contain' properties in general are to help isolate parts of your document
<fantasai> TabAtkins: perf wins are a benefit, esp layout
<fantasai> TabAtkins: But also helps you isolate parts of your document to make it easier to think about
<fantasai> TabAtkins: It covered the remaining thing that would leak out of a component
<fantasai> TabAtkins: Was a completion exercise in making an isolated component
<fantasai> emilio: Did we decide how counters work in CSS? Are they off DOM tree or flat treee?
<fantasai> TabAtkins: CSS works on flat tree as its "element tree"
<fantasai> TabAtkins: So counters are defined to work on flat tree
<fantasai> TabAtkins:...
<fantasai> emilio: Tests?
<fantasai> TabAtkins: Had some in past, lost them. before wpt
<fantasai> TabAtkins: Might pick up again when working on Lists
<fantasai> dbaron: Counters are part of generated content, thus box tree
<fantasai> TabAtkins: Mental model is that everything is elements, then we turn things into boxes, then we turn things into fragments
<heycam> fantasai: if we had counters working on the not flat tree, then I don't know that list numbering would make much sense, if part of your component was reordering items in a list
<heycam> ... so I think they do need to work on the flat tree
<astearns> q?
<fantasai> TabAtkins: If you take an ol, give it a shadow tree, rearrange items, numbering should reflect final display, not original ol.
<fantasai> fantasai: Right.
<fantasai> futhark: I agree with emilio that there is not much to do with optimization for contain: style
<Rossen> ack futhark
<fantasai> futhark: One useful thing would be if we said that inheritance doesn't happen from 'contain: style' down
<dbaron> At the time we implemented ::before and ::after as part of the box tree, the specs were still pushing towards allowing multiple CSS presentations of a single document.
<fantasai> futhark: Then we can optimize for ?
<fantasai> futhark: If 'contain: style' meant that 'all: initial', then we could optimize getComputedStyle
<fantasai> futhark: Then it wouldn't rely on layout (???)
<fantasai> futhark: Then can do display locking
<fantasai> emilio: ...
<fantasai> TabAtkins: Contain property doesn't block things going into the subtree. It blocks things leaking out.
<fantasai> florian: It's the contain property, not the isolate property
<Rossen> q?
<fantasai> TabAtkins: If it ends up being that we don't want to impelment 'contain: style ' across browsers, we can drop it. It just, it's part of my vision for what 'contain' was about. Last piece necessary to create a seal around the subtree
<fantasai> TabAtkins: There's a bunch of parts of CSS where we have global names etc.
<fantasai> TabAtkins: Maybe we just rely on shadow DOM.
<fantasai> florian: Wanted to ask rego's pov , since he fixed a lot of bugs on 'contain: style'
<fantasai> emilio: It's very broken to the point that 'contain: style' toggling doesn't do anything dynamically
<rego> there are a few bugs https://github.com//issues/3280#issuecomment-452580469
<fantasai> emilio: Implementing it in Gecko is really hard, and I'd rather not ship something that's broekn.
<fantasai> emilio: My ask is drop it.
<fantasai> Rossen^: So what's your ask, Emilio?
<fantasai> Rossen: So proposal here is to drop 'contain: style' from css-contain
<fantasai> AmeliaBR: Is there any reason this couldn't be added back later, if it turns out to be useful?
<fantasai> florian: Yes and no. It's easy to add stuff. But there's 'contain: strict' which is all of the contains. If we add a new one, then it woudldn't just be an addition but a change.
<fantasai> florian: So we'd have to add a new keyword for all of the contains that includes the new type of containment
<fantasai> chrishtr: If property changes on an element on 'contain: style', and we don't have 'contain: style', is it possible to dirty something else?
<fantasai> TabAtkins: counters and quote property
<fantasai> emilio: The computed style doesn't change.
<fantasai> emilio: The counter values are not stored in computed styles
<fantasai> chrishtr: Does contain: layout say that counters...?
<fantasai> emilio: Style is a bit of misnomer
<fantasai> chrishtr: Regardless of name, need to have this functionality to have complete perf
<fantasai> emilio: My point is that changing counters is not something that is typically a perf bottleneck. Not like changing height, which has lots of effects throughout the doc
<fantasai> emilio: Not soemthing I've seen in a perf profile at all
<fantasai> chrishtr: But if you want to do things like async rendering or display locking
<fantasai> chrishtr: you'd need this, just in case the content changed a counter
<futhark> q+
<fantasai> chrishtr: Whether it should be its own thing, idk
<fantasai> emilio: It's not something that happens frequently. It can have a layout effect across the page.
<fantasai> chrishtr: But unless you lock it, has an effect
<fantasai> emilio: It's same as changing content property
<fantasai> florian: But that doesn't affect outside the element
<fantasai> emilio: ... counters reset can change stuff across document
<fantasai> chrishtr: Point of containment is that you can reason about the relationship of work between stuff in the contained subtree fvs rest of document
<fantasai> chrishtr: It's small but a real footgun?
<fantasai> emilio: That's fair, but we still don't have a great model for counters
<fantasai> emilio: Makes it seem like counters work in the style tree.
<fantasai> emilio: Which isn't true
<fantasai> emilio: We need tests for like shadow DOM, need tests for display: contents, for all these edge cases which change how counters are affected by style containment
<fantasai> chrishtr: Agree we need tests
<fantasai> emilio: and a proper spec
<fantasai> dbaron: We had an interim agreement to add 'counter-set'
<fantasai> dbaron: we never added
<fantasai> TabAtkins: it's in a spec, it's in Lists
<fantasai> TabAtkins: just never past WD
<fantasai> emilio: ... spec, not in implementations
<fantasai> emilio: Even in Blink, renumbering lists
<fantasai> emilio: If element is display: contents; contain: strict; if you add a list item inside of it?
<fantasai> emilio: You have a <ol><div style="contain: strict"><li></div></ol>
<fantasai> emilio: Right now if you change the div's display, it is buggy
<fantasai> TabAtkins: Our entire counters implementation has issues
<fantasai> eae: Spec is correct, but our impl is incorrect
<fantasai> emilio: Given state of impls, implementing 'contain: style' is not worth it
<fantasai> TabAtkins: Fact that built-in lists might be magical is a separate issues
<fantasai> emilio: If lists are magical, then we have another leak
<fantasai> dbaron: We have a patch to Gecko to use counters for lists, so might fix that
<fantasai> chrishtr: Sounds like all the browsers are sad, and I think we agree that there is a real footgun even if a small one
<fantasai> chrishtr: So I think we should add proper tests and fix things to not be sad
<fantasai> chrishtr: Then if that's the case, come back to you about this.
<fantasai> dholbert: Sounds like use case is lazily rendering the subtree
<fantasai> dholbert: If counters and quotes are the only things that would have an effect, maybe implementations can just add checks for those properties
<fantasai> dholbert: They're quite rarely used
<fantasai> dholbert: Might be easier to just disable perf optimizations in cases where they're used rather than implementing 'contain: style'
<gregwhitworth> q+
<astearns> ack futhark
<fantasai> futhark: I think Chris you had some thoughts... I'm confused about isolation vs containment
<Rossen> ack futhark
<fantasai> futhark: For perf, you probably want isolation
<fantasai> futhark: If you modify DOM outside something that's contaiend
<fantasai> futhark: It can affect sibling selectors that affect the contained subtree
<fantasai> emilio: Which can set 'contain'
<fantasai> TabAtkins: Nothing about contain is about isoaltion
<fantasai> TabAtkins: You can't have layout isolation
<fantasai> TabAtkins: You can't use percentage or auto or anything. It has to be 100% manually-specified or nothing.
<fantasai> TabAtkins: You have a subree that you can ignore when changes happen inside it. That's the use case we're designing for
<fantasai> chrishtr: Points about % sizing and isolation vs something else is a complicated subject, and the more you go twards one end the more you lose use cases or perf
<fantasai> chrishtr: needs investigation
<fantasai> chrishtr: Not only is 'contain: style' poorly implemented, the other contain modes while implemented corretly don't actually improve perf
<florian> q+
<gregwhitworth> ack me
<fantasai> emilio: Even though containment is designed to ignore a subtree, you can still have e.g. :empty { contain: strict } and that div's contained but you insert a child in that div, and you are no longer contained
<fantasai> emilio: contain can be dependent on DOM content sof an element
<fantasai> emilio: There are sleectors already that depend on contents of the element
<fantasai> chrishtr: ...
<fantasai> TabAtkins: You cannot have selectors that depend on style
<fantasai> TabAtkins: Filing an issue won't solve it.
<fantasai> TabAtkins: We can't do that.
<Rossen> q?
<xfq> q- fr, fl
<Rossen> ack all the florians
<fantasai> florian: Mentioned about testing and things, at the moment we have reasonably extensive testing of normal counters
<fantasai> florian: If lists are fake counters, that's not tested separately
<fantasai> florian: I couldn't find tests for shadow DOM and display: contents
<fantasai> florian: BUt for normal counters, should be well-covered
<Rossen> q?
<fantasai> TabAtkins: Given large number of inconsistencies in lists from when I was testing them awhile back....
<fantasai> florian: Checking for what ti's supposed to do to counters.
<fantasai> florian: If you toggle contain on/off, we don't have tests for that.
<fantasai> florian: But effect of contain on counters, we do have tests
<fantasai> TabAtkins: Thanks for test suites
<fantasai> florian: Thank gtalbot
<fantasai> Rossen: Hearing pushback from Mozilla
<fantasai> Rossen: Not hearing much from other vendors
<fantasai> Rossen: What do we want to do next?
<fantasai> fantasai: Rename it, obviously.
<fantasai> Rossen: Or we can drop it
<fantasai> emilio: Can we drop contain: style and if we decide it's a thing we want
<fantasai> TabAtkins: Drop style now, figure it out later, decide what to do about 'strict' and whether to make it stricter or add a stricter value?
<fantasai> fantasai: Might be able to slip it in, because unlikely to be dependent on leaking counters/quotes
<fantasai> TabAtkins: Quotes definitely rare. Unsure about counters.
<fantasai> emilio: ...
<fantasai> Rossen: We could try dropping style now, and see if counters surface as a prominent use case, then deal with it
<fantasai> TabAtkins: What do you think, Chris
<fantasai> chrishtr: Drop it from the spec, but leave it implemented in one browser?
<fantasai> TabAtkins: No, that'd be a spec violation
<fantasai> gregwhitworth: It's implemented and shipping in a browser, but it doesn't work
<fantasai> TabAtkins: It does for real counters, if you have no dynamic changes
<fantasai> hober: It's up to them what they ship in the browser.
<fantasai> Rossen: So would there be an objection to dropping 'contain: style'?
<hober> s/in the browser/in their browser. It's up to us what we have in the spec./
<fantasai> emilio: My point for dropping it now is that it's the same kind of risky change to change Blink's lists to use real counters as it would be to drop 'style' / implement later
<fantasai> emilio: The case of having 'contain: style' that spans across a list
<fantasai> emilio: or counters inside a 'contain: style' subtree
<fantasai> emilio: Until Lists work that way, you're going to break something
<fantasai> TabAtkins: If our counter impl is already broken and weird, so it probably doesn't matter if we leave the code in?
<fantasai> chrishtr: What would likely happen is that we wouldn't remove the feature, we'd fix it
<fantasai> chrishtr: I'd rather fix it in Chrome and work through the spec issues than drop it
<fantasai> chrishtr: What we do with the spec in teh meantime
<fantasai> eae: It's something we really want to do in Blink, and we do realize that the current state of thing where e.g. Lists don't work that way
<fantasai> eae: So it might make sense to drop it for now
<fantasai> florian: If we drop now and add back later gets us to strict + stricter
<fantasai> florian: I'm not bikeshedding the stricter
<fantasai> emilio: We also want to ship containment
<fantasai> emilio: But we really don't want to implement 'contain: style' under the current state of affairs
<fantasai> emilio: Given it needs more work in specs and implsmentations
<TabAtkins> q+
<fantasai> emilio: It would make sense not to block shipping containment on 'contain: style'
<fantasai> chrishtr: Was there a compat issue?
<fantasai> emilio: No, but we don't want to willfully violate the spec.
<fantasai> emilio: We don't want to parse a value and then not implement it
<fantasai> (That is in fact a violation of the CSS spec)
<fantasai> TabAtkins: Is it just about built-in lists or all counters/
<fantasai> emilio: It's generally hard to implement in our counters implementation
<xfq> ack Tab
<fantasai> TabAtkins: I'm wondering how difficult it is from doing a counter-reset on all possible counters?
<fantasai> dbaron: I think in our counters implementation, the right thing to do is just create a new counter-manager for an element that has 'contain: style'
<fantasai> dbaron: And then it's reasonable
<fantasai> emilio: And then dynamic changes, you'd have to reframe
<fantasai> dbaron: You'd have to reframe anywya
<fantasai> TabAtkins: You can make it as slow as you want to change 'contain'. It's not a use case to flip it dynamically.
<fantasai> florian: Unless I missed something, counters have a definition problem. CSS 'contain: style' doesn't.
<fantasai> florian: There's a dependency, but I think implementation and spec being wrong is an overstatement
<fantasai> TabAtkins: Lists spec having bugs is adequate to say there's a spec problem.
<fantasai> florian: My point is, if there's a problem with the contain spec there needs to be an issue so I can fix it. But there isn't.
<fantasai> TabAtkins: ...
<fantasai> emilio: What would be the best way for Mozilla to ship contain: layout
<fantasai> florian: Could just not ship strict yet, then ...
<fantasai> TabAtkins: People are reasonably encouraged to turn on strict, so technically the right way to do it, but don't think it's good advice
<fantasai> q+
<rego> neither contain:strict neither contain:content (as both include style)
<xfq> ack fantasai
<heycam> fantasai: I think the right way to go is to ship everything except the style value itself
<heycam> ... and then at some future point, incorporate that into strict
<heycam> ... in the majority of cases it's not going to have an effect, so I don't think it's something to be too worried about
<fantasai> emilio: it would be nice if Blink didn't parse 'style' either, and we could do that change together later
<fantasai> florian: When you say don't do style, did you also mean change tehavior of strict later when we add it?
<heycam> fantasai: yeah, we will eventually change the behavior
<fantasai> fantasai: Yes
<fantasai> chrishtr: You said it's not so easy to implement contain: style
<fantasai> chrishtr: How hard is it?
<fantasai> emilio: How hard is it?
<fantasai> chrishtr: Couple months of work?
<fantasai> emilio: It's work, that somebody needs to do
<fantasai> TabAtkins: Given taht I do have a direction for naming in the future
<fantasai> TabAtkins: I'm OK with dropping style for now
<fantasai> TabAtkins: Dropping from definition of strict, dropping as a value
<fantasai> TabAtkins: And then we add 'all' later, that does all 4
<fantasai> TabAtkins: Do that once our implementation is good enough to be meaningful for style
<fantasai> TabAtkins: And Mozilla can also fix
<fantasai> emilio: And add a bunch of tests :)
<fantasai> chrishtr: So what you're suggesting is to refactor spec so that easier to incrementally add in the future
<fantasai> TabAtkins: Right, drop 'style' and add it back in a future level of the spec
<fantasai> chrishtr: What if we do the other things you mention and leave style?
<fantasai> TabAtkins: Drop style containiment from strict and content?
<fantasai> dholbert: That would make us reject 'contain: style' but...
<fantasai> chrishtr: CSS parsers can ignroe keywords they don't understand?
<fantasai> florian: If you as an author writes 'contain: style size" it'll be lost
<Rossen> q?
<fantasai> florian: but if you write 'contain: size; contain: style size' then you just lose the second declaration keep the first
<fantasai> TabAtkins: Most of the time we recommend strict anyway
<fantasai> florian: Seems like least harmful way to do this
<fantasai> chrishtr: And then we'll fix our bugs and allow ppl to opt in
<fantasai> Rossen: Any objections?
<fantasai> RESOLVED: remove style containment from keywords that aren't 'style'
<fantasai> RESOLVED: mark 'style' at risk
<fantasai> RESOLVED: Republish CR of css-contain once edits are in
<fantasai> chris: Ping me when you have a DoC and file a transition request