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

Re: [css-scoping] Shadow Cascading

From: Koji Ishii <kojiishi@gmail.com>
Date: Fri, 12 Jun 2015 13:10:55 +0900
Message-ID: <CAN9ydbUFvf75fdbQp+UAk_LekrJYCQ7+sfC94bUW8dEsipYLZQ@mail.gmail.com>
To: Rune Lillesveen <rune@opera.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Hayato Ito <hayato@google.com>, www-style list <www-style@w3.org>, sorvell@google.com, Elliott Sprehn <esprehn@google.com>, Olli Pettay <olli@pettay.fi>
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 04:11:22 UTC

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