- From: Hayato Ito <hayato@google.com>
- Date: Tue, 13 Jan 2015 05:02:00 +0000
- To: Marc Fawzi <marc.fawzi@gmail.com>, 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: <CAFpjS_082opkUXSmB8gpdhezW_G0zzPoMw2wv7it1UXs2rhfWQ@mail.gmail.com>
"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 >> >> >> >
Received on Tuesday, 13 January 2015 05:02:28 UTC