Intent to Prototype: Imperative Shadow DOM Distribution API

107 views
Skip to first unread message

Yu Han

unread,
Feb 27, 2020, 5:13:19 PM2/27/20
to blink-dev
yuzh...@chromium.org https://github.com/yuzhe-han/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md Specification: https://github.com/whatwg/html/issues/3534 https://github.com/yuzhe-han/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md None yet. I will request one once the API implementation is flushed out. Web developers can specify node-to-slot assignments imperatively in Shadow DOM slotting. Please see the spec discussion [1] and the strawman proposal [2] at this point. - [1] https://github.com/whatwg/html/issues/3534 - [2] https://github.com/yuzhe-han/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md Allow node-to-slot assignments without needing to add slot attribute in markup. And enabled dynamic slotting behavior based on input conditions.
This feature is early stage and implementing it is intended to give us insight into these risks as developers experiment with it. This shouldn’t break any existing content, as it is a new API, and existing declaratively-slotted content will continue to function as-is. However, we are still going to spend some time figuring out the impact of the new API on existing declarative API. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals
This is a new API, existing tools should work as is when this API is released. Yes No There were some WPT tests added in an earlier implementation. However, the API behavior has changed and new tests need to be written. This feature should be fully testable via WPT.

Comments

There was an attempt to implement this feature in 2018, Intent to implement: Shadow DOM imperative distributed API [3]. However, this feature was put on hold because browser vendors hadn’t yet agreed on the API’s behavior. In the last F2F TPAC meeting [4], Sept, 2019, the API’s behavior has been finalized. This intent is to implement this API based on the agreed changes.  

 

Differences from the previous implementation and additional work are:

 - The order of assigned nodes needs to be preserved.

 - Slot assignment is absolute.

 - Assigning a grandchild node or ancestor node of the shadow host will throw an exception. Only direct light tree children are slotable.

 - Slotchange event is raised when list of assigned nodes or their order changes.


 -[3] https://groups.google.com/a/chromium.org/d/msg/blink-dev/IVjeSC9tk64/u1kIxBFiBQAJ

 -[4] https://github.com/whatwg/html/issues/3534#issuecomment-537802687


 https://www.chromestatus.com/feature/5711021289242624

Mounir Lamouri

unread,
Feb 28, 2020, 1:55:03 PM2/28/20
to Yu Han, blink-dev
Hi Yu Han,

Regarding the TAG review, even if the change isn't fully fleshed out and the implementation not ready, it is recommended to file an "early design review", see https://github.com/w3ctag/design-reviews/issues/new/choose. It will help your chances of getting some feedback on the API by the time you are ready to launch and avoid getting TAG feedback after the launch occurred.

-- Mounir

--
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/CABgHHk4Tp87oYoREOiY5Msw2d2tzJyt6r0ETdVvFxTWuxDuubA%40mail.gmail.com.

Yu Han

unread,
Feb 28, 2020, 4:11:07 PM2/28/20
to Mounir Lamouri, blink-dev
Mounir,

Got it. Thanks for the tip!  I'll start the Tag review soon after I work on it a bit more.

Thanks,
Han

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B-LeH99t-w%2BV_BdhpT1qtuP7%3D%3DKByHs-7PuYxxLmRUsPV5VDg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages