Open Bug 1542645 Opened 2 years ago Updated 6 months ago

Implement <style scoped> (again)

Categories

(Core :: CSS Parsing and Computation, enhancement, P5)

55 Branch
enhancement

Tracking

()

People

(Reporter: mark, Unassigned)

References

Details

This feature has many practical use cases and was dropped in Firefox 55. It was also dropped from the spec because there was no real interest from the Google corner to implement this. [1]
The discussion in [1] clearly indicated many voices against removal from the web author corner of the web, but it was dropped (while there was no real strong opinion either way according to the meeting's minutes) because of lack of implementer interest.

While I understand it may need some extra work for stylo, having scoped styles that do NOT require Shadow DOM or Web Components (and JS) is a very efficient way for web authors to handle styling of separate components of their sites - especially for web applications this would be greatly beneficial.
If I understood correctly, the idea was also to revisit this scoped styling feature later on because of its desire from the web authors out there. I can speak for many web authors when I say that interest for this feature is in no way less than it was in 2016, and many sites/frameworks currently use workarounds to achieve the same (e.g. by preprocessing CSS to get nested scopes using classes or using JS polyfills). While these workarounds work, I sincerely doubt that they are either performant or efficient. Having an HTML level scoping mechanism for styles would simplify doing this for many involved parties.

I've opened a new issue on against the HTML spec[2] but it was made clear to me that it requires implementer interest of at least two parties to get it reinstated in the spec. I'm hoping I've got a willing ear here and that you will support my proposal to have it added back to the spec.

[1] https://github.com/whatwg/html/issues/552
[2] https://github.com/whatwg/html/issues/4508

Honestly it's not only "some extra work". It's probably code that is both invasive / complex, and affecting other performance-critical code.

Not sure how much incentive to implement we have when both Apple and Google don't have any other interest in implementing this. In practice if they remain with the same position re. <style scoped> this will only become a maintenance burden to us.

Also, the CSSWG needs to define how stuff like @font-face, @keyframes and such interacts with the feature (arguably Shadow DOM has the same problem though).

Type: defect → enhancement
No longer regressed by: 1291515
See Also: → 1291515
Summary: Reinstate <style scoped> for content documents. → Implement <style scoped> (again)

Thanks for listening and not dismissing out of hand.

I'd gather that interactions with and implementation through Shadow DOM is going to be (even) more complex than this html element based scoping (although I admit I don't know how Stylo works, internally). If there are things not yet clear regarding scoped styling in the CSSWG in terms of interaction of certain keywords then it would be great to get that in the clear, of course, since this question will come up either way -- but in the meantime, things could be adopted the way they were pre-stylo; that certainly worked in practice.

As for support from Apple/Google, perhaps pinging the correct people about this (again), considering this is still very much a desired feature by web authors, might get some implementer support. I just hope Google won't be as stubborn this time around - they are already pushing the envelope pretty hard to make specs conform to (their) implementation instead of the other way around.

If you are considering this, then please indicate your support for/interest in the proposal in the WhatWG issue linked above so they are aware of your implementer interest.

I'd gather that interactions with and implementation through Shadow DOM is going to be (even) more complex than this html element based scoping (although I admit I don't know how Stylo works, internally).

This is not true. ShadowRoots have a few nice properties which <style scoped> doesn't, which we rely on:

  • A shadow root cannot stop being a shadow root dynamically or vice versa. And the fact that an element is a shadow host only affects descendants, not siblings.
  • Elements inside a Shadow Root only receive rules from one containing shadow root, not arbitrarily many.

That is not to say that <style scoped> couldn't be implemented efficiently, but there's some complexity associated with it.

but in the meantime, things could be adopted the way they were pre-stylo; that certainly worked in practice.

The way styling works pre-and-post stylo is completely different. The way those interact... Sure, we could certainly make them work the same way the work with Shadow DOM today.

Implementation-wise, by the time we did stylo we didn't have all the Shadow DOM stuff, so at least some stuff could be borrowed from that. Still it would be pretty much a complete re-implementation of <style scoped>.

If you are considering this, then please indicate your support for/interest in the proposal in the WhatWG issue linked above so they are aware of your implementer interest.

I don't think that's my call to make. The official way to get an official Mozilla position on a standards topic is filing an issue in https://github.com/mozilla/standards-positions. I can certainly provide feedback, but probably I'm not the only one who should.

Oh, another very nasty complexity is how to invalidate style properly. A class change would need to look at all descendant style scopes, which is something I wouldn't want to do. An example is:

<div id="outer">
  <div id="scope">
    <style scoped>
      .foo span { color: green }
    </style>
    <span>Some text</span>
  </div>
</div>

That means that in order to find <span> when a class change in #outer changes we need to do a tree walk in order to find the styles that affect the <span>.

This is the same reason we and Apple have opposed similar Shadow DOM proposals, see https://github.com/w3c/csswg-drafts/issues/1914.

The way styling works pre-and-post stylo is completely different. ...
Still it would be pretty much a complete re-implementation of <style scoped>.

I understand - however that kind of work is to be expected if you decide to completely re-implement the way styling works, for any style. If I read this correctly, also, part of this work is already done that can be drawn on. Since both approaches (HTML vs SD) have different use cases and complement each other from a web authoring perspective, I don't see that any strong objections should be made against it.

The official way to get an official Mozilla position on a standards topic is filing an issue
in https://github.com/mozilla/standards-positions. I can certainly provide feedback, but probably
I'm not the only one who should.

So who should be making this entry then? I'm not entirely sure if I have either the necessary background or position/contacts to make a sufficiently coherent request there, but if you insist I can do my best.
A lot of the discussion around this topic (and significant feedback before the issue was closed to public commentary, preventing others from indicating their input in the matter and/or voting on point made) is in the discussion on issue https://github.com/whatwg/html/issues/552 and most of that still applies now. I'd like to avoid a chicken and egg stalemate where WhatWG isn't considering the proposal because there's "insufficient implementer interest", and Mozilla isn't taking a standards position because it's not in the standards at the moment.

That means that in order to find <span> when a class change in #outer changes we need to do a
tree walk in order to find the styles that affect the <span>.
This is the same reason we and Apple have opposed similar Shadow DOM proposals

Then it would be reasonable to change the spec addition to explicitly not inherit class changes from outside of scope, if walking the tree would be too costly for the real world (I personally doubt that). Those details can always be worked out later with the relevant workgroups and implementers, though.

Priority: -- → P5

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Not sure how much incentive to implement we have when both Apple and Google don't have any other interest in implementing this. In practice if they remain with the same position re. <style scoped> this will only become a maintenance burden to us.

For the record, Apple has never said we're not interested in implementing this. At the time of removal, we were not consulted. (I don't know what our style experts would think, it is possible that on closer scrutiny they'd also be concerned about the implementation complexity.)

You need to log in before you can comment on or make changes to this bug.