An HTML Switch Control
webkit.org
webkit.org
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.
<form id=theme>
<label for=theme-l>light</label><input id=theme-l type=radio name=theme value=l>
<input id=theme-d type=radio name=theme value=d checked><label for=theme-d>dark</label>
</form>
<style>
input:checked{position:relative;z-index:1}
input+input{margin-left:-1em}
</style>I'd much rather write:
<select type=switch id=theme>
<option value=l>light</option>
<option value=d selected>dark</option>
</select>
<label>light<input type=radio name=theme value=l></label>That's why their main application is opting out of tracking, where user confusion is a desired feature.
There's a mention of pull request to standards (repo?) but that is curiously not linked to anything.
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.
It'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)
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.
Considering the constraints, I think very well done safari. Please get the second implementor on board.
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.
This is just some bullshit Apple pushed onto the web without talking to anyone about it just to push their own proprietary UI.
<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.
checked="checked"> 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.