Re: [css-scoping] Shadow Cascading

On Fri, Jun 12, 2015 at 3:47 PM Rune Lillesveen <rune@opera.com> wrote:

> 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?
>
>
Yeah, they are always same (in terms of relative order)! I thought there is
a case where they are different. However, I can't find a case where they
are different. That's an unintentional outcome, however it sounds a good
news to us.


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