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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
There are rendering differences. But it feels like the rendering fallbacks for non-supporting browsers (everyone else) should handle what they have here fine.
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.
