Re: [css-scoping] Shadow Cascading

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