Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requesting <input type="switch"> #4180

Open
atishay opened this issue Nov 19, 2018 · 25 comments

Comments

9 participants
@atishay
Copy link

commented Nov 19, 2018

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.

Toggle Switch

@annevk

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

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

cc @whatwg/rendering

@atishay

This comment has been minimized.

Copy link
Author

commented Nov 19, 2018

Definitely makes more sense as we get backwards compatibility.

@annevk

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 19, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

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

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

@atishay

This comment has been minimized.

Copy link
Author

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

@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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

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

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

@atishay

This comment has been minimized.

Copy link
Author

commented Dec 5, 2018

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

@annevk

This comment has been minimized.

Copy link
Member

commented Dec 5, 2018

@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----

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 5, 2018

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

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 18, 2018

@atishay We're standardizing "Form-associated custom elements", and Chrome Canary has it behind a flag. Please refer to w3c/webcomponents#187 (comment)

@domenic

This comment has been minimized.

Copy link
Member

commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Author

commented Jan 9, 2019

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

This comment has been minimized.

Copy link
Author

commented Jan 29, 2019

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

@atishay

This comment has been minimized.

Copy link
Author

commented Feb 24, 2019

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

@tkent-google

This comment has been minimized.

Copy link
Collaborator

commented May 16, 2019

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

This comment has been minimized.

Copy link

commented May 16, 2019

@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

This comment has been minimized.

Copy link
Member

commented May 16, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 7, 2019

@zcorpan zcorpan referenced this issue Jun 13, 2019

Open

A toggle switch control element #384

3 of 5 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.