Intent to Implement: Toggle switch control element
TAMURA, Kent
Software Engineer, Google
Daniel Bratell
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFTzNQFSX4pNOZQJ9iFQWhx%3DmrgMRO8r1jDRj9x1MH%2Biw%40mail.gmail.com.
Emilio Cobos Álvarez
I kind of agree, fwiw. This looks just like a checkbox, fundamentally.
The explainer says that "It's hard to change checkbox's appearance to a switch-like appearance, for when that user experience is desired.", but is that really true? A checkbox with -webkit-appearance / -moz-appearance: none always becomes non-replaced in all browsers, and thus you can style it regularly plus add pseudo-elements.
For example, I just did a quick try here (source), and it looks pretty ok IMO (could be improved in multiple ways of course).
- Emilio
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z27sb31irbppqq%40cicero2.linkoping.osa.
Domenic Denicola
Hey Daniel and Emilio, thanks for chiming in!
We tried to make it clear that switches and checkboxes are different, linking to several external sources of documentation. Switches are not simply “modern checkboxes”; see e.g. NNG’s guidelines (linked from the explainer). Major modern UI platforms (e.g. Android, iOS, Windows, and as of the latest WWWDC, also macOS) distinguish between them and provide distinct APIs to developers. They are semantically distinct to users and to accessibility technology.
Regarding styling, it’s definitely possible for someone with good knowledge of CSS to override the appearance of a checkbox to make it more switch-like. This is not great, because then sighted users will see a switch, but AT users will be told about a checkbox. But more generally, the idea behind this intent (and others my team is working on) is to make the web platform something that’s easy to use out of the box, and competitive with the native control set of other platforms. Saying “use NSSwitch and you get a switch” is a good story. Saying “use <input type=checkbox>, but then adjust its ARIA role, and use these 37 lines of CSS to make it switch-like, and be sure to never set .indeterminate” is not a great story.
To Daniel’s point, historically we’ve indeed left the burden of creating a competitive and usable platform in the hands of library makers. We don’t think this has turned out very well, leading to library bloat, as well as inconsistent accessibility and UX. We’re hopeful that by providing more basic controls with the platform, we can reverse these trends, and let libraries and frameworks focus on higher-level issues like styling, data flow, and application-layer logic.
I hope this helps! I’m glad we have the early intent to implement stage, so we can have these discussions :).
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b046780c-8701-f368-f346-3ccc774aebb3%40mozilla.com.
Boris Zbarsky
I was wondering: was <input type="switch"> considered? The
explainer is not 100% clear on this, though it does talk about
possible interop issues with "native" implementations. That said,
interop issues that might arise with built-in modules are
uncharted territory so far; maybe we will be lucky and there won't
be any, but I'm a bit worried about it.
The risk is low. It's a small new feature, and no opposition by other browser vendors.
At least in the Firefox case, I suspect because we just weren't
asked, that I know of.
-Boris
Emilio Cobos Álvarez
Hey Daniel and Emilio, thanks for chiming in!
We tried to make it clear that switches and checkboxes are different, linking to several external sources of documentation. Switches are not simply “modern checkboxes”; see e.g. NNG’s guidelines (linked from the explainer). Major modern UI platforms (e.g. Android, iOS, Windows, and as of the latest WWWDC, also macOS) distinguish between them and provide distinct APIs to developers. They are semantically distinct to users and to accessibility technology.
Regarding styling, it’s definitely possible for someone with good knowledge of CSS to override the appearance of a checkbox to make it more switch-like. This is not great, because then sighted users will see a switch, but AT users will be told about a checkbox. But more generally, the idea behind this intent (and others my team is working on) is to make the web platform something that’s easy to use out of the box, and competitive with the native control set of other platforms. Saying “use NSSwitch and you get a switch” is a good story. Saying “use <input type=checkbox>, but then adjust its ARIA role, and use these 37 lines of CSS to make it switch-like, and be sure to never set .indeterminate” is not a great story.
To Daniel’s point, historically we’ve indeed left the burden of creating a competitive and usable platform in the hands of library makers. We don’t think this has turned out very well, leading to library bloat, as well as inconsistent accessibility and UX. We’re hopeful that by providing more basic controls with the platform, we can reverse these trends, and let libraries and frameworks focus on higher-level issues like styling, data flow, and application-layer logic.
I guess that's a fair take. I'm not 100% sure I agree with it, but sure.
I'm a bit concerned about what the fallback and interop story are for these custom elements:
- Are all browsers supposed to ship the same version of the standard library?
- Are they supposed to share implementation of these custom elements?
- What's the versioning story for these? And the
feature detection?
- What's the bar needed to get something shipped
as a builtin module?
It is a bit concerning that adding anything to this standard library will be setting it in stone forever. I guess that's also the case for adding a new built-in form controls, but the bar for those is quite a bit higher, I think...
In any case I see that most of these are already
open
issues
in a variety of repos. So I guess experimenting is ok as long as
they end up sorted out?
-- Emilio
I hope this helps! I’m glad we have the early intent to implement stage, so we can have these discussions :).
From: blin...@chromium.org <blin...@chromium.org> On Behalf Of Emilio Cobos Álvarez
Sent: Tuesday, June 11, 2019 06:59
To: blin...@chromium.org
Subject: Re: [blink-dev] Intent to Implement: Toggle switch control element
I kind of agree, fwiw. This looks just like a checkbox, fundamentally.
The explainer says that "It's hard to change checkbox's appearance to a switch-like appearance, for when that user experience is desired.", but is that really true? A checkbox with -webkit-appearance / -moz-appearance: none always becomes non-replaced in all browsers, and thus you can style it regularly plus add pseudo-elements.
For example, I just did a quick try here (source), and it looks pretty ok IMO (could be improved in multiple ways of course).
- Emilio
On 6/11/19 11:51 AM, Daniel Bratell wrote:
I know that the text at several places says that a switch is different from a checkbox, but it still sounds like a tweaked checkbox to me.
In modern UI:s standard checkboxes are considered outdated (ugly or unsuitable for other purposes) but won't this also be old/ugly in a couple of years, so that we will then need <input type=lever> for the next generation of boolean toggles?
With custom form elements, maybe new controls like this should be left to library makers?
/Daniel
On Mon, 10 Jun 2019 07:05:54 +0200, TAMURA, Kent <tk...@chromium.org> wrote:
Contact emailstk...@chromium.org Explainerhttps://github.com/tkent-google/std-switch/blob/master/README.md Design docs/spec N/A TAG reviewhttps://github.com/w3ctag/design-reviews/issues/384 Summary Introduce new form control element representing a toggle switch, as a built-in module Motivation Many UI frameworks have switch controls to represent off/on states and ask a user to change the state. As of June 2019 the HTML standard has a checkbox, which is functionally similar to switch control. However a checkbox and a toggle with have different semantics, and should have different accessibility roles. Risks
Interoperability and Compatibility The risk is low. It's a small new feature, and no opposition by other browser vendors. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive (https://github.com/whatwg/html/issues/4180) Positive for the feature, but not sure for implementation as a built-in module Activation This feature strongly depends on form-associated custom elements, which only Chrome supports as of June 2019.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No tests yet. We can test all behavior of this feature if we have testdriver.send_keys(). Link to entry on the Chrome Platform Statushttps://chromestatus.com/features/6624580116414464
--
TAMURA Kent
Software Engineer, Google
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFTzNQFSX4pNOZQJ9iFQWhx%3DmrgMRO8r1jDRj9x1MH%2Biw%40mail.gmail.com.
--
/* Opera Software, Linköping, Sweden: CEST (UTC+2) */
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z27sb31irbppqq%40cicero2.linkoping.osa.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b046780c-8701-f368-f346-3ccc774aebb3%40mozilla.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BN6PR13MB1651EDFCFC61ED1CB0EDC1B9DFED0%40BN6PR13MB1651.namprd13.prod.outlook.com.
Domenic Denicola
> I'm a bit concerned about what the fallback and interop story are for these custom elements:
Blink intends to implement these internally as custom elements in JavaScript, but the specification will be flexible and allow any implementation. The details need to be worked out. (E.g. assuming we stick with imports, we'd probably want to reuse the custom elements upgrade machinery if someone imports late, and maybe at that point specifying it in terms of custom elements makes more sense?) But, that's why we're implementing---it'll give us concrete pointers toward possible solutions to these questions.
As such, for the questions you listed as bullet points, all of the answers should be the same for <std-switch> as for <dialog> or <details> or <portal> or any other HTML elements. Browsers ship according to their priorities, not in lockstep. Browsers can share code (as is done for e.g. RegExp engines, Web Audio, or Web RTC), or can implement independently (as is done for most features). APIs get extended in a backward-compatible way, and can be detected by checking prototypes.
The bar is meant to be as high for new elements as it always was. We need a rigorous spec, and tests, and API owner approval, to ship something in Blink. And we need a rigorous spec, tests, and multi-implementer interest, before something lands in the HTML spec.
I'll see if we can make any of this clearer in the switch explainer. Thanks again for raising these things.