Remove <style scoped> #552
Comments
|
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. |
|
@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. |
|
(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. |
|
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.
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.
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.
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.
|
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. |
|
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 |
|
This is a shame. Retaining |
|
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. |
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. |
|
@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 |
|
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. |
|
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.) |
|
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. |
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 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). |
|
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. |
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. |
|
You don't have to create a "component" of any sort to use shadow DOM and the resulting style encapsulation. |
|
@domenic I'll try to figure out how. Until then if you have a small demo that supports:
I am nothing but excited! |
Also remove existing test for <style scoped>. See whatwg/html#552
|
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. |
|
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 on the other side, |
|
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 |
|
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? |
|
@josh A declarative way that does not require JS, that sounds very good! Does QuestionNow one could use ReasonIt 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 # 2Does HTTP2 solve this by actively pushing the Shadow-DOM css-ressources (via 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> |
|
This would be really helpful for drop-in frontend libraries that utilize own UI. |
|
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. |
|
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? |
|
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>
.
|
|
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. |
|
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. |
|
Being able to scope a |
|
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.
|
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 :) |
|
Shadow DOM would be okay if there was a declarative way to do so without Javascript being a requirement to render scoped CSS. |
|
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.
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 |
@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:
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. |
|
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. |
and others
<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<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: