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

Re: [css-scoping] Shadow Cascading

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 15 May 2015 15:14:51 -0700
Message-ID: <CAAWBYDBg_LoAg3q7w14ynZ6UgaBQADOihFcPmrVm+WC=Za-Vng@mail.gmail.com>
To: Rune Lillesveen <rune@opera.com>
Cc: Hayato Ito <hayato@google.com>, www-style list <www-style@w3.org>
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
Received on Friday, 15 May 2015 22:15:38 UTC

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