Re: Shadow tree style isolation primitive

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