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

Re: Shadow DOM Encapsulation

From: Peter Linss <peter.linss@hp.com>
Date: Thu, 6 Feb 2014 23:37:00 -0800
Cc: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <0BF6DDB6-0C71-43F3-8292-AAA07CD6CC14@hp.com>
To: Brad Kemper <brad.kemper@gmail.com>

On Feb 6, 2014, at 10:34 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

>> On Feb 6, 2014, at 8:26 PM, Peter Linss <peter.linss@hp.com> wrote:
>>> On Feb 6, 2014, at 7:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>> On Thu, Feb 6, 2014 at 6:54 PM, Peter Linss <peter.linss@hp.com> wrote:
>>>> On Feb 6, 2014, at 5:23 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>>>> wrote:
>>>>> Note also that this isn't quite as easy as it sounds.  When you expose
>>>>> things, where are they relative to everything else?
>>>> They are in the same place as they are defined, the structure is preserved for everything exported.
>>>> For example, given the shadow DOM:
>>>> <component>
>>>> <part-one export>
>>>>  <sub-part-one />
>>>> </part-one>
>>>> <part-two>
>>>>  <sub-part-two export>
>>>>    <sub-sub-part-two />
>>>>  </sub-part-two>
>>>> </part-two>
>>>> </component>
>>>> You'd see it as though it were defined as:
>>>> <part-one>
>>>> <sub-part-one />
>>>> </part-one>
>>>> <sub-part-two>
>>>> <sub-sub-part-two />
>>>> </sub-part-two>
>>> Oof, so then "part-one + sub-part-two" would actually match?  That's
>>> seems super weird to me.
>> In that obviously contrived example, yes, (although, for consistency, it would actually be "::part-one + ::sub-part-two") because that's the structure that's being exported, the <part-two> element doesn't exist when seen from the outside.
> I think the idea is interesting, not weird. But it is a lot of colons. While initially I was in favor the pseudo-element approach, why couldn't your 'export' opt-in-to-expose work with the hat? Thus, the exact same mark up, but selected like this:
> component ^ part-one + sub-part-two
> Or even:
> component^ > part-one + sub-part-two
> That seems pretty clear to me. The carrot (hat) pierces the component barrier, making the component similar to :host, and closest level down of something with an export attribute acts as a child of that. It is more readable.

Theoretically, it could. The mechanisms to expose and select are a bit orthogonal.

But here's another argument for pseudo-elements: one of the purported uses for components is to allow authors to experiment creating new elements that have compound behavior. The premise is that over time the "good ones" will get folded in and be part of the platform as native elements instead of components (see ExtensibleWebManifesto).

So if today I make a 'foo' component that has a 'bar' and a 'baz' inside it, and then the 'foo' becomes a single HTML element tomorrow. How does one style the internals of the 'foo' HTML element? With ^ combinators? No, you'll use pseudo elements... so the same styling system that is exposed (and experimented with) during the component phase, simply becomes part of the formal style model later. The same stylesheets might still even work if the pseudo-element names and structure survive.

The big advantage is that style sheet authors (those using the components, not creating them) don't have to think about shadow dom and piercing architectural layers, they simply think about styling components the same way they style HTML, it's just elements and pseudo-elements, no new concepts (except richer pseudo-elements, the way they already expect them to work).

>> This is actually a feature. For example, what if the component was initially shipped without the <part-two> element? It can be added, but not exported, and not break existing stylesheets because it doesn't affect the structure exposed to the selectors.
> Maybe it is just the contrived example, but this seems dangerous still. Suppose I authored the following rule for a component you created:
> component ::sub-part-two { display:block; width:50%; }
> It now appears under part one, and goes halfway across the whole component's content box. But then you come along later and update the component by adingd an inline-block 'part-two' around it, and as the component author you think it looks good, but it completely changes the width and placement that my styling was intended to set. Is that just the nature of the beast?

Those kinds of issues are simply the nature of the beast. I don't see this model being any less fragile than if the component internals were simply exposed. If authors are allowed to apply arbitrary style to the internals of components, there are all sorts of opportunities to break things. I'm sure at some point someone will ask for a "!!! really-important" modifier for style inside the component so that it can't be overridden by author style sheets.

>>>> [...] 
>>> "component ::before" explicitly means the same thing as "component
>>> *::before".  Similarly, "component ::piece" would mean the same thing
>>> as "component *::piece", which is definitely not what you're
>>> intending.  
>> It _is_ what I'm intending.
>>> This is part of the definition of pseudo-element syntax; I
>>> don't think it's reasonable to change it.
>> Not proposing to change it. I'm only proposing to relax the restrictions on it's use. So:
>> component ::part-one:hover ::sub-part-one[foo=bar]:nth-child(even) { ... }
>> would be valid.
> I would like to see that sort of loosening of pseudo-elements, regardless.

Yeah, we keep talking about it, but we never do it... we just need the compelling use case to drive it.


Received on Friday, 7 February 2014 07:37:26 UTC

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