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