Re: [shadow-styling] First Draft of Shadow DOM Styling uploaded

> The rules in the component are scoped to the component in the sense that 
> they can only affect the styles of nodes in the shadow DOM (modulo 
> inheritance issues).
>
> What :ancestor lets you do is change the styles of the nodes in the shadow 
> DOM based on, say, a class on the <body> of the page.  It doesn't let you 
> change the styles of the <body> itself.

Hum, that's already more acceptable. I either misread the spec or it wasn't 
quite obvious.



> > In all seriousness, can you provide a single "responsible" use case for 
> > this?
>
> Tab and I actually discussed this a bit yesterday, offline.  The use case 
> he cited was theming, where a theme-aware component would basically do 
> something like ":ancestor([theme=dark]) .myThingie" and 
> ":ancestor([theme=light]) .myThingie" to hook into existing theme styling 
> setups, which commonly use an attribute of some sort on the <body>.

That's a probable use case. I wonder whether it would not be better to use 
custom css properties for that, though.

You could do .myThingie:inherited(var-theme: light)) ... { ...} where 
:inherited(...) only consider the inherited value of a property, and not its 
final value. We could restrict to custom properties as a starter to avoid 
issues with shorthand/longhand properties.




> > The reverse, however, should not be true because, otherwise, "siblings" 
> > shadow DOMs may break into each-other privacy and totally make nut the 
> > purpose of the Shadow DOM specification.
>
> A bigger issue for _this_ is the scripting model, in which afaict the 
> component can just mess with the DOM of the page all it wants, should it 
> choose to do so.  Including by accident, I expect; if a component uses 
> jQuery and does $("div") it'll get the divs of the page, not its own...

Not sure there exists a good way to solve this, though.

Received on Saturday, 8 February 2014 17:09:28 UTC