Confirmed, but it's more complicated. The required property does not exist on the element so our hook for boolean attributes returns undefined since the property is undefined. I'm not too worried about this one. There's no way to fix it and have the results be consistent across browsers unless we simply remove required from the boolean regex and drop support for setting that boolean with attr. OR, we can leave it as is since this is also an indicator that IE9 doesn't support required.

In other words, the boolHook is doing it's job, but it's not really doing anything in IE9.

This bug also exists in FF3.6

Another test case (created by coldhead)

http://jsfiddle.net/VrHHM/2/

I really only see two ways this could be patched

a) remove required from the boolHooks since apparently setting .required property isn't going to affect it anyway.

You can do this yourself in your JS with

 $.attrHooks.required = {} 

-- It should monkey patch this bug in the meantime.

b) Update the boolHook on get to only return the property if it is !== undefined, since it seems that FF3.6 / IE9 are returning "undefined" for the property:

http://jsfiddle.net/VrHHM/7/ has some further testing

Also mentioned in IRC...

 .is('[required]') 

seems to be an alternate way (not subject to this particular bug) to get true/false based on the presence of a "required" attribute...

Concerning gnarf's option b, I believe it already does that. We only return a value when true and undefined if not true. However, I see an underlying issue here and there are multiple options.

1. We can use the boolean hook as a means of checking for support, which becomes necessary if we are going to check the property values when returning values for these attributes (this is what it already does and we have specific tests for it).

2. We can check for the presence of the attribute without checking property values at all and return the attribute name if present and undefined if not (this will be consistent, but will not reflect the property since the properties are inconsistent across browsers).

3. We can drop support completely for using attr to set html5 boolean attributes such as autofocus, autoplay, controls, and required because these are the properties which are not consistently supported across browsers.

Personally, I am in favor of either 1 or 3. If 1 is the most popular, this bug can be closed. If 3 is the most popular, it's an easy fix. 2 would require the most work with all of the getAttribute AND getAttributeNode quirks in IE for boolean attributes and I don't think it's worth it.

For boolean attributes, all user cares about is its existence. So will introduce another API like .hasAttr() be an option? It conveys user intention more clearly and can function more efficiently by directly calling hasAttribute().

@gravof: I don't think that's a good enough reason to add a new function, especially since attr can handle it for everything that is not a boolean attribute. However, that may be a good reason to go with #3, restoring that functionality in attr for boolean attributes.

BTW, hasAttribute would not work in all browsers so we'd need a fallback similar to what attr does already anyway.

Just found out .is('[required]') doesn't work in IE8 and below. Should I fire another issue or does it relate to this issue?

Test case here: http://jsfiddle.net/VrHHM/11/

@gravof there are tickets open already concerning that issue. Thanks!

#9735 is a duplicate of this ticket.

Check the attribute node value for false for HTML5 booleans when not supported. Fixes #9504.

Changeset: 1886d7443453feab0b73f4a7c4b15fbd9401c4af

#9990 is a duplicate of this ticket.

Which version has this fix?