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

Re: Shadow tree style isolation primitive

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 12 Jan 2015 15:51:11 -0800
Cc: Anne van Kesteren <annevk@annevk.nl>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
Message-id: <491D7A3E-C0AF-4388-83A5-88340BF05B6F@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

> On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>>> On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> Let's assume we did it, though.  We'd have to have some mechanism for
>>> defining an isolation boundary, and denoting whether rules were
>>> "inside" or "outside" the boundary.  This sounds like an at-rule,
>>> like:
>>> @isolate .example {
>>> h1 { ... }
>>> div { ... }
>>> }
>>> Now, a problem here is that you have a conflict between nesting
>>> isolated things and specifying isolation.  Say you have <foo> and
>>> <bar> elements, both of which need to be isolated. You'd think you
>>> could just write:
>>> @isolate foo {
>>> ...
>>> }
>>> @isolate bar {
>>> ...
>>> }
>>> But this won't work! If you have markup like
>>> <foo><bar>...</bar></foo>, the <bar> there is inside the <foo>'s
>>> isolation boundary, so the @isolate rule can't find it.  You'd need to
>>> *also* nest the "@isolate bar" rule (and all its styling rules) within
>>> the foo one, and vice versa.  The effect of this on *three* mutually
>>> isolated components is, obviously, terrible; let's not even mention
>>> trying to use multiple modules together that weren't explicitly
>>> designed together.
>>> Alternately, say that it does work - the @isolate selector pierces
>>> through isolation boundaries.  Then you're still screwed, because if
>>> the outer page wants to isolate .example blocks, but within your
>>> component you use .example normally, without any isolation, whoops!
>>> Suddenly your .example blocks are isolated, too, and getting weird
>>> styles applied to them, while your own styles break since they can't
>>> cross the unexpected boundary.
>> Another alternative.  We can add a host language dependent mechanism such as an element or an attribute to "end" the current isolation, just like insertion points in a shadow DOM would.
>> Better yet, we can provide this mechanism in CSS. e.g.
>> @isolate foo integrates(bar) {
>>  ...
>> }
>> @isolate bar {
>>  ...
>> }
>> (I'm not proposing this exact syntax. We can certainly do better.)
> Yeah, something like that would work, but it also means you need to
> account for all the things that might want to be isolated in your
> component.  That's relatively clumsy.

Examples?  Are you talking about DOM APIs such as querySelectorAll and alike?  Then, please refer to my other reply [1] in which I listed use cases that involve no author scripts.

>>> This last one, though, is pretty much exactly Custom Elements, just
>>> with the children staying in the light tree rather than being moved
>>> into a shadow tree.  But keeping them in the light tree has
>>> complications; it means that everything in the platform needs to be
>>> made aware of the isolation boundary.  Should qSA respect the
>>> isolation boundaries or not?  Depends on what you're using it for.
>>> What about things that aren't CSS at all, like getElementsByTagName()?
>>> That's equivalent to a qSA with the same argument, but it's not a
>>> "selector", per se.  Manual tree-walking would also need to be made
>>> aware of this, or else you might accidentally descend into something
>>> that wants isolation.  Shadow DOM at least gives an answer to all of
>>> these, by putting the elements in a separate tree.  You don't need to
>>> think of every one individually, or deal with inconsistent design when
>>> someone forgets to spec their new tree-searching thing to respect the
>>> boundary.
>> Let's not conflate style isolation with isolation of DOM subtrees.  They're two distinct features.  Even though I do agree it might be desirable to have both in many important use cases, there are use cases in which we don't need subtree isolations.
> I'm not trying to, I'm pointing out that "style isolation", as a
> concept, seamlessly blends into "DOM isolation" as you move across API surfaces.

I don't see any connection between the two.  Many of the use cases I listed [1] require us to have DOM isolations.

Now, I agree there are use cases in which such DOM isolation mechanisms are desirable.  If we didn't want to add two separate mechanisms to address both use cases, we could use a host language dependent mechanism such as a dedicated HTML attribute to define a boundary.

[1] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0112.html

- R. Niwa
Received on Monday, 12 January 2015 23:52:01 UTC

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