westbrook / a11y-elements Goto Github PK

It's easy to hide away everything that goes into an element and only ship something like the followign over the wire:

<my-element></my-element>
<script>
document.querySelector('my-element').data = data;
</script>

This can be particularly useful in the context of a child element, as it means that in-app implementations get to take less into account, there are just passing a data object, after all.

However, the data = data context will fail in non-JS contexts, presents difficulty in the context of rendering on the server, and will likely require a fairly complex configuration object, and/or a high number of attributes and properties to ensure that reusability is as high as it can/needs to be. To that end, I think it is important to explore APIs that draw on slotted content as much as possible to populate the final shadow DOM output. In some cases that may be fairly easy to manage, one final piece of content === one slot certainly keeps things simple. However, when you need a variable amount of content/slots, things can get hairy quickly and if you want to wrap that slotted content in more complex DOM, things are even less direct.

I'd love to establish a pattern that allowed web components to act more directly like we see with select elements:

<select value="something">
    <option value="nothing">Nothing</option>
    <option value="somthing>Something</option>
</select>

When you insect that select element, much of its internal API is a surfacing of the option elements internal to it as data. It's like SSR when it was still just rendering on the server, as opposed to the complex and varied topic it's morphed into as of late.

I spent a good part of a day chatting with Erik Isaksen about this concept earlier this week in the context of a tabs pattern, and together we worked towards an idea that looks like this: https://stackblitz.com/edit/lit-element-7q3rfk?file=tab-viewer.js Mix slots and Mutation observer to manage a dynamic template of projection points for your light DOM content... and it's coming together fairly nicely, if I do say so myself. It would seem that with some more abstraction that this could serve as a basis for data acquisition from the DOM across a number of accessible patterns.

In so far as the only element in question so far is the a11y-accordion, I'm going to put together a more specific issue to outline how I think we could leverage this pattern in that context, soon. In the interim, I'd love to hear any thoughts that this might bring to anyone's mind.

Thoughts?