Html: Requesting <input type="switch">

[atishay]

This is a feature request on the behalf of all web developers targeting mobile. Here are reasons the toggle switch element should be natively available in HTML forms:

• Switch is a standard and popular UI control in both Android and iOS mobile platforms.
• Checkbox is used in websites due to the absence of the switch. Checkbox is absent from iOS and is not considered a good part of the human interface for forms on mobile. Checkbox has a smaller hit area than switches.
• Switch is very popular in UI frameworks that have been providing this as a component to use - Material Design, Bootstrap, React Native
• Switches are non-trivial to implement properly in CSS. See Codepen, W3Schools. Most frameworks that are provided to generate HTML on the server do not have a switch causing developers, especially enterprise using checkbox in the place of a switch. PWAs without switches appear non-native on mobile platforms.
• Implementing switches should have no performance overhead for the browsers (separate component in the UI).

I am happy to help writing a spec for the <input type="switch" /> element if that can help getting it into the browsers.

[annevk]

Shouldn't this be a checkbox with a different style? E.g., appearance: switch?

cc @whatwg/rendering

[atishay]

Definitely makes more sense as we get backwards compatibility.

[annevk]

Apologies for not welcoming you by the way, I missed this is your first issue. Belatedly, welcome! https://whatwg.org/working-mode#changes and https://whatwg.org/faq#adding-new-features provide some context for the way work is done. I think for this particular request there is enough to go on as this is clearly an established UI widget that makes sense to expose the web in some form. Thanks for raising it.

[domenic]

Indeed, welcome. I'm glad @annevk pointed you to the adding new features FAQ, as it helps keep specific solutions (e.g. <input type="switch">) separate from the problem statement ("displaying a control that looks like a switch").

Coincidentally we have been having some discussions internally in Chrome about better built-in UI widgets and form controls. At this point I don't have much to report beyond tentative interest in the general program. But there's a lot to still figure out in the specifics: e.g. theme-ability, whether we can do this in a layered way that does not require more browser magic (like appearance does), etc.

[sideshowbarker]

👍 It also seems worth mentioning that ARIA (since ~1.1 I think) now has a switch role:

https://w3c.github.io/aria/#switch

[atishay]

I am happy to work with the team if any help in needed in getting this spec'ed or implemented, in whatever form it makes sense to get a toggle switch control into the browsers. I will be careful about not having a solution but only a problem in the future.
Really glad to see how active the HTML WG is on their github channel.

[annevk]

@sideshowbarker that's very interesting, that almost suggests there is some semantic related to the presentation of a switch checkbox. Using a CSS property at that point wouldn't work well as that couldn't map to ARIA cleanly.

cc @whatwg/a11y

[LJWatson]

The ARIA 'switch' role maps to the accessibility APIs, so an element with 'role="switch"' has semantic meaning to screen readers.

• MSAA + IA2: Role: ROLE_SYSTEM_CHECKBUTTON, Role: IA2_ROLE_TOGGLE_BUTTON
• UIA: Control Type: Button, Localized Control Type: toggleswitch
• ATK/AT-ASPI: Role: ROLE_TOGGLE_BUTTON, Object Attribute: xml-roles:switch
• AX API: AXRole: AXCheckBox, AXSubrole: AXSwitch

[malchata]

I don't think this is a _bad_ idea, but proposals for new browser features can take a long time between conception and implementation across platforms—assuming universal adoption is ever achieved.

Because of this, the question that immediately springs to mind for me is "what does a reliable non-JavaScript fallback pattern look like for this?", and appearance: switch; in combination with <input type="checkbox"> seems to provide a foundation for a progressively enhanced and accessible switch element.

[annevk]

I agree that's a good consideration, but note that <input type=checkbox switch> would provide that too and is probably more apt given the slight semantic implication.

[malchata]

Good point @annevk. I can't see any reason why that wouldn't work as well!

[atishay]

There seems to be no progress on this issue for some time. Is there any way I can help?

[annevk]

@tkent-google @cdumez @hober @smaug---- is this something you'd implement if specified?

@atishay apart from getting the above question addressed (implementation interest), we'll need someone to make the relevant changes to the standard and write tests. I suspect a new boolean attribute named switch is the way to go, signaling a change in presentation. One thing that we'll need to work out is how checkbox's intermediate state works together with this. Presumably we'd disable that somehow.

[smaug----]

Sounds reasonable.

When spec'ing this, need to be very careful with styling related properties.
We've so often failed to spec those early enough with form control elements.
(one option is that there isn't any specific pseudoclasses/elements for switch, but if that is the case, better to spec it)

Why we'd disable the intermediate state? I'd rather try to keep the behavior on JS side as close to checkbox as possible.

[domenic]

Chrome would prefer to not perform a new quick-fix for this, e.g. adding an attribute. We'd instead prefer to work on it more holistically as part of a general question of how to add new form controls and behaviors, in a way that does not involve magic that only browsers could do today (such as adding a new attribute to <input> and wiring that up to appropriate a11y and styling interactions). This is a longer-term project, but it's one of our priorities for 2019.

(Side note: as a benefit, our preferred approach should entirely determine the styling interactions, helping with @smaug----'s concern.)

More concretely, we'd prefer to see something implemented in JavaScript/custom elements/Houdini/AOM/ElementInternals/etc., and then put into the spec in a way that is indistinguishable from such a solution. If that's not possible today (e.g. due to missing foundational pieces) then we'd like to delay committing to a solution in the spec. Our suspicion is that this will not be possible today, but for those interested in making progress, Chrome's preferred avenue would be to attempt to do so with today's technologies, and see where the gaps are, exactly.

All that said, I would not count this as "strong opposition", so if there are multiple other independent engines who want to add form controls in the usual magic-using way, that would be fine to land as part of the WHATWG progress. Chrome just would not prioritize following such an implementation, as we'd rather commit those resources to working through the general problem space of allowing the set of form controls to be extensible/themeable/polyfillable/etc.

[atishay]

I looked at the various ways to create custom element to do this task. Here are some issues that we would face with Custom Elements:

1. Shadow DOM cannot be attached to an <input> tag.
2. We can place an input type checkbox inside a shadow of a regular element, but that would have weirdness with <label for="">. We will have to synchronize values on click and name properties.
3. This can be implemented as a custom element without the shadow DOM by injecting the ::before and ::after pseudo elements, which in chrome can be placed above the checkbox UI to look like a switch. These properties are not protected by the shadow DOM and modifying the CSSOM from JS is one way that could be done, though it is not very clean.

The documentation is scant on custom elements and I am not sure if I missed anything. If needed I can provide a Codepen for approach 2 or 3.

@domenic A form element to have a shadow DOM would be required for a clean implementation. It could associate the value property and the <label for="id"> and then rest of the details could be filled in by the shadow dom.

Another way, this could be spec'ed out is to allow Shadow DOM to <input> tag. When a HTMLInputElement is provided a shadow DOM, it could potentially convert to an empty element with no default UI. If a text field is needed, that could be added in shadow DOM and the corresponding properties synchronized. That would allow maximum flexibility with full backwards compatibility. That approach can be taken to provide shadow DOM to any HTML tag and allow extensibility.

[tkent-google]

@atishay We're standardizing "Form-associated custom elements", and Chrome Canary has it behind a flag. Please refer to https://github.com/w3c/webcomponents/issues/187#issuecomment-444817775

[domenic]

Thanks very much for the exploration, @atishay! Indeed, as @tkent-google mentions, the form-associated custom elements feature would be a crucial building block for this sort of work, I think. We'd love for you to try it out and see how well a switch control built on that works out.

Another approach worth considering is using CSS custom paint (customizing an <input type="checkbox">), instead of shadow DOM. Although that doesn't help with the accessibility differences mentioned.

[atishay]

I have a basic version of switch using custom elements here: https://codepen.io/atishayjain/pen/XoEQXN?editors=1010

This is not very customizable and I can make a version which is much more dynamic if that helps in standardization. This is not backwards compatible with checkbox.

If needed, I can try the custom paint approach, which could behave like appearance.

[atishay]

Is there something else that can be done to get some progress in getting a toggle switch element?

[atishay]

@domenic Do we need anything else? Is there still interest in building something in this area?

[tkent-google]

Google is going to propose standardizing the switch form control as a JavaScript Standard Library. Here is an initial explainer: https://github.com/tkent-google/std-switch/blob/master/README.md

[gregwhitworth]

@tkent-google That's pretty cool thanks for sharing. I agree with @domenic statement here. As such, I think we should take this a bit further in a few different ways as I think there a few key pillars to the problems that web developers face with regard to the native controls on the web, some of which you have issues open for so I'll focus those discussions on those.

One thing that I believe we should allow is for built in components to not require the dash. So in this case, we wouldn't have <std-switch> but simply <switch>. This would align with our other controls and allow at a quick glance which ones are native and which come from third party code.

Additionally, while I think this can be done in a stepping stone fashion, I don't think the author should be required to import the control to utilize it, especially since it will already be shipping with the browser. That seems like un-necessary overhead for the author.

[domenic]

The dash question is an interesting one. We've briefly discussed it in another context at https://github.com/WICG/virtual-scroller/issues/161. Maybe we should open an overall issue.

Similarly, we're very interested in exploring a future built on Apple's JavaScript standard library proposal where new high-level features can be opt-in imported, instead of every page paying for every new web platform feature we add forever.

As noted in that issue, the two design choices are connected and synergize with each other.

[tkent-google]

I opened a WICG thread for this. https://discourse.wicg.io/t/proposal-a-toggle-switch-control-element/3620

[tuespetre]

Hmmm... an input of type “checkbox” is specified to submit a value of “on” already. That seems like a switch to me. A checkbox is — literally — a toggle control. If ARIA finds a difference worth mentioning then sure, use a role of “switch”, but there should be no need to introduce a whole honking input type for this. Browser vendors need to focus instead on standardizing some style-able parts (like Shadow DOM parts or whatever) to make more visual designs possible, not just for checkboxes but for other input types as well.

[atishay]

@tuespetre Switch is a standard control in most operating systems and native UI toolkits. If the browsers don't have controls natively, we ask the developers to keep reinventing the wheel.

I can use the same logic for checkboxes and say that we already have input type text(or radio) and they should be removed as you can write code to make another input look and behave like a checkbox. The entire DOM could be implemented on a canvas.

I don't disagree with having extensibility in the browser controls and with those we can get the ability to experiment. But asking every web developer to manually build a UI element that native developers get for free does seems a of work.

[tuespetre]

@atishay well I gotta say now you have me thinking about the physical action that comes with a switch. That is a pretty important experience with visual, audio, and possibly tactile feedback, so I think that you are right, authors and application developers should not have to bear the burden of properly crafting it.

[tuespetre]

Yall, I was looking at my 3-way bulb lamp tonight. And an input of type “switch” would be excellent if it had the ability to cycle through states.

[alystair]

I created a proof of concept (chromium-based browsers only) for styling of checkbox inputs with a 'toggle' attribute. My preference leans towards 'toggle' naming instead of 'switch'.

https://codepen.io/alystair/pen/jOWWqwa?editors=1100

About the POC

• I felt this was timely due to the recent work that Microsoft and others have done to improve the default styling of inputs elements across multiple browsers.
• Matches default Chrome style. Although it's technically a checkbox, it stylistically resembles an elongated radio input.
• Pure HTML/CSS with no JS outside of setting indeterminate.
• POC won't work under Firefox because according to the spec, I shouldn't be able to use ::before/after on self-closing elements, but it saved me plenty of time! Wish changing input styles was more intuitive...
• It's accessible... because it's literally a checkbox input.
• Let me know if it requires a specific license for reuse.

Since it's an alternative styling to 'checkbox', implementation wouldn't be as difficult as creating an entirely new input type.

Screenshot

One gotcha I see with plain toggles (such as this POC) is that current state isn't as obvious compared to checkboxes. This may be due to lack of iconography (checkmark, etc). Perhaps allowing for on/off state styling, as seen in many light/dark mode toggles popping up these days may solve the issue.