This has actually been problematic for me and I'm sure others. I'm currently working on an app that is Angular based and trying as hard as I can to avoid a jQuery dependency, mostly because I have no direct use for it and would rather avoid the dependency as it is rather large in file size, actually my largest. I've gone through multiple states of 'this library fits my needs right now and is fast to implement, but I need jQuery' using it, then immediately placing a TODO to get rid of it ASAP when I have time to work something else into being what I want.

This comment shouldn't be taken as a rant or complaint, I know why the current state of libraries is what it is, just an observation that jQuery seems to be, at least for me, transitioning from being 'an assumption' into 'the thing I want to get rid of'.

I could be wrong, but if you use a CDN, won't jQuery be already cached for 99% of users? I can definitely imagine that filesize is an issue with less popular frameworks, but I'd wager that it really doesn't matter with jQuery.

If anyone has statistics on this, I'd love to see them!

You're in fact wrong, the chance that users will have exactly the same version of jQuery cached is pretty small. [1] If you want to read more about jQuery on cdns, there is a long discussion on html5boilerplate github page. [2]

[1] http://statichtml.com/2011/google-ajax-libraries-caching.htm...

[2] https://github.com/h5bp/html5-boilerplate/pull/1327

Well dang, thanks for pointing out my error and providing sources to back it up.

If you are using Angular already, you have a lite jQuery lib loaded. Perhaps it covers the cases you want to use jQuery for?

http://docs.angularjs.org/api/angular.element

I've tried this but have found that in almost all cases jqLite doesn't implement something needed for a given lib. Moreover, a single lib not working with jqLite spoils the entire thing.

For Angular there's https://github.com/import-io/angular-toggle-switch

That switch isn't draggable. It becomes a UX antipattern – a false affordance – if you can't swipe it on/off.

You know, I forgot that people actually drag these things. Now that you can't get with CSS, as far as I'm aware.

It's draggable for me (on Chrome).

Looking at the source itself, there's no way it's "draggable" unless you're just toggling it coincidentally with drag gestures. Perhaps your drags are just coinciding with the 0.3s ease animation, or we have a different expectation of what it means to drag a switch…in iOS, those types of switches will follow the finger's drag motion, not just be toggled by the existence of one.

I definitely didn't make it to be draggable. When I made it, I wasn't even thinking that people actually did that.

Confirming draggable for me too. Chrome version 28.0.1500.95 on Fedora Linux 17. It probably means nothing at all but it only works if my cursor stays on the "label" bit. If I move the cursor up or down off the label while dragging it snaps to whichever option is closest

* Missed the bit where I can drag it halfway one way and then back to the original position

It's not draggable for me on Chrome. Version 28.

:checked isn't supported in oldie

The phrasing "Switch on" is terrible: are you telling me that the switch is currently "on" or that clicking it will turn it on?

That's why I made it so easily customizable. Generally, you'd probably want to have more of a label or some context for a control like this. In this case, if you're smart about the wording, it can serve as its own label.

Think of the light switches in your house. They do have a label (look closely), but there's also context: By switching it one way or the other, you'll immediately see the effect when the lights turn on or off.