Setting a property via property or setAttribute

Question

Is one of these more preferable than the other? Why? How about performance--if these are being called thousands of times?

A) element.setAttribute("disabled", true);
B) element.disabled = true;

They both seem to disable an input[text] element in FF 4.

B is certainly more idiomatic. The W3C came along and made the DOM APIs look like Java. >. — davidchambers, Nov 05 '11 at 07:40
@davidchambers: You prefer some weird getter/setter magic in the background? — thejh, Nov 05 '11 at 07:43
possible duplicate of [JavaScript setAttribute vs .attribute=](http://stackoverflow.com/questions/3919291/javascript-setattribute-vs-attribute) — Felix Kling, Nov 05 '11 at 10:10

score 5 · Accepted Answer · edited Nov 05 '11 at 07:52

5

In general…

Use properties. For a long time (until version 7 or 8 IIRC) Internet Explorer had a seriously broken implementation of setAttribute that would set the property not the attribute (the classic point of failure was class since there is no class property (it is className).

In this case in particular… element.setAttribute("disabled", true); is wrong. It should be element.setAttribute("disabled", "disabled");

edited Nov 05 '11 at 07:52

thejh

44,854
16
96
107

answered Nov 05 '11 at 07:46

Quentin

914,110
126
1,211
1,335

You sure that's incorrect? [W3.org](http://www.w3.org/TR/html5/forms.html#the-fieldset-element) says that this attribute is a boolean. Both work, of course. – Some Guy Nov 05 '11 at 08:15
2

@Amaan — That describes the DOM API (and thus the `disabled` *property*, so it is `element.disabled = true/false`) – Quentin Nov 05 '11 at 08:34
Oh. I thought it'd work similarly for setAttribute. Guess I was wrong. – Some Guy Nov 05 '11 at 08:36
4

@Quentin - `element.setAttribute("disabled", true)` isn't "wrong". The disabled attribute doesn't have a value, the second argument is irrelevant so any value will do (even empty string, or none at all). It is the presence of the attribute that matters, not its value. – RobG Nov 05 '11 at 13:28
@RobG — It does have a value ("disabled"), you are just allowed to leave the name off when you write markup (just as you are allowed to leave the end tag off a `
` and leave off the start and end tags for `
`. – Quentin Nov 05 '11 at 14:43
@Quentin - read the specification, either [HTML 4.01](http://www.w3.org/TR/html4/interact/forms.html#adef-disabled) (which is the current HTML standard) or [HTML5](http://dev.w3.org/html5/spec-author-view/introduction.html#restrictions-on-content-models-and-on-attribute-values) (which is a draft) under "Errors that indicate a likely misunderstanding of the specification". – RobG Nov 06 '11 at 20:38
@RobG — See the [definition of a boolean attribute](http://www.w3.org/TR/html4/intro/sgmltut.html#didx-boolean_attribute) (it doesn't say "takes a 'true' or 'false' value"). – Quentin Nov 06 '11 at 20:40
@Quentin - The HTML disabled attribute has no value. In a valid HTML 4.01 document it is written as `<... disabled ...>`. It's presence creates a DOM property that has a boolean value of true. The only reason it was ever written with a value, e.g. `<... disabled="disabled" ...>`, was to satisfy the XML syntax requirements of XHTML—the value served no other purpose it's ignored. The DOM *setAttribute* method creates an HTML disabled attribute. When setting, it does not require any value at all, because the **presence** of the attribute causes the related DOM property to be true. – RobG Nov 07 '11 at 00:10
@RobG — The only part of that which is true is the bit about the DOM property. Reread the definition I linked to in my previous comment. That predates XHTML (which just removed the option to use the shorthand version where you write only the value and not the name (or the `=` or the quotes)). – Quentin Nov 07 '11 at 06:43
@Quentin - XHTML 1.0 became a standard barely 1 month after HTML 4.01, clearly they were developed with full knowledge of each other. The section on SGML was likely added to bring the HTML specification closer to XML. If you go back to HTML 3.2 (when XML was in its infancy), there is no mention at all of giving "boolean" attributes values, and the HTML 4.01 DTD doesn't give them a default value. – RobG Nov 07 '11 at 07:23
@RobG — Boolean attributes are SGML / XML features used by (X)HTML. SGML has been around since the '60s and long predates XML. HTML 3.2 doesn't mention it explicitly because it assumes you will read it in the context of SGML. If we go back earlier, then even [HTML 2](http://www.w3.org/MarkUp/html-spec/html-pubtext.html) is clearly an SGML application. – Quentin Nov 07 '11 at 12:34
@RobG — As for your claim that HTML 4.01 doesn't specific a default value in the DTD, that is true … because you can't specify the attribute without explicitly specifying the value. You can specify [just the value](http://www.w3.org/TR/html4/intro/sgmltut.html#didx-boolean_attribute) and the DTD tells us what value you are allowed to give it: `disabled (disabled)` – Quentin Nov 07 '11 at 12:36
@Quentin - Not sure I understand "can't specify the attribute without explicitly specifying the value". – RobG Nov 09 '11 at 03:49
@Quentin - Given ``, in Firefox 5, Chrome 15 and Opera 11 *getAttribute* returns an empty string, in IE8 it returns "true". Apart from highlighting IE's poor implementation, it shows that those browsers don't give the attribute a default value. The specification for [getAttribute](http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-666EE0F9) states that it returns "the empty string if that attribute does not have a specified or default value". Browsers don't give the attribute a default value, but they all show the input as checked by default. – RobG Nov 09 '11 at 03:50
@RobG — As I've said several times, if you specify `disabled` then you are specifying the value and omitting the name, and congratulations, you appear to have found a bug which is consistent across all browsers except IE (which is different). – Quentin Nov 09 '11 at 07:52
@Quentin - so once again there is the specification and then there is reality. Thanks for persisting. – RobG Nov 09 '11 at 08:23
As of this writing, HTML 5.2 spec specifies that "the disabled attribute is specified on this element (regardless of its value)". So the bug in the 'specs' was fixed, apparently, and now behaves as per what @RobG said (https://www.w3.org/TR/html52/sec-forms.html#enabling-and-disabling-form-controls-the-disabled-attribute) – Jan 05 '18 at 13:04

cHao · Answer 2 · 2011-11-05T19:36:26.417

element.setAttribute("disabled", some_bool) doesn't work like you'd think it will. In particular, standardswise, disabled is what's known as a boolean attribute; its very presence, regardless of its value, makes it true. disabled="", disabled="disabled", disabled="true" and even disabled="false"(!!!) all mean the same thing in most browsers. (Although the last two are actually invalid HTML, most browsers will consider them equivalent to disabled="disabled" for truth purposes. Including every one of the Big Four.) You set a boolean attribute to true by setting a value -- any value, even if it's falsy -- and you set it to false by removing the attribute entirely.

If you care about the actual string value of the attribute (which in this case you shouldn't), and particularly if the attribute isn't already exposed via the DOM (that is, it doesn't have a corresponding property), then use (get/set)Attribute. In most cases (particularly if you care about how it affects the element, like in this case where you're trying to disable an element), use the DOM property.

XHTML will only validate `boolean="boolean"`. HTML 4.01 will only validate `boolean` and `boolean="boolean"`. HTML 5 will validate `boolean`, `boolean=""`, and `boolean="boolean"`. They're not the same things at all. `boolean="true"` will not validate in any of them. It's illegal. — , Nov 05 '11 at 19:04
I mentioned what browsers do, not what validates. :) Valid or not, the four are all equivalent in every browser i have access to (IE7-9, FF7, Chrome 14, and Opera 11.52). *Even when the document has an XHTML Strict doctype and .xhtml extension.* Some check for well-formedness, but *none* of them complain about the value of the "disabled" attribute -- they only care that it has one (because of XML's rules). — cHao, Nov 05 '11 at 19:33

score 0 · Answer 3 · answered Nov 05 '11 at 07:37

0

IE needs some attributes to be set with setAttribute, but not all. I don't have a list though, you just have to check if it works or not. Also, using setAttribute will put the attribute in the DOM, so it can be shown when doing view source.

answered Nov 05 '11 at 07:37

Some programmer dude

400,186
35
402
621

2

I've never heard of IE needing `setAttribute` for anything, quite the opposite, and `view source` shows the **source** not a serialisation of the live DOM. – Quentin Nov 05 '11 at 07:47
@Quentin It's to early here in Sweden, maybe it was the other way around. But I recently did one feature where I HAD to use `setAttribute` or it wouldn't work in one browser, but right now I can't seem to remember which, IE or FF. :/ – Some programmer dude Nov 05 '11 at 07:51
@Joachim - there are various quirks with *get/setAttribute* in IE. Also, Firefox will not create DOM properties for non-standard attributes, so for those you must use *getAttribute*. It's a mess. Better to just use property access with standard attributes and avoid non-stanard attributes altogether. – RobG Nov 09 '11 at 04:17

score 0 · Answer 4 · answered Nov 05 '11 at 14:14

0

Only one tip: element.setAttribute('class',xxx) doesnt works in some versions of IE.

Prefer element.className = xxx instead

answered Nov 05 '11 at 14:14

Ricardo Bin

887
6
12

Setting a property via property or setAttribute

4 Answers4

Linked