- From: Marc Fawzi <marc.fawzi@gmail.com>
- Date: Mon, 12 Jan 2015 20:23:18 -0800
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
- Message-ID: <CACioZivkSLXmDXh5Lb6u0HdkXk25pXRsynxQQw1JO+_wwJoT6w@mail.gmail.com>
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 > > >
Received on Tuesday, 13 January 2015 04:24:26 UTC