New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
emilio opened this Issue Nov 2, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@emilio
Copy link
Collaborator

emilio commented Nov 2, 2018

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

This comment has been minimized.

Copy link
Collaborator

emilio commented Nov 2, 2018

cc @dholbert

@emilio

This comment has been minimized.

Copy link
Collaborator

emilio commented Nov 2, 2018

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

cc @frivoal as well.

@emilio emilio changed the title [css-contain] contain: style is not useful. [css-contain] contain: style does not seem useful. Nov 2, 2018

@emilio emilio removed the css-content-3 label Nov 26, 2018

@frivoal frivoal self-assigned this Dec 1, 2018

@ewilligers

This comment has been minimized.

Copy link
Contributor

ewilligers commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Collaborator

emilio commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Member

tabatkins commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Collaborator

emilio commented Jan 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment