since the latter will, if the box was initially checked, change the behaviour of a call to .reset() on any form that contains it - a subtle but probably unwelcome behaviour change.

For more context, some incomplete discussion of the changes to the handling of the checked attribute/property in the transition from 1.5.x to 1.6 can be found in the version 1.6 release notes and the Attributes vs. Properties section of the .prop() documentation.

Any version of jQuery

If you're working with just one element, you can always just modify the HTMLInputElement's .checked property:

@Xian removing the the checked attribute makes it impossible to reset the form
– mcgrailmMar 23 '11 at 15:27

6

As a side note, jQuery 1.6.1 should be fixing the issue I mentioned, so we can tehcnically all still go back to using $(...).prop(...)
– cwharrisMay 13 '11 at 20:08

17

"If you're working with just one element, it will always be fastest to use DOMElement.checked = true". But it would be negligible, because it's only one element...
– Tyler CromptonMar 30 '12 at 9:32

41

As Tyler says, it is a negligible improvement in performance. To me, coding using a common API makes it more readable than mixing native API and jQuery APIs. I'd stick with jQuery.
– Charlie KilianMay 4 '12 at 16:28

18

@TylerCrompton - Of course, its not entirely about performance, but doing $(element).prop('checked') is a complete waste of typing. element.checked exists and should be used in the cases where you already have element
– gnarfOct 1 '12 at 23:35

also $(selector).checked to check is checked
– eomeroffMay 2 '11 at 23:56

6

I tried this exact code and it didn't work for me in the case of a select all / select none checkbox that needs to check and uncheck all as well as check their state. Instead, I tried @Christopher Harris' answer and that did the trick.
– JD SmithMar 28 '13 at 1:26

Why using "form #mycheckbox" instead of simply "#mycheckbox"? The id is already unique in the whole document, it is faster and simpler to pick it directly.
– YuriAlbuquerqueOct 11 '13 at 15:27

@YuriAlbuquerque it was an example. you can use whatever selector you want.
– bchhunOct 13 '13 at 0:14

5

$(selector).checked does not work. There is no 'checked' method in jQuery.
– Brendan ByrdOct 7 '15 at 16:42

By doing this, you are using JavaScript standards for checking and unchecking checkboxes, so any browser that properly implements the "checked" property of the checkbox element will run this code flawlessly. This should be all major browsers, but I am unable to test previous to Internet Explorer 9.

The Problem (jQuery 1.6):

Once a user clicks on a checkbox, that checkbox stops responding to the "checked" attribute changes.

Here is an example of the checkbox attribute failing to do the job after someone has clicked the checkbox (this happens in Chrome).

This plugin will alter the checked property of any elements selected by jQuery, and successfully check and uncheck checkboxes under all circumstances. So, while this may seem like an over-bearing solution, it will make your site's user experience better, and help prevent user frustration.

In your first JSFiddle example you should be using removeAttr('checked') rather than attr('checked', false)
– Daniel X MooreJan 30 '12 at 7:00

4

@DanielXMoore, You're skirting around the issue. The example was to show that once the check-box was clicked by the user, the browser no longer responds to checked attribute changes, regardless of the method used to change them.
– cwharrisJan 30 '12 at 13:28

3

@ChristopherHarris Ok, you're right, I missed that. As of jQuery 1.6 shouldn't you use the .prop method though?$('.myCheckBox').prop('checked', true) That way it will automatically apply to the entire set of matched elements (only when setting though, getting is still only the first)
– Daniel X MooreFeb 2 '12 at 1:45

Yes. prop is definitely the appropriate way to set attributes on an element.
– cwharrisFeb 2 '12 at 2:40

4

Nice little plugin, thanks! To maintain chainability, add "return this" just before the end of the plugin.
– JD SmithMar 28 '13 at 2:47

@MarkAmery you mentioned that my post added nothing at the time of post but that is in accurate. If you look at the history of the accepted answer you'll find they suggest removing the element. Which makes it impossible to reset the form, which was why I posted to begin with.
– mcgrailmDec 15 '14 at 14:50

1

@mcgrailm I've gone ahead and modified the accepted answer in light of your remarks. If you'd like to cast an eye over it and check that it looks good in its current state, I'd appreciate that. My apologies again for offering up sharp criticism that was, at least in part, highly misguided.
– Mark AmeryDec 15 '14 at 16:54

This doesn't answer the question (the question is about setting whether a checkbox is checked, not determining whether a checkbox is checked). It's also a pretty ugly way of determining if the checkbox is checked (for one thing, you're exploiting the non-self-evident fact that .val() will always return undefined when called on 0 elements to detect that a jQuery object is empty, when you could simply check its .length instead) - see stackoverflow.com/questions/901712/… for more readable approaches.
– Mark AmeryDec 14 '14 at 23:47

-​1; mixing jQuery selectors like $("#check") with raw DOM API calls like document.getElementsByTagName("input") seems inelegant to me, especially given that the for loops here could be avoided by using .prop(). Regardless this is yet another late answer that adds nothing new.
– Mark AmeryDec 15 '14 at 18:33

In Internet Explorer prior to version 9, using .prop() to set a DOM
element property to anything other than a simple primitive value
(number, string, or boolean) can cause memory leaks if the property is
not removed (using .removeProp()) before the DOM element is removed
from the document. To safely set values on DOM objects without memory
leaks, use .data().

shouldn't it be true and false and not 'true' and 'false'?
– tpowerJan 5 '12 at 15:34

9

It "didn't work" because 'false' was converted to boolean value which resulted in true - empty string evaluates to false thus it "worked". See this fiddle for example of what I mean.
– Shadow WizardJun 24 '12 at 11:41

@chris97ong I've rolled back your edit; when someone says "Don't use the code below because it doesn't work", fixing that code while leaving the comment saying that it doesn't work is harmful - especially when it breaks the explanation in the comments of why the code isn't working. That said, this answer is still somewhat confused and deserves a downvote for the reasons given by tpower and ShadowWizard.
– Mark AmeryDec 15 '14 at 18:46

1

use true and false values for boolean, do not use 'true' or 'false' (strings).
– Jone PolvoraFeb 21 '15 at 22:34

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).