<input type=checkbox 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 WICG/webcomponents#187 (comment)

[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 WICG/virtual-scroller#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

[yisibl]

@annevk Nice!

I think it would be good for the specification to also specify the interaction behavior of dragging, which would help other browser implementations to remain interoperable.

As a user, I'd love to have dragging as a feature that would otherwise require JS.

[annevk]

HTML doesn't go into that level of detail for built-in controls. That might make sense in the context of an appearance:base control, but that's a bit further off.

[domenic]

I'd encourage people to continue their discussion of Safari's implementation on the Safari bug tracker, not on the HTML Standard bug tracker.

[yisibl]

HTML doesn't go into that level of detail for built-in controls. That might make sense in the context of an appearance:base control, but that's a bit further off.

I apologize for not knowing enough about the scope of the HTML specification.
It looks like this should go to CSSWG?

[annevk]

(I decided to reply to #9546 (comment) here as this reply doesn't really pertain directly to the contents of the PR. And I generally prefer open-ended discussion to happen in the issues.)

Hey @chrishtr, good to know we're largely in agreement. We would certainly like to have more definitive answers for styling form controls as well and we hope that if we all prioritize that somewhat we can make a dent in the coming years. Now given your response there's a couple things I wanted to note:

• It seems that on the same day you wrote that appearance: none is not sufficient, Joey is proposing doing exactly that for proposed select element enhancements here: [css-ui] Changing UA styles based on the computed value of the appearance property w3c/csswg-drafts#10028 (comment). I think that illustrates that what we should do exactly around styling form controls is still rather unclear and would benefit from more discussion.
• I don't think it's feasible to define switch's rendering model in isolation from other controls. I belatedly filed [css-ui] Styling of native appearance w3c/csswg-drafts#10039 on sorting this out further. Our hope was that it would be sufficient for v1 that it's essentially a checkbox, but with different intrinsic sizing. It seems you have placed a much higher bar for doing anything in this area, but it's not clear that is reasonable. It's certainly not something that was upheld when <details name> was added.
• Although you claim our approach is not stylable, it certainly is. As requested we made sure that all properties have their initial values in the appearance: none case so web developers essentially have a clean canvas. We would have liked to go further with pseudo elements, but there were multiple open issues on the CSS WG side that haven't really progressed thus far:
  • Names of <input type=range> / <input type=checkbox switch> pseudo-elements w3c/csswg-drafts#9830
  • [css-pseudo-4] Standardizing input[type="range"] styling w3c/csswg-drafts#4410
  • [css-ui] Form control pseudo-element audit w3c/csswg-drafts#9825
  • New property to control the direction of slider controls w3c/csswg-drafts#9832
• You now claim that appearance: base is a pre-requisite (although unclear how that aligns with the select element issue above), but in a much more recent comment than the one you pointed to Mason said the opposite: <input type=checkbox switch> #4180 (comment). (And later on also suggested the to us rather unacceptable <input base> as an alternative further hinting that that entire topic requires more thought, collaboration, and cannot be solved for a single control.)
• As for the feedback on the semantics:
  • Controlling the orientation of controls is one of the CSS issues referenced above. As I noted there perhaps an attribute is the way to go there after all, given the semantic implications. This is not a problem unique to switch and needs a holistic solution.
  • Controlling the labels I'm less clear on. This is not a property I think that is offered by OS libraries, but it's certainly something we could look into. I don't think nested elements is a very attractive solution for that, even if that were a possibility.
  • The accessibility exposure is handled with the switch role. If you have further feedback on this it would be good to raise that in Expose <input type=checkbox switch> as role=switch w3c/html-aam#496. There's also tentative WPTs for that.

I hope we can make meaningful progress together on all this soon and figure out a larger plan around stylable form controls. Thanks!

[tabatkins]

It seems you have placed a much higher bar for doing anything in this area, but it's not clear that is reasonable.

A switch does have a higher bar than a checkbox, yes. There's significantly more variation in styling of existing hand-rolled switch controls than there is with a checkbox, and the internal structure is meaningfully more complex. It's nearly the complexity of a range input, which does indeed trigger exactly the issues Chris is worried about (authors ignoring the built-in because it's ugly in its base form, and insufficiently styleable to fix).

It's certainly not something that was upheld when <details name> was added.

Do you have any styling concerns about <details name> that aren't already part of plain <details> and will be solved in both cases by the same solutions? Off the top of my head I can't think of any. I don't think this is a meaningfully comparable case, so it's appropriate to have a different response to it.

[scottaohara]

Commenting here as follow on to being mentioned in the other thread, and the Webkit bug I had filed.

The a11y concern with the current state of the switch proposal is how to treat or explain the accessibility implications of authors adding custom CSS pseudo content to styled switches. The text that authors would add to a switch in this manner is not typically representative of its 'label', but rather text / revised text, or a graphical representation of the switch's state. E.g., "on" or "off" being a typical visible representation of the way the switch is communicated to people using screen readers, for example.

But where there is presently a gap is how 'custom states' might be conveyed to people. E.g., a switch that displays text in its track of 'light' or 'dark', where the designer's intent is that those are the states they want the switch to convey to people, but a user who would interact with such a switch would continue to hear "on" and "off".

<label for=s>Theme</label>
<input type=checkbox switch>

<style>
[switch]:checked::before {
  content: 'light'
}
[switch]::after {
  content: 'dark'
}
/* other styles here to position the pseudo content based on the current state, 
    so only one string of text is visible at a time */
</style>

The webkit bug i filed became an issue about how the alternative text for the pseudo content had a bug, so marking it as decorative wasn't working, and thus the pseudo content was being used to name the switch, since none of the demos had labels. While that was a bug that became apparent because of the unlabelled examples, making the alt for pseudo content work properly doesn't resolve the above where one might want the visible pseudo content that represents the custom 'states' to be conveyed - but it would still be inappropriate to convey it as the 'name' of the switch.

We have been discussing this exact issue in Open UI, and the subsequent issue I filed in ARIA in how this use case might be supported.

A potential solution that was discussed was having companion attributes in HTML to allow authors to express what state they'd want communicated, rather than the default on/off. (the reason companion attributes in HTML was brought up is because while ARIA could arguably create the attributes to do this - ideally developers shouldn't have to use ARIA to make default HTML elements fully accessible. So we would like to see this solved in HTML, rather than as an extra feature/band aid someone would need ARIA for). Making them attributes would mean that then CSS pseudo content could still leverage the text, allowing devs to continue to style the way they are now. But it'd take the strings out of CSS and into HTML, where then those attributes could be exposed to the accessibility tree, and would allow for arguably easier localization by developers.

<label for=s>Theme</label>
<input type=checkbox switch onstate=light offstate=dark>

<style>
input[switch]::before {
  content: attr(offstate);
}
input[switch]:checked::before {
  content: attr(onstate);
}
</style>

If someone has a different proposal to accommodate this use case that wouldn't need these attributes, then awesome. Would love to hear it. But without accounting for that / how to make the custom states accessible to more than just people who can see, i would expect some strong guidance informing authors to not provide custom states in this way, and also guidance on how to craft labels for their switch controls that would lend themselves better to the on/off states the control communicates. E.g., "Enable dark theme" where hearing on/off would make more sense, instead of just "theme" where on/off is insufficient and the visible pseudo content is necessary to understand what on and off even mean.

If state could be communicated via the attributes I mentioned (bikeshed away) then the 'descendants' of the switch could arguably just be hidden from the a11y tree. If not going in that direction though, then again would expect guidance to emphasize the importance of not relying on pseudo content to convey information about the swtich - and how if a switch goes unlabelled (already should be a no-no....) then the pseudo content could contribute to the name of the control, or not, depending on if decorative CSS alt text was applied to the pseudo content... and honestly, devs will often miss this detail...

[chrishtr]

(I decided to reply to #9546 (comment) here as this reply doesn't really pertain directly to the contents of the PR. And I generally prefer open-ended discussion to happen in the issues.)

I wasn’t sure whether to comment on the PR or issue myself; discussing non-PR review items further here makes sense to me.

Hey @chrishtr, good to know we're largely in agreement. We would certainly like to have more definitive answers for styling form controls as well and we hope that if we all prioritize that somewhat we can make a dent in the coming years.

Definitely! We all agree I think that customized styling of built-in form controls, but without losing all of the other benefits of those built-in controls, is an important developer need (and has been for a very long time).

It seems that on the same day you wrote your that appearance: none is not sufficient, Joey is proposing doing exactly that for proposed select element enhancements here: [css-ui] Changing UA styles based on the computed value of the appearance property w3c/csswg-drafts#10028 (comment). I think that illustrates that what we should do exactly around styling form controls is still rather unclear and would benefit from more discussion.

The issue can definitely be confusing (at least for me). In fact, I discussed it at length with him yesterday to make sure I understood it fully, and I think I understand it well now.

What Joey is saying there is that we won’t be able to change the UA style sheet in response to different values of appearance. It doesn’t mean that there is no difference between appearance: none and appearance:base. His statement is in fact in support of having a third value for appearance in order to support the fully developer-styleable version.

Stepping back / orthogonally to the above point, let me describe what I/the DOM team mean by a “styleable form control”. It’s a form control that has a mode where:

• The developer can apply arbitrary styles and content to it to fit their site’s design
• And nevertheless, the user agent can always understand the form control and provide users with important features like accessibility and autofill that depend on fully understanding the control’s semantics

Currently, websites often use appearance:none or other approaches to form controls that utilize extra div elements that are outside the form control to represent it visually. For example, even for a checkbox, more advanced versions of swapping out the glyph or surrounding style can result in the need to use specialized divs unassociated with the actual <input type=checkbox> and event handlers that mirror state or forward events. This can result in worse accessibility and inability for the UA to safely update the checkbox state (because the site might not correctly mirror that state back into its divs).

In the case of <select> it’s almost always the case that sites entirely elide the <select> element, because appearance:none for that control doesn’t allow any styling of the popup. For example, MUI select menus need to use a “sea of divs, SVG, ARIA attributes and CSS classes” (not to mention plenty of script) to represent the select menu, and place the selected element in a hidden <input>. In the appearance:base future none of that will be necessary, and user/developer outcomes will be significantly better.

I don't think it's feasible to define switch's rendering model in isolation from other controls. I belatedly filed [css-ui] Styling of native appearance w3c/csswg-drafts#10039 on sorting this out further.

I agree that this should be worked out, thanks for filing that issue and let’s discuss more there.

It's certainly not something that was upheld when <details name> was added.

I’m not sure how this is applicable. The name attribute didn’t introduce a new form control. I guess you’re referring to how the name attribute allows grouping of details elements and that is somehow a new semantic? I don’t think that is comparable, and we can see that because as @dbaron has been retrofitting styleability onto <details>, he hasn't needed to address the name attribute.

We would have liked to go further with pseudo elements, but there were multiple open issues on the CSS WG side that haven't really progressed thus far:

• Names of <input type=range> / <input type=checkbox switch> pseudo-elements w3c/csswg-drafts#9830
• [css-pseudo-4] Standardizing input[type="range"] styling w3c/csswg-drafts#4410
• [css-ui] Form control pseudo-element audit w3c/csswg-drafts#9825
• New property to control the direction of slider controls w3c/csswg-drafts#9832

I agree these should progress. We'll actively engage with these issues, but we'll need WebKit folks to help drive them to consensus.

You now claim that appearance: base is a pre-requisite (although unclear how that aligns with the select element issue above), but in a much more recent comment than the one you pointed to Mason said the opposite: #4180 (comment). (And later on also suggested the to us rather unacceptable as an alternative further hinting that that entire topic requires more thought, collaboration, and cannot be solved for a single control.)

Mason was suggesting alternate designs in those cases (e.g. using an attribute to opt-in, rather than a CSS property), in part to address possible drawbacks or complications of a CSS property. To reiterate, I (and Joey in his comment referenced above) are saying we think that approach (the appearance CSS property) would work fine for select and we’re ok with it. Joey is now prototyping a complete implementation.

I hope we can make meaningful progress together on all this soon and figure out a larger plan around stylable form controls. Thanks!

I agree 100%. The main aim of my comment was about shipping, not about the viability of different proposals. I’m glad we are collectively making progress on this area, since it’s important to developers that we help them solve this problem. I think the web will be much better off for our efforts!

[annevk]

I don't think we're in agreement that changing appearance cannot possibly change the default style sheet. However, how would <input type=checkbox> work if appearance:base cannot change the default style sheet? It's a little worrying this is not being approached holistically.

And also, it was at least our understanding that appearance:base would give web developers a set of controls that look reasonable by default, have a consistent look, are accessible (and thus have sufficient contrast), etc. I'm having a hard time seeing how we can get there if we're bound to appearance:none.

[LeaVerou]

Some thoughts (that may be better as a separate issue?) from an architectural point of view:

It’s a pretty common problem that authors want to style controls in a way that looks dramatically different, even though the underlying semantics and API don't necessarily change very much (or even at all).

A few examples:

• Checkbox and switches
• Sliders (<input type=range>) and spinners (<input type=number>) can be seen as different presentations for the same thing.
• Circular sliders and regular sliders
• Circular progress bars and regular progress bars
• <meter> and rating widgets
• Dropdown, radios, cycle toggles, exclusive button groups
• Checkbox group, <select multiple>, multiselect dropdown, non-exclusive button group

So how could things like these be addressed?

• Should the syntax be CSS-based?
  Things like these go beyond the low-level control of CSS. Even if something like native CSS mixins worked, these use cases require new pseudo-elements and/or slots, so it's unclear if that's even possible via a pure CSS solution. And even semantically, this is not 100% presentation, it's UI, which is the domain of HTML.
• New elements? Using existing elements has the advantage of a natural fallback mechanism, and reduces the surface space of elements that authors need to learn by introducing a natural grouping. A two stage process of base thing → UI presented could involve lower cognitive overhead.

So it seems that an attribute might be the better approach here, but not ad-hoc attributes like switch but something that has room to grow and address the more general problem at hand. Perhaps ui="switch"?

[chrishtr]

However, how would work if appearance:base cannot change the default style sheet? It's a little worrying this is not being approached holistically.

And also, it was at least our understanding that appearance:base would give web developers a set of controls that look reasonable by default, have a consistent look, are accessible (and thus have sufficient contrast), etc. I'm having a hard time seeing how we can get there if we're bound to appearance:none.

You make a good point that we need to make sure it works for a variety of form controls, looks ok by default, and be easily customizable. To that end, I worked with @argyleink to explore that for several controls and commented here with our results. It looks feasible to me to do so without changing UA styles for input or select, with the default output looking fine and accessible by default.

[hober]

@chrishtr wrote:

Stepping back / orthogonally to the above point, let me describe what I/the DOM team mean by a “styleable form control”.

What do you mean by "the DOM team"? People who work on the DOM Standard? Surely that includes @annevk.

[chrishtr]

@chrishtr wrote:

What do you mean by "the DOM team"? People who work on the DOM Standard? Surely that includes @annevk.

I meant the Chrome DOM team. Apologies for forgetting the qualifier.