Hacker News new | past | comments | ask | show | jobs | submit login

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.


This feels like an old way of thinking. We used to have to submit to CGI, and it would have been very disruptive to do every time a control changed.

We don't have this separation for textboxes, radio boxes or selectors, so why do we need it for checkboxes?


Didn't Marquee and Blink elements get removed? That's progress.


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.


You can do it in CSS only.


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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: