setAttribute versus assigning a property

[mitch]

Suppose I have a DOM element, say a td, and I want to add a
value to it to be used later. I am unclear on when it's OK to do

td.myAttr = "hello";

versus when I need to do

td.setAttribute("myAttr", "hello");

Could somebody explain the difference between these two?
In an application I'm working on, a lot of the code uses the
first method, and it seems to work most of the time, but
sometimes not, and I'm trying to understand the pattern.
Thanks.

[Randy Webb]

mitch said the following on 4/26/2006 4:08 PM:

Suppose I have a DOM element, say a td, and I want to add a
value to it to be used later. I am unclear on when it's OK to do

td.myAttr = "hello";

versus when I need to do

td.setAttribute("myAttr", "hello");

Could somebody explain the difference between these two?
One is buggy in IE and the other isn't.
In an application I'm working on, a lot of the code uses the
first method, and it seems to work most of the time, but
sometimes not, and I'm trying to understand the pattern.

When it fails would be a better indication of why it failed than to say
"It fails". Find an example of where domElementRef.property doesn't work
when domElementRef.setAttribute(property,propertyValue) does and post it
along with relevant HTML.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[VK]

mitch wrote:

Suppose I have a DOM element, say a td, and I want to add a
value to it to be used later. I am unclear on when it's OK to do

td.myAttr = "hello";

versus when I need to do

td.setAttribute("myAttr", "hello");

Could somebody explain the difference between these two?

In the first case you are dealing with the exposed scriptable DOM
interface, in the second case you are working directly with the DOM
tree. The difference may seem subtle, but it is revealed on
standard-compliant browsers like Firefox. Say if you define a div like
<div id="myDIV" foobar="something">Content</div>
then both attributes will be parsed and added to the tree. But on
var ref = document.getElementById('myDIV');
you are not getting the relevant tree fragment. Instead you are getting
DOM interface, and it will contain only properties and methods listed
for this interface. This way ref.id will give you "myDIV" but
ref.foobar will give you undefined. At the same time get/setAttribute
works directly with the tree. It is slower than DOM interface, but you
can get any parsed nodes this way, listed and not listed in the
interface.
ref.getAttribute('foobar') // "something"

[Thomas 'PointedEars' Lahn]

mitch wrote:

Suppose I have a DOM element, say a td, and I want to add a
value to it to be used later. I am unclear on when it's OK to do

td.myAttr = "hello";

versus when I need to do

td.setAttribute("myAttr", "hello");
If taken literally: neither one. You are dealing with host objects.
Do not expect that it is possible to add arbitrary properties to them
or to the items they represent. See ECMAScript 3,
Could somebody explain the difference between these two?
The first assignment creates a new property of the DOM host object
referred to, if that host object does not have it already and allows
that, and assigns it the value of "hello".

The second statement adds a new attribute to the (element) node this
host object represents, if the element does not have it already, and
if the DOM allows that. Although recommended by the W3C DOM Core
Specification, this approach usually is more error-prone than the
former, as setAttribute() implementations are known to be buggy
(i.e. do not follow the W3C DOM Core standard).
In an application I'm working on, a lot of the code uses the
first method, and it seems to work most of the time, but
sometimes not, and I'm trying to understand the pattern.

See? Avoid using host objects as containers for arbitrary information in
the first place. If you determined that the host object already has the
property, it is OK to assign it a value in the expected type/format, in
order to overwrite the current value. But do not try to create new
properties/attributes on it; "works for me" is not a reasonable design
approach.
PointedEars

[VK]

VK wrote:

mitch wrote:

Suppose I have a DOM element, say a td, and I want to add a
value to it to be used later. I am unclear on when it's OK to do

td.myAttr = "hello";

versus when I need to do

td.setAttribute("myAttr", "hello");

Could somebody explain the difference between these two?

In the first case you are dealing with the exposed scriptable DOM
interface, in the second case you are working directly with the DOM
tree. The difference may seem subtle, but it is revealed on
standard-compliant browsers like Firefox. Say if you define a div like
<div id="myDIV" foobar="something">Content</div>
then both attributes will be parsed and added to the tree. But on
var ref = document.getElementById('myDIV');
you are not getting the relevant tree fragment. Instead you are getting
DOM interface, and it will contain only properties and methods listed
for this interface. This way ref.id will give you "myDIV" but
ref.foobar will give you undefined. At the same time get/setAttribute
works directly with the tree. It is slower than DOM interface, but you
can get any parsed nodes this way, listed and not listed in the
interface.
ref.getAttribute('foobar') // "something"

Another key difference I missed to mention:

setAttribute("attrName", "attrValue") effectively equals to "runtime
typing in" <tagname attName="attValue">

It means that this way you can set only string values. if attValue is
not a string, a relevant toString() method will be called first.
Respectively getAttribute returns strings only. This way you cannot
store say object references via setAttribute, they will be stringified
and lost for you. You have to use DOM interface instead for that.