Remove <style scoped> - Githubissues

domenic commented 8 years ago

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

smaug---- commented 8 years ago

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 commented 8 years ago

@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---- commented 8 years ago

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 commented 8 years ago

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.

dbaron commented 8 years ago

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 commented 8 years ago

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 https://github.com/whatwg/html/issues/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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

(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 https://github.com/w3c/csswg-drafts/issues/270#issuecomment-231999279.

prlbr commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

htstudios commented 8 years ago

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

workguy66 commented 8 years ago

Can't we just allow the <style> tag in the body?

As previously mentioned it's often the only way to achieve the necessary result and why should the only way be considered an error in the html? (Especially if it's supported in all browsers and works well)

That would satisfy the majority as you can hack through the scoped problem using classes. But obviously a working and supported scoped attribute would be very useful, but a bit niche (not like there's no other niche things in html).

annevk commented 8 years ago

@workguy66 could you file a new issue on that? I think that since we allow <link rel=stylesheet> in <body> these days you're probably correct that we should allow <style> too.

ionas commented 8 years ago

Browsers do it anyway @ style-tag. However I don't see how it solves with non-leaking style declarations and assignments of those blocks (modules, namespaces, etc).

workguy66 commented 8 years ago

@ionas yeah, I already mentioned that they do it anyway, I just think it makes sense to mark it as "valid" html.

workguy66 commented 8 years ago

@annevk will this work? https://github.com/whatwg/html/issues/1605

annevk commented 8 years ago

Yeah great, thanks!

upsuper commented 8 years ago

Given <style scoped> is similiar to what Shadow DOM would do, would any other implementor be willing to have <style scoped> done based on the support of Shadow DOM? It seems Gecko shares code between these two things, and thus I suppose having Shadow DOM might make scoped style easier to implement in other engines as well.

akyoto commented 8 years ago

Aero, the fastest node.js framework for making websites, heavily relies on style scoped for AJAX requested pages.

It's a shame I didn't even see this discussion until now. I can see why this specification causes problems but personally I would like to keep using the scoped attribute.

domenic commented 8 years ago

@blitzprog So Aero was a Firefox-only framework? You can personally keep using whatever you like, but the specification is not designed to just support single-browser web pages.

akyoto commented 8 years ago

@domenic Oh I misunderstood the issue. I thought this was about disallowing style tags in the body.

Aero is using style elements as a part of the AJAX response, they happen to be scoped. Up until now I didn't even realize Chrome doesn't restrict it to the div they're in.

Guess I never really used the scoped nature of it but disallowing style tags in the AJAX response or in the body is what I was worried about. As long as this continues to work I'm a happy man.

akyoto commented 8 years ago

Correct me if I'm wrong but I believe this is correct:

Situation before style scoped was invalid:

style tag in body was considered invalid HTML 5
style scoped tag in body makes it valid HTML 5

Situation after style scoped has been removed from the standard:

style in body is invalid HTML 5
style scoped in body is invalid HTML 5

I am getting lots of these messages recently, from the HTML 5 validator: html validation

I was wondering if we could somehow keep either style or style scoped tags in the body as valid HTML 5, without producing warnings.

Or introduce a new attribute à la style embedded that doesn't imply the scoped nature of its predecessor?

domenic commented 8 years ago

That's the topic of a separate issue, #1605.

It's good the validator caught these issues with your page though, since apparently you were using the scoped attribute, which causes your page to have different behavior in Firefox than in every other browser!

sideshowbarker commented 8 years ago

Situation after style scoped has been removed from the standard:

style in body is invalid HTML 5

style scoped in body is invalid HTML 5

Yes, correct.

I am getting lots of these messages recently, from the HTML 5 validator

Yes, because I updated the validator to match the spec change that dropped support for <style scoped> in the body.

I was wondering if we could somehow keep either style or style scoped tags in the body as valid HTML 5, without producing warnings.

The current issue we have open for that is https://github.com/whatwg/html/issues/1605 and that is about just changing the spec to allow style in body.

sideshowbarker commented 8 years ago

https://github.com/whatwg/html/issues/552#issuecomment-237077513 from @upsuper

Given <style scoped> is similiar to what Shadow DOM would do, would any other implementor be willing to have <style scoped> done based on the support of Shadow DOM? It seems Gecko shares code between these two things, and thus I suppose having Shadow DOM might make scoped style easier to implement in other engines as well.

Yeah it would be good to get implementor feedback about that. But I don’t know where/how to suggest as the place to have the discussion…

akyoto commented 8 years ago

@domenic @sideshowbarker Thank you for pointing me to #1605. Will continue the discussion there.

zcorpan commented 8 years ago

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

hax commented 8 years ago

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---- commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/whatwg/html/issues/552#issuecomment-303957768, or mute the thread https://github.com/notifications/unsubscribe-auth/AMN7xov7Y_90K8c4lBO-ik40J9D7XuxHks5r9UBEgaJpZM4HLE_F .

ianthedev commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

shellbryson commented 7 years ago

A shame. I just finished FE development of a componentized site delivered via Drupal. Most of the images were CSS defined. Being able to

whatwg / html

Remove <style scoped> #552

Question

Reason

Question # 2

Question # 3 (Edit 2)