- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 08 Feb 2014 11:23:54 -0500
- 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