Re: [css-scoping] Shadow Cascading

On Fri, May 15, 2015 at 2:59 PM, 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.

Looks like WebApps agreed to drop the shadow-piercing stuff from CSS's
dynamic profile anyway, so this thread is (luckily) moot.

~TJ