Intent to Ship: Slots in flat tree

106 views
Skip to first unread message

Rune Lillesveen

unread,
Feb 22, 2018, 9:47:03 AM2/22/18
to blink-dev

Contact emails

fut...@chromium.org, hay...@chromium.org


Spec

https://drafts.csswg.org/css-scoping/#flattening

https://html.spec.whatwg.org/multipage/scripting.html#the-slot-element

https://dom.spec.whatwg.org/#shadow-tree-slots


Tag review (not sure how relevant this is): https://github.com/w3ctag/design-reviews/issues/79


Summary

Make slot elements in shadow trees take part in the flat tree which makes them styleable as any other element. This is what has been specified for Shadow DOM, but Blink has not been following the spec here while WebKit has. This is also a pre-requisite for the implementing Incremental Shadow DOM (see the motivation section of the intent to implement below).


Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/5s1nbytTL68


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

Yes.


Risks

Interoperability and Compatibility

The interoperability risk with other browsers is if we don’t ship this. Compatibility issues would be for author content already using Shadow DOM v1 in Blink accidentally styling slot elements which currently does not have an effect, but would have when we ship this. For instance, if current content has “slot {color:red}”, it will have no effect, but it will make the color of the slot red and inherit that color down to flat tree descendants when this ships.


I have asked the Polymer team to run their tests against a Canary build with the runtime flag enabled, but I have not received any feedback yet.


Edge:Public support

Firefox:Public support

Safari: Shipped


Performance

Adding slots to the flat tree means we will generate computed style for them. This caused a regression in a microbenchmark where half of the elements in the document tree were slots. See issue 811423 which has been WontFixed.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/css/css-scoping/css-scoping-shadow-nested-slot-display-override.html

https://wpt.fyi/css/css-scoping/css-scoping-shadow-slot-display-override.html

https://wpt.fyi/css/css-scoping/css-scoping-shadow-slot-fallback.html

https://wpt.fyi/css/css-scoping/css-scoping-shadow-slot-style.html

https://wpt.fyi/css/css-scoping/css-scoping-shadow-slotted-rule.html

https://wpt.fyi/css/css-scoping/slotted-invalidation.html

https://wpt.fyi/css/css-scoping/slotted-slot.html


Entry on the feature dashboard

Feature dashboard entry


--
Rune Lillesveen

Yoichi Osato

unread,
Feb 22, 2018, 9:04:32 PM2/22/18
to Rune Lillesveen, blink-dev
Are you testing user selection, copy&paste and its HTML serialization?

2018年2月22日(木) 23:47 Rune Lillesveen <fut...@chromium.org>:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeSQA6qjB2b0rGgKJ-DQQZvAqm79z0_ihxZHATj_4xkRTg%40mail.gmail.com.

Hayato Ito

unread,
Feb 23, 2018, 12:29:35 AM2/23/18
to Yoichi Osato, Rune Lillesveen, blink-dev
Hi yoichio@,

Could you clarify which kinds of additional tests we need from the selection's perspective?
A concrete example would be helpful for us.

AFAIK, as long as the implementation of user selection uses a well-defined abstraction layer, such as FlatTreeTreversal, and/or LayoutTree structure, slot-in-flat-tree shouldn't have any impact on user selection.
I'm wondering what would make the difference to user selection.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Yoichi Osato

unread,
Feb 23, 2018, 1:23:11 AM2/23/18
to Hayato Ito, Rune Lillesveen, blink-dev
Let's think about following example:
<div id="div" contenteditable>pastehere</div>
<div id="div2"><span style="font-weight:bold">foo</span>bar</div>
<div id="div3"><span slot="foo">foo</span>bar</div>
<script>
let shadow = div3.attachShadow({ mode: "open" });
shadow.innerHTML = '<slot name=foo style="font-weight:bold"></slot>baz';
</script>

If we can style slot element, it would be rendered as:
pastehere
foobar
foobaz

We can copy second foobar to "pastehere" while keeping style.
What if we paste sloted foobaz to not shadow host #div?


2018年2月23日(金) 14:29 Hayato Ito <hay...@chromium.org>:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

Hayato Ito

unread,
Feb 23, 2018, 1:44:45 AM2/23/18
to Yoichi Osato, Rune Lillesveen, blink-dev
Thank you for the concrete example.
Could you share an expected result and an actual result too?

It looks '<slot name=foo style="font-weight:bold"><span slot="foo">foo</span></slot>baz' would be pasted, and that looks fine to me as is.


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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato

Yoichi Osato

unread,
Feb 23, 2018, 2:14:14 AM2/23/18
to Hayato Ito, Rune Lillesveen, blink-dev
https://dom.spec.whatwg.org/#shadow-tree-slots
> A shadow tree contains zero or more elements that are slots.
It results <div><slot name=foo style="font-weight:bold"><span slot="foo">foo</span></slot>baz</div> as light tree.
Is it defined slots behavior outside shadow root?

2018年2月23日(金) 15:44 Hayato Ito <hay...@chromium.org>:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato

Hayato Ito

unread,
Feb 23, 2018, 2:25:53 AM2/23/18
to Yoichi Osato, Rune Lillesveen, blink-dev
On Fri, Feb 23, 2018 at 4:13 PM, Yoichi Osato <yoi...@google.com> wrote:
https://dom.spec.whatwg.org/#shadow-tree-slots
> A shadow tree contains zero or more elements that are slots.
It results <div><slot name=foo style="font-weight:bold"><span slot="foo">foo</span></slot>baz</div> as light tree.
Is it defined slots behavior outside shadow root?

Yes. <slot> behaves as if it were <div style="display: contents">, regardless of in a document tree or in a shadow tree.
The only difference is that assignment doesn't happen in a shadow tree.


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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato



--
Hayato

Hayato Ito

unread,
Feb 23, 2018, 2:27:35 AM2/23/18
to Yoichi Osato, Rune Lillesveen, blink-dev
> The only difference is that assignment doesn't happen in a shadow tree.

The only difference is that assignment does happen only in a shadow tree.

--
Hayato

Yoichi Osato

unread,
Feb 25, 2018, 9:11:00 PM2/25/18
to Hayato Ito, Rune Lillesveen, blink-dev
Understood.
Then if paste destination is another contenteditable node in shadow tree like <my-editor> custom element,
it causes unintentionally slotting, right?

2018年2月23日(金) 16:27 Hayato Ito <hay...@chromium.org>:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato



--
Hayato



--
Hayato

Hayato Ito

unread,
Feb 25, 2018, 9:28:52 PM2/25/18
to Yoichi Osato, Rune Lillesveen, blink-dev
Yes.

If you want to know a slot element's expected behavior in general, you might want to see the following specs carefully:

If you have still questions, I am happy to answer that.


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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato



--
Hayato



--
Hayato



--
Hayato

Hayato Ito

unread,
Feb 27, 2018, 12:38:11 AM2/27/18
to Yoichi Osato, Rune Lillesveen, blink-dev
> I have asked the Polymer team to run their tests against a Canary build with the runtime flag enabled, but I have not received any feedback yet.

Regarding this, we got a response from the Polymer team, as follows:

> The change does not cause any failures in Polymer tests. I was a little concerned about a potential performance regression if `display: contents` has not been optimized, but so far I have been unable to observe any performance issue.

Given that, it is unlikely that slots-in-flat-tree will cause any compat issue in practice.

--
Hayato

Yoichi Osato

unread,
Feb 27, 2018, 12:40:28 AM2/27/18
to Hayato Ito, Rune Lillesveen, blink-dev
+1 to me.

2018年2月27日(火) 14:38 Hayato Ito <hay...@chromium.org>:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato



--
Hayato



--
Hayato



--
Hayato



--
Hayato

TAMURA, Kent

unread,
Feb 27, 2018, 2:22:16 AM2/27/18
to Yoichi Osato, Hayato Ito, Rune Lillesveen, blink-dev
LGTM1.
Safari already has this behavior. This will improve interoperability.

+1 to me.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato



--
Hayato



--
Hayato



--
Hayato



--
Hayato

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAEV3pmOL1-vyeRTzsGKE7Tn0eRVOm3Djmz0rMUyZ%3DdmFqqRrQ%40mail.gmail.com.



--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Feb 27, 2018, 5:14:58 AM2/27/18
to TAMURA, Kent, Yoichi Osato, Hayato Ito, Rune Lillesveen, blink-dev
LGTM2

wpt.fyi does not yet run pre-stable browsers, but I ran the listed test in Safari Technology Preview (PR) and there are just two failures:

/css/css-scoping/css-scoping-shadow-slotted-rule.html
  FAIL [Parent]
/css/css-scoping/slotted-slot.html
  FAIL Check that ::slotted does not match slot elements

I don't understand the css-scoping-shadow-slotted-rule.html failure as they look identical to me, but the other is 'assert_equals: expected "rgb(0, 128, 0)" but got "rgb(255, 0, 0)"'.

If all other tests pass and these differences are understood, then I think we'll be on a good path to interop!

+1 to me.

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

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.



--
Hayato



--
Hayato



--
Hayato



--
Hayato



--
Hayato

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAEV3pmOL1-vyeRTzsGKE7Tn0eRVOm3Djmz0rMUyZ%3DdmFqqRrQ%40mail.gmail.com.
--
TAMURA Kent
Software Engineer, Google


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHHh%3DTDgpQR_%3DJN%3DquF-8encC%3DJmNoR1tL0pWdrDoBfZg%40mail.gmail.com.

Chris Harrelson

unread,
Mar 1, 2018, 1:14:26 PM3/1/18
to Philip Jägenstedt, TAMURA, Kent, Yoichi Osato, Hayato Ito, Rune Lillesveen, blink-dev
LGTM3

+1 to me.

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



--
Hayato



--
Hayato



--
Hayato



--
Hayato



--
Hayato

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
 To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdHbRRmw%3DovGsET5ws3ygckgU5pfF1gr%3DGm4VOSVn7tdw%40mail.gmail.com.

Rune Lillesveen

unread,
Mar 2, 2018, 8:24:36 AM3/2/18
to Philip Jägenstedt, TAMURA, Kent, Yoichi Osato, Hayato Ito, blink-dev
On Tue, Feb 27, 2018 at 11:14 AM Philip Jägenstedt <foo...@google.com> wrote:
LGTM2

wpt.fyi does not yet run pre-stable browsers, but I ran the listed test in Safari Technology Preview (PR) and there are just two failures:

/css/css-scoping/css-scoping-shadow-slotted-rule.html
  FAIL [Parent]

Manually running this in Safari Tech Preview WebKit 13606.1.5 on High Sierra, I see an expected 100x100 green square with this test, but I don't know if there could be visual artifacts running it as a reftest?

/css/css-scoping/slotted-slot.html
  FAIL Check that ::slotted does not match slot elements

I don't understand the css-scoping-shadow-slotted-rule.html failure as they look identical to me, but the other is 'assert_equals: expected "rgb(0, 128, 0)" but got "rgb(255, 0, 0)"'.

This is a very recent change to Blink:


The spec says ::slotted() matches the assigned elements after flattening, which means slots which are assigned to slots are replaced by their own assigned nodes after flattening: https://drafts.csswg.org/css-scoping/#slotted-pseudo

There's already a WebKit bug for it: https://bugs.webkit.org/show_bug.cgi?id=179402

If all other tests pass and these differences are understood, then I think we'll be on a good path to interop!
 
--
Rune Lillesveen
Reply all
Reply to author
Forward
0 new messages