W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-scoping] Shadow Cascading

From: Hayato Ito <hayato@google.com>
Date: Fri, 12 Jun 2015 06:29:13 +0000
Message-ID: <CAFpjS_24iA9w5LxVS5xSVRTbxvBHEONLnRpjB=e9rhByP0UsiA@mail.gmail.com>
To: Koji Ishii <kojiishi@gmail.com>, Rune Lillesveen <rune@opera.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>, sorvell@google.com, Elliott Sprehn <esprehn@google.com>, Olli Pettay <olli@pettay.fi>
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
>>
>>
Received on Friday, 12 June 2015 06:35:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC