html
html copied to clipboard
whatwg
Reinstate <style scoped>
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.
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.
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?
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.
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.)
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.
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?
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 :(.
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
(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.)
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).
Some WebKit folks who might have an opinion or relevant expertise: @rniwa @smfr @litherum @hober
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?
@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.
Note that there are problems that are still unsolved with Shadow DOM and that
<style scoped>needs a solution for too (@font-faceand 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.
@emilio https://github.com/w3c/csswg-drafts/issues/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?
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.
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!
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.
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.)
@myfonj Nesting in inline styles is very much planned, but technically harder to implement so we deferred it for later.
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.
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.
With CSS
@scopebeing 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.
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?
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.
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
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 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.