INPUT type=“button” and BUTTON element improvement

I was referred to this forum as the place to make my recommebdation, so I have come here to do so. I have been thinking about this for a very long time… years in fact. I have decided that now is the time to make this recommendation.

Element(s) to be amended: INPUT type=“button”, BUTTON

Behavior modification: addition of attribute to allow for constant-state (always pushed, versus momentarily pushed)

Explanation: In the electronics world there have almost always been two types of push buttons, momentary throw and toggle throw. Momentary throw is the behavior mimicked by HTML buttons since their inception. However, toggle throw (off until pushed on, on until pushed off) has never been implemented as a part of the button syntax… In earlier versions of html, the toggle throw could be mimicked by using javascript and images. I believe that this method is still usable today, but I rarely see it in use anymore.

In more current times, the use of CSS and javascript together are an alternative, but the commonly recommended way to accomplish it uses checkboxes instead of buttons, and css to make the checkbox look like a button. I have seen one alternative that uses the push button and a css class named .dotoggle to achieve this, but all it does is change the text and background colors of the button so it is obviously “pushed”,

I believe that none of these methods is preferable. There should be an attribute (such as ‘toggle’, or a type=“toggle” that would cause the button to mimic a toggle throw button and use the browser’s built-in “pushed button” to show that the button is in the pushed state. There are many circumstances where this type of behavior is more desirable than the momentary method that exists now.

Note that this usage is more likely to be used outside of a form (without a form even on the page) than within a form. While I know some will say, “It is a form element and should not be altered for use outside a form,” push buttons can and are used in this fashion and have been since HTML forms were introduced. Also, the validators do not consider this usage to be invalid, and therefore the usage should be considered valid.

Use case: I have developed a page that uses three push buttons to allow the user to select between three divs. The divs are hidden until the user pushes a button. When a button is pushed, the associated div appears. If the user pushes a different button, the currently selected div is hidden and the newly selected div appears in its place. What I am looking for is the selected push button to appear pushed until the user pushes a different button, or until they push the same button again.

Adding a toggle attribute, or a type=“toggle” type, could accomplish this. The syntax would look as follows:

<INPUT type="toggle" onClick="some function">
<INPUT type="button" toggle onClick="some function">
<BUTTON toggle onClick="some function">

I’m not sure what gains this has (functionally) over a simple checkbox, which can be styled to look like a button or anything else you’d like: http://tympanus.net/Tutorials/CSS3ButtonSwitches/index.html

In your use case you would need JS to respond to the click events. If you are determined enough, you can make your divs appear/disappear using only CSS (see https://css-tricks.com/the-checkbox-hack/). Combine that with the styling possibilities and I think you got your use case well covered.

It’s not an uncommon UI feature, in accessibility APIs some HTML controls such as buttons can have a pressed state exposed, which can be set by use of aria-pressed=true|false

• an (old) example of its use

Ironically I was just talking to @SteveF about this last week - I agree it’s weird that we don’t have this since we did find it appropriate to add the states for aria. The checkbox hack is really used a lot because tracking a toggle state is a super useful thing, we even have toggle in classlist. It feels… weird that we have so many things ‘almost’ doing it. I’m not entirely sure what the best thing to do is, but I definitely think it’s interesting.

I’m just not sure what this would add semantically. The behaviour and look/feel are achievable today, and the semantics of the checkbox seem appropriate to describe such a “toggle button”.

The one thing I’d like to see is for radio buttons to allow a NAND state, i.e. disable all buttons. That would allow for expressing the semantics of a “control panel” with a bunch of mutually-exclusive toggle buttons, but that allows all to be off simultaneously (see the example “Radio All Off” on the bottom right here). But that is not quite what this suggestion is about.