Re: ::part Additions

On Tue, Jul 2, 2013 at 9:16 AM, Bronislav Klučka
<Bronislav.Klucka@bauglir.com> wrote:
> On 2.7.2013 18:03, Tab Atkins Jr. wrote:
>> On Tue, Jul 2, 2013 at 8:52 AM, Bronislav Klučka
>> <Bronislav.Klucka@bauglir.com> wrote:
>>>
>>> On 2.7.2013 17:28, Tab Atkins Jr. wrote:
>>>>
>>>> On Tue, Jul 2, 2013 at 6:32 AM, Bronislav Klučka
>>>> <Bronislav.Klucka@bauglir.com> wrote:
>>>>>
>>>>> 2/ change of part attribute from DOMString to DOMTokenList
>>>>
>>>> This sounds all right.  part='' is already class-like, since multiple
>>>> elements can have the same part='' value.  The example at your page is
>>>> pretty compelling about this ability's usage.  I guess ::part() would
>>>> also expand to taking a list of idents.
>>>
>>> Why would it? We have established convention for AND operator
>>> .class1.class2
>>> would became
>>> ::part(node-checked)::part(node-selected)
>>>
>>> and for OR operator
>>> .class1, .class2
>>> would became
>>> ::part(node-checked), ::part(node-selected)
>>>
>>> :matches(.class1, .class2)
>>> would became
>>> :matches(::part(node-checked), ::part(node-selected))
>>
>> Oh, no no no.  ::part() is not a pseudo-class, it's a pseudo-element -
>> it points to a brand new element, rather than filtering the one you've
>> got.  The fact that part='' is acting like class='' notwithstanding,
>> using ::part() like would be an abuse of the syntax.  If we want to
>> support this, it has to be through something like "::part(node-checked
>> node-selected)".
>>
>> As an example of why violating the syntax model is a bad idea, this
>> directly conflicts with your desire to surface the ::part()s of nested
>> components - the thing that exposes them might be exposed as a
>> ::part() as well, so you need to be able to chain off of an existing
>> ::part(), like "x-video::part(controls)::part(play-button)" (assuming
>> the controls were actually implemented by another component nested
>> inside the <x-video> shadow tree).
>
> so
> x-video::part(controls)::part(play-button)
> would target part="play-button" within part="controls" within x-video?

Not quite what I intended.  I was thinking that ::part(controls) would
be an <x-controls> element or something, and ::part(play-button) would
be in the <x-controls> shadow tree.

> and the list of idents
> ::part(part1 part2) {without comma? with comma?}
> would target part="part1 part2"? an AND operator?
>
> the OR I've mentioned being correct?

Yes to all.

> so how about this:
>
> ::part(node-checked)::part(node-selected)
> would represent any selected node within checked node (regardless of level
> of nesting)
> ::part(node-checked) > ::part(node-selected)
> would represent selected node within checked node (directly within, no other
> part in between)

No, this is definitely inconsistent.  The first one would have to be
"::part(node-checked) ::part(node-selected)" (with a space between
them).

An alternative is to go the ::content route, and kill the parentheses.
 As soon as you type ::part, you're in the "surface shadow tree" of
the component (which respects the shape of the real shadow tree, but
may skip nodes), and can then use the standard selectors/combinators
to get through it.

You'd need some additional work to make multiple part values work,
perhaps just treating part='' literally as a class, like:

x-video::part .play-button

Selecting multiple would be:

x-tree::part .node-checked.node-selected

(though I'd change the part='' stuff around so I could just write
".node.checked.selected")

Selecting children would be:

x-tree::part .node-checked .node-selected

Descending into nested shadow trees would just involve adding more
::part pseudos to the correct places.

~TJ

Received on Tuesday, 2 July 2013 20:25:22 UTC