Reinstate <style scoped>

[wolfbeast]

I've read through the discussion in #552 and I'd like to ask that you reconsider your stance on removing this from the spec. There are many use cases for scoped styles that allow pure-HTML+CSS solutions in favor of a much more restrictive Shadow DOM and/or Web Components approach, let alone the involved complexity for web authors dealing with SD.

The only reason I see that this was scrapped from the spec was because Google refused to do the work and implement it, with nothing more than some vague excuses while playing favorites for SD. Considering Edge -> Chromium is now a thing, it's basically removing a good feature in the standard because of one implementer not wanting to implement it. The general responses on #552 also clearly voted against it -- this is the kind of feedback you should be listening to because those (people actually reading discussions on github for spec changes) are the people actively working with your specs.
Of note is that these approaches are not mutually exclusive or one being better than the other -- Different use cases would call for different approaches. They have overlap, there was also talk of revisiting this kind of styling question because there is a clear need for scoped styles on the web (and in the wild) that are currently using polyfills and workarounds to achieve, while we already had a proper solution for this in <style scoped>.

FTR: Our projects building on UXP intend to keep this implementation despite it being scrapped from the spec, considering it is, in our opinion, a mistake that it was removed to begin with.

The need for this feature has not changed or diminished since 2016. Please consider undoing this mistake in the spec and reinstated scoped styling.

[domenic]

Hi @wolfbeast, thanks for your interest. You'll want to familiarize yourself with https://whatwg.org/working-mode, and in particular https://whatwg.org/working-mode#additions. In particular, adding things to the spec does not magically make them appear in browsers; we are dependent on implementer interest to advance additions. We remove things from the spec when there are not two implementers supporting them, which was the case with scoped styles.

We can leave this open as a "needs implementer interest" feature request, but I just want to be clear that the editors don't consider this feature of our process a "mistake", and we can't "undo" it without violating our working mode.

[domenic]

Unfortunately this thread is no longer on topic for the whatwg/html repository. If people would like to discuss the WHATWG working mode, then whatwg/sg is the right place to do so; that is where our policies are maintained and set.

I'll mark the above comments as off-topic, but if folks continue to discuss things other than adding a new scoped styles feature, I'll have to lock this thread :(.

[wolfbeast]

I'll re-post what is relevant but what was marked off-topic.

It's not something new that's added to the spec. it's asking for reinstatement of something that was there before, and was removed despite interest of web authors.

Currently zero of three browser engines have such plans.

Correction: that would be one of four (ours, Goanna*). I've also asked Mozilla to re-evaluate this for Gecko/Stylo. Bug 1542645 - Implement <style scoped> (again)

(In case you are not yet familiar with it, Goanna is a Gecko fork at the basis of UXP which is a multi-application platform for XUL-based applications. Yes, it is a hard fork with its own development and implementations, not a "near-Gecko" variant.)

[othermaciej]

Proponents of <style scoped> are also welcome to ask Blink to reconsider or to get WebKit's input (which I don't think was solicited originally, in part because the removal happened before the current Working Mode).

[mattatobin]

Not a bad idea, I suppose. Any idea how to proceed on that front like specific contacts?

[othermaciej]

Some WebKit folks who might have an opinion or relevant expertise: @rniwa @smfr @litherum @hober

[rniwa]

One of the issues <style scoped> had was its vague definition. It wasn't quite at the rigor of modern CSS/HTML specifications. Now that CSS Scoping has done the leg work to define all the necessary semantics, it's possible we can define this feature back with more rigor in its semantics. I think someone interested in this feature reinstated has to put the effort to re-define the feature in terms of new concepts in CSS scoping. Perhaps someone from Mozilla would be interested in that? @dbaron @emilio?

[emilio]

@heycam is who implemented it originally, maybe he has more input. I don't think I'd personally have time right now to spend in writing a spec for <style scoped>. Note that there are problems that are still unsolved with Shadow DOM and that <style scoped> needs a solution for too (@font-face and such come to mind).

In general, I don't think the feature is terribly hard to spec. I'm a bit concerned about implementation complexity (a big part of the reasons we removed it is that we were rewriting the style engine, and re-implementing <style scoped> was pretty hard). I've left a few comments in https://bugzilla.mozilla.org/show_bug.cgi?id=1542645 about some particularities I thought of while thinking through it. As I said I don't think any of those are necessarily deal breakers, but it does mean it's a bunch more effort to implement efficiently.

[rniwa]

Note that there are problems that are still unsolved with Shadow DOM and that <style scoped> needs a solution for too (@font-face and such come to mind).

Yeah, it seems like we should first fix all those scoping issues before re-introducing <style scoped>. It's kind of irresponsible to keep introducing half-baked stuff into the platform.

[tabatkins]

@emilio w3c/csswg-drafts#1995 is the issue tracking this problem for CSS references. Ryosuke recently commented again on it, and I just responded; would you mind putting an eye on it as well?

[gnat]

This project is living in the future: https://github.com/gnat/css-scope-inline

Keep the syntax simple and short, friends. I want to see <style scoped> return too, but let's try our best to cut down the excess verbosity.

[wolfbeast]

As an implementation note: While we've worked on keeping a lot of parity with other browsers and removing dropped specs, we've made it a point of exception to retain <style scoped> in our Goanna layout engine. It simply being there if web devs want to make use of it and not being in the way otherwise, it's remained an active feature for us all this time (we currently support both WebComponents/shadow DOM and the <style scoped> approaches, showing that it's definitely a possibility). It seems WebComponents is severely over-complicating scoped styling for web devs to achieve a very similar thing; many web devs as a result are using unintelligible/generated unique class identifiers or iframes as a result to not have to deal with it.

I think we should aim to keep things straightforward for web content for a feature that has a ton of obvious utility for the web.

@gnat: Interesting polyfill; creative workaround for sure!

[bramus]

With CSS @scope being a thing nowadays, I think we can technically do this?

<style scoped> would imply that its contents is wrapped inside a prelude-less @scope, meaning these two snippets would be equivalent:

<wrapper>
  <style>
    @scope {
      :scope {
        color: green;
      }
    }
  </style>
  <p>I am green!</p>
</wrapper>

<wrapper>
  <style scoped>
    :scope {
      color: green;
    }
  </style>
  <p>I am green!</p>
</wrapper>

/ping @mirisuzanne since we chatted about this.

[myfonj]

Related plug from CSS WG: simple & nesting in inline HTML style attribute (w3c/csswg-drafts#8752) would/will give us powerful and very similar tool, possibly. Basically it redefines current &-less HTML style="…" value to be implicitly nested like style="&{…}". So such basic example should work, without changing much extra:

<wrapper style="
  & > p:first-child {
    color: green;
  }
  & > p:last-child {
    color: red;
  }
">
  <p>I am green!</p>
  <p>I am red!</p>
</wrapper>

At this point is unclear to me whether "scope-escaping" constructs like & ~ * or even *:has(&) will be allowed. (I hope they will.)

[LeaVerou]

@myfonj Nesting in inline styles is very much planned, but technically harder to implement so we deferred it for later.

[mattatobin]

I think part of the point of scoped styling being wanted where more sophisticated WebComponents could be used may simply be to some is like ordering a raid 10 NAS when all you need is a flash drive. The other bit is the nested style tag keeps the markup tidy where inline style attrs of any complexity are a mess (and that draft cited above would make that worse by normalizing it)

While this may not be much of a consideration with high level frameworks and the vast and diverse landscape of javascript libs that make them up.. It is when you are just well.. making a website or writing the software to make a website and need some one off styling that is more than a one liner.

I still believe the best solution is to have <style scoped> as Mozilla implemented it and just make it incompatible with WebComponents ie CustomElements or ShadowDOM would just.. Ignore or strip it out if it touched it.

I dunno, maybe thinking about it like that will offer some insight.

[ExE-Boss]

The issue with <style scoped> is that legacy user agents will treat it the same way as a non‑scoped <style> element and apply its styles globally, just like how legacy user agents treat <script nomodule> the same as <script>, which is why the nomodule attribute was used to signal to modern browsers to ignore it when modules are supported.

[mirisuzanne]

Right, authors can decide when they're ready to switch, but it's possible to polyfill (and hide from legacy browsers) using the @scope syntax.

[bkardell]

With CSS @scope being a thing nowadays, I think we can technically do this?

Yeah, I'd like to suggest that we should probably close this as "done". It isn't done in exactly the same way, but better.

[kizu]

Random thought/idea: I wonder if we could bring the type attribute in play in some way for this?

<style type="scoped">
    :scope { … }
</style>

Instead of using an attribute, use a new type(at first I thought about something like text/css/scoped, but I'm not sure there is any need to complicate this?), which will render the styles inside invalid for the browsers that do not understand implicit scopes (granted they will support this way of defining them).

Right now, the type is not really used for <style>, and the guaranteed invalidity for legacy browsers could be a good fit for a feature like this?

[bramus]

Yeah, I'd like to suggest that we should probably close this as "done". It isn't done in exactly the same way, but better.

Not suggesting to close things here, but suggesting to add <style scoped> it after all.

That way things like frameworks/CMSes can simply output the custom CSS in the <style> element without needing to alter its contents. With the attribute, it’s easily to toggle scoped styles on or off as well.

[wolfbeast]

The issue with <style scoped> is that legacy user agents will treat it the same way as a non‑scoped <style> element

The issue isn't legacy user agents at this point, the issue is that most of the current user agents have dropped it and treat it as such at the moment. That is, however, no different of a situation where new features are being introduced all the time.

User agents can treat <style scoped> as something to ignore if they don't (yet) want to support it, without actually breaking the overall page style, instead of only ignoring the scoped keyword like is being done currently and applying it globally, i.e. ignore the entire tag that isn't currently supported instead of transforming it into a global element -- that would provide an easy transition to a re-implementation, offer webmasters the option to use it without fear of breakage, and allow a good path forward to offering both ways of scoping CSS for different use-cases (framework or non-).

Not suggesting to close things here, but suggesting to add <style scoped> it after all.
That way things like frameworks/CMSes can simply output the custom CSS in the <style> element without needing to alter its contents.

I fully agree with this. Frameworks/CMSes have the option to spit out whichever CSS is necessary or desired based on browser detection (a common practice), and reintroducing it in the original implementation would also allow light-weight/scriptless and non-framework use of scoped styling without having to deal with completely over-engineered shadow-DOM solutions that are very difficult to implement properly for simple style separations in a page (and regularly don't even provide exactly what a web designer wants).

[mattatobin]

@wolfbeast I do not believe you will win arguments or prove your point by calling web components "over-engineered" when you produce a XUL/XBL application platform and browser. Kinda stretches credibility ;)

---

Unless something significant changes I will just add one more thing for now: HTML Templates were rolled into WebComponents even though they kind of predate them or at least was considered separate originally. Cramming complex style rules into a tag's style attr is just messy as much as a super long JSON structure in an attr is. <style scoped> should be re-instated into the spec for its ease of use and code aesthetics as well as to compliment html templates as a lightweight alternative to full-on webcomponents.

What I believe makes WebComponents seemingly daunting is it isn't just one concept like most of html has been but several packaged together as a single huge game changing concept. Even though I am slightly familiar with Mozilla XBL, picking up WebComponents concepts at least at this early stage I am at has not been a walk in the park.

This is a source of frustration my esteemed former colleague is letting slip through and others including my self feel because not everyone is the reach for whatever the popular framework is for everything type.

Like I said, that's all I have really left to say on the matter unless there is a significant change.

[wolfbeast]

@mattatobin What projects and technologies I am otherwise involved in is completely irrelevant to the discussion here. The over-engineered nature of WebComponents is self-evident.