6 Answers
6

It would be pretty interesting in which browser you experience that behavior. Even more interesting would be to know, if not working means, the element does not get disabled, or the attribute is just missing the disabled as value.

Due to W3C there should not be a value for disabled or readonly.

So syntatically

<select disabled></select>

is just fine and correct. No value needed.

Unfortunatly, there is no way to create such a construct with javascript (if you don't want to overwrite the html), so you are forced to add some value. Since both propertys are boolean, you can add pretty much anything. .attr('disabled', 'foobar') is just as good as .attr('disabled', true).

Doing .attr('disabled', true/false); and the same with readonly is the quickest approach. However, do remember that if an element is "disabled" it will not appear in the forms submit data, whereas readonly will appear in the post data. This is a common pitfall for developers to want to disable input but then wonder why they don't get their $_POST data in PHP.

@OP: I suspect the button is functionally disabled but visually not disabled.

I experienced exactly the same symptoms. Using attr('disabled', 'disabled') yielded disabled="" in the DOM. The button was in fact disabled in that it no longer generated a click event nor submitted the form. However it was still being highlighted as if it were.

The cause was the CSS for the button, which contained the pseudo-selector ':active'. This is being applied even though the button is disabled. Adding ':not([DISABLED])' to active removed the misleading highlighting.

To any Drupal users, the Seven theme has this CSS and Seven is the default administrative theme.