Re: ::part Additions

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

~TJ

Received on Tuesday, 2 July 2013 16:04:02 UTC