#486: Imperative Shadow DOM Distribution API.

Visit on Github.

Opened Mar 18, 2020

Hello TAG!

I'm requesting a TAG review of Imperative Shadow DOM Distribution API.

This feature will allow web developers to explicitly set the assigned nodes for a slot element. This feature will allow web developers to set the assigned nodes for a slot element explicitly. It enables node assignment based on input properties without needing to change HTML markup. (see explainer for more details)

Further details:

  • I have reviewed the TAG's API Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WhatWG
  • The group where standardization of this work is intended to be done ("unknown" if not known): unknown
  • Existing major pieces of multi-stakeholder review or discussion of this design:
  • Major unresolved issues with or opposition to this design: None
  • This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @yuzhe-han, @mfreed7

Discussions

Discussed Apr 6, 2020 (See Github)

Tess: overall I think this looks good. I have one concern I'm writing up right now. This proposal says - when you create a shadow dom you can choose manual or automatic. Automatic is the status quo. New mode: you have to use an API and slot things in different places. One cited advantage of the API is implementing something like the details element. before having this feature you can't implement that feature on top of web components. One downside of the exclusivity of the two modes (man/auto) is that it's sometimes advantageous to have special behavior with some descendants but have the rest auto. My feedback is that I'd like them to make that case easier - some manual slotting and then "everything else auto". Otherwise it looks great!

Ken: I looked it and also liked it.

Tess: i will mark as pending ext feedbac

Comment by @hober Apr 6, 2020 (See Github)

Overall I think this looks great.

One minor concern I have is with the exclusivity of the slot assignment modes, though I think my concern could easily be addressed by some syntactic sugar.

It's common to have special behavior with one child (or a few children) and some kind of default behavior for the rest. Consider the following markup:

<details>
  <summary>This is the summary.</summary>
  and
  <p>these
  <p>are
  <p>the
  <p>details
</details>

The proposed imperative API lets you easily handle <summary>. It would be nice if it were easy/straightforward to implement a default slot using the imperative API, so that the rest of <details>'s children could be taken care of easily too. Maybe something like shadowRoot.setDefaultSlot(slot). You do some manual slotting and then everything not slotted ends up in the default slot.

cc @yuzhe-han, @mfreed7

Comment by @yuzhe-han Apr 9, 2020 (See Github)

@hober,

Thanks for reviewing and providing feedback.

Your concern is a good one and has been discussed in the comments surrounding following comment, https://github.com/whatwg/html/issues/3534#issuecomment-538613515

In there, @fergald provides one way of emulating a default slot in a custom element using manual slot assignment. I think it can be used to address your issue. Another way I can think of, but requires addition markup, is to use a custom element to wrap the additional detail's content.

Hopefully these methods above address your concerns. We want to avoid mixing imperative and declarative slot assignment as listed in point 4 of https://github.com/whatwg/html/issues/3534#issuecomment-537802687.

Thanks.

Discussed Apr 13, 2020 (See Github)

Tess: Part of the goal is that .. no slot ... imperative API lets you manually slot everything... Doesn't solve the usability issue - if you want to implement something like details .. one or two that have special slotting behaviour and rest auto - this not solved. They replied to this issue. I need to digest the response.

Dan: they said already looked at?

Tess: yes - my concern was raised years ago... can polyfill.. need to look into it more. Was nice to get a response promptly. Work in progress...

Peter: might be interesting to have a declarative way of doing this - could be as a polyfill on top of this API. A map of selectors...

Tess: that's what Shadow DOM v0 did. There were some complicated rules ... shadow dom v1 dropped that and has a model of explicit name slotting. Could be worth exploring again.

Peter: might be worth at some point revisiting the declarative... so you can build custom elements without having to write any [javascript].

bumpe

Comment by @hober May 28, 2020 (See Github)

@kenchris and I looked at this again during the TAG F2F this week, and we're wrapping up our review. Overall we think this looks great, and while we would have preferred some default slot sugar, we understand why you're reluctant to add it. Thanks! Please open a new design review if your approach significantly changes in the future.