Intent to remove <style scoped>

2880 views
Skip to first unread message

Elliott Sprehn

unread,
Mar 19, 2014, 6:34:27 PM3/19/14
to blink-dev
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: 
https://groups.google.com/a/chromium.org/d/topic/blink-dev/JB8nFQXhAuQ/discussion
Compatibility RiskNone
Row on feature dashboard?http://www.chromestatus.com/features/5374137958662144
Requesting approval to remove too?Yes

Tab Atkins Jr.

unread,
Mar 19, 2014, 10:13:15 PM3/19/14
to Elliott Sprehn, blink-dev
LGTM

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.

Hayato Ito

unread,
Mar 20, 2014, 12:49:31 AM3/20/14
to Tab Atkins Jr., Elliott Sprehn, blink-dev
LGTM.

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


--
Hayato

Adam Barth

unread,
Mar 24, 2014, 1:56:08 PM3/24/14
to Hayato Ito, Tab Atkins Jr., Elliott Sprehn, blink-dev
LGTM

Ojan Vafai

unread,
Mar 24, 2014, 2:15:17 PM3/24/14
to Adam Barth, Hayato Ito, Tab Atkins Jr., Elliott Sprehn, blink-dev
LGTM

TAMURA, Kent

unread,
Mar 25, 2014, 5:41:10 PM3/25/14
to Ojan Vafai, Adam Barth, Hayato Ito, Tab Atkins Jr., Elliott Sprehn, blink-dev
LGTM3

--
TAMURA, Kent
Software Engineer, Google


ethan...@gmx.net

unread,
Apr 1, 2014, 4:16:30 AM4/1/14
to blin...@chromium.org
hi, without scoped css web components make no sense.

Adam Barth

unread,
Apr 1, 2014, 11:49:13 AM4/1/14
to ethan...@gmx.net, blin...@chromium.org
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.

Adam

Tab Atkins Jr.

unread,
Apr 3, 2014, 3:14:44 PM4/3/14
to ethan...@gmx.net, blink-dev
On Tue, Apr 1, 2014 at 1:16 AM, <ethan...@gmx.net> wrote:
> hi, without scoped css web components make no sense.

The CSS-related behaviors of Web Components are completely unrelated
to scoped styles. Shadow DOM does not use scoped styles in any
meaningful sense.

~TJ

danny...@gmail.com

unread,
Feb 20, 2015, 1:42:42 AM2/20/15
to blin...@chromium.org
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 :((

PhistucK

unread,
Feb 20, 2015, 7:41:00 AM2/20/15
to danny...@gmail.com, blink-dev
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.


PhistucK

lonn...@startport.com

unread,
Nov 4, 2015, 12:12:37 AM11/4/15
to blink-dev
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:

<div style="span{color:red}">
    This is
<span>red</span>.
</div>



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:

  <style scoped href="AnyStyleSheetInTheWorld.css" type="text/css">
     
<!--Add additional styles here if necessary -->
 
</style>



The web will have truly matured when such flexibilities are ubiquitous. Let the modules layout and style themselves (inside themselves)!

lonn...@startport.com

unread,
Nov 4, 2015, 12:37:53 AM11/4/15
to blink-dev
By the way, I recall proposing something similar to this back 2005. Luckily, I was able to google and find it:
http://lists.w3.org/Archives/Public/www-html/2005Jul/0043.html

PhistucK

unread,
Nov 4, 2015, 3:37:54 AM11/4/15
to lonn...@startport.com, blink-dev
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.
(Granted, it requires JavaScript which is pretty bad)


PhistucK

On Wed, Nov 4, 2015 at 7:37 AM, <lonn...@startport.com> wrote:
By the way, I recall proposing something similar to this back 2005. Luckily, I was able to google and find it:
http://lists.w3.org/Archives/Public/www-html/2005Jul/0043.html

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

keith...@gmail.com

unread,
Jun 8, 2016, 8:42:38 PM6/8/16
to blink-dev
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.

franz....@gmail.com

unread,
Jun 11, 2016, 12:45:33 AM6/11/16
to blink-dev, keith...@gmail.com
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

Regards
Franz Liedke

mathew...@globalyceum.com

unread,
Jun 20, 2016, 4:21:46 PM6/20/16
to blink-dev
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. 


On Wednesday, March 19, 2014 at 3:34:27 PM UTC-7, Elliott Sprehn wrote:

franz....@gmail.com

unread,
Jun 20, 2016, 10:29:59 PM6/20/16
to blink-dev, mathew...@globalyceum.com
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.

Mathew Corley

unread,
Jun 21, 2016, 11:12:56 AM6/21/16
to franz....@gmail.com, blink-dev
Thank you, sir. There is hope yet.
--
Regards,
Mathew Corley, Globalyceum.com

tra...@ministrycentered.com

unread,
Jun 22, 2016, 12:37:52 AM6/22/16
to blink-dev
LGTM


On Wednesday, March 19, 2014 at 3:34:27 PM UTC-7, Elliott Sprehn wrote:

adamje...@gmail.com

unread,
Jun 22, 2016, 5:31:49 PM6/22/16
to blink-dev
LGTM

On Wednesday, March 19, 2014 at 5:34:27 PM UTC-5, Elliott Sprehn wrote:

seyedmojt...@gmail.com

unread,
Jun 23, 2016, 6:11:57 AM6/23/16
to blink-dev
LGTM

adi.zarf...@gmail.com

unread,
May 7, 2018, 12:11:31 PM5/7/18
to blink-dev, esp...@chromium.org
what is the status of <style scoped> ?
I can use it in chrome, but I see this feature have been removed ?
am I using something deprecated or is this feature supported ?
In my use case, this feature is a blessing...

PhistucK

unread,
May 7, 2018, 12:51:32 PM5/7/18
to adi.zarf...@gmail.com, blink-dev, Elliott Sprehn
It was never enabled by default and it was removed from the code base itself about four years ago.

PhistucK


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Domenic Denicola

unread,
May 7, 2018, 1:39:30 PM5/7/18
to PhistucK, adi.zarf...@gmail.com, blink-dev, Elliott Sprehn

So in particular, when you use <style scoped> in Chrome, it is the same as using <style asdf>, or just <style>.

keith...@gmail.com

unread,
May 7, 2018, 9:04:19 PM5/7/18
to blink-dev, esp...@chromium.org
<style scoped> is no longer in the spec. The way to do this now is with the Shadow DOM. https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM

kimly...@gmail.com

unread,
Jun 11, 2018, 3:42:20 PM6/11/18
to blink-dev, esp...@chromium.org
I am very sad this feature (scoped styling) was removed.  With programitcally loaded css from an outside source, I wanted to limit the scope without resorting to an iframe or something similar.  I've looked at shadow dom and it just doesn't seem to meet my need the way the scoped attribute would have. I wanted a very simply, html/xhtml only solution which scoped would have provided.   


~Kim
Reply all
Reply to author
Forward
0 new messages