Styling/scoping

[bkardell]

An issue came up in CSSWG about style scoping. It was linked to a kind of confused seeming thread but numerous people in CSSWG confirmed that they are consistently asked questions about this and don't really know what to say.

Here's the relevant IRC log with what I had to say: TL;DR: It's complicated, there's history and experimentation, CSSWG alone probably can't solve this problem, we need to involve developers by exposing the right things (several already underway or available), describing the history and problem and that solutions should be incubated.

Tab is going to work on putting together a history and maybe a post, probably some work in WICG.

If there are thoughts or disagreements, let me know.

---

astearns: And TabAtkins is still collecting data there.

12:19 PM A
w3c/csswg-drafts#270

12:19 PM D
Topic: [css-scoping] Support for CSS namespaces
12:20 PM ChrisL: This si the what to do with shadowDom thing. How do you style, do selectors work, etc. I think closing and saying we won't fix is doing the community a disservice. I'm hearing a lot of pain where people want to be able to do modularizable solutions. I see huge long naming conventions.

12:20 PM B<bkardell_> Brian Kardell
that issue seems confused

12:20 PM D
ChrisL: It's not do we have namespaces, it's what are we working toward to have local variable type styling for theme-ability. Just saying we won't do anything for a few years isn't appropriate.
12:21 PM TabAtkins: Today the answer is web components. THere are some holes and we'd like it something like easier to do declaritively, but we'd like it to mature to see where we need to go in. That's our focus. Everything that people suggest won't do what they want. You want hte full both directions that web components allow. Their solutions dont' think both directions. And browsers aren't doing scoped styles.
12:21 PM ChrisL: What does web componets allow? Can you theme and style? I'm not familiar enough

12:22 PM B<bkardell_> Brian Kardell
TabAtkins: it could be declarative today, right? all you need is a web component that just does that.

12:22 PM D
TabAtkins: If you put things in a shadow tree they're stylable in the tree. THe styles inside can't go out and the styles outside can't go in. So it's a full self-contained piece of HTML that won't be messed up by styling o nthe rest of the page.
12:22 PM leaverou: How are they themed?
12:22 PM leaverou: I've refraned from using components because they're not skin-able.

12:23 PM B<bkardell_> Brian Kardell
q+
12:23 PM Z— Zakim sees ChrisL, bkardell_ on the speaker queue

12:23 PM D
TabAtkins: We have some soultion now. If you use variables you can pass in styling one piece at a time. Not the most convient. We have the @apply rule that was generally accepted that lets you shift entire style blocks across the boundary.

12:23 PM C
q-
12:23 PM Z— Zakim sees bkardell_ on the speaker queue

12:24 PM D
TabAtkins: From inside the tree you can detect what's going on from the outside like if a class is on an ancestor so you can adjust accordingly. SO you can ship with multiple themes that do something depending on a class outside.

12:24 PM A
ack bkardell_
12:24 PM Z— Zakim sees no one on the speaker queue

12:24 PM I<iank_>
Polymer has a writeup here of the mixin/custom-prop solution: https://www.polymer-project.org/1.0/docs/devguide/styling#custom-css-properties

12:25 PM D
bkardell_: I wanted to add that one of the good things about this is that we did experiment with several things. Chrome and polymer had experiments to allow you to explicitly cross boundaries. We had a number of discussions based on what people thought they wanted, but when we gave it it wasn't really what they wanted.
12:25 PM bkardell_: Going forward we shoudl expose basic things, allow experimentation and progress. This is new ground. The only way we can know this is the right thing is to be allowed to use it.
12:26 PM TabAtkins: He's referring to the ::deep selector. It led to unending problems of people changing thigns they didn't mean to. So we diled back to explicit sharing. It's all the flexability without a footgun
12:27 PM leaverou: This sounds good but I'm skeptical that a component exposes its variable so to change it you have to change your CSS. Assuming there's no native slide, you want to use a slider and than another slider you have to look up the doc. Native components to accept some styling. It would be nice if author components did the same thing.
12:27 PM TabAtkins: That's good feedback. WE should keep that in mind as we move toward more declaritive.

12:27 PM B<bkardell_> Brian Kardell
but if we expose the right bits, then maybe people like leaverou can experiment with ways to do that in wicg :)

12:27 PM F
ChrisL w3c/csswg-drafts#270 (comment) ?

12:27 PM D
leaverou: I'm not sure this is jsut shadowDOM. I think it may also be nesting. That's another thing authors ask me about.
12:28 PM leaverou: Authors ask me a lot about nesting and scoping in every conference for the last few months. I don't know what to tell them.
12:28 PM leaverou: So nesting is another big thing. This is what the naming conventions are tryign to address.

12:28 PM F
www-style thread!!! :D

12:28 PM B<bkardell_> Brian Kardell
fantasai: nooooooooooooooo
12:28 PM :)
12:29 PM F— fantasai misses subthreading :(

12:29 PM D
astearns: So there's several issues. Scolping, nesting, a moredeclaritive approach to components. I'm not sure a single github thread will be that helpful. It might be good to have a single place with the history of this conversation. So look we have this deep selector and it didn't work like we wanted.
12:29 PM astearns: I'm thinking a wiki page with all the history where we can take this github and point it there to say we've worked on these things, we're trying these things. So we're not shutting down convo but it's not a sincle thread.

12:29 PM B<bkardell_> Brian Kardell
this really does sound to me like a great thing to bring up in wicg before csswg itself burns time on it... that is inclusive of devs and hopefully then we can bring back the good ideas

12:30 PM
astearns: I want a place where we can engage the community on these issues and some place with the history of what we tried and what we're looking to do.
12:30 PM ChrisL: SOunds great. So who sound write it and who has the material to begin it.
12:30 PM TabAtkins: I can start writing that. I have the history in my head.

12:30 PM B<bkardell_> Brian Kardell
q+
12:30 PM Z— Zakim sees bkardell_ on the speaker queue

12:30 PM D
fantasai: A blog post would be nice, but the commenting on our blog is too broken.

12:30 PM B<bkardell_> Brian Kardell
q-
12:30 PM Z— Zakim sees no one on the speaker queue

12:31 PM D
astearns: And bkardell_ mentioned on IRC that this may be good for the incubation group.

12:31 PM B<bkardell_> Brian Kardell
also repos and wikis and all available on wicg

[dmethvin]

Scoped styles seem like a simple solution to a common problem, but I haven't looked deeply enough to see whether they're only a partial solution that couldn't stand alone in practice. The general response when this comes up seems to be "that's solved by shadow DOM," is it really? What other baggage does shadow DOM bring with it that is unwanted or unneeded? Maybe someone could write up a side-by-side on how to implement the scoped styles using what we already have in the spec today.

[bkardell]

Let's wait for tab's post as it may write up all of that stuff nicely. If it doesn't, I can maybe try to write up what I see as the history/features there. As of now though, no browsers are pursuing scoped styles and all of them are pursuing shadow dom. 'Baggage' I think kind of depends on what you think the benefits and drawbacks actually are and, unfortunately, without use I don't think we're in a good position to judge. Both had experimental implementations, experimental use and feedback... There were even new combinators to help deal with issues based on that feedback and once people started using them, it turns out they didn't really want that either. It seems to me that Shadow DOM, all/resets and variables will give us some fundamentals on which people can try out theories and maybe actually get something that really feels sane - but that's just my own feeling. I'd like to hear more discussion. From where we stand right now, I'd really like to see incubation of new ideas in this space that involve the community and something that can be useful enough for people to play with in the real world.

[tabatkins]

I can lay out the basics right now (it'll help me organize things for the wiki page anyway).

So, first we had scoped stylesheets, proposed to solve the problem of "I want to style this component without having to worry about what else is on the page". But only Firefox ended up implementing this. In practice, it's nearly identical to just putting an ID in front of every selector in the sheet. (It has slightly deeper implications on the cascade to ensure the scoped styles win when there's a conflict with the outer page, but that's relatively minor - most of the time, the extra ID would have ensured a specificity win anyway.)

Roughly simultaneously, we started working on web components. They were meant to solve several problems (one big one was: every big JS library had its own unique component system and API; a standardized API would help them talk to each other and reduce siloing), but one in particular was "I want to style this component without having to worry about what else is on the page", because being able to reason about your page component-wise (rather than globally) was important.

One thing we quickly realized in exploring the problem space is that proper componentization requires not just lower-boundary protection (preventing the component's styles from accidentally fiddling with the outside page) but also upper-boundary protection (protecting the outside page from accidentally fiddling with the component) - without both you don't actually have independent components, and can't design something that's guaranteed to work on every page in a single website, let alone be worthwhile to distribute.

Upper-boundary protection is something most people miss when thinking of components, because they tend to think locally, of just the one component in one particular spot. Even with upper-boundary protection you have to be careful, because "accidental fiddling" is easier than you might think. When we were first digging into Shadow DOM, with the Polymer team as our sounding board, we tried to keep the "communication channels" between the outer world and the shadow very limited and intentional, but Polymer fought back, on the grounds that it was too annoying to work with. This is why the first draft of the Shadow DOM spec had the "deep" combinator that let outer selectors pierce into the shadows. Turns out this was a mistake! It was far too easy to misuse this and get yourself into a terrible state where components deep in the tree were being accidentally fiddled with because of a badly-written selector somewhere much further up the tree that used the deep combinator.

So the current Shadow DOM spec is much tighter. Selectors never cross component boundaries. There are only two limited communication channels. The first is via inheritance, with custom properties (invoked via var() and, soon, by @apply) as the arbitrary information channel. Everything's well-defined and the only way to get accidental fiddling is if two components, one nested inside the other, use the same variable name, and the outer doesn't reset that variable for the inner - it'll then receive the value meant for the outer component, rather than using a default value due to the variable being undefined. The second is via the :host() pseudo-class from within the shadow tree, where you can test if the host element (or an ancestor, via :host-context()) matches some selector, and act accordingly. This lets you set up multiple "themes" triggered via a theming class, and has several other uses. Importantly, both of these channels put the component in control - only it, not the outer page, can decide what custom property names it cares about, or theming classes/attributes it's looking for.

This architecture was designed through intense feedback and real-world experience by a mid-sized team of professional web designers writing sites and developing libraries for use by others. It's not perfect, but it's pretty battle-tested, and we are very aware of several of the landmines we ended up routing around. The lack of good upper-boundary protection is a big one, and it's why I think anything resembling scoped styles isn't worth time developing - it ends up being a very incomplete solution patching over just one aspect of the "everything in CSS is a global variable and it hurts" problem. (Scoped styles' cascade thing, mentioned above, is a very limited form of upper-boundary protection - it ensures that accidental fiddling from outside can't override any property you specifically set, but it does nothing for all the properties you didn't set on the element because the defaults were okay. The less protection you have the more defensive you have to be, and it would be terrible if it became common to embed reset stylesheets into every scoped-style component just to protect it from fiddling.)

There is one big problem with Shadow DOM right now - it only works via JS. You have to make some explicit JS calls to create a shadow tree and attach it to an element. You can hide this behind a library and just expose a web component, so all the page author has to do is include a <foo-bar> element, but that still requires JS even if you're doing nothing but "create a shadow tree and shove all the children into it, then attach a stylesheet". This makes it substantially more annoying to work with for simple cases than scoped styles were, where you just add an attribute to a <style> element and you're good to go. After Shadow DOM has stabilized a bit in a year or two and the implementations have matured, I'm going to be pushing for a more declarative HTML- or CSS-based API to invoke a limited form of the web component API. Imagine just being able to wrap your component's contents in a <shadow> element and automatically getting them all dropped into a shadow DOM attached to the component. Then just putting a <style> element inside of there would automatically get you "scoped" styles, since it would only operate within the shadow tree!

Given the relative ease of writing a "just cram it all into a shadow tree" component, I expect to see a lot of experimentation in this area in the next year or so, which we can hopefully use to help design the standardized API when that's ready to be worked on.

So that's the history and my medium-term plans for this problem-space.

[arschmitz]

Having worked on theming components for jQuery UI, jQuery Mobile, and now Chassis my gut reactions are this.

when making and styling a component the idea of being able to protect your styles from outside interference is a great concept, and could help with many bugs, but i don't think its what consumers of these libraries want. We have received many requests over time to make it MORE EASY to override our base styles and have always encouraged completely custom theme development. Over time we have actively made it easier to modify both the base styles and classes of components.

We have received many request however to make our theme and css scoped and have tried things like you mention with an id through a build system, but none have been successful or things we were happy with overall. These requests were more along the lines of not polluting the global namespace for compatibility reasons or wanting to use multiple themes on a single page though. I don't think we have ever had complaints about wanting the css to be more protecting from outside fiddling only less.

It seems like shadow DOM as the solution to this goes against what i have heard from developers that they want from component libraries over all which is more customizability it seems like it would make developing a custom theme or tweaking styles for your use case or website harder not easier. Shadow DOM would appear to fix the global scope issue though.

[bkardell]

@arschmitz if you have shadow dom and CSS Custom Properties, then libraries like jQuery UI or others could work on creating a community driven standard for how to do this I believe? Effectively you would simply make a custom element like which followed rules around how it exposed/used CSS custom property stuff... It seems like all the 'parts' we'd need to figure it out, no? The alternative challenge is convincing everyone that this is inadequate and that more is needed right away and should receive priority over many other things - which seems hard to do without at least an effort to try... especially given that earlier experiments didn't yield the fruit they thought it would.

Did jQuery UI do experiments with style scoped? if so, was anyone actually able to use it and feedback positive? The challenge with these is that they are so limited because it all has to take place in a single browser/behind a flag. The nice thing about getting raw materials is that experiments can be in the open and valuable/shippable/functioning in the meantime.

What do you think?

[scottgonzalez]

Did jQuery UI do experiments with style scoped?

The extent of scoped styles in jQuery UI is prefixing our selectors with some custom selector. The only reason we even do that is so people can use multiple themes on a page. We don't want to avoid page styles from coming into our widgets.

[arschmitz]

if you have shadow dom and CSS Custom Properties, then libraries like jQuery UI or others could work on creating a community driven standard for how to do this I believe?

While i would love this idea in theory. However having reached out to other frameworks for something very similar fairly recently i can say i think there is no chance of this sort of community collaboration happening.

Effectively you would simply make a custom element like which followed rules around how it exposed/used CSS custom property stuff... It seems like all the 'parts' we'd need to figure it out, no?

I don't think all the parts are there. This would work very well to replace something like the jQuery UI theme roller http://jqueryui.com/themeroller/ where you are exposing specific variables to change but not for the general case of over riding any random prop you want or all of them for a rule ( unless you suggest we expose ever singe value as its own variable )

Did jQuery UI do experiments with style scoped?

The extent in ui is as @scottgonzalez mentioned the generic rule prefix similar to what @tabatkins mentioned, you can see this at http://jqueryui.com/download/ in theme section at bottom

jQuery mobile experimented with other attempts at multiple themes on a page which included defining multiple themes and an inheritance system so you could set it on a top level element and have it inherit but then over ride again any where within. We made 2 different attempts at this the first use javascript to detect and apply the inheritance classes this worked but was not at all performant. The second attempt used css specificity to do it which turned into a night mare quickly.

We have never had any type of request for or attempt to shield our selves from outside css nor do we have any desire to do this its quite the opposite of what our users have expressed they wanted. Our concerns are completely about restricting our own scope to allow multiple themes or multiple frameworks that might use the same class.

[bkardell]

@scottgonzalez no I meant did anyone experiement with <style scoped> - it was implemented in chrome in 2012 IIRC, maybe also ff? Early experiments didn't actually seem promising from what I gather, but again, that was limited because you couldn't really use it in prod... I'm just curious if someone had other feedback (like "we tried it and it was working out really well")

[bkardell]

@arschmitz

While i would love this idea in theory. However having reached out to other frameworks for something very similar fairly recently i can say i think there is no chance of this sort of community collaboration happening.

Even if that community was pioneered by one lib, it would still be a community. Ideally it would be bigger than that, but that doesn't mean it needs to start that way. If someone shines a light, others might jump on, or maybe just inspire something better that more people can get behind?

jQuery mobile experimented with other attempts

That this seems to be the case with other things in this space too, I think, is the point tab and some in the WG are making. "it turned into a nightmare quickly" after we got something we thought we wanted WRT this problem seems like a common refrain. If we are asking for a new feature, it's got to be one we're sure will work and be accepted and not turn into a nightmare. I guess my question is: Do you (or we at large) think that <style scoped> is definitely that? if so, why? To be very clear, I am not suggesting it definitely isn't - I am suggesting simply that I don't currently have data that I could use to make that case, and that on the other hand, I see the alternative as potentially providing a better outcome and probably faster actual usefulness.

[scottgonzalez]

@scottgonzalez no I meant did anyone experiement with <style scoped>

No, we have no use for such a feature.

[scottgonzalez]

It seems like there is an expectation that libraries like jQuery UI want style scoping. Can someone please clearly explain a concrete use case that they think libraries like jQuery UI have where this would be beneficial?

[bkardell]

No, we have no use for such a feature.

@scottgonzalez works for me. Generally speaking a lot of the discussion around shadow dom and style scoped deals with components - this issue was simply to log where those efforts stood in CSS and why, as well as my current position (not trying to push for style scoped which looks dead atm) was simply seeing if anyone had other information/insights.

jQuery UI came up in response, but if jQuery UI has no need of it, that's simple. I do think some other component libs have expressed a want for 'something' it's just not entirely clear what or how it would work (which is why I favor giving them powers to figure it out).

[giuseppeg]

There is one big problem with Shadow DOM right now - it only works via JS

I would also add "it can't be render on the server side"

Imagine just being able to wrap your component's contents in a element and automatically getting them all dropped into a shadow DOM attached to the component

I've always thought this and wondered why it's never been done. Why wait?
A couple of years are ages in this industry unfortunately.

@tabatkins correct me if I am wrong but inheritance still applies to ShadowDOM i.e. inherited properties like color are not reset and instead inherited from the outside page. If this is accurate it could lead to unexpected results, side effects and in my opinion not fully encapsulated styles. Would it make sense to make inheritance opt-in instead? This is somehow similar to explicitly make a property configurable from the outside world via custom properties e.g. color: var(--MyComponent-color) (the suggested way to theme WCs by the Polymer folks)

[tabatkins]

Yes, inheritance still flows thru the shadow; this is very intentional, so that widgets will, by default, style themselves like the rest of the page, and so variables will work as intended.

If you want to block inheritance, you can set all: reset on the top-level elements of the shadow tree. An earlier iteration of the shadow DOM spec had an explicit flag to block inheritance, but that was removed in the simplification to reach v1.

[giuseppeg]

@tabatkins thanks for replying, I learnt about all: revert (I guess you meant revert not reset) only last week :) It is a pity that ~nobody has implemented it yet.

Sounds like what I described and somehow I still think that it should be the default – not arguing about that, it is not my intention :)

[zlamma]

2 cents regarding one dialogue here:

@bkardell: ... did anyone experiement with <style scoped>
@scottgonzalez: No, we have no use for such a feature.
@bkardell: works for me ...

I feel that the @scottgonzalez's answer is simply because this is not a feature for UI library authors, but for users of such libraries. I think this best shown by @arschmitz's account of contact with the users - #47 (comment) & #47 (comment).

Moreover, I feel this is not needed by all of the users, but only those that had to deal with complicated use cases, e.g. having to produce a single document containing multiple homogeneous contents, authored independently and without regards to scoping, while being able to control some aspects of them with minimum code changes.
It is very helpful even in web application development, in scenarios where one has to deal with legacy code. Having this one-directional scoping is an enabler for a very cheap 'baby-step' continuous improvement process. I had the very issue at my organization very recently, where people have independently developed quite advanced components in the kendo-ui library using 3 different themes, each customized, and the business were in huge shock to learn that just moving them onto a single page while retaining control over the look of few important elements is so costly to do.
But the feature is especially needed if this is not a one-off task, where one could 'grin and bear' the refactoring of the original sources, but when such document needs to be provided continuously.

[tabatkins]

See #47 (comment) where I explain in some depth why <style scoped> isn't good enough to solve this case, and it's not worth the time developing or using.

[tabatkins]

Indeed. Fixed, thanks.

[zlamma]

@tabatkins I think I have read that one thoroughly. It's talking about specific use cases of certain people, although it doesn't exactly say what problems the were solving. Did they have the problem I was highlighting in #47 (comment) ? That is, were they dealing with historical hypertext not developed with scoping in mind, had to still influence some of its appearance 'on request', and had time pressure and not enough resources to rewrite all of it? It's not clear, but I somehow doubt that. I would argue that the world has much more of such situations than we like to think. I would understand if we were debating the design of a web-app framework, but hypertext is the language in which plenty of valuable content has already been created. Interoperability with legacy content, without having to change it, is paramount.

I'm not arguing that Shadow DOM with two-way-protection shouldn't be offered. Look, I am not even arguing that my use case is the majority. I'm fine if it stays 'on' as default. I am just saying that there are cases where "leak-prevention from outside" is too much and it's forcing people to do more work than they can afford. Especially when one has to deal with content authored by other people. I really can't understand why an optional feature that, to me, clearly has some significant use cases, is so verboten. At least it allows people to try their luck, before bringing the heavy guns of 'variablizing' CSS they didn't write. If it doesn't work, they fall back & grin and bear the refactoring.

NB. Regarding <style scoped>, I actually don't think that was the best solution for the scenarios I am describing. It still requires people to touch the old content, even if it's just to modify all the <style> tags. Much better would be the akin of a declarative Shadow DOM like <shadow mode='let-all-styles-in-but-none-out'>, to borrow someone's intentionally ungroomed name. This one would truly allow user not to touch any of the alien hypertext.

[prlbr]

So, first we had scoped stylesheets […]. But only Firefox ended up implementing this. In practice, it's nearly identical to just putting an ID in front of every selector in the sheet.

Putting an ID in front of every selector isn’t actually trivial for an automatic system (any such software will have to include and keep a CSS parser up to date to do it correctly; unfortunately it’s not something that a simple regular expression can do reliably for stylesheets in the wild) and also a lot of work for human authors doing it manually for all but the shortest stylesheets.

Web browsers are software that already include a CSS parser, so adding that functionality should be less trouble for browsers than for other software. Yet it was removed from Blink with the note that it added a lot of complexity. However, that’s a matter of the past.

Today it’s not about whether <style scoped> is worth the development effort in parallel to the development of Shadow DOM. Today we have Shadow DOM and are about to introduce a declarative version. Adding a flag to let styles penetrate from outside in doesn’t seem very complex. So a main reason not to do it seems to be gone while the demand for one-way encapsulation has always been and continues to be there.[1]

As a developer I still need one-way encapsulation as I have done for years. The workarounds continue to cause much work and are unreliable.[2]

By the way, the concept of one-way style encapsulation is anything but alien to HTML/CSS: adding a style attribute to an HTML tag will define styles for that element which don’t leak out and yet styles defined in a <style> element somewhere else will affect that element without problem:

<style>p {font-weight:bold; color:black}</style>
<p style='color:blue'>This is blue and bold</p>
<p>This black and bold</p>

This is one-way style encapsulation. And it has worked well for many years. The only trouble is that this only works for single elements. Please make encapsulation work for bigger DOM parts too. Declarative shadow DOM with a flag seems to be the way to go now, but actually, as a user and developer it’s unimportant to me how it’s implemented exactly as long as it is implemented and works without weird requirements such as having Javascript activated for the CSS to work.

Many thanks. :)

---

[1] See the continuing grievance in whatwg/html#552 for example; the issue has been locked recently though.
[2] Once declarative Shadow DOM works, the easiest way to simulate one-way encapsulation somewhat without a flag for it will be by copying all the styles from outside shadowroots into shadowroots. This can blow up the size of a HTML document containing multiple shadowroots though.

[zlamma]

To add a new argument to the debate, it's interesting how the all: ??? feature (either with a value of unset, already widely available, or revert) is being proposed to achieve 'leak prevention from outside' (1, 2, 3), which is pretty cool, because, if it works like the suggesters promise, it allows to apply it without touching the enclosed content*), just like shadowRoot does currently.

That would mean that "two-way-protection Shadow DOM" can be achieved by combining:

1. all: unset
2. and the "let-all-styles-in-but-none-out" barrier feature
   (ideally, applicable without touching the enclosed content*), just like shadowRoot)

Ergo: The feature 2) is the missing primitive - the building block. Shadow DOM unnecessarily bundles it with the feature 1), and, in the process, introduces a second method of achieving the same thing.

It is only reasonable that standards should prefer building blocks over complex solution hardwired for singular use cases.
@bkardell himself nicely highlighted the "need to focus on electricity, rather than lightbulb fixtures", and this one strikes me as a perfect similarity. Except in the lightbulbs story, someone finally made it possible to use electricity for different purposes than lighting.

*) Ability to apply scoping without touching the enclosed content is a feature very desired for interoperability with historic content (e.g. ability to quote someone with all the richness of they way he presented it using CSS stylesheets). Shadow DOM actually delivers that, but proposals like <style scoped>, @namespace or @when do not. They require the changes to be applied to the enclosed content/style.).