Intent to Ship: Final specified imperative slot distribution behavior

[Mason Freed]

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

imperative, slot, shadow 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]

LGTM1

[Mike West]

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]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcEwLyRqL0x%2BUCxuTQfcy1GVjbJ%2B3JNvpKDZ-3B0Up3bg%40mail.gmail.com.

[Mason Freed]

Thanks everyone!

[Mason Freed]

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]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDi%3DrDN_CQSHKid8CbSawU8CNPUUKa8VOsLkzw-rxYZvbw%40mail.gmail.com.

[Mike West]

LGTM2.

--

-mike

[Mason Freed]

Thanks for the two LGTMs here. Friendly ping - could I get a #3?

Thanks,

Mason

[Alex Russell]

LGTM3 and apologies for the delay.

[Mason Freed]

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