Html: 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?

[mattatobin]

Shouldn't the standards dictate what html, css, javascript, etc is supposed to be and clients respond with support or not at their discretion with all the consequences of that decision?

What I mean is a standard should be able to justify its own existance as what should be agreed on as a standard regardless of special intrests of one class of rendering engine or vendor.

How else can you foster natural growth of those standards without interference?

This is even more important now than in the previous decade because with exception of gecko and the smaller engines (goanna, apple webkit, pure khtml, and others) it is just going to be all flavors of chromium from the top vendors.

One rendering engine regardless of multiple vendor clients should not be given absolute or defacto veto power over standards like style scope.

The standards should be standards regardless and natural market forces can drive the implementation and conformity of those standards in vendor clients regardless of rendering engine (or flavor there of).

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