Re: [css-scoping] Shadow Cascading

On Thu, Jun 11, 2015 at 7:53 AM, Koji Ishii <kojiishi@gmail.com> wrote:
> Back to the Rune's proposal:
>
> On Sat, May 16, 2015 at 6:59 AM, Rune Lillesveen <rune@opera.com> wrote:
>>
>> On Fri, Feb 6, 2015 at 10:11 AM, Rune Lillesveen <rune@opera.com> wrote:
>> > On Fri, Feb 6, 2015 at 1:13 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>> > wrote:
>> >
>> >> Hmm, you're right, this isn't very stable.  If you remove #3, it
>> >> completely changes the ordering, so that #2 sorts ahead of #1, rather
>> >> than at the end.  The ordering of any two declarations shouldn't be
>> >> affected by the presence or absence of other declarations.
>> >>
>> >> We should fix this up somehow to make things work better.  It probably
>> >> means adding some special cascade behavior for ::content?
>> >
>> > I don't have experience in making real web components.
>> >
>> > I don't know the rationale for handling re-distribution to shadow tree
>> > siblings differently from distribution to shadow trees for other
>> > hosts.
>> >
>> > If specificity should beat ordering for redistribution and ::content
>> > through different hosts, like the spec says now, why isn't that what
>> > you want for re-distribution through shadow tree siblings as well?
>>
>> We have a similar sort of complex inter-dependencies even with single
>> shadow roots when some of the scopes have an ascendant/descendant
>> relationship in the tree-of-trees, and some not.
>>
>> Example:
>>
>> <style id="A"></style>
>> <host1>
>>     <:shadowroot>
>>         <style id="B"></style>
>>         <host1_1>
>>             <:shadowroot>
>>                 <style id="C"></style>
>>                 <div>
>>                     <content/>
>>                 </div>
>>             </:shadowroot>
>>             <content/>
>>         </host1_1>
>>     </:shadowroot>
>>     <host2>
>>         <:shadowroot>
>>             <style id="D"></style>
>>             <content/>
>>         </:shadowroot>
>>         <inner/>
>>     </host2>
>> </host1>
>>
>> Plain ::content rules stylesheets A, B, C and D may apply to <inner>.
>>
>> Rules from A beats non-important rules in B, C, D because it's in an
>> outer scope.
>> Rules from B beats non-important rules in C (outer scope).
>> Rules from B and C beats rules in D if they have higher specificity,
>> but D wins for rules with the same specificity because of
>> order-of-appearance in the tree-of-trees.
>> Then, !important rules also have to be taken into account, turning
>> things upside down for inner/outer case.
>>
>> This is mildly said complicated to implement.
>>
>> It should be noted that Blink currently only tries to implement the
>> tree-of-trees order-of-appearance part of the cascading order in the
>> CSS Scoping spec, which means specificity currently trumps scope. Even
>> that part has bugs [1].
>>
>> What I think would be simpler, both to grasp for authors(?), and to
>> implement, is to specify the cascading order in terms of the composed
>> tree.
>
> We discussed on your proposal, and this sounds like a reasonable change to
> us. What's important to us is the conceptual notion of the outer scope wins
> over the inner scope. As long as it is kept, I agree that using the composed
> tree can solve complex cases.

Yes outer/inner scope priority is kept as currently specified. I'm
introducing scope order between all scopes. Even those that don't have
an ascendant/descendant relationship in the tree-of-trees.

I don't think these are complex cases, btw. At least they are real
world cases with Polymer. I inspected the Google I/O site and found
that the <paper-tab> component has a rule for padding for "::content >
a". If a <paper-tab> is distributed to <my-component>'s shadow tree
below, a "::content > #linkid" selector in <my-component>'s shadow
tree will currently win over the one in <paper-tab>, while "::content
> a" would not. That is what my proposal is trying to fix, so that
normal rules for "a" in <my-component> will win over <paper-tab>
regardless of specificity, while !important rules in <paper-tab> would
win over <my-component>.

<my-component>
  <paper-tab>
    <a id="linkid">mylink</a>
  </paper-tab>
</my-component>

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

-- 
Rune Lillesveen

Received on Thursday, 11 June 2015 08:05:22 UTC