Re: Shadow DOM: Hat and Cat -- if that's your real name.

On Feb 4, 2014, at 10:56 AM, Tab Atkins Jr. <jackalmage@gmail.com>
 wrote:

> On Tue, Feb 4, 2014 at 10:02 AM, Edward O'Connor <eoconnor@apple.com> wrote:
>> Hi Dimitri,
>> 
>> You wrote:
>> 
>>> As indicated by Tab at the F2F, Blink currently implements the cat/hat
>>> combinators proposed by yours truly [3].
>>> 
>>> FWIW, I don't fully understand why it would be so terrible to leave
>>> cat and hat alone (in talking with Tab, there's only a weak precedent
>>> for preferring pseudo element functions to combinators with
>>> ::content), but I am okay with renaming them. Ultimately, it's this
>>> WG's shed, I just store my bike there.
>> 
>> I don't think host documents should be able to select arbitrary elements
>> in the shadow DOM. A much better model, which IIRC was in one of your
>> documents at one point, is to let the component author explicitly export
>> certain shadow elements as pseudos. Something like:
>> 
>> # In shadow tree
>> 
>>    <div pseudo=foo>...</div>
>> 
>> # in CSS, if that shadow tree is attached to el with id bar
>> 
>>    #bar::pseudo(foo) { ... }
>> 
>> In this model, the component author is only signing up for a contract
>> for which they know the terms.
> 
> I didn't get into depth about this during the f2f, but we tried this,
> and it doesn't work.  It's an attractive nuisance, because it's
> actually way weaker and more annoying than you think from looking at
> it.
> 
> For one, it requires explicit annotations on every element you want to
> expose to styling.  If you want to expose all or most of a component's
> internals, that's extremely annoying.
> 
> For two, the pseudo name is roughly a class analogue, and a class by
> itself is too weak of a mechanism for useful styling - you can't, for
> example, style based on an attribute on the element, or on
> :nth-child(), or anything else like that.  (It's actually weaker than
> class as originally specified, since you can only provide one name per
> element.  But that's obviously a detail that could be tweaked.)
> 
> For three, it's only a rough analogue for hat ^, not cat ^^.  If you
> only surface the pseudos that the given component defines, you can't
> style anything further down.  If you surface all the pseudos defined
> by the component and anything internal, you run into lots more
> problems - name collisions, can't distinguish between things when a
> component uses two copies of another component internally, etc.
> 
> By exposing the structure directly via the shadow combinators, you do
> lose some of the benefits of encapsulation, but the usability wins are
> *enormous* over any other solution we've seen so far.
> 

Thanks, that was helpful. I'm not quite sold on the usability argument, though. Or maybe I wonder usable for whom. Letting anyone trivially select any component internals doesn't sound like an encapsulation/usability trade-off. It sounds more like letting CSS ignore encapsulation provided the component user is willing to add a two-char combinator to their selectors. As a result, if my component is successful I may quickly find that any change I make breaks ^^ selectors all over the place.

So while I sympathize with the issues you raise the proposed solution doesn't seem like it really strikes a balance between encapsulation and usability; it just sets a very low hurdle on breaking encapsulation from CSS. 

So yes, things remain as 'usable' for component users as they are today: by adding ^^ a shadow DOM tree is as easy to style as any jQuery plug-in. But is that a good trade-off for the people who make components? As a thought experiment, assume future browsers consider using Shadow DOM for built-in controls: is this level of styling access a desirable default? To make sure I'm clear: the issue here is not about whether this level of access should be possible but, given how trivial it is to use ^^, whether the component author should have some choice in the matter. They're authors too, after all.

Or is there some mooted way for the component author to say 'nope, i'm in control of what can be selected below this point'?

Received on Tuesday, 4 February 2014 20:34:31 UTC