Research ToggleButtons

[lukewarlow]

trafficstars

Toggle buttons are pretty common UI elements that currently require aria (aria-pressed). I feel these would be relatively simple to specify a native ability for.

First thing to do would be pull together research on existing design systems to work out existing implementations. (https://react-spectrum.adobe.com/react-aria/ToggleButton.html is just one example)

[lukewarlow]

Name tbd obviously (would probably go with <button type="toggle"> or <button type="button" toggle>).

But then maybe we want a pressed attribute to take the true false mixed values.

Which begs the question do we want tri-state?

How do we handle styling is there an existing pseudo class that works (:active?) Or do we need a new one (`:pressed)?

All of this would hopefully be answered by research.

[lukewarlow]

I propose this would be a valid element for invoketarget (like a button with type="button" and type="reset")

[lukewarlow]

These along with focusgroup would allow for a proper toolbar implementation such as the one on the GitHub comments panel (or really any Toolbar). We are however currently missing a toolbar semantic element, potentially we could spec one of those too which could provide the focusgroup semantics without needing to ship focusgroup itself as a pre-requesite.

Also useful for UI such as in video calls where you have UI for toggling microphone and camera state (though it's key that we educate to ensure people don't change the label as part of changing the pressed state).

[scottaohara]

@lukewarlow i had been tooling around with a draft proposal for this a couple weeks ago. I would argue that instead of introducing a new attribute, we reuse the checked attribute.

unfortunately 'toggle' (in this context indicating a pressed/not pressed or mixed state) could get confusing with 'toggling' a popover/dialog - since those are also toggling but not self toggling. sigh. we need more words rather than calling everyting a tooltip, toggle or a card.

[lukewarlow]

Yeah thinking on it I think pressed (to match aria?) or checked or something other than toggle is for the best.

[bkardell]

I agree either of those is better than toggle or toggled or whatever.

[keithamus]

Allowing a list of options inside of a button, and having the button cycle between those might be worthwhile:

<button type=toggle>
  <option value="play">Play</option>
  <option value="pause">Pause</option>
</button>

Providing <options> allows for a computed value, an easily computed accname, a well understood transition of state, and it is webcompat (to my knowledge).

We are looking at adding richer media to <option> for <select> so it would be a net gain here too.

Having option also allows for N states, which may either sell you on the idea or put you off it entirely 😉 :

<button type=toggle>
  <option value="1">One</option>
  <option value="2">Two</option>
  <option value="3">Three<option>
</button>

[lukewarlow]

I've raised some issues to try and gather some use cases.

https://github.com/openui/open-ui/issues/1039 - toggle buttons https://github.com/openui/open-ui/issues/1040 - cycle buttons (the sort of thing Keith mentions above)