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.

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.

0 reposts6 likes

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)?

They keep their intrinsic roles. I don't believe toolbar implies any, but tablist for example will set buttons to tab but most other items won't change role. Buttons was a recent change originally anything with its own role kept it, but I believe it was Sarah pointed out buttons really shouldnt.

What about keyboard navigation? do the elements participate in the focus group/arrow key navigation? I know this has been in discussion but I don't know if there has been a final decision on this

Yes they do provided they're already keyboard focusable, though there's behaviour to handle key conflicts. So the input for example you can arrow into it but then you'll need to tab out and it makes sure there's no part of the focusgroup you're prevented from getting to.

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/

is simplified to "not to use aria". We can't really expect that to work out if we have a bunch of aria roles with no html solution. Obviously we might disagree here but I think we really should be adding toolbar, menu and menubar, tablist and any others we might be missing.

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.

Google? I don't work for Google. I'm also just doing this in my free time as part of the OpenUI group. 🤷🏻‍♂️