Intent to Ship: shadow-piercing descendant combinator, '>>>'

[Hayato Ito]

Contact emails

hay...@chromium.org

Spec

http://dev.w3.org/csswg/css-scoping-1/#deep-combinator

Summary

'>>>', shadow piercing combinator, is the new name for '/deep/' combinator. Blink has already shipped a '/deep/' combinator. We have to rename it to '>>>'.

Link to “Intent to Implement” blink-dev discussion

No. I'd like to skip this. This is renaming '/deep/' to '>>>', basically.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

The line to the article about the usage of the '/deep/' is  http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/#toc-style-cat-hat

Compatibility Risk

No. '/deep/' will be deprecated via 'Intent to deprecate' separately after shipping '>>>'. Both, '/deep/' and '>>>', co-exist for a while.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=446051

[ad...@chromium.org]

Non-owner LGTM. We'll want to update the Web Component polyfills that projects like Polymer use to support the revised combinator name. Filed an issue.

[Rune Lillesveen]

On Wed, Jan 28, 2015 at 6:34 AM, Hayato Ito <hay...@chromium.org> wrote:
> Contact emails
> hay...@chromium.org
>
> Spec
> http://dev.w3.org/csswg/css-scoping-1/#deep-combinator
>
> Summary
> '>>>', shadow piercing combinator, is the new name for '/deep/' combinator.
> Blink has already shipped a '/deep/' combinator. We have to rename it to
> '>>>'.

non-owner lgtm as long as we have a high confidence the spec won't change again.

I tried to find a www-style discussion about the change without luck.

--
Rune Lillesveen

[Kouhei Ueno]

non-owner lgtm

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

Kouhei Ueno

[Adam Klein]

On Tue, Jan 27, 2015 at 9:34 PM, Hayato Ito <hay...@chromium.org> wrote:

Compatibility Risk

No. '/deep/' will be deprecated via 'Intent to deprecate' separately after shipping '>>>'. Both, '/deep/' and '>>>', co-exist for a while.

What about compatibility with other browsers? My understanding is that Mozilla intends to implement Shadow DOM; have they offered any feedback about the '>>>' combinator?

- Adam

[Elliott Sprehn]

Can you link to the thread about why this is getting renamed? I thought the plan of the CSSWG was to make all selectors use the /name/ syntax and stop adding symbols like this.

[Hayato Ito]

It looks like It was the conclusion at CSSWG F2F.

http://lists.w3.org/Archives/Public/www-style/2014Jun/0106.html

|  - RESOLVED: Add ">>" as an alias for the descendant combinator,

|       and change /deep/ to >>>

I think Tab might know the better context behind the change.

You can see his comment: https://code.google.com/p/chromium/issues/detail?id=446051#c6

[Philip Jägenstedt]

The plan, which has already been spec'd, seems to be:

'>' child combinator: http://dev.w3.org/csswg/selectors/#child-combinators
whitespace or '>>' descendant combinator:
http://dev.w3.org/csswg/selectors/#descendant-combinators
'>>>' shadow-piercing descendant combinator:
http://dev.w3.org/csswg/css-scoping/#deep-combinator

That looks OK to me, although '>>' will be useless until supported
everywhere, many years from now.

William Chen and Olli Pettay: Judging by gecko-dev history you have
been doing most of the Shadow DOM work in Gecko. Please let us know if
you have any objections to '>>>'. I'll forward your reply if you can't
post to blink-dev.

Absent any objections, LGTM to ship both '>>>' and '>>' and to
deprecate '/deep/' in the same milestone. (If '>>' is shipped later
and found to not be Web compatible we'd be left in an odd state, and
deprecating '/deep/' later would delay the time until it can be
removed.)

Philip

[smaug]

On 01/29/2015 08:36 AM, Philip Jägenstedt wrote:
> The plan, which has already been spec'd, seems to be:
>
> '>' child combinator: http://dev.w3.org/csswg/selectors/#child-combinators
> whitespace or '>>' descendant combinator:
> http://dev.w3.org/csswg/selectors/#descendant-combinators
> '>>>' shadow-piercing descendant combinator:
> http://dev.w3.org/csswg/css-scoping/#deep-combinator
>
> That looks OK to me, although '>>' will be useless until supported
> everywhere, many years from now.
>
> William Chen and Olli Pettay: Judging by gecko-dev history you have
> been doing most of the Shadow DOM work in Gecko. Please let us know if
> you have any objections to '>>>'. I'll forward your reply if you can't
> post to blink-dev.
>
> Absent any objections, LGTM to ship both '>>>' and '>>' and to
> deprecate '/deep/' in the same milestone. (If '>>' is shipped later
> and found to not be Web compatible we'd be left in an odd state, and
> deprecating '/deep/' later would delay the time until it can b

> removed.)
>

Personally I've never been a fan of >>> since it lets one to accidentally select
stuff inside shadow DOM you might not be interested in or should not touch (because it is
'someone else's' shadow DOM). IMO Shadow Root should have a flag/name to opt-in to let >>> to see into itself, and
then >>> should take some param to see only into such named shadow DOM.

(We need to keep in mind that we'll probably want encapsulation for shadow DOM sooner or later).

But I'm not the one who would implement >>> in Gecko.


-Olli

[Philip Jägenstedt]

Are you saying that one might use >>> accidentally instead of >> or >,
or do have the same concern with /deep/?

It seems to me that the top-level page is ultimately able to do
whatever it wants, even if that means changing the code for the
components it uses. Any encapsulation would be to protect against
mistakes only, right?

In order to avoid such mistakes, couldn't one put an id on the shadow
host and use a selector like #shadowhostid >>> span?

Philip

[Boris Zbarsky]

On 1/29/15 9:47 AM, Philip Jägenstedt wrote:
> It seems to me that the top-level page is ultimately able to do
> whatever it wants, even if that means changing the code for the
> components it uses.

No, because components can be provided by the UA, whether by default
(think <input type="text">) or by extensions.

> Any encapsulation would be to protect against
> mistakes only, right?

Not if we have any hope of ever explaining form controls via web components.

-Boris

[smaug]

Same concern with deep.

>
> It seems to me that the top-level page is ultimately able to do
> whatever it wants, even if that means changing the code for the
> components it uses. Any encapsulation would be to protect against
> mistakes only, right?

Well, mistake is too weak word here. If you don't specifically control all the elements and shadow stuff there is in the
document (say, a page ends up merging different functionality done by different dev teams),
you may accidentally end up changing stuff you weren't going to.

>
> In order to avoid such mistakes, couldn't one put an id on the shadow
> host and use a selector like #shadowhostid >>> span?

That is doing rather specific filtering on parent side. If you do that, why use shadow dom at all?
And making such filtering opt-in wouldn't really work in general.


-Olli


>
> Philip

[Dimitri Glazkov]

This is https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775 in spec. The actual work of renaming of the combinator is orthogonal to the discussion, as mentioned before.

As a side note, I agree with the sentiment that shadow-piercing combinators are generally evil. I am still not sure whether they're a necessary evil. Given the inextensible black box that is CSS, they are for now, but CSS custom properties seem to offer at least a glimmer of hope.

:DG<

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Tab Atkins]

On Wed, Jan 28, 2015 at 4:56 PM, Elliott Sprehn <esp...@chromium.org> wrote:
> Can you link to the thread about why this is getting renamed? I thought the
> plan of the CSSWG was to make all selectors use the /name/ syntax and stop
> adding symbols like this.

That is still the plan, yes.

However, we needed a way to spell the descendant combinator that
wasn't a space (required for some corner cases when using relative
selectors), and went with the clever mnemonic that since the
descendant combinator is just a super-child combinator, it could be
spelled >>, to harmonize with the > of the child combinator.

Then, since the shadow-piercing combinator is just a super-descendant
combinator, we can spell it >>> for the same reason.

This was decided at one of the f2f meetings a while back.

~TJ

[Hayato Ito]

I think we can continue to discuss some of conversation topics in spec bugs, such as in  https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775, as Dimitri pointed out. I welcome any feedbacks about the concept of 'closed shadow tree'.

In this thread, I'd like to hear opinions about the pros and cons about renaming '/deep' to '>>>'. The functionality doesn't change at all.

A) Keep '/deep/' as is, which doesn't match the recent spec.

B) Rename it to '>>>'. It matches the recent spec change.

I thought that B is better than A.

[Philip Jägenstedt]

I'm slightly clueless on this topic, but my assumption has been that
internal uses of Shadow DOM would not be reachable with '>>>' or in
any way observable, as that would require standardizing the internal
structure of those shadow trees to have interoperability.

My assumption is currently wrong, however, as /deep/ can reach inside
<video controls> for example. That seems like a problem, because if
actually used it would limit our ability to change the controls.

Philip

[Hayato Ito]

The relevant discussion is on-going, though this is not updated recently, here:

https://code.google.com/p/chromium/issues/detail?id=433977

Philip

[Elliott Sprehn]

It shouldn't be able to, if it can, that's a bug. Crossing a type() boundary should never be allowed by any selector.

- E

[Tab Atkins Jr.]

Yes, browser-provided elements that use Shadow DOM implicitly use a
"sealed" form of it that we haven't defined yet in the spec. The >>>
combinator shouldn't be able to select into it, nor should the
::shadow pseudo-element match.

~TJ

[Philip Jägenstedt]

Thanks, I've filed https://code.google.com/p/chromium/issues/detail?id=454282

Philip

[Dimitri Glazkov]

The API Owners met yesterday and concluded that it doesn't seem like a good idea to proceed with this intent, given that we're not even sure we should keep shipping the /deep/ combinator.

:DG<

[PhistucK]

Are there plans to remove /deep/, then?

☆PhistucK

On Wed, Feb 4, 2015 at 8:23 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

The API Owners met yesterday and concluded that it doesn't seem like a good idea to proceed with this intent, given that we're not even sure we should keep shipping the /deep/ combinator.

:DG<

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dimitri Glazkov]

Not yet, but I am trying to figure this out.

:DG<

[ad...@chromium.org]

/deep/ piercing UA Shadow root seems like an inherent bug we should fix. We probably shouldn't encourage a styling world where internal widget structure becomes difficult to change because developers rely on it.

That said, I'm curious if we're exploring other styling mechanisms for native widgets as an alternative (I assume existing pseudo-selectors aren't being evolved). There's value in avoiding developers having to re-implement native controls themselves just to work around such limitations.