Intent to Ship: Final specified imperative slot distribution behavior

116 views
Skip to first unread message

Mason Freed

unread,
Apr 15, 2021, 12:25:08 PM4/15/21
to blink-dev

Contact emails

mas...@chromium.org

Explainer


https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md

Specification

https://html.spec.whatwg.org/#dom-slot-assign

API spec

Yes

Summary

The final imperative slot distribution API spec has been landed at [1]. There are minor changes from the initial draft [2] which was implemented in Chromium. This feature represents the changes from the draft to the final spec. [1] https://html.spec.whatwg.org/#dom-slot-assign [2] https://chromestatus.com/feature/5711021289242624



Blink component

Blink

Search tags

imperativeslotshadow dom

TAG review

This is a fully-specified feature, and the majority is already landed.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

This does represent a breaking change to the API shipped in Chromium in M86. However, the usage of this API is exceedingly small [1], at less than 0.000001% of page loads. Additionally, the breakages are mainly around less common use cases, such as explicitly setting the slotAssignment mode to "auto". The other breakage mode is that previously, moving a node out of a shadow host, or moving a slot out of a shadow root, would break the node assignment. Now it will not. This seems unlikely to cause breakage issues. [1] https://chromestatus.com/metrics/feature/timeline/popularity/3442



Gecko: Positive (https://github.com/whatwg/dom/pull/966) annevk@ was directly involved in landing the spec.

WebKit: Positive (https://github.com/whatwg/dom/pull/966) rniwa@ was directly involved in landing the spec.

Web developers: No signals


Debuggability

There is one debuggability issue, which is tracked in [1]. As with the prior (existing) imperative slot API, there is an unobservable "manually assigned nodes" array on each HTMLSlotElement. And with the new proposal, there is also a "manually assigned slot" attached to each Node. It would likely be helpful to be able to see the contents of these properties from devtools. However, this doesn't seem to be critical to launching this feature. https://crbug.com/1199119



Is this feature fully tested by web-platform-tests?

Yes

Flag name



Tracking bug

https://crbug.com/1196842

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4979822998585344

This intent message was generated by Chrome Platform Status.

Alex Russell

unread,
Apr 15, 2021, 3:31:34 PM4/15/21
to blink-dev, Mason Freed
LGTM1

Mike West

unread,
Apr 20, 2021, 10:16:29 AM4/20/21
to Alex Russell, blink-dev, Mason Freed
LGTM2.

This is a small-enough change to an existing API in terms of both usage and behavior that I'm comfortable considering it a bug fix, and not requiring either TAG review or formal standards position requests from Gecko and WebKit. The informal participation in the PR against HTML seems good enough for this particular feature.

-mike


--
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/45dfa69b-2da1-4277-9e0a-ab10c40d9a02n%40chromium.org.

Chris Harrelson

unread,
Apr 20, 2021, 10:49:15 AM4/20/21
to Mike West, Alex Russell, blink-dev, Mason Freed

Mason Freed

unread,
Apr 20, 2021, 2:35:15 PM4/20/21
to Chris Harrelson, Mike West, Alex Russell, blink-dev
Thanks everyone!

Mason Freed

unread,
Apr 26, 2021, 7:16:02 PM4/26/21
to Chris Harrelson, Mike West, Alex Russell, blink-dev
Hello API Owners,

I'd like to request a re-review of this I2S. As part of the WHATWG review of the WPTs I landed after I received 3 LGTMs here, one significant difference was noted between the landed spec and the Chromium implementation/tests. The spec calls for a variadic parameter list of nodes, while the prior implementation (from M86 to now) used a single sequence parameter. This represents a completely-breaking change, as `slot.assign([n1,n2])` will now throw a TypeError. The new usage would be `slot.assign(n1,n2)`. Given the extremely-low usage of this API (it is essentially zero), I am still comfortable shipping this change. It makes the API more ergonomic and better-aligned with other web platform APIs, and I believe the risk is low. However, I want to be sure we're all on the same page, so I'd like to request three more LGTMs on this I2S.

I've updated the chromestatus entry accordingly, and I've copied the relevant changed sections below for convenience.

Thanks,
Mason

----

Motivation

The differences are:

 1. Assignments between nodes and slots are more "permanent", and are not removed if either slots or nodes are moved around the tree or among documents. Exceptions will not be thrown from .assign() for slots or nodes "in the wrong spot".

2. The slot assignment mode "auto" has been renamed to "named", to allow additional values to be used later.

3. Repeated nodes in a call to .assign() will now be ordered first-in-first-out order. Previously, assign([a,b,a]) would result in [b,a] ordering. Now, it will result in [a,b] ordering.

4. The parameter(s) to .assign() are now passed in as a variadic list of nodes (e.g. slot.assign(n1,n2,n3)) rather than a single sequence argument (e.g. slot.assign([n1,n2,n2])).


Interoperability and Compatibility

This does represent a breaking change to the API shipped in Chromium in M86. In particular, one of the changes (#4, the sequence-to-variadic change) is a completely breaking change - old calls to slot.assign() will now result in a TypeError being thrown.

However, the usage of this API is exceedingly small [1], at less than 0.000001% of page loads. This API has basically not been publicized at all, not even (it seems) in the release notes for M86. So this change should still be fairly safe.


[1] https://chromestatus.com/metrics/feature/timeline/popularity/3442

----





Chris Harrelson

unread,
Apr 26, 2021, 7:53:31 PM4/26/21
to Mason Freed, Mike West, Alex Russell, blink-dev

Mike West

unread,
Apr 27, 2021, 1:42:50 AM4/27/21
to Chris Harrelson, Alex Russell, Mason Freed, blink-dev
LGTM2.
--
-mike

Mason Freed

unread,
May 3, 2021, 2:01:16 PM5/3/21
to Mike West, Chris Harrelson, Alex Russell, blink-dev
Thanks for the two LGTMs here. Friendly ping - could I get a #3?

Thanks,
Mason

Alex Russell

unread,
May 3, 2021, 4:31:30 PM5/3/21
to blink-dev, mas...@chromium.org, Chris Harrelson, sligh...@chromium.org, blink-dev, mk...@chromium.org
LGTM3 and apologies for the delay.

Mason Freed

unread,
May 3, 2021, 4:44:29 PM5/3/21
to Alex Russell, blink-dev, Chris Harrelson, sligh...@chromium.org, mk...@chromium.org
On Mon, May 3, 2021 at 1:31 PM Alex Russell <sligh...@google.com> wrote:
LGTM3 and apologies for the delay.

No problem, thank you all, and sorry for the double-request for this one!

Thanks,
Mason
Reply all
Reply to author
Forward
0 new messages