W3C home > Mailing lists > Public > www-style@w3.org > February 2014

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 08 Feb 2014 11:23:54 -0500
Message-ID: <52F65A1A.6000807@mit.edu>
To: www-style@w3.org
On 2/8/14 5:48 AM, Fran├žois REMY wrote:
> Firstly, I never saw any discussion about the ":ancestor(...)" pseudo-class in the past, which allow selectors inside a shadow DOM to select elements outside the shadow DOM. Wow, I think we are breaking yet another level of encapsulation here in a way I don't like at all. A Shadow DOM should never have an impact on an another element in the visible DOM than the element it's applied on

I think you're confusing "selecting" and "styling" here.

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.

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

I did have some performance concerns, and also concerns that the feature 
is more powerful than strictly needed for the theming use case.

In Gecko we actually have some theming pseudo-classes (for a fixed set 
of theme values that we control, which is a bit different from what we 
have here), which basically allow you to match some document-wide theme 
state that's actually stored directly in the document.  So in Gecko the 
above selectors today would look more like ".myThingie:-moz-theme-dark" 
or whatnot.  That doesn't quite work for sites in general, which 
presumably want to define their own theme names.

The suggestion came up, as part of that conversation, that we might be 
able to just use custom media queries for the theming use case, 
especially if the custom media setup can be declaratively triggered by 
the page.  This is less powerful than :ancestor in that it doesn't let 
you do different themes for different parts of the page, but it wasn't 
clear to me how much of a use case there is for doing that.

If you have suggestions for better addressing the theming use case 
(which looks like a valid and use case to me), I'd love to hear them.

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

-Boris
Received on Saturday, 8 February 2014 16:24:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC