Re: [shadow-dom] ::before/after on shadow hosts
Oops, found that you were already there :) https://code.google.com/p/chromium/issues/detail?id=393490#c15 On Fri, Jul 3, 2015 at 2:49 PM, Takayoshi Kochi (河内 隆仁) ko...@google.com wrote: Sorry for coming late, but - crbug.com/393490 Before and After pseudo elements don't work in ShadowRoots (with :host styles) - crbug.com/393509 :host()::before or :host()::after should work have the relevant discussion about the current implementation in Blink (#2). On Thu, Jul 2, 2015 at 1:16 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: All right, sounds pretty unanimous that #2 (current behavior) is what we should go with. I'll clarify the Scoping spec. Thanks! ~TJ -- Takayoshi Kochi -- Takayoshi Kochi
Re: [shadow-dom] ::before/after on shadow hosts
Sorry for coming late, but - crbug.com/393490 Before and After pseudo elements don't work in ShadowRoots (with :host styles) - crbug.com/393509 :host()::before or :host()::after should work have the relevant discussion about the current implementation in Blink (#2). On Thu, Jul 2, 2015 at 1:16 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: All right, sounds pretty unanimous that #2 (current behavior) is what we should go with. I'll clarify the Scoping spec. Thanks! ~TJ -- Takayoshi Kochi
Re: [shadow-dom] ::before/after on shadow hosts
All right, sounds pretty unanimous that #2 (current behavior) is what we should go with. I'll clarify the Scoping spec. Thanks! ~TJ
Re: [shadow-dom] ::before/after on shadow hosts
#2 for sure On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. jackalm...@gmail.com wrote: I was recently pointed to this StackOverflow thread http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/ which asks what happens to ::before and ::after on shadow hosts, as it's not clear from the specs. I had to admit that I hadn't thought of this corner-case, and it wasn't clear what the answer was! In particular, there seem to be two reasonable options: 1. ::before and ::after are *basically* children of the host element, so they get suppressed when the shadow contents are displayed 2. ::before and ::after aren't *really* children of the host element, so they still show up before/after the shadow contents. According to the SO thread (I haven't tested this myself), Firefox and Chrome both settled on #2. I'm fine to spec this in the Scoping module, I just wanted to be sure this was the answer we wanted. ~TJ
Re: [shadow-dom] ::before/after on shadow hosts
On 07/01/2015 02:48 AM, Tab Atkins Jr. wrote: I was recently pointed to this StackOverflow thread http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/ which asks what happens to ::before and ::after on shadow hosts, as it's not clear from the specs. I had to admit that I hadn't thought of this corner-case, and it wasn't clear what the answer was! In particular, there seem to be two reasonable options: 1. ::before and ::after are *basically* children of the host element, so they get suppressed when the shadow contents are displayed 2. ::before and ::after aren't *really* children of the host element, so they still show up before/after the shadow contents. According to the SO thread (I haven't tested this myself), Firefox and Chrome both settled on #2. I'm fine to spec this in the Scoping module, I just wanted to be sure this was the answer we wanted. ~TJ Just after reading the first paragraph and without knowing what the implementations do in this case I thought #2 would be the most obvious behavior to have. -Olli
Re: [shadow-dom] ::before/after on shadow hosts
::before and ::after are basically *siblings* of the shadow host, That's not a correct sentence. ::before and ::after shouldn't be a siblings of the shadow host. I just wanted to say that #2 is the desired behavior. On Wed, Jul 1, 2015 at 1:01 PM Hayato Ito hay...@chromium.org wrote: The spec [1] also says: ::before Represents a styleable child pseudo-element immediately before the originating element’s actual content. ::after Represents a styleable child pseudo-element immediately before the originating element’s actual content. It sounds to me that ::before and ::after are basically *siblings* of the shadow host, instead of children. I think that should be the intended behavior. [1] http://www.w3.org/TR/css-pseudo-4/#generated-content On Wed, Jul 1, 2015 at 12:33 PM Erik Isaksen nevra...@gmail.com wrote: #2 for sure On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. jackalm...@gmail.com wrote: I was recently pointed to this StackOverflow thread http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/ which asks what happens to ::before and ::after on shadow hosts, as it's not clear from the specs. I had to admit that I hadn't thought of this corner-case, and it wasn't clear what the answer was! In particular, there seem to be two reasonable options: 1. ::before and ::after are *basically* children of the host element, so they get suppressed when the shadow contents are displayed 2. ::before and ::after aren't *really* children of the host element, so they still show up before/after the shadow contents. According to the SO thread (I haven't tested this myself), Firefox and Chrome both settled on #2. I'm fine to spec this in the Scoping module, I just wanted to be sure this was the answer we wanted. ~TJ
Re: [shadow-dom] ::before/after on shadow hosts
On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito hay...@chromium.org wrote: ::before and ::after are basically *siblings* of the shadow host, That's not a correct sentence. ::before and ::after shouldn't be a siblings of the shadow host. I just wanted to say that #2 is the desired behavior. Indeed they're children, immediately before and immediately after the composed children of an element. fwiw this is also how it must work to prevent breaking the web or implementing special cases. input (and textarea) has a ShadowRoot and input::before and input::after are both common ways to add decorations to input elements. I broke this once in WebKit and we found all that content. - E
Re: [shadow-dom] ::before/after on shadow hosts
The spec [1] also says: ::before Represents a styleable child pseudo-element immediately before the originating element’s actual content. ::after Represents a styleable child pseudo-element immediately before the originating element’s actual content. It sounds to me that ::before and ::after are basically *siblings* of the shadow host, instead of children. I think that should be the intended behavior. [1] http://www.w3.org/TR/css-pseudo-4/#generated-content On Wed, Jul 1, 2015 at 12:33 PM Erik Isaksen nevra...@gmail.com wrote: #2 for sure On Tue, Jun 30, 2015, 4:52 PM Tab Atkins Jr. jackalm...@gmail.com wrote: I was recently pointed to this StackOverflow thread http://stackoverflow.com/questions/31094454/does-the-shadow-dom-replace-before-and-after/ which asks what happens to ::before and ::after on shadow hosts, as it's not clear from the specs. I had to admit that I hadn't thought of this corner-case, and it wasn't clear what the answer was! In particular, there seem to be two reasonable options: 1. ::before and ::after are *basically* children of the host element, so they get suppressed when the shadow contents are displayed 2. ::before and ::after aren't *really* children of the host element, so they still show up before/after the shadow contents. According to the SO thread (I haven't tested this myself), Firefox and Chrome both settled on #2. I'm fine to spec this in the Scoping module, I just wanted to be sure this was the answer we wanted. ~TJ
Re: [shadow-dom] ::before/after on shadow hosts
Yeah, ::before and ::after should be added as the children of the shadow host in the composed tree, as a *pseudo* first child and a *pseudo* last child. On Wed, Jul 1, 2015 at 1:15 PM Elliott Sprehn espr...@chromium.org wrote: On Wed, Jul 1, 2015 at 12:08 AM, Hayato Ito hay...@chromium.org wrote: ::before and ::after are basically *siblings* of the shadow host, That's not a correct sentence. ::before and ::after shouldn't be a siblings of the shadow host. I just wanted to say that #2 is the desired behavior. Indeed they're children, immediately before and immediately after the composed children of an element. fwiw this is also how it must work to prevent breaking the web or implementing special cases. input (and textarea) has a ShadowRoot and input::before and input::after are both common ways to add decorations to input elements. I broke this once in WebKit and we found all that content. - E
