Re: Shadow tree style isolation primitive

"Intent to remove <style scoped>" in blink-dev is here:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R1x18ZLS5qQ
On Tue Jan 13 2015 at 1:26:52 PM Marc Fawzi <marc.fawzi@gmail.com> wrote:

> Can someone shed light at why Scoped Style Element was removed from Chrome
> experimental features?
>
> http://caniuse.com/#feat=style-scoped
>
> In suggesting @isolate declaration, I meant it would go inside a scoped
> style element. If there are nested scope style elements and each have
> @isolate then it means that the styles don't bleed from parent with scoped
> style to child with scoped style if child has @isolate
>
> The big question is why was scoped style element removed from Chrome 37's
> experimental flags?
>
> Just curious.
>
>
>
> On Mon, Jan 12, 2015 at 6:27 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>
>>
>> > 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
>>
>>
>>
>