- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 12 Jan 2015 15:51:11 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
> 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:51:40 UTC