> On Jan 12, 2015, at 3:51 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > >> On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote: >> >> On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa <rn...@apple.com> wrote: >>>> On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. <jackalm...@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.
doesn't 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 >