New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove <style scoped> #552

Closed
domenic opened this Issue Jan 24, 2016 · 55 comments

Comments

@domenic
Member

domenic commented Jan 24, 2016

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

@smaug----

This comment has been minimized.

Collaborator

smaug---- commented Jan 24, 2016

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

This comment has been minimized.

Member

annevk commented Feb 1, 2016

@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----

This comment has been minimized.

Collaborator

smaug---- commented Feb 1, 2016

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

This comment has been minimized.

prlbr commented Feb 2, 2016

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.

domenic added a commit that referenced this issue May 10, 2016

Remove <style scoped>
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.

domenic added a commit that referenced this issue May 10, 2016

Remove <style scoped>
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.

domenic added a commit that referenced this issue May 11, 2016

Remove <style scoped>
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.

@annevk annevk closed this in #1226 May 11, 2016

annevk added a commit that referenced this issue May 11, 2016

Remove <style scoped>
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

This comment has been minimized.

Member

dbaron commented May 11, 2016

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

This comment has been minimized.

Member

domenic commented May 11, 2016

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

@wturnerharris

This comment has been minimized.

wturnerharris commented Jun 21, 2016

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

This comment has been minimized.

igabesz commented Jun 21, 2016

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

This comment has been minimized.

prlbr commented Jun 21, 2016

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

This comment has been minimized.

igabesz commented Jun 22, 2016

@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

This comment has been minimized.

neil-h commented Jul 13, 2016

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

This comment has been minimized.

Collaborator

tabatkins commented Jul 13, 2016

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

This comment has been minimized.

neil-h commented Jul 13, 2016

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

This comment has been minimized.

Collaborator

tabatkins commented Jul 13, 2016

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

This comment has been minimized.

prlbr commented Jul 13, 2016

(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

This comment has been minimized.

prlbr commented Jul 14, 2016

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

This comment has been minimized.

ionas commented Jul 14, 2016

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

This comment has been minimized.

Member

domenic commented Jul 14, 2016

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

@htstudios

This comment has been minimized.

htstudios commented Jul 14, 2016

@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!

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

@zcorpan

This comment has been minimized.

Member

zcorpan commented Sep 12, 2016

@hax

This comment has been minimized.

Contributor

hax commented Sep 22, 2016

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

This comment has been minimized.

Collaborator

smaug---- commented Sep 22, 2016

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

This comment has been minimized.

chenzx commented Sep 28, 2016

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.

@Ian-Y

This comment has been minimized.

Ian-Y commented Dec 8, 2016

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

This comment has been minimized.

josh commented Dec 12, 2016

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

This comment has been minimized.

inoas commented Dec 12, 2016

@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

This comment has been minimized.

piotr-cz commented Feb 20, 2017

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

This comment has been minimized.

DanMan commented Apr 29, 2017

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

This comment has been minimized.

nektro commented May 25, 2017

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

This comment has been minimized.

workguy66 commented May 25, 2017

@Ian-Y

This comment has been minimized.

Ian-Y commented May 25, 2017

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

This comment has been minimized.

inoas commented May 25, 2017

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

This comment has been minimized.

nektro commented May 25, 2017

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

This comment has been minimized.

@shellbryson

This comment has been minimized.

shellbryson commented Jul 14, 2017

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.

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

[selectors] Remove scoped <style> element (#1699)
Scoped style was removed from WHATWG HTML. See whatwg/html#552.
@btopro

This comment has been minimized.

btopro commented Nov 9, 2017

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

This comment has been minimized.

inoas commented Nov 9, 2017

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

@ilovecomputers

This comment has been minimized.

ilovecomputers commented Feb 9, 2018

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

This comment has been minimized.

zlamma commented Feb 9, 2018

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.

@whatwg whatwg locked and limited conversation to collaborators Feb 10, 2018

@sideshowbarker

This comment has been minimized.

Member

sideshowbarker commented Feb 10, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.