Remove <style scoped> #552

domenic · 2016-01-24T05:33:03Z

<style scoped> has not been getting implementer interest. Would Firefox be OK with removing it? @smaug----, thoughts?

It seems shadow DOM and stylesheets restricted to a shadow tree ends up solving more of the real-world problems developers are faced with, although the two features don't work the same and it's certainly possible to conceive of use cases better served by style scoped.

I think that if nothing else, we should set a deadline for removal, similar to MediaController.

Related bugs that could be resolved upon removal:

<link rel="stylesheet" scoped> would become unnecessary
Allow <link> in body would become uncontroversial since the main argument against it was that style scoped + import is better.

The text was updated successfully, but these errors were encountered:

smaug---- · 2016-01-24T14:17:20Z

I'm not the best person to answer to this, but I've heard several times how web devs seem to like the <style scope>, and were just annoyed that it is not implemented everywhere.

annevk · 2016-02-01T15:33:41Z

@smaug---- who else can answer this? Per https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c36 it seems developers would not want this.

smaug---- · 2016-02-01T18:17:25Z

Perhaps @heycam or @dbaron.

(I don't know how https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c36 explains why devs wouldn't want this. That seems to be about different case mostly. Not about scoped handling per se. And even the case where tertiary loads before secondary can be a very valid case - say in a view where each section are in the same row of a table and the size of cells is defined in some global style.)

Forcing people to use shadow DOM to achieve certain styling characteristic feels overkill.

But in general, I don't have strong feelings about styling related issues, at least partially because I don't know all the history behind various design decisions.

prlbr · 2016-02-02T21:37:49Z

As a developer I would appreciate scoped styles a lot. They would be a very welcome tool to me.

But I also think that it doesn't make sense to have features in the specification that most browser vendors don't intend to implement. Knowing their reasons for not including it would be interesting though.

This reverts 29cf39d and many follow-up refinement commits due to lack of implementer interest. Most of the use cases served by <style scoped> are better served by <style> elements inside a shadow root (although the features do work differently, in that shadow DOM enforces isolation from the cascade, whereas <style scoped> does not). Fixes #552.

dbaron · 2016-05-11T20:47:09Z

Is there an explanation for why this doesn't address the demand that it was created for? It's not clear to me why this was removed.

domenic · 2016-05-11T20:53:25Z

This isn't really an issue of there something being wrong with the feature. Rather, it's a feature with only one implementation, and no positive signals from any other vendors. As such, it's not part of the interoperable web platform, and not on track to become such, so it needs to be removed. It is similar to MediaController, the microdata API, and requestAutocomplete in that regard.

(requestAutocomplete had positive signals from Gecko I guess, but Chrome removed it, leaving Gecko as the only positive signal.)

Some other more general discussions at #209.

Its use cases also overlap with shadow DOM, although they are certainly different. (E.g., styles from outside are limited in how they can impact the shadow DOM, whereas outside styles can always reach inside an <article><style scoped>...</style>...</article>. Shadow DOM prevents both inward and outward leakage, whereas style scoped only prevents outward leakage.)

See whatwg/html#552.

wturnerharris · 2016-06-21T15:32:45Z

This is a shame. Retaining <style scoped> could be considered beneficial since I see <style> tags used within the <body> quite frequently. I believe it was always restricted to being in <head> only, so the introduction of the scoped attribute simply allowed these to be mixed within the DOM for presentational purposes. I see this quite frequently when attempting to serve device-specific sizes as background images. While this works with the image-set notation, the feature is only supported by webkit/blink engines, so Firefox/Gecko and Edge/IE are left in the cold.

igabesz · 2016-06-21T21:44:03Z

Note that the necessity of this feature is further decreased by nesting available in SASS and LESS. It's not the same but it covers the common use-cases:

.div-that-would-containt-scoped-styles {
  /* quasi-nested styles */
  .some-div { color: red; }
}

Which is compiled to the following CSS:

.div-that-would-containt-scoped-styles .some-div { color: red; }

As a dev I was also looking forward for this feature, too bad it seems we won't get it.

prlbr · 2016-06-21T23:31:40Z

Note that the necessity of this feature is further decreased by nesting available in SASS and LESS.

SASS and LESS demonstrate the usefulness and interest in this feature. But there are many unrelated reasons why CSS-preprocessors are not used in many (and likely the majority) of cases where CSS is used. So I’d say that SASS and LESS stress the necessity of this feature, not that they would decrease it.

But what can we do about it, if only Firefox’s rendering engine implemented it? For Google/blink, it's too complex for the time being, Microsoft doesn't plan to implement it for whatever reason and I don't know about WebKit’s position.

igabesz · 2016-06-22T01:25:06Z

@prlbr The preprocessor usage can be debatable (just googled some stats), nevermind, I agree that it would have been a useful and strong feature.

EDITED ehh, I found the same forum as you

neil-h · 2016-07-13T18:23:36Z

A use case in favor of style scoped. I implement quiz questions in a LMS. I need to be able to keep certain styles consistent, even if the LMS is moved to a new theme in 5 years. Further, we want people to be able to create questions, but not to be able to change the LMS theme.

I would imagine many organizations using CMSs would have people who need to style things they input, without having access to the overall CSS. If it's a one-time thing, it's much easier to insert scoped CSS in place with the HTML, than to have an admin upload custom styles, and (hopefully) remove them when they're no longer needed.

tabatkins · 2016-07-13T18:37:23Z

Use custom elements and that works just as well, if not better - it means that changing styles on the outside won't accidentally fiddle with something inside your quiz component.

(Basically every use-case for scoped styles is only paying attention to the local case and so only valuing the outbound protection scoped styles brings, when they're actually better served by the two-way protection you get from web components.)

neil-h · 2016-07-13T19:21:44Z

I don't believe web components work in production as yet, outside of Chrome, or using an external framework, such as polymer.

Honestly, it isn't the scoped functionality itself, so much as the ability to place a style element in the body. Designers have been doing that for years, as often it's the only option they have (other than inline styles for miles).

The scoped attribute has been added because "then it's valid", with the understanding that it would be supported in future. My concern is that, if the style tag within the body is not somehow standardized, in 5 years browsers may drop support, as Facebook, Google, etc. don't use this, rather it's individuals who are working in a constrained CMS environment.

tabatkins · 2016-07-13T19:24:46Z

I don't believe web components work in production as yet, outside of Chrome, or using an external framework, such as polymer.

Scoped styles don't work outside of Firefox. Worse, no other browsers are planning to support scoped styles, while every browser is in the process of implementing web components.

My concern is that, if the style tag within the body is not somehow standardized, in 5 years browsers may drop support, as Facebook, Google, etc. don't use this, rather it's individuals who are working in a constrained CMS environment.

<style> in <body> is just a conformance error. It's required to be supported, and every browser does and will do so forever.

prlbr · 2016-07-13T22:56:13Z

(Basically every use-case for scoped styles is only paying attention to the local case and so only valuing the outbound protection scoped styles brings, when they're actually better served by the two-way protection you get from web components.)

My use case needs outbound and only outbound protection.

I'm a developer of a server-side light-weight markup language to html converter. It supports importing documents into other documents, useful e.g. for adding a navigational area that is used on multiple pages. Typically, you do not want the imported document to change the styles of the main document, but you want the main document to be able to change the styles of the imported document, for example when that particular page uses a different color scheme.

I don't need the complexity that the original scoped styles draft may have had, though. Some CSS syntactic sugar would be very helpful already, as described in w3c/csswg-drafts#270 (comment).

prlbr · 2016-07-14T00:16:22Z

Besides, nobody who can't or doesn't want to rely on JavaScript for their styles to work is served better by shadow DOM's two-way protection, as shadow DOM requires JavaScript as far as I know.

ionas · 2016-07-14T10:41:38Z

It seems shadow DOM and stylesheets restricted to a shadow tree ends up solving more of the real-world problems developers are faced with, although the two features don't work the same and it's certainly possible to conceive of use cases better served by style scoped.

This is simply not true. It is a different set of problems. Not everything you want to encapsulate in terms of style declarations needs to be a web component. Its an overlapping feature not something where one is better than the other.

That being said the majority of DOM and CSS affected by the missing feature of namespaces/modules/scopes (and not the limited 'scoped' keyword only) has nothing to do with "components" but "regular web pages". Please try to think about the hundreds of thousands of web developers that face issues with CSS leakage every day.

domenic · 2016-07-14T16:17:21Z

You don't have to create a "component" of any sort to use shadow DOM and the resulting style encapsulation.

htstudios · 2016-07-14T19:09:59Z

@domenic I'll try to figure out how. Until then if you have a small demo that supports:

no upwards leaks,
no downwars leaks,
explicit reusage of a nlock of declarations (extending)
All done without JS

I am nothing but excited!

Also remove existing test for <style scoped>. See whatwg/html#552

zcorpan · 2016-09-12T12:34:06Z

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1291515

hax · 2016-09-22T21:50:51Z

I understand the decision is unchangeable, but I still want to express my disappointment. We developers never have chance to experiment scoped style feature broadly, and we are forced to use inline styles, css in js, css modules... which all ugly and ruin css IMO.

It's a shame that Chrome reject to support a feature just because uncertain performance excuse. In fact, many developers use polyfill or just add ID selector manually to restrict the rules. There is NO WAY a native support of scoped styles would be slower than such polyfills.

The "Priority of Constituencies" in https://www.w3.org/TR/html-design-principles/ said "consider users over authors over implementors over specifiers over theoretical purity." Unfortunately the real world is one or two browser vendors decide which feature will survive.

smaug---- · 2016-09-22T22:14:01Z

My guess is that we will re-evaluate this once all the browsers support shadow DOM, since the styling there requires something similar, and makes no sense to require use of shadow DOM to achieve that.
But from implementation point of view I can understand that someone might want to implement similar stuff first only to shadow DOM.

chenzx · 2016-09-28T16:52:16Z

scoped brings nested dealings, which brings C++ recursive calls, which is not as performant as flat style iterating, IMO.

but on the other side, module is good, though not applied to CSS, must figure out a way to do so.

ianthedev · 2016-12-08T02:06:06Z

IMHO, do introduce a feature as long as it can noticeably benefit web development; do not hesitate on introducing it because of the inability or uninterest of a certain browsers.

I don't currently see how scoped <style> can noticeably benefit web development though.

josh · 2016-12-12T20:26:09Z

Shadow DOM definitely seems better than Scoped Styles, but having a declarative tag was pretty useful. What if we brought that ability to create Shadow DOM roots?

https://discourse.wicg.io/t/declarative-shadow-dom/1904

inoas · 2016-12-12T20:40:44Z

@josh A declarative way that does not require JS, that sounds very good! Does mode="open" mean it inherits from the outside (allows leaking in)?

Question

Now one could use @import within <style></style> but how could you reference part of one css-ressource to be used that has been (or will be) before/after in the header or footer of the body?

Reason

It should be in general possible to either have one css resource at the top (above the fold) and one at the bottom (below the fold) to be loaded, each time one combined and minified file - it seems that HTTP2 will address this.

The set of properties to be applied to the (then declarative) Shadow-DOM, should be fetched from one of those two requests/files.

Question # 2

Does HTTP2 solve this by actively pushing the Shadow-DOM css-ressources (via @import) that the client will require?
If the answer is yes, what about the state of adoption of HTTP2 (will take a look myself)?

Edit: @domenic In reply to https://discourse.wicg.io/t/declarative-shadow-dom/1904 - Simply said, I would love a solution without a JavaScript dependency on the client. I have been there and it was called Netscape Navigator 4.0 and it loaded CSS only if JS was enabled.

Question # 3 (Edit 2)

Could it be possible to combine a declarative Shadow DOM with HTTP2 Push to enable components of css/js/assets to be pushed over the wire in one request and without any client javascript requirement whatsoever?, e.g.

<shadow-root mode="open">
  <link href="/push/component-x.css" rel="preload" as="stylesheet"/>
  <!-- above will be pushed as part of the HTTP2 request if available or as a single request via loadCSS if HTTP/1.1 -->
  <button class="btn">Red Button</button>
</shadow-root>

piotr-cz · 2017-02-20T20:46:54Z

This would be really helpful for drop-in frontend libraries that utilize own UI.
It's real hard to keep consistent look as host stylesheets force styling on anything that that's in the DOM.

DanMan · 2017-04-29T23:43:15Z

This would have been really useful on sites where users can customize a website through CSS themselves, because the scope could have prevented them from screwing up things they shouldn't have customized in the 1st place. Example: styling of sub-reddits.

But I guess this could be achieved by prefixing every CSS rule with an additional selector by a pre-processor.

nektro · 2017-05-25T08:47:59Z

I see a lot of the comments on this bringing up that 1) only one browser supports the feature, and 2) custom elements solves a lot of the same problem with shadow dom, etc. I would definitely use scoped styles and its sad to see this feature dropped.

With that said, is there any word on when v1 of CE or SD will be supported in more than just chrome?

workguy66 · 2017-05-25T09:25:28Z

I think shadow dom is not the way to go, way too complicated of a solution for something that should be simple.

…

On 25 May 2017 at 10:48, Sean D ***@***.***> wrote: I see a lot of the comments on this bringing up that 1) only one browser supports the feature, and 2) custom elements solves a lot of the same problem with shadow dom With that said, is there any word on when v1 of CE or SD will be supported in more than just chrome? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#552 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMN7xov7Y_90K8c4lBO-ik40J9D7XuxHks5r9UBEgaJpZM4HLE_F> .

ianthedev · 2017-05-25T09:47:07Z

In my humble opinion, this "scoped style" is not a good idea because it requires user to add the tags into specific locations in HTML code and requires users to remove the tags from HTML code when they no longer need those styles.

CSS approaches should not require users to modify HTML code too often like that.

inoas · 2017-05-25T11:11:35Z

Shadow dom is much too complicated.

A declarative html/css only approach that stops leaks TO the surrounding context and optionally stops leaking FROM the surrounding context is what IMHO the whole web community is waiting for years now.

nektro · 2017-05-25T16:41:36Z

Being able to scope a <style> to only affecting its neighbors and their children, is not only great for debugging a whole block of code, but it would also make inlined <style>s a lot more viable.

heycam · 2017-06-20T02:56:37Z

We plan to unship support for <style scoped> in Firefox soon.

shellbryson · 2017-07-14T10:42:51Z

A shame. I just finished FE development of a componentized site delivered via Drupal. Most of the images were CSS defined. Being able to <style> per component was essential in giving the content owners the flexibility to upload images for breakpoints and colors. We scoped the styles using component IDs, which avoided the issue of style-bleeding described by others. It'd be "nice" if the project validated too.

Scoped style was removed from WHATWG HTML. See whatwg/html#552.

btopro · 2017-11-09T18:59:57Z

A polyfill I found if anyone needs this capability back in the platform https://github.com/thomaspark/scoper

A few years down the road and the quote from above "Forcing people to use shadow DOM to achieve certain styling characteristic feels overkill." is ringing true for me right now when this would have fixed an issue immediately :)

inoas · 2017-11-09T21:51:44Z

Shadow DOM would be okay if there was a declarative way to do so without Javascript being a requirement to render scoped CSS.

ilovecomputers · 2018-02-09T09:18:10Z

I too want to voice my disapproval for removing scoped style tags from the spec.

Even with the shadow DOM, while we prevented styles from leaking out, we also prevented user styles from cascading in. There's been proposals to style inside the shadow DOM, but it leaves the discretion of what can be styled to the element author.

<style scoped> was the only web spec that allowed authors to prevent their components from leaking out styles onto the user, but still allow the user to style a custom component within their page.

As an aside, one form of styles do pierce the shadow DOM and that is inherited styles (color, font, etc.) unless the component author adds a :host { all:initial; }. That is even more hostile to the user; bringing in a custom element that's in an illegible font that cannot be changed. With <style scoped> that font could be changed and that custom element won't change the font on matching selectors outside of itself.

zlamma · 2018-02-09T23:34:00Z

That is even more hostile to the user

@ilovecomputers - I concur. I would even add that it's against the open, inclusive, sharing-friendly spirit of all other WWW standards that brought us the web we have today.

Consider:

JavaScript - interpreted (so source is available), malleable, runtime patchable, extendable without asking for agreement of the author🤗
HTML - intelligible, easy to understand, open data format, which allows to take any existent text/page and publish a improvement/mashup/extension without asking for agreement of the author🤗
URI - allows to link to any information, including proprietary, without asking for agreement of the author🤗
RDF - allows to create open databases where everyone can make statements about any information, even in proprietary databases without asking for agreement of the author🤗
CSS - styling format extensible throughout, where, even when reusing a great amount of document content, it's 'more specific trumps general' cascading rules allow you to mashup/extend/improve the original appearance with minimal code without asking for agreement of the author🤗
Shadow DOM - a feature that allows to create restrictions that nullify the openness of CSS, that prevent you from being able to easily change the appearance of an element you haven't wrote
😲❓
That's right. If you want to change an appearance of an existent content behind a Shadow DOM, you either need to learn about new mechanisms (CSS Variables which, interestingly, suffers the original problem that encapsulation was trying to solve - variables are global) and ask the author to 'allow you to change the appearance' (he might also need to learn it), or fork your own version, if the component is a self-hostable npm package (but for a truly 'information-sharing-friendly', I'm much more concerned about those shared directly).

I would like to argue that the fact that your own code is easily able to modify content pre-authored by someone else's is a feature, not a bug. I'd like to point out that it existed since the dawn of the web, and people somehow coped. Perhaps it's because the assumption that "when it happens it's unintentional" is simply much more often untrue than true. Or perhaps it's because when it was truly unintentional, the original CSS features allow user to easily fix the 'intent clash' by adding more specificity to his rules.

I'm not saying that there isn't a place for Shadow DOM on the web, but I would argue that it does not cater for the common web user, but rather for interest of commercial institutions. I like to be skeptical about Google's will to dominate, but from where I'm standing, it's no wonder why Chrome removed an already implemented feature while it's Polymer foundation heavily preached that the worst evil is 'styles leaking in' and advertising Shadow DOM as the savior, not mentioning scoped CSS in materials that justify its introduction.

sideshowbarker · 2018-02-10T00:18:56Z

In the interest of avoiding others deciding this issue is a good place for off-topic comments like #552 (comment), I’ve locked the issue for now.

domenic added the removal/deprecation Removing or deprecating a feature label Jan 24, 2016

prlbr mentioned this issue Apr 22, 2016

Support scoped attribute on style element w3c/svgwg#118

Closed

domenic mentioned this issue May 10, 2016

Remove <style scoped> #1226

Merged

annevk closed this as completed in #1226 May 11, 2016

zcorpan added a commit to zcorpan/caniuse that referenced this issue May 14, 2016

<style scoped> was removed from WHATWG HTML

f40b809

See whatwg/html#552.

zcorpan mentioned this issue May 14, 2016

<style scoped> was removed from WHATWG HTML Fyrd/caniuse#2512

Merged

prlbr mentioned this issue May 26, 2016

[css-scoping] scoped attribute on style element removed from HTML w3c/csswg-drafts#137

Closed

Ms2ger pushed a commit to web-platform-tests/wpt that referenced this issue Sep 9, 2016

Test that <style scoped> is not supported (#3685); r=Ms2ger

575ecfe

Also remove existing test for <style scoped>. See whatwg/html#552

jakearchibald mentioned this issue Oct 3, 2016

Proposal: Calling stylesheets contextually w3c/html#603

Closed

xfq mentioned this issue Oct 23, 2016

[css-cascade] Remove scoped styles w3c/csswg-drafts#637

Closed

skishore mentioned this issue Nov 15, 2016

Animation doesn't start on Firefox skishore/makemeahanzi#13

Closed

inoas mentioned this issue Dec 21, 2016

[css-scoping] Support for CSS namespaces w3c/csswg-drafts#270

Open

geoffmcl mentioned this issue Jun 3, 2017

Tidy does not move <style>-Tag to head htacg/tidy-html5#567

Closed

bangseongbeom mentioned this issue Aug 6, 2017

[selectors] Remove scoped <style> element w3c/csswg-drafts#1699

Merged

tabatkins pushed a commit to w3c/csswg-drafts that referenced this issue Aug 7, 2017

[selectors] Remove scoped <style> element (#1699)

235175f

Scoped style was removed from WHATWG HTML. See whatwg/html#552.

whatwg locked and limited conversation to collaborators Feb 10, 2018

Remove <style scoped> #552

Remove <style scoped> #552

Comments

domenic commented Jan 24, 2016

smaug---- commented Jan 24, 2016

annevk commented Feb 1, 2016

smaug---- commented Feb 1, 2016

prlbr commented Feb 2, 2016

dbaron commented May 11, 2016

domenic commented May 11, 2016 • edited Loading

wturnerharris commented Jun 21, 2016

igabesz commented Jun 21, 2016 • edited Loading

prlbr commented Jun 21, 2016

igabesz commented Jun 22, 2016 • edited Loading

neil-h commented Jul 13, 2016

tabatkins commented Jul 13, 2016

neil-h commented Jul 13, 2016

tabatkins commented Jul 13, 2016

prlbr commented Jul 13, 2016 • edited Loading

prlbr commented Jul 14, 2016

ionas commented Jul 14, 2016

domenic commented Jul 14, 2016

htstudios commented Jul 14, 2016

zcorpan commented Sep 12, 2016

hax commented Sep 22, 2016

smaug---- commented Sep 22, 2016 • edited Loading

chenzx commented Sep 28, 2016

ianthedev commented Dec 8, 2016 • edited Loading

josh commented Dec 12, 2016 • edited Loading

inoas commented Dec 12, 2016 • edited Loading

Question

Reason

Question # 2

Question # 3 (Edit 2)

piotr-cz commented Feb 20, 2017

DanMan commented Apr 29, 2017 • edited Loading

nektro commented May 25, 2017 • edited Loading

workguy66 commented May 25, 2017 via email

ianthedev commented May 25, 2017 • edited Loading

inoas commented May 25, 2017 • edited Loading

nektro commented May 25, 2017

heycam commented Jun 20, 2017

shellbryson commented Jul 14, 2017 • edited Loading

btopro commented Nov 9, 2017

inoas commented Nov 9, 2017

ilovecomputers commented Feb 9, 2018

zlamma commented Feb 9, 2018 • edited Loading

sideshowbarker commented Feb 10, 2018

domenic commented May 11, 2016 •

edited

Loading

igabesz commented Jun 21, 2016 •

edited

Loading

igabesz commented Jun 22, 2016 •

edited

Loading

prlbr commented Jul 13, 2016 •

edited

Loading

smaug---- commented Sep 22, 2016 •

edited

Loading

ianthedev commented Dec 8, 2016 •

edited

Loading

josh commented Dec 12, 2016 •

edited

Loading

inoas commented Dec 12, 2016 •

edited

Loading

DanMan commented Apr 29, 2017 •

edited

Loading

nektro commented May 25, 2017 •

edited

Loading

ianthedev commented May 25, 2017 •

edited

Loading

inoas commented May 25, 2017 •

edited

Loading

shellbryson commented Jul 14, 2017 •

edited

Loading

zlamma commented Feb 9, 2018 •

edited

Loading