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.

It seems like a version of named pseudo-exporting that exports all children would make it trivial to accomplish this - you would only need to annotate the root to expose your full shadow DOM to styling. It would also provide a way to handle the nested component case - just mark its ancestor in the outer shadow dom as exporting children through its pseudo.

With your proposal, the whole structure of the shadow DOM effectively become part of your component's API contract, whether you want it to or not

[... snip ...]

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

s/some/all/ - you'll never be able to change the structure of your Shadow DOM without potentially breaking compat with some client.

If "export everything to styling" is even offered, it should be opt-out, not opt-in.

Regards,
Maciej

Received on Wednesday, 5 February 2014 02:32:02 UTC