When does a tab get transitioned to? After a ‘click’, maybe when enter key is pressed?
If transition is triggered by a key press, which variation? ‘keyDown’, ‘keyUp’?
How should the content load once transitioning to a tab? (Lazily vs eager)
Should the tab content already be in the DOM waiting to be shown? Or injected when its requested?
Should the tab content be cached upon first view? If so, when do we query for up-to-date content?
Should it have a loading spinner?
If there is a loading spinner, when should it show/hide? Right before content is shown?
How would the loading spinner get displayed? Fade in? Fade out? Css transition? Css Animations?
1 and 2. Keyboard interaction with tab controls is standardized in ARIA, so that is taken care of.
3, 4 and 5. The tab control is merely responsible for displaying the correct tab panel. Whether or not tab panels are prepopulated or lazyloaded is up to the web app.
6, 7 and 8. No loading indicator is needed since the tab panel is displayed immediately (it’s the same mechanism as with the <details>/<summary> elements).
I hope this makes it clear that my proposal is only for a basic tabbed UI functionality.
I’m not sure what “trump the original claim” means. Does it mean that expanding another panel automatically collapses the previously expanded panel? This would be needed for built-in interaction functionality in a a tabbed interface, which is what I want.
Also, having to set the expandable attribute on each panel isn’t optimal (it would be code repetition, since a tab panel is expandable by design); it would be nice if the attribute could be set on the panel set element.
In making it, I didn’t feel as though I really needed additional elements, however that meant relying heavily on ARIA attributes. What I felt was lacking were certain CSS selectors.
It’d be great if there were a way to use attribute references in selectors in some way so that a checkbox could select its own label(s), and a label could select its checkbox. Given how many ARIA attributes are IDs or lists of IDs, this would significantly improve ARIA in general.
All that said, there are certainly some issues. Without JS there’s no way to manage state such as the aria-expanded attribute. Having some dedicated elements that have explicit behavior could simplify implementations, and make it easier for developers to build tabs correctly, rather than a bunch of <div>s with onclick.
I’m sure there are a bajillion reasons why this sort of selector can’t and won’t exist, and I have no idea what sort of specificity the selector would have, but I can guarantee that if I had access to something like it, I’d use it all the time.