Re: [css-scoping] Shadow Cascading

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
>>
>> /koji
>>
>>