Re: ::part Additions

there are still too many strange things going on :]
see below

On 2.7.2013 22:19, Tab Atkins Jr. wrote:
> 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.
so it would select something like
<x-video>
    #SHADOW ROOT
        <x-controls>
           #SHADOW ROOT
              <div part=play-button></div>
        <x-controls>
</x-video>

how is it, that one time the ::part targets element and other time 
attribute? or is it

<x-video>
    #SHADOW ROOT
        <x-controls>
           #SHADOW ROOT
              <x-play-button></x-play-button>
        <x-controls>
</x-video>
?
in both cases, how can you target element inside shadow tree? or do you 
essentially mean
<x-video>
    #SHADOW ROOT
        <x-controls part=controls>
           #SHADOW ROOT
              <x-play-button part=play-button></x-play-button>
        <x-controls>
</x-video>

so the no space syntax means crossing shadow boudaries and space syntax 
means no crossing
so

x-video::part(controls) ::part(play-button) //with space
would mean

<x-video>
    #SHADOW ROOT
        <x-controls part=controls>
              <x-play-button part=play-button></x-play-button>
        <x-controls>
</x-video>

I have a problem with that, described below

>
>> 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.
And that is exactly the problem, TreeView, popup menu, pretty much every 
controls containers (thing about placing tabs into one tab of another 
tabs, that is placed into on tab of the third tabs)
The shadow nesting could go on and on, there is no way you can style 
that without knowing the exact structure

if I would want all LI to have disc, all I can do is type
li { list-style-type: disc; }
and it's always, everywhere

If I would want all inactive tabs of TabControl (implemented using 
shadow) to have gray text color what would I do? just wondering...
cannot target
tab-control::part(tabs) ::part(inactive) - you cannot target 
<tab-control> element by it's name if the tab control is inside shadow 
dom inside shadow
can you target
::part(tabs) ::part(inactive)
without the element selector? does this goes all the way through all 
possible nested shadow dom? What if tab is placed inside shadow dom of 
control, that is not tab (in generic CSS something like: container1 
container2 tabControl tabs .inactive)
//can i somehow make :not work here? as :not(::part(active)) ? so then 
what other parts?

it somehow makes it impossible to distinguish among different controls, 
so I would somehow have to "ID" them with token in part attribute of the 
control itself...

the question is, how to style custom element regardless of it's position 
within dom / shadow dom
would you actually have to duplicate?
<tab-controls part=tab-controls>
and then go with
::part(tab-controls)?
or actually
tab-controls, ::part(tab-controls)
to reach tab control directly in document and in shadow dom?

I'm actually comparing this to styling controls in something like Delphi 
or VisualStudio...

Brona

Received on Wednesday, 3 July 2013 00:00:43 UTC