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.

[wolfbeast]

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.
I'm not asking you to violate your working mode, either. I'm asking you to recognize that there is a real, practical desire for this feature from web authors. I don't think refusal by one implementer to add this (Google in this case) should keep desired features from the spec. I do call it a "mistake" in that context that it was removed from the spec.
As for wanting interest from implementers: what exactly counts as an "implementer interest"? The number of applications wanting the feature?

[domenic]

As for wanting interest from implementers: what exactly counts as an "implementer interest"?

I'll refer you again to the working mode document I linked to earlier. (Note that web platform features are implemented by browser engines, if that's what you're asking.)

It would violate our working mode to add a feature to the spec (no matter whether it's previously been written in spec form or not) if there are not plans from two browser engines to implement it. Currently zero of three browser engines have such plans.

These rules are meant to ensure that the spec should reflect reality of what is usable in browsers, not wishful thinking about what contributors wish browsers would do on their behalf.

[wolfbeast]

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.

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

[wolfbeast]

Note about your working mode: your working mode is going to be increasingly unworkable as the number of browser engines diminishes and you would still require two browser engines to indicate interest. We're heading towards a monoculture here. Also, there have been more than a few occasions where something was added or changed in the spec to reflect what Chromium implemented, and other browsers only adopted or shown interest in adopting it after it was added to the spec. That did not meet your criterion of "at least two".
I doubt it would have been removed from the spec in the first place if it was Chromium implementing this as only implementer.

[Sa-Ja-Di]

In general the question is why bowing down to the dictatorship of one single developer and one single browser (Google/Chrome)?

Chrome/Chromium has in the meantime such a high market share and the people behind have more or less the decision power of what should and should not be standard or desirable - it should be evaluated if this is really the way today the web is going to go. Such things are highly questionable and not desirable at all - because if one single developer group - Google/Chromium - has the ultimate decision power... then there is clearly something more than wrong!

And if that alone would not be worse enough... Just compare it with years ago.. We had many different browsers with different feature sets and a wide variety of engines - even that has gone lost and all the feature diversity has been replaced by Google's design principles - how a browser should look and work - and adopted without questioning by Mozilla and Opera and now even by Microsoft!

How about doing the right thing and showing Google their correct place for once?

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

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