Post

Initial prototype of a `<toolbar>` element is coming along. Largely piggybacks off the focusgroup code so it's actually quite simple to do. Lots to discuss and tweak before it's finished but got to start somewhere.

That looks like a use case for a custom element. What’s different with this native new element?

It's built into the browser? Handling the keyboard behaviour automatically is a pretty big win over using a JS library for it, imo. Focusgroup has actually quite complex conflict handling for if you say put an input inside a toolbar. Doing this in a custom element would be quite a pain.

ok... but that is not scalable at all if we need to convince browser vendors for every such use case. I'm sure some enjoy the control that gives them but damn... Looks like the primitives need fixing instead?

We add what 1 or 2 new html element every 5 years (I'm ignoring the weird permissions element stuff). That doesn't seem too unreasonable? I agree some stuff (CSS and even JavaScript) does move too fast at times but html is pretty conservative. Fwiw we are doing the primitive that's the focusgroup 1/

...attribute which I think is the sort of thing you're asking for. It enables the single tab stop arrow-key keyboard behaviour. That's the heavy lift for browsers, but once we have that I see no reason why we shouldn't be able to make first class elements for these things. First rule of aria is 2/

Just want to say I agree with this so much. Not everyone knows how to build custom elements. And the main reason ARIA exists is to provide semantics for things that don't exist in HTML. But, as others have said before me: ARIA should be thought of as a temporary solution.