Post

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.

slightly off topic but what does happen when you put an element that shouldn't infer an implicit role inside the widget (like the input inside the toolbar or a link inside a tablist or something)?

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?

Exactly. Better to have a native implementation everyone can use than 500 (likely inaccessible) versions—assuming one knows how to make custom elements at all.

How is this different from focusgroup?

It's not all that different right now, it's akin to `<div focusgroup="toolbar">`. In fact it's using focusgroup under the hood in my prototype just without spawning the attribute. But there's potentially some extra things we can do, e.g. stricter key conflict handling.

Nice! When I read the proposal for focusgroup, I was thinking that they all sounded like they should be HTML elements!

Yup, menu(list) and menubar are being worked on too. So I think with those 3 it's just tablist left to go! But they all have varying levels of complexity beyond just what focusgroup provides (admittedly toolbar itself is quite simple).

Will the existing menu be adapted?

That's cool. I need to look into the proposals. For tablist, I imagine you'd want to go all in and provide a proper hide and reveal behaviour when switching between tabs.