Dude, these are great, ignore the haters. People understand slider toggles and, for top level, high value on/off values or mobile versions of a UI these will be fine.

Just keep polishing them and getting them cross browser. I'll be forking the project and using them.

I'd like to second this sentiment. Instead of tearing down someone's significant effort to build something cool, the community should constructively communicate their issues with the project and offer suggestions for improvement.

I was personally impressed that drag actions were supported, because that's a frequently overlooked aspect when people roll their own slider toggles. Without looking at the source, I would guess that implementing mobile touch events would go a long way towards making this library cross-browser.

I feel that there is a mix of legitimate criticism and “hating.” Of course I don't like to read the actual hating, but I also don't understand why we on HN should unquestioningly praise everything posted here simple because someone worked on it.

Yeah, that's fair: I'm lumping legitimate criticism and reasonable UX opinions in with "hating", but I'd bet for the guy who put his technical heart into these things, the short, unqualified (no "hey, cool stuff!") criticisms are tough to swallow.

I was surprised that Bootstrap didn't have these from the get-go, so I'm going to say, again: hell yes. This is practical, useful development that will make a lot of apps better.

I would strongly advice against using these. While these type of toggle switches work great on mobile, they can we really confusing on desktop/mobile web: where does one click to change state, which state is active etc.

Matt Gemmell wrote a good post about toggle switches some time ago: http://mattgemmell.com/2011/11/01/on-off-switches/

That article is about a particular implementation of toggle switches that makes a number of usability mistakes. He contrasts that implementation with iOS' implementation, and highlights how the iOS version avoids these mistakes.

The buttons linked follow the example from iOS and avoid the mistakes he talks about.

Even on iOS I sometimes wondered if the "Off" word means that it is offline or will be offline after the toggle.

Except that you can't do the 'drag' style toggle on mobile devices. But if they had that, I'd agree with you.

android 4+ has drag style toggles that also respond to a tap like ios in addition to actually being draggable

Please don't use these. I've seen too many mobile users get confused by these sliders, wondering why they can't manually slide them.

It's weird jQueryUI hasn't implemented touch events for dragging yet. Here's an example using YUI: http://www.orangebits.nl/code/gallery-slidecheckbox/gallery-...

You can manually slide these!

They look really good.

Hoever, on iOS5, especially when zoomed in - page just scrolls.

On the demo page, when not zoomed in, it hard to tell if it actually slides or not because the button is completely covered by my finger tip.

Not on a mobile device. (iOS 5 Chrome)

Not on Jellybean Chrome.

Regardless, like everyone else suggests.. please don't use these.

I opened an issue for that

It's actually poor UX for desktop users too. It is possible to slide the buttons with a mouse drag and have them fail to change state. I see this behavior on many sites trying to optimize for mobile, but it degrades the desktop UX.

I had toggles like this on my site and found that a checkbox was a lot less confusing. It is just too hard to tell if state is successfully saved and if clicking things turns it on or off.

The behavior I ended up implementing is... when the box is clicked, it is immediately hidden and replaced with a loading animation while the ajax request is hitting the server saving state. When that finishes, it shows a icon-thumbs-up for a second and then the checkbox again (either checked or unchecked).

I'm wary of these, because form elements tend to be very, very very veryvery platform-dependent, and users (like me!) develop expectations about how toggles (i.e., checkboxes) should behave on the platform they're using.

I know this isn't your intent, but when the behavior of something like this fails to match my expectations, it is extra irritating, because I feel the author thought having something pretty and iOS-looking was more important than it being usable for me. Either that, or else s/he decided that I'm too stupid to know what I like, and decided to shove an iOS form-control down my throat.

That being said, I must admit that these are visually gorgeous, and their behavior seems pretty excellent at first blush. (But again, I am unsure how I will feel once I start seeing them pop up and inevitably being even slightly misused in the wild. I also haven't tried them on my phone yet.)

Please package this as a Component for better interoperability and modularity.

https://github.com/component/component https://github.com/component/component/wiki/F.A.Q

Twitter bootstrap isn't modular or supported by a package manager.

Funny. I just started using these.

The assumption that the "toggle" is 50% of the width is hard coded into the library. I went to change it and, holy cow, the code is a mess.

I got it to work, but had to disable the click-and-slide behavior.

Be warned if you decide to change any of its behavior!

Looks great.

Two things,

#1: If you modify the attribute checked of the input, the state doesn't change.

#2: I don't see a programmatic way of changing the state from your source without re-initializing all the elements?

#1 That's not possible http://stackoverflow.com/questions/4836818/jquery-how-to-cat...

#2 You're right

#1: Not really impossible, just requires additional maintaining of a monitor, methods within the script, or custom triggers to handle the switch.

Mattia DMed me about this earlier today asking if it could be included in the Bootstrap core. For the time being, I've decided against it as it's another custom form element and we're not implementing anything like that at this point.

That said, if any iOS style switches were done very well, we can explore adding them down the line. I'm not against them 100%, but custom form elements can get tricky. I'm not going to discourage their development—tons of folks have created their own implementation of this. I look forward to them improving over time.

Looking at this again, I'll try to shoot him some feedback so he can improve them and we can get closer to a solution that's fit for the Bootstrap core.

I'm mixed on using these buttons. I've seen people in user research tests use them well, and then I've seen people use them horribly in such a situation too. However, there are times when they're perfectly acceptable.

I've forked and pull requested.

The background states were light at the top and darker at the bottom giving a button feel, rather than an inset feel. :)

These are terrible for ui/ux. not only do they not behave as you would expect, by actually sliding Them, but this pattern is inconsistent with mobile ui native to both IOS and especially android recently where they actually slide.

So sad to see people discouraging the effort.

Someone should come up with an unofficial list of all these bootstrap additions. They're really great, but I always forget about them when I'm actually get to doing work.

http://bootsnipp.com/ & http://designshack.net/articles/css/20-awesome-resources-for... were recently posted here although they doesn't perfectly match what you're suggesting.

Couldn't a lot of these, including TFA, be pull requests to Bootstrap?

I'm the creator of Bootsnipp.com and I will put a nice centralized resources page on bootsnipp soon, right now I have all the resources in the Bootsnipp twitter account @bootsnipp. Hopefully that will be helpful!

Ugh I hate these on airbrake. They never work properly.

It seems to me that the on state of the button should have the outline around the blue area (of the default button) also be blue instead of gray. Keeping the border gray when the slider goes to "on" gives the button the wrong appearance. The blue area doesn't look like it has been uncovered but instead looks like a tab sticking out of the side.

Awesome, one suggestion I would make is that the buttons should ignore input in when translating between on and off. It seems awkward that it will just keep switching on and off even though I have stop giving it input, or accidentally double clicking on it and set it back to what ever it was.

Just added a pull request for that

For some reason, I had expected this to be default in Bootstrap. Thanks for posting this

Bootstrap has Toggle Buttons http://twitter.github.com/bootstrap/javascript.html#buttons

Oh cool. I skimmed right over that. I still meant iOS-like toggle buttons but thanks!

I've managed to break it and get a few pixels of pink showing through at the corners in OSX Chrome. http://imgur.com/9jT7m Look good otherwise

Looks nice, can you set their color and apperance using clases in the same way as normal Bootstrap buttons, e.g .btn .btn-primary, etc?

Dear Matias, why do you require us to put a div around the input? Why not just make this targetable by class?

Very nice. I wish these were in the core bootstrap to let people who need to use them, use them.

I would recommend getting rid of the styling options and let people style in their own CSS.

Isn't that against the point of Bootstrap? The fact Bootstrap is opinionated is what makes it's rapid development.

Interesting. I always expected the way to do this was with radio buttons.

Unfortunately, you can't style those in Firefox.

Do you mean checkboxes? But if so: yeah, me too.

Well, either radio buttons or a single checkbox, because the point of these sliders is that you can only make a single selection: on or off, not both.

This is using checkboxes ??