|Intent to remove <style scoped>||Elliott Sprehn||3/19/14 3:34 PM|
Primary eng (and PM) emailsesp...@chromium.org
SummaryRemove <style scoped>
MotivationThis feature is not maintained, not shipping and no progress has been made in 5 months. It also adds a lot of complexity to how the scoped style system works for Shadow DOM.
Previous discussion and support for removal is here:
Row on feature dashboard?http://www.chromestatus.com/features/5374137958662144
Requesting approval to remove too?Yes
|Re: [blink-dev] Intent to remove <style scoped>||Tab Atkins Jr.||3/19/14 7:13 PM|
I'm not 100% sure whether we actually want to pursue this feature or
not in the future, but regardless, we can take up that question later.
On Wed, Mar 19, 2014 at 3:34 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> Primary eng (and PM) emails...@chromium.org
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.
|Re: [blink-dev] Intent to remove <style scoped>||Hayato Ito||3/19/14 9:49 PM|
<style scoped> has been burden for us to maintain.
I've felt several times that <style scoped> is the cause of code complexity when I work on Shadow DOM styling.
I'm not saying that blink shouldn't support <style scoped>.
I am saying that we can get benefits from the view of hack-ability of style system if we can forget <style scoped>.
We can reimplement <style scoped> later once we feel it's needed.
|Re: [blink-dev] Intent to remove <style scoped>||Adam Barth||3/24/14 10:56 AM|
|Re: [blink-dev] Intent to remove <style scoped>||Ojan Vafai||3/24/14 11:15 AM|
|Re: [blink-dev] Intent to remove <style scoped>||TAMURA, Kent||3/25/14 2:41 PM|
Software Engineer, Google
|Re: Intent to remove <style scoped>||ethan...@gmx.net||4/1/14 1:16 AM|
hi, without scoped css web components make no sense.
|[blink-dev] Re: Intent to remove <style scoped>||Adam Barth||4/1/14 8:49 AM|
Style are still scoped to ShadowRoots, which means they still work properly for web components. This mechanism was duplicate functionality that let you scope styles at arbitrary points in the DOM.
|Re: [blink-dev] Re: Intent to remove <style scoped>||Tab Atkins Jr.||4/3/14 12:14 PM|
On Tue, Apr 1, 2014 at 1:16 AM, <ethan...@gmx.net> wrote:The CSS-related behaviors of Web Components are completely unrelated
to scoped styles. Shadow DOM does not use scoped styles in any
|Re: Intent to remove <style scoped>||danny...@gmail.com||2/19/15 10:42 PM|
Very sad to see this one go. This feature was convenient for testing purposes and also served as a hacky workaround for cached and merged css/js files being served by CDN :((
|Re: [blink-dev] Re: Intent to remove <style scoped>||PhistucK||2/20/15 4:41 AM|
It is probably very easy to emulate using an extension or a bookmarklet (looks for <style scoped>, adds #some-generated-unique-id to all of the non at-rules and adds an id="some-generated-unique-id" to the containing element, or uses the existing ID), if you are only talking about testing purposes.
|Re: Intent to remove <style scoped>||lonn...@startport.com||11/3/15 9:12 PM|
This feature excites me more than any other I've seen in recent years. It allows each module to essentially "style itself" overriding unwanted cascading/inherited styles. Its a great flexibility that should have been there from the beginning.
Consider this, when it comes to the current state of inline styling, you can't put a selector into html attributes. For example, you can't do this:
The style attribute only has scope to effect properties of the div, you cannot insert selectors into the style attribute to control the entire scope (of all sub elements with that div).
Instead, you must "id" or "class" the div, and use some style sheet completely outside the location of this element to style it. This make modules too tightly coupled with the pages they appear on.
With style scopes, however, you could potentially showcase, on a single web page, a bunch of independently styled modules, without those modules having to cooperate with style-sheets of the page they are appearing on.
To achieve this now, without style scopes, it is always a pain the ass. You either have to style each attribute of each sub element (within a scope hierarchy), or play the id/class game, basically making your module have to "register" its styles OUTSIDE of itself with the page it is appearing on.
I say, let the modules style themselves, within the module, using selectors, in the scope where they exist. Then, if you put that module on a page, its layout and look, will be exactly like you designed it to be, without having to cooperate with the page it appears on.
Additionally, I also think <style scoped> should not be limited to inline selectors, it should also have the ability to call any stylesheet URL. Something like this:
The web will have truly matured when such flexibilities are ubiquitous. Let the modules layout and style themselves (inside themselves)!
|Re: Intent to remove <style scoped>||lonn...@startport.com||11/3/15 9:37 PM|
|Re: [blink-dev] Re: Intent to remove <style scoped>||PhistucK||11/4/15 12:37 AM|
Web Components (Shadow DOM in particular) can have <style> in them that only affects the encapsulated DOM. This sounds like a (more real) module to me.
On Wed, Nov 4, 2015 at 7:37 AM, <lonn...@startport.com> wrote:
|Re: Intent to remove <style scoped>||keith...@gmail.com||6/8/16 5:42 PM|
This is one of the most exciting potential features to me. I really hope it resurfaces, especially in its newer iteration in the working draft (https://drafts.csswg.org/css-scoping/). This relies on an @scope at-rule rather than the html scoped attribute. It makes more sense to me to do this in stylesheets rather than inline in the HTML document.
|Re: Intent to remove <style scoped>||franz....@gmail.com||6/10/16 9:45 PM|
Agreed. The new iteration sounds very promising, and should be a nice CSS-only way to keep a sane CSS architecture while still decoupling styles from HTML
|Re: Intent to remove <style scoped>||mathew...@globalyceum.com||6/20/16 1:21 PM|
Please inform me as to were I may voice my appeal in favor to continue to develop <style scoped>. If I'm in the right place then I believe works such as <style scope> is absolutely necessary. CSS is at best a quasi- language (perhaps a more appropriate term would be slang?) , it's purpose is to facilitate the presentation aspects of HTML. It lacks so many essential features that it has become more of a necessary burden than boon. Not being able to control CSS global influence effectively costs us more valuable time devising half-assed measures such as post-processing, BEM, etc.. Getting <style scoped> out there is a big step in the right direction.
|Re: Intent to remove <style scoped>||franz....@gmail.com||6/20/16 7:29 PM|
There is a new version of the editor's draft at https://drafts.csswg.org/css-scoping/ that suggests a CSS-only solution for scoped styles. So even if <style scoped> is removed, implementing scoped styles will likely become possible in the future.
|Re: Intent to remove <style scoped>||Mathew Corley||6/21/16 8:12 AM|
Thank you, sir. There is hope yet.
|Re: Intent to remove <style scoped>||tra...@ministrycentered.com||6/21/16 9:37 PM|
|Re: Intent to remove <style scoped>||adamje...@gmail.com||6/22/16 2:31 PM|
|Re: Intent to remove <style scoped>||seyedmojt...@gmail.com||6/23/16 3:11 AM|