Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 3:51 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 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.

? I didn't mention DOM APIs.  I'm referring back to the example you're
replying to - if you use a <bar> element inside your <foo> component,
and you know that <bar> has isolation styles, you have to specifically
call that out inside your <foo> styling so that it (a) is shielded
from your foo styles, and (b) is able to pick up the global definition
for bar styles.  This is relatively clumsy.  Some of the other
solutions attach the "I want to be isolated" information to the
element itself more directly, so you don't have to worry about what
you put inside of yourself.

>>>> 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.

I listed a number of APIs in the text you're responding to, all of
which may or may not want to pay attention to style isolation,
depending on the use-case.  I'm not saying you necessarily need DOM
isolation for any given use-case.  I'm saying that there are a lot of
APIs that query or walk the DOM, and whether they should pay attention
to a "style isolation" boundary is a question without clear answers.

~TJ

Received on Tuesday, 13 January 2015 00:11:21 UTC