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.
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.
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.
> 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?
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.
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.
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.
Don't know about the hair dryer, but a lot of other things have switched to buttons with indicator lights or screens nowadays. Dials and switches fell out of fashion like a decade ago.
As someone blind, I really hate the word "switch" because it is both a verb and a noun. So, I go to a page, reach an element with the text "something switch on" and I'm in the woods. Is this a switch in the on position or it is telling me that it is off and I can press to switch it on?
How is it any less obvious than a checkbox? If it looks like the empty/white, it’s off. If it’s the primary color, it’s on. Exactly the same as a checkbox.
There are rendering differences. But it feels like the rendering fallbacks for non-supporting browsers (everyone else) should handle what they have here fine.
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.
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.
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?
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.
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.
> 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.
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.
Apart from the issue regarding attributes, I do agree adding an attribute on the element isn't great. Though mostly because this is a functionally a checkbox, as evidenced by how they're fine with it falling back to a checkbox, and so they could have just added a CSS attribute instead.
> I believe certain doctypes or serving the HTML with another content type (XML) will throw an error for not having the quotes.
That is irrelevant - most HTML found in the wild is not particularly close to valid XML as it is. And as per sibling comments, there's no need for quotes here for html - they are multiple separate boolean attributes, and the norm in HTML is to use those without a value for the truthy case.
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.
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.
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.
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.
This feels like an enormously loaded set of expectations you are bringing here. If one in one hundred thousand people could reproduce this answer I'd be surprised.
This question of immediacy feels like it applies to any form control. I don't see how the slider is in any way clearer or more obviously immediate.
IMO this just comes down to Apple having switched to mainly using sliders, and wanting that to be a look people can use. And it so happens that Apple doesn't have "save" or "submit" or "done" on any of their forms: on Apple it so happens that almost all their form controls are live. But these are two separate decisions, aesthetic and function, and wanting to couple them is just forcing your prejudice, and there's not any actual reason cause or substance for it.
I have the same expectation - that's what a switch does, both in real life, and on devics. You toggle it, the thing happens. So I don't think this is 1 in 100,000.
Having a weird design language expressly for immediate-effect entities is absurd & dumb. There's other context we should be using to set expectations, rather than creating parallel systems that do the same thing but through gentle skeuomorphisms imply something. Currently we have checkboxes and checkboxes alone as distinct, but it feels like this line of logic should be extended further if this is the implication.
I think it's still 1 in 100,000 in any broad sense of people, not just Apple-fans on HN. Especially not folks who are already reading the thread.
For what it’s worth, I have the same expectation and have been applying it to forms since IOS 3 or 4.
If we’re going to have a switch-looking thing, it’s because it brings some skeuomorphic affordance with it: I think “off/on with immediate effect” seems like exactly the thing it should bring to differentiate from a checkbox.
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/ 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.
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.
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.
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”).
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.
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.
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.
67 comments
[ 3.6 ms ] story [ 40.6 ms ] threadIt's inventing a square wheel, when a round wheel already exists.
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.
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?
Like a checkbox shows it's current state.
> up for on
.. is regionally specific. e.g. in some places, you turn on lights in a house by flipping the switch down.
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.
One or two of the switches I've had have even been sideways.
But look around, loads of switches in the real world show their current state.
Hair Dryer, Stove, A/C. Mostly, toggle switches and dials show the current state. (And sure, 3x and 4x lighting circuits exist)
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.
There are rendering differences. But it feels like the rendering fallbacks for non-supporting browsers (everyone else) should handle what they have here fine.
There's a mention of pull request to standards (repo?) but that is curiously not linked to anything.
https://github.com/whatwg/html/issues/4180
https://github.com/mozilla/standards-positions/issues/990
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?
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.
On the other hand, as I was one day early, I'm taking full credit.
<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.
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.
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.
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.
> I believe certain doctypes or serving the HTML with another content type (XML) will throw an error for not having the quotes.
That is irrelevant - most HTML found in the wild is not particularly close to valid XML as it is. And as per sibling comments, there's no need for quotes here for html - they are multiple separate boolean attributes, and the norm in HTML is to use those without a value for the truthy case.
Considering the constraints, I think very well done safari. Please get the second implementor on board.
Also, blink was removed before the CSS version was efficiently optimized on the browser's side: https://github.com/Microsoft/vscode/issues/22900
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.
This question of immediacy feels like it applies to any form control. I don't see how the slider is in any way clearer or more obviously immediate.
IMO this just comes down to Apple having switched to mainly using sliders, and wanting that to be a look people can use. And it so happens that Apple doesn't have "save" or "submit" or "done" on any of their forms: on Apple it so happens that almost all their form controls are live. But these are two separate decisions, aesthetic and function, and wanting to couple them is just forcing your prejudice, and there's not any actual reason cause or substance for it.
I think it's still 1 in 100,000 in any broad sense of people, not just Apple-fans on HN. Especially not folks who are already reading the thread.
If we’re going to have a switch-looking thing, it’s because it brings some skeuomorphic affordance with it: I think “off/on with immediate effect” seems like exactly the thing it should bring to differentiate from a checkbox.
We don't have this separation for textboxes, radio boxes or selectors, so why do we need it for checkboxes?
Make a new element or input type that makes it easy to do switches right, with two labels.
There's already an existing control for that too: the radiobutton.
UI design isn't simple. You can't just pick basic options. Getting it right takes a lot of effort.
A checkbox can actually have 3 states, checked, unchecked, indeterminate/mixed.
I'd much rather write:
And it'd be an actual switch with one label on each side and I'd get the value with theme.valueThat's why their main application is opting out of tracking, where user confusion is a desired feature.
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”).
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.
This is just some bullshit Apple pushed onto the web without talking to anyone about it just to push their own proprietary UI.