Re: [css-scoping] Shadow Cascading

Yes, the scopes established by NODE's own shadow roots must be
included for :host and :host-context.

While the proposed scope linearization algorithm describes which
scopes may contain rules that apply to NODE, isn't it so that the
inner/outer scope order is simply the tree-of-trees order of the
scopes?

On Fri, Jun 12, 2015 at 8:29 AM, Hayato Ito <hayato@google.com> wrote:
> I found one drawback.
>
> If a NODE is a shadow host, the result of the scope linearization algorithm
> may not include the scope of the shadow tree, where ":host' might be used in
> the selector.
> For a shadow host and ':host' rules, we might want to prepend the scope of
> the shadow tree to SCOPES.
>
> I'm assuming that "::content()" can take only a simple selector, as we
> discussed in other places.
>
> On Fri, Jun 12, 2015 at 2:57 PM Hayato Ito <hayato@google.com> wrote:
>>
>> Rune's proposal looks good to me.
>>
>> I've spec-ed it briefly here. I appreciate any feedbacks.
>>
>> An additional cascade criteria must be added, between Origin and Scope,
>> called Shadow Tree.
>>
>> Shadow Tree Criteria:
>> When comparing two declarations, if they are in different node trees, then
>> for normal rules the declaration from the *outer* node tree wins, and for
>> important rules the declaration from the *inner* node tree wins.
>>
>> *outer/inner* is defined by the following scope linearization algorithm.
>>
>> The scope linearization algorithm:
>> Input
>>   NODE, a node
>> Output
>>   SCOPES, the ordered list of scopes. From inner to outer.
>>
>> 1. Let SCOPES be the empty ordered list of scopes
>> 2. Let CURRENT be NODE
>> 3. Repeat while CURRENT exists:
>>    1. If CURRENT is either Shadow Root or Document:
>>       1. Append CURRENT to SCOPES
>>    2. If the destination insertion points of CURRENT is not empty:
>>       1. Let CURRENT be the final destination of CURRENT
>>    3. Otherwise:
>>       1. Let CURRENT be the deep parent of CURRENT
>>
>>
>> On Fri, Jun 12, 2015 at 1:10 PM Koji Ishii <kojiishi@gmail.com> wrote:
>>>
>>> On Thu, Jun 11, 2015 at 5:04 PM, Rune Lillesveen <rune@opera.com> wrote:
>>>>
>>>>
>>>> [snip]
>>>>
>>>>
>>>>
>>>> >> For the example above, the composed tree path from the <inner>
>>>> >> element
>>>> >> and up is:
>>>> >>
>>>> >>   inner -> host2 -> div -> host1_1 -> host1
>>>> >>
>>>> >> This gives a total parent/child ordering of the scopes that apply to
>>>> >> a
>>>> >> given element:
>>>> >>
>>>> >>   scope(D) -> scope(C) -> scope(B) -> scope(A)
>>>> >>
>>>> >> If you include the shadow roots you pass through traversing the
>>>> >> composed tree, you end up with:
>>>> >>
>>>> >>   inner -> scope(D) -> host2 -> div -> scope(C) -> host1_1 ->
>>>> >> scope(B)
>>>> >> -> host1 -> scope(A)
>>>> >>
>>>> >> (should work for multiple shadow roots as well)
>>>> >>
>>>> >> The ordering of rules from stylesheets A-D for the <inner> element
>>>> >> would then be:
>>>> >>
>>>> >> 1. scope(D) Important
>>>> >> 2. scope(C) Important
>>>> >> 3. scope(B) Important
>>>> >> 4. scope(A) Important
>>>> >> 5. scope(A) normal
>>>> >> 6. scope(B) normal
>>>> >> 7. scope(C) normal
>>>> >> 8. scope(D) normal
>>>> >>
>>>> >> That means specificity will not make a rule from one shadow tree beat
>>>> >> a rule from another. I don't know why it currently is like that, or
>>>> >> if
>>>> >> it makes sense.
>>>> >
>>>> > Yes, "Origin and Scopes" should win over the specificity in terms of
>>>> > the
>>>> > priority. I believe that's what the current spec defines, and that's
>>>> > what
>>>> > you would like it to be, right?
>>>>
>>>> Yes. The current spec says so for inner/outer, but not for scopes
>>>> which do not have a parent/child relationship in the tree-of-trees.
>>>
>>>
>>> Right, I got your point.
>>>
>>> IIUC we're in consensus that when comparing two declarations in different
>>> trees, the Shadow Tree cascade criteria[1] should define to use the composed
>>> tree to define which tree wins.
>>>
>>> What I meant was, assuming it was fixed, it catches all different trees
>>> cases that the criteria in lower priorities (Scopes, Specificity, and Order
>>> of Appearance[2]) does not affect precedence. Specificity is determined per
>>> declaration, so we do not want to fall back to it when comparing two
>>> declarations in different trees.
>>>
>>> One thing we need to solve is that, when you build an ordered list of
>>> tree scopes from a composed tree, a node tree could appear multiple times. I
>>> discussed this with Hayato, he'll give some thoughts on it and follow up on
>>> this thread.
>>>
>>> [1] http://dev.w3.org/csswg/css-scoping/#cascading
>>> [2] http://dev.w3.org/csswg/css-cascade/#cascading

-- 
Rune Lillesveen

Received on Friday, 12 June 2015 06:48:24 UTC