5 ms·

An HTML Switch Control

68 points by feross 3y ago

jwells89 3y ago
Very cool, love to see new widgets added to HTML (even if this is technically a variation on checkbox). Hope to see more — this is the sort of thing that eventually helps slip down frameworks and libraries and lets web authors do more with less.
38 3y ago
Please God no. It's awful for accessibility. What's on? What's off? Or is it left or right? Or something else? Also fun times when someone starts using gray for the element color (I've seen that in production). It's inventing a square wheel, when a round wheel already exists.
- pilif 3y ago
  The control reflects how the equivalent of checkboxes look on mobile devices in native apps. So this is a great way to get to use the same control as the rest of the OS uses without having to implement it yourself in CSS and JS. This means that as the OS changes, this control will adapt, including accessibility affordances like showing a 0 or 1 on the control to denote state. I see why you don’t like the control, but this is what mobile OSes use (mainly because a checkbox the size required for a finger to hit comfortably would look ridiculous) and what users are now used to and what many websites in their mobile modes are emulating and not getting quite right. Being able to have access to the native control is a huge benefit I think.
  - phkahler 3y ago
    Done right, a checkbox should toggle when you touch the label as well. No need for a giant box.
- jsjohnst 3y ago
  > It's awful for accessibility. What's on? What's off? There’s an accessibility mode where it says literally on and off as appropriate. It follows the same behavior as native controls on the same platform, including aria behavior. Want to spread more fud?
  - phkahler 3y ago
    This was just discussed in several HN topics. Is "on" the current state, or what happens if you flip the switch? It's not obvious. Checkboxes are obvious.
    - djbusby 3y ago
      Real life switch shows it's current state (eg: light switch, up for on (and some even have little text showing ON when on)). Like a checkbox shows it's current state.
      - kube-system 3y ago
        Not that I disagree with you, but: > up for on .. is regionally specific. e.g. in some places, you turn on lights in a house by flipping the switch down.
        pjerem 3y ago
        In my house, it’s random. Not because there is no standard around here (I live in the EU, The Holy Land Of The Mandatory Standards) but because it looks like the previous owners didn’t care enough. More seriously, it also depends if there is only one switch for the light. If there is two nothing makes sense anymore and if there is more, you are forced to use a relay so switches become one state buttons.
        Izkata 3y ago
        I didn't know anyone had any standard until a conversation on here where it came up a year or two ago. Every place I've lived had two switches somewhere (both ends of a hallway, both entrances to a room, etc) so I never internalized any directionality for switches - it's just always been "flip the switch if the light is in the wrong state". One or two of the switches I've had have even been sideways.
      - riffraff 3y ago
        I've seen plenty of rooms with more than one switch, where it acts like a toggle, so "on" can be up or down. There is no standard.
- deleted 3y ago
  [deleted]
cookiengineer 3y ago
Why didn't they propose a WHATWG draft for type=switchbox instead? This kind of shit is why web tech is in a messy state. Remember how we got there, and WebKit behaving like Trident isn't helping anyone.
- jauntywundrkind 3y ago
  I'm not sure how it's not a checkbox though? There are rendering differences. But it feels like the rendering fallbacks for non-supporting browsers (everyone else) should handle what they have here fine.
- Borgz 3y ago
  Because then it wouldn't be backward compatible.
- halostatue 3y ago
  https://github.com/whatwg/html/pull/9546 https://github.com/whatwg/html/pull/9546
bitpush 3y ago
What is the standards story for this? Is this Webkit only? There's a mention of pull request to standards (repo?) but that is curiously not linked to anything.
- wubin 3y ago
  HTML switch was already requested in 2018: https://github.com/whatwg/html/issues/4180 https://github.com/whatwg/html/issues/4180
deleted 3y ago
[deleted]
000ooo000 3y ago
As mentioned by others, OK idea, but not a fan that this isn't standardized. After a quick search+peruse, these seem to indicate that it's not around the corner either. Happy (/hope) to be corrected. https://github.com/whatwg/html/issues/4180 https://github.com/whatwg/html/issues/4180 https://github.com/mozilla/standards-positions/issues/990 https://github.com/mozilla/standards-positions/issues/990
- domenicd 3y ago
  Also see the spec PR from WebKit: https://github.com/whatwg/html/pull/9546 https://github.com/whatwg/html/pull/9546
tylerchilds 3y ago
Is there a polyfill available to make this available cross browser? that seems like an acceptable compromise, if we're going to normalize fragmenting the web.
- sublinear 3y ago
  Not sure how a polyfill would be able to replicate the native OS style without needing to be updated regularly in sync with OS releases. If the native OS style uses effects not supported by CSS the illusion will break. If that's the way it's going to be implemented why not just use a CSS class from a UI framework instead of a janky non-standard attribute with a desirable name that's bound to cause bugs in naive code?
  - tylerchilds 3y ago
    I totally agree. When we were running into cross browser innovation in CSS, we used vendor prefixes. Awfully bold of apple to claim switch when it should be osx-switch, webkit-switch, ios-switch, or apple-switch, depending on their law of conway. My polyfill comment was more tongue in cheek than "i will want and use that". Honestly, for this use case, I'm not too bothered, but in principle, this is precedent of the shape of things to come, but I think we're all up to speed on apple killing off the "add to homescreen" PWAs.
    - tylerchilds 3y ago
      Correction: I was not up to speed on apple not killing off the add to homescreen stuff. https://appleinsider.com/articles/24/03/01/apple-reverses-course-on-death-of-progressive-web-apps-in-eu https://appleinsider.com/articles/24/03/01/apple-reverses-co... On the other hand, as I was one day early, I'm taking full credit.
sublinear 3y ago
> The HTML for this example looks roughly like this: <style> .special { accent-color: papayawhip } </style> <input type=checkbox switch checked> <input type=checkbox switch checked class=special> I immediately don't trust these docs nor the implementation due to the almost invalid HTML examples. Attributes with spaces require quotes around the value. Opinions that extend beyond the standards, but even to the examples is why the web is so ugly. The way this parses is that switch and checked are attributes with no value. That is technically correct but ambiguous to humans. Unsupported browsers will just ignore the switch attribute, but adding custom attributes this way is bound to cause weird bugs if using frameworks that don't prefix the names of their custom attributes. I believe certain doctypes or serving the HTML with another content type (XML) will throw an error for not having the quotes.
- abdusco 3y ago
  > Attributes with spaces require quotes around the value. It's meant to be read/parsed as `type="checkbox"`, `switch="true"`, `checked="true"`, `class="special"`. They're different attributes, not a long `type` attribute without quotes.
  - sublinear 3y ago
    > checked="true" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... That's not how the value of the checked attribute works. It's already messed up enough. > The value attribute is one which all <input>s share; however, it serves a special purpose for inputs of type checkbox: when a form is submitted, only checkboxes which are currently checked are submitted to the server, and the reported value is the value of the value attribute. If the value is not otherwise specified, it is the string "on" by default.
    - vidarh 3y ago
      > That's not how the value of the checked attribute works. It is roughly/conceptually how the "checked" attribute works, in that boolean attributes provided by name but without a value will be set/truthy. From the link you gave: > checked > A boolean attribute indicating whether this checkbox is checked by default (when the page loads). What you quoted is how the "value" attribute works, which is entirely irrelevant to how the "checked" attribute works.
atishay811 3y ago
Took forever. I opened the github issue more than 5 years back. This implementation is solid though - full backwards compatibility with checkbox, stying support. Considering the constraints, I think very well done safari. Please get the second implementor on board.
QuadrupleA 3y ago
Why? We already have checkboxes with the same purpose. If that's not stylish enough, it's easy enough to implement a switch like this on the page. Browsers are already enormously complicated - every feature just piles another straw on the camel's back, uses more memory & code, makes the web a little harder to learn, bloats our Electron executables a little more. Wish developers would be a little more judicious about adding things. Maybe even remove things once in a while.
- djbusby 3y ago
  Didn't Marquee and Blink elements get removed? That's progress.
  - littlestymaar 3y ago
    Honestly, I don't understand why blink was removed: the use was pretty niche, but it existed and now people are doing crap with Javascript to do the same effect and spending tons of CPU cycles out of the window.
    - WA 3y ago
      You can do it in CSS only.
      - littlestymaar 3y ago
        Sure, like many things, and you should because it's going to be hardware accelerated, but in practice people don't. Also, blink was removed before the CSS version was efficiently optimized on the browser's side: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900
- cbovis 3y ago
  With a switch you expect an immediate effect to occur. The expectation is that I toggle the switch then get on with my day. Checkboxes don't have side effects, they're expected to be form based. Once I toggle a checkbox the expectation is that I need to then also submit that selection in some way.
abrudz 3y ago
Please don't support making switches be an alternative to checkboxes, since it isn't clear what the current state means. I do like the idea of switches, but they should only be used to select one of two labelled choices but usually not yes/no, as a checkbox does well there. See e.g. https://abrudz.github.io/sans/ https://abrudz.github.io/sans/ where I use four switches to choose between binary non-yes/no options. Make a new element or input type that makes it easy to do switches right, with two labels.
- userbinator 3y ago
  but they should only be used to select one of two labelled choices There's already an existing control for that too: the radiobutton.
  - onion2k 3y ago
    Radio buttons can be used to select one of any number of choices. Toggles are strictly limited to two.
    - deprecative 3y ago
      Which is what a checkbox is. A switch element seems needlessly duplicative. A checkbox and a switch have the same purpose. I don't mind it entirely after all we have plenty of block level elements that do the same things as one another. This just feels like a solution in search of a problem.
      - onion2k 3y ago
        Not really. A checkbox toggles between two binary states of a single option. A toggle switches between two different options. UI design isn't simple. You can't just pick basic options. Getting it right takes a lot of effort.
        extra88 3y ago
        A switch is not for choosing between two options. It has two states, on and off, and it should be named in a way that makes sense with that in mind ("Dark mode" not "Dark/Light"). A checkbox can actually have 3 states, checked, unchecked, indeterminate/mixed.
pavlov 3y ago
The “switch versus checkbox” advice in this post is not very clear, IMO. The essential difference is that a switch commits its state immediately, while a checkbox is part of a form that has a separate submit/apply action. The real-world metaphors for these elements help remember the distinction. A light switch acts immediately. A checkbox printed on paper only takes effect when that form is processed somehow. Another standard UI element that usually follows the same rule is radio buttons. They are form elements, and their immediate-effect counterpart is the multi-part button (which Apple calls “segmented control”).
- pupileater 3y ago
  this is correct. checkbox and radio buttons are form elements and it's helping the user to select choices before sending a form / finalizing. A switch is turning something on or off. a crude example: when you are ordering your porsche taycan you are using checkboxes to select additional features and radios to set the color of the car. this form will be finalized into an order, your selections cannot (or will not often) be changed later, a final choice has been made. your new porsche arrives and you start to set it up to your liking, you might switch on/off features the way you like and switch them back later in a different context. (you won't be able to remove features from your car, or add new one.) if changing a car's color is not a radio button anymore on an order sheet, then it might be just a switch or a more complex selector of different colors. look at the BMW i Vision Dee, its led panels all around, you won't have to choose a color before, they successfuly eliminated the need for a color selection before owning the car.
  - deprecative 3y ago
    Sure seems like this should be a drop down that updates a preview image in change.
MrOxiMoron 3y ago
the biggest problem I have with it that with custom styling and bad choices in those that it will be hard to see when it's on or off. A checkbox is very clear in that regard.
Exoristos 3y ago
This is just two radio buttons in a trench coat.
mdhb 3y ago
For all the shit that Google gets for introducing new APIs at least they go through the regular standards tracks. This is just some bullshit Apple pushed onto the web without talking to anyone about it just to push their own proprietary UI.
- halostatue 3y ago
  https://github.com/whatwg/html/pull/9546 https://github.com/whatwg/html/pull/9546
poiuyt098 3y ago
How about making it submit the "off" value while you're at it? So I wouldn't need js hacks for arrays of checkboxes on forms.
- sourdoughness 3y ago
  The way this is implemented, it’s polish over a checkbox, with a fallback to the checkbox where it’s not supported. The semantics has therefore got to be the same as a checkbox - that is, no (native) submission of “off” switches.

68 points by feross 3y ago

Very cool, love to see new widgets added to HTML (even if this is technically a variation on checkbox). Hope to see more — this is the sort of thing that eventually helps slip down frameworks and libraries and lets web authors do more with less.

38 3y ago

Please God no. It's awful for accessibility. What's on? What's off? Or is it left or right? Or something else? Also fun times when someone starts using gray for the element color (I've seen that in production). It's inventing a square wheel, when a round wheel already exists.

pilif 3y ago
The control reflects how the equivalent of checkboxes look on mobile devices in native apps. So this is a great way to get to use the same control as the rest of the OS uses without having to implement it yourself in CSS and JS. This means that as the OS changes, this control will adapt, including accessibility affordances like showing a 0 or 1 on the control to denote state. I see why you don’t like the control, but this is what mobile OSes use (mainly because a checkbox the size required for a finger to hit comfortably would look ridiculous) and what users are now used to and what many websites in their mobile modes are emulating and not getting quite right. Being able to have access to the native control is a huge benefit I think.
- phkahler 3y ago
  Done right, a checkbox should toggle when you touch the label as well. No need for a giant box.
jsjohnst 3y ago
> It's awful for accessibility. What's on? What's off? There’s an accessibility mode where it says literally on and off as appropriate. It follows the same behavior as native controls on the same platform, including aria behavior. Want to spread more fud?
- phkahler 3y ago
  This was just discussed in several HN topics. Is "on" the current state, or what happens if you flip the switch? It's not obvious. Checkboxes are obvious.
  - djbusby 3y ago
    Real life switch shows it's current state (eg: light switch, up for on (and some even have little text showing ON when on)). Like a checkbox shows it's current state.
    - kube-system 3y ago
      Not that I disagree with you, but: > up for on .. is regionally specific. e.g. in some places, you turn on lights in a house by flipping the switch down.
      - pjerem 3y ago
        In my house, it’s random. Not because there is no standard around here (I live in the EU, The Holy Land Of The Mandatory Standards) but because it looks like the previous owners didn’t care enough. More seriously, it also depends if there is only one switch for the light. If there is two nothing makes sense anymore and if there is more, you are forced to use a relay so switches become one state buttons.
        Izkata 3y ago
        I didn't know anyone had any standard until a conversation on here where it came up a year or two ago. Every place I've lived had two switches somewhere (both ends of a hallway, both entrances to a room, etc) so I never internalized any directionality for switches - it's just always been "flip the switch if the light is in the wrong state". One or two of the switches I've had have even been sideways.
    - riffraff 3y ago
      I've seen plenty of rooms with more than one switch, where it acts like a toggle, so "on" can be up or down. There is no standard.
deleted 3y ago
[deleted]

cookiengineer 3y ago

Why didn't they propose a WHATWG draft for type=switchbox instead? This kind of shit is why web tech is in a messy state. Remember how we got there, and WebKit behaving like Trident isn't helping anyone.

jauntywundrkind 3y ago
I'm not sure how it's not a checkbox though? There are rendering differences. But it feels like the rendering fallbacks for non-supporting browsers (everyone else) should handle what they have here fine.
Borgz 3y ago
Because then it wouldn't be backward compatible.
halostatue 3y ago
https://github.com/whatwg/html/pull/9546 https://github.com/whatwg/html/pull/9546

bitpush 3y ago

What is the standards story for this? Is this Webkit only? There's a mention of pull request to standards (repo?) but that is curiously not linked to anything.

wubin 3y ago
HTML switch was already requested in 2018: https://github.com/whatwg/html/issues/4180 https://github.com/whatwg/html/issues/4180

deleted 3y ago

[deleted]

000ooo000 3y ago

As mentioned by others, OK idea, but not a fan that this isn't standardized. After a quick search+peruse, these seem to indicate that it's not around the corner either. Happy (/hope) to be corrected. https://github.com/whatwg/html/issues/4180 https://github.com/whatwg/html/issues/4180 https://github.com/mozilla/standards-positions/issues/990 https://github.com/mozilla/standards-positions/issues/990

domenicd 3y ago
Also see the spec PR from WebKit: https://github.com/whatwg/html/pull/9546 https://github.com/whatwg/html/pull/9546

tylerchilds 3y ago

Is there a polyfill available to make this available cross browser? that seems like an acceptable compromise, if we're going to normalize fragmenting the web.

sublinear 3y ago
Not sure how a polyfill would be able to replicate the native OS style without needing to be updated regularly in sync with OS releases. If the native OS style uses effects not supported by CSS the illusion will break. If that's the way it's going to be implemented why not just use a CSS class from a UI framework instead of a janky non-standard attribute with a desirable name that's bound to cause bugs in naive code?
- tylerchilds 3y ago
  I totally agree. When we were running into cross browser innovation in CSS, we used vendor prefixes. Awfully bold of apple to claim switch when it should be osx-switch, webkit-switch, ios-switch, or apple-switch, depending on their law of conway. My polyfill comment was more tongue in cheek than "i will want and use that". Honestly, for this use case, I'm not too bothered, but in principle, this is precedent of the shape of things to come, but I think we're all up to speed on apple killing off the "add to homescreen" PWAs.
  - tylerchilds 3y ago
    Correction: I was not up to speed on apple not killing off the add to homescreen stuff. https://appleinsider.com/articles/24/03/01/apple-reverses-course-on-death-of-progressive-web-apps-in-eu https://appleinsider.com/articles/24/03/01/apple-reverses-co... On the other hand, as I was one day early, I'm taking full credit.

sublinear 3y ago

> The HTML for this example looks roughly like this: <style> .special { accent-color: papayawhip } </style> <input type=checkbox switch checked> <input type=checkbox switch checked class=special> I immediately don't trust these docs nor the implementation due to the almost invalid HTML examples. Attributes with spaces require quotes around the value. Opinions that extend beyond the standards, but even to the examples is why the web is so ugly. The way this parses is that switch and checked are attributes with no value. That is technically correct but ambiguous to humans. Unsupported browsers will just ignore the switch attribute, but adding custom attributes this way is bound to cause weird bugs if using frameworks that don't prefix the names of their custom attributes. I believe certain doctypes or serving the HTML with another content type (XML) will throw an error for not having the quotes.

abdusco 3y ago
> Attributes with spaces require quotes around the value. It's meant to be read/parsed as `type="checkbox"`, `switch="true"`, `checked="true"`, `class="special"`. They're different attributes, not a long `type` attribute without quotes.
- sublinear 3y ago
  > checked="true" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... That's not how the value of the checked attribute works. It's already messed up enough. > The value attribute is one which all <input>s share; however, it serves a special purpose for inputs of type checkbox: when a form is submitted, only checkboxes which are currently checked are submitted to the server, and the reported value is the value of the value attribute. If the value is not otherwise specified, it is the string "on" by default.
  - vidarh 3y ago
    > That's not how the value of the checked attribute works. It is roughly/conceptually how the "checked" attribute works, in that boolean attributes provided by name but without a value will be set/truthy. From the link you gave: > checked > A boolean attribute indicating whether this checkbox is checked by default (when the page loads). What you quoted is how the "value" attribute works, which is entirely irrelevant to how the "checked" attribute works.

atishay811 3y ago

Took forever. I opened the github issue more than 5 years back. This implementation is solid though - full backwards compatibility with checkbox, stying support. Considering the constraints, I think very well done safari. Please get the second implementor on board.

QuadrupleA 3y ago

Why? We already have checkboxes with the same purpose. If that's not stylish enough, it's easy enough to implement a switch like this on the page. Browsers are already enormously complicated - every feature just piles another straw on the camel's back, uses more memory & code, makes the web a little harder to learn, bloats our Electron executables a little more. Wish developers would be a little more judicious about adding things. Maybe even remove things once in a while.

djbusby 3y ago
Didn't Marquee and Blink elements get removed? That's progress.
- littlestymaar 3y ago
  Honestly, I don't understand why blink was removed: the use was pretty niche, but it existed and now people are doing crap with Javascript to do the same effect and spending tons of CPU cycles out of the window.
  - WA 3y ago
    You can do it in CSS only.
    - littlestymaar 3y ago
      Sure, like many things, and you should because it's going to be hardware accelerated, but in practice people don't. Also, blink was removed before the CSS version was efficiently optimized on the browser's side: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900
cbovis 3y ago
With a switch you expect an immediate effect to occur. The expectation is that I toggle the switch then get on with my day. Checkboxes don't have side effects, they're expected to be form based. Once I toggle a checkbox the expectation is that I need to then also submit that selection in some way.

abrudz 3y ago

Please don't support making switches be an alternative to checkboxes, since it isn't clear what the current state means. I do like the idea of switches, but they should only be used to select one of two labelled choices but usually not yes/no, as a checkbox does well there. See e.g. https://abrudz.github.io/sans/ https://abrudz.github.io/sans/ where I use four switches to choose between binary non-yes/no options. Make a new element or input type that makes it easy to do switches right, with two labels.

userbinator 3y ago
but they should only be used to select one of two labelled choices There's already an existing control for that too: the radiobutton.
- onion2k 3y ago
  Radio buttons can be used to select one of any number of choices. Toggles are strictly limited to two.
  - deprecative 3y ago
    Which is what a checkbox is. A switch element seems needlessly duplicative. A checkbox and a switch have the same purpose. I don't mind it entirely after all we have plenty of block level elements that do the same things as one another. This just feels like a solution in search of a problem.
    - onion2k 3y ago
      Not really. A checkbox toggles between two binary states of a single option. A toggle switches between two different options. UI design isn't simple. You can't just pick basic options. Getting it right takes a lot of effort.
      - extra88 3y ago
        A switch is not for choosing between two options. It has two states, on and off, and it should be named in a way that makes sense with that in mind ("Dark mode" not "Dark/Light"). A checkbox can actually have 3 states, checked, unchecked, indeterminate/mixed.

pavlov 3y ago

The “switch versus checkbox” advice in this post is not very clear, IMO. The essential difference is that a switch commits its state immediately, while a checkbox is part of a form that has a separate submit/apply action. The real-world metaphors for these elements help remember the distinction. A light switch acts immediately. A checkbox printed on paper only takes effect when that form is processed somehow. Another standard UI element that usually follows the same rule is radio buttons. They are form elements, and their immediate-effect counterpart is the multi-part button (which Apple calls “segmented control”).

pupileater 3y ago
this is correct. checkbox and radio buttons are form elements and it's helping the user to select choices before sending a form / finalizing. A switch is turning something on or off. a crude example: when you are ordering your porsche taycan you are using checkboxes to select additional features and radios to set the color of the car. this form will be finalized into an order, your selections cannot (or will not often) be changed later, a final choice has been made. your new porsche arrives and you start to set it up to your liking, you might switch on/off features the way you like and switch them back later in a different context. (you won't be able to remove features from your car, or add new one.) if changing a car's color is not a radio button anymore on an order sheet, then it might be just a switch or a more complex selector of different colors. look at the BMW i Vision Dee, its led panels all around, you won't have to choose a color before, they successfuly eliminated the need for a color selection before owning the car.
- deprecative 3y ago
  Sure seems like this should be a drop down that updates a preview image in change.

MrOxiMoron 3y ago

the biggest problem I have with it that with custom styling and bad choices in those that it will be hard to see when it's on or off. A checkbox is very clear in that regard.

Exoristos 3y ago

This is just two radio buttons in a trench coat.

mdhb 3y ago

For all the shit that Google gets for introducing new APIs at least they go through the regular standards tracks. This is just some bullshit Apple pushed onto the web without talking to anyone about it just to push their own proprietary UI.

halostatue 3y ago
https://github.com/whatwg/html/pull/9546 https://github.com/whatwg/html/pull/9546

poiuyt098 3y ago

How about making it submit the "off" value while you're at it? So I wouldn't need js hacks for arrays of checkboxes on forms.

sourdoughness 3y ago
The way this is implemented, it’s polish over a checkbox, with a fallback to the checkbox where it’s not supported. The semantics has therefore got to be the same as a checkbox - that is, no (native) submission of “off” switches.