Re: Shadow DOM Encapsulation

> On Feb 6, 2014, at 11:37 PM, Peter Linss <peter.linss@hp.com> wrote:
> 
> 
>> 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?

Possibly. Other than things like 'select optgroup option', which has no pseudo syntax or piercing syntax, we don't have real precedents. I guess there some WebKit-prefixed things for selecting scrollbar elements, but those are pretty unwieldy. I wouldn't mind writing 'input[type=file] ^ button'.

> No, you'll use pseudo elements...

I think that part is debatable. But if so, I'd prefer just one per element, such as 'foo::shadow bar'. As you say, this syntax part is orthogonal to the part that defines what internal structure you expose.

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

The simplest for authors at that point would be to select the way internals like 'optgroup' and 'option' are selected now: with no new combinators or pseudos. More than that, the author still has to learn what pseudo to use or what combinator to use. At that point, one new pseudo like '::shadow' has the advantage of being easier to learn and recognize than a new combinator. The things being selected inside have to have their names learned anyway, and it would be easier to not have to put double colons in front of each and every one of them.

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

OK, agreed.

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

Yes, maybe this is it. Some of the arguments against pseudo-elements vs. combinators seem to be rooted in the idea that how pseudo-elements must continue to have their current restrictions, with no spaces before or after them, and I'd like that argument to disappear.

Received on Friday, 7 February 2014 15:36:29 UTC