Re: Shadow tree style isolation primitive

> On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> 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).

I don't want to go too much on a tangent but it seems like this is a dangerous assumption to make once components start depending on different versions (e.g. v1 versus v2) of other components.  Also, it's not hard to imagine authors may end up defining custom elements of the same name to be used in their own components.  If someone else then pulls in those two components, one of them will be broken.

To solve a dependency problem like this, we need a real dependency resolution mechanism for components.

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

I don't think having a global registry of tag names is a sufficient nor a necessary mechanism to address the issue at hand.  As such, I'm not suggesting or supporting that.

- R. Niwa

Received on Tuesday, 13 January 2015 02:27:35 UTC