Re: Shadow tree style isolation primitive

On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> [ryosuke, your mail client keeps producing flattened replies. maybe
>> send as plain-text, not HTML?]
>
> Weird.  I'm not seeing that at all on my end.

It's sending HTML-quoted stuff, which doesn't survive the flattening
to plain-text that I and a lot of others do.  Plain-text is more
interoperable.

>> The style defined for <bar> *in <bar>'s setup code* (that is, in a
>> <style> contained inside <bar>'s shadow tree) works automatically
>> without you having to care about what <bar> is doing.  <bar> is like a
>> replaced element - it has its own rendering, and you can generally
>> just leave it alone to do its thing.
>
> If that's the behavior we want, then we should simply make @isolate pierce through isolates.  You previously mentioned that:
>
>> On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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.
>
> But this same problem seems to exist in shadow DOM as well.  We can't have a <bar> inside a <foo> behave differently from ones outside <foo> since all bar elements share the same implementation.  I agree

Yes!  But pay attention to precisely what I said: it's problematic to,
for example, have a command to isolate all class=example elements
pierce through isolation boundaries, because classes aren't expected
to be unique in a page between components - it's very likely that
you'll accidentally hit elements that aren't supposed to be isolated.
It's okay to have *element name* isolations pierce, though, because we
expect all elements with a given tagname to be the same kind of thing
(and Web Components in general is built on this assumption; we don't
scope the tagnames in any way).

But then we're not actually providing selectors to the isolate
mechanism, we're just providing tagnames, and having that affect the
global registry of tagnames.  That's fine, it's just a different type
of solution, with different contours, and it's much closer to normal
web components stuff.  (And thus it makes more sense to stick as close
to web components as reasonable, to reduce the number of
slightly-different concepts authors have to think about.)

~TJ

Received on Tuesday, 13 January 2015 02:12:16 UTC