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