W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: Need a better way to reach into the shadow DOM subtree

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 11 Apr 2011 17:30:11 -0700
Message-ID: <BANLkTik=05xx1j09P9TCn=fD59c_YDKahA@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>
On Mon, Apr 11, 2011 at 3:08 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/11/11 2:58 PM, Tab Atkins Jr. wrote:
>> XBL exposes the shadow tree directly
> I have no idea what you mean by that.
>> 1. It makes the selector tree not match the source tree, without an
>> explicit indication that something weird is going on.  Components
>> should, in general, look like and act like normal elements, so that
>> ordinary selectors act in expected ways.  (For example, "details>  p"
>> should match the<p>  in "<details><p>foo</p></details>", even if the
>> implementation puts a shadow wrapper around the contents.
> That works today, in XBL1 and in the XBL2 proposals.  Have you actually
> tried this, or did you just assume things about the way those work that
> don't match reality?

Sorry, I made a slight mistake in reading the XBL2 spec (Hixie's
writing style at the time was much more opaque than now).

Take a document like the following:


<template id='details-binding' allow-selectors-through='true'>
  <content include='summary'></content>

details {
  binding: url('#details-binding');

details > div {
  border: thick solid;

Both the light and shadow divs are matched by "details > div" and
styled with a border.  This is *crazytimes* - both an element and its
parent in the layout are matched as direct children of an element.
That just goes against the basic definition of what a "child selector"

XBL2 is just inconsistent here - it basically says that selectors
operate on both the original *and* final flattened trees at the same

>> 2. It exposes the entire shadow tree.
> _This_ I agree is a problem in current XBL1/2.  However, it seems like so
> does the '%' proposal.  And if it doesn't, then whatever restrictions that
> proposal is applying can apply just as easily to ' '.
> So I still don't see the need for a new combinator here...

No, the intention is that the magic new shadow combinator only selects
from the elements that are explicitly indicated by the component

Received on Tuesday, 12 April 2011 00:30:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:50 UTC