Webcomponents: Add an assignedElements() method

[cyrilletuzi]

Sometimes we need to know how many elements are provided by the user (for example, in a custom element with a shadowdom creating a slideshow, I need to know how many slides are provided to be able to generate the same number of pagination items).

Trying to use assignedNodes().length, I get the wrong data, because as the method name suggests, assignedNodes() returns all nodes, including empty text nodes, not just elements nodes.

I'm quite surprised to face the old DOM problems again. Nearly every time, we work on elements, not all nodes. All classic DOM node properties and methods have their elements equivalent (parentNode > parentElement, nextSibling > nextElementSibling...).

So I think we need an assignedElements() method. Can't see a real use case for just assignedNodes().

[treshugart]

I've stumbled upon this as well. It's worth noting that this can only be a problem with default content because this will pull in text nodes. With explicitly slotted content, you will only get elements because you can only tell element nodes to go into a particular slot.

[cyrilletuzi]

In my case it would be really painful to do an explicit slotted content. As I'm waiting for an undefined number of slides, it would force the user of the component to add a container with a slot attribute with a specific name. The user should not have to do that, it's part of the internal/private behavior of the component.

[treshugart]

Totally, just clarifying that point. You could create a mixin / base class to provide this behaviour to all of your components you need it for (for now at least) until this is rectified.

class BaseComponent extends HTMLElement {
  get defaultSlottedElements () {
    return Array.prototype.filter.call(
      this.shadowRoot.querySelector('slot:not([name])').assignedNodes(),
      e => e.nodeType === Node.ELEMENT_NODE
    );
  }
}

[hayatoito]

Thank you for the suggestion. Adding assignedElements() to the platform makes sense to me. I guess developers are not interested in text nodes in most use cases.

@rniwa, @annevk
Are you fine with assignedElements()?

[rniwa]

Yeah, adding assignedElements() makes sense to me.

[annevk]

SGTM. Should be relatively easy to add to the DOM Standard, interested in trying that @cyrilletuzi?

[cyrilletuzi]

Never did a spec contribution before but yes, I'm interested to try. 👍

[annevk]

Great, https://github.com/whatwg/dom has instructions, let me know if you need help.

[cyrilletuzi]

Sorry for the delay, too much work. I have some time now, but I'm confused : I can't find any mention of assignedNodes() in the spec anymore.

[annevk]

@cyrilletuzi that is my fault. It needs to be added to https://github.com/whatwg/html. See https://html.spec.whatwg.org/multipage/scripting.html#the-slot-element. I forgot we're talking about a method on an HTML element.

[JanMiksovsky]

We'd really like to see this as well. Additionally, we've come across a case where we wanted the assigned textContent: an auto-sizing textarea component that needs to support the use of <slot>.

I think we ultimately want Shadow DOM-aware variations of children, childNodes, and textContent, and think it might be best to take care of all of them at the same time.

We could have a uniform map of regular DOM property -> Shadow DOM-aware property:

• children -> assignedChildren
• childNodes -> assignedChildNodes
• textContent -> assignedTextContent. This joins together the textContent of all assigned nodes, just as if they were light DOM child nodes.

These would all be invoked on the host HTML element, not the slot.

[cyrilletuzi]

From the host element, you already have access to children of any type via classic DOM.

From the slot element, if you're just assigning text content (so just one text node), assignedNodes()[0] will do the job. If you're mixing nodes (text and elements), then it seems normal you have to filter what you want by yourself.

[annevk]

@JanMiksovsky that would only make sense for open shadow trees. In any event, that really seems like a distinct issue from this one. This is just a convenience method on top of an existing feature.

[TimvdLippe]

This seems like an interesting proposal, but it lost steam on the way. As far as I can see, it stopped after a discussion about the way the proposal was tested. Could this be resolved such that this issue can be resolved?

[annevk]

Yeah, if someone has the time to drive the test refactoring this can move forward easily I think.

[annevk]

In particular, the tests over at https://github.com/w3c/web-platform-tests/pull/4541 need to be refactored a bit to have less duplication.