Any reason to ever use <node>.setAttribute (or getAttribute)?

[Jeremy J Starcher]

I know that <node>.setAttribute is unreliable thanks to various browser
differences and that the recommend practice is to use set the property on
the node directly.

But I found myself wondering ...

Is <node>.setAttribute ever actually useful? Does <node>.getAttribute
ever return more than just the property -- perhaps tracing back through
the style sheets in a reliable and consistent way?

 

[Thomas 'PointedEars' Lahn]

Is <node>.setAttribute ever actually useful?
Yes.

Does <node>.getAttribute ever return more than just the property --

No. It is supposed to return the _attribute value_ *instead*.

perhaps tracing back through the style sheets in a reliable and consistent
way?

No. Element::getAttribute() is supposed to return exactly the values of the
attributes of the element represented by the object implementing the Element
interface.


PointedEars

 

[Jeremy J Starcher]

No. It is supposed to return the _attribute value_ *instead*.


No. Element::getAttribute() is supposed to return exactly the values of
the attributes of the element represented by the object implementing the
Element interface.

Then this is where I have to wrinkle my nose and confess my total
confusion.

I've STFW and in every instance I can find, properties and attributes
appear interchangeable.

Align can also be a property, as shown here:
https://developer.mozilla.org/en/DOM/element.setAttribute

An example on MS's page again shows something that appears
interchangeable.
http://msdn.microsoft.com/en-us/library/dd347148(v=VS.85).aspx


So.. what is the difference between properties and attributes?

 

[Thomas 'PointedEars' Lahn]

So.. what is the difference between properties and attributes?

I have explained that at great length not long ago.


PointedEars

 

[Jeremy J Starcher]

I have explained that at great length not long ago.

I believe that I found the post you were referring to:
< http://groups.google.com/group/comp.lang.javascript/browse_thread/
thread/84e5d305bc453f6a/9ad5e3f7840fb19f?q=pointedears+attribute+property
+group:comp.lang.javascript#9ad5e3f7840fb19f >

To paraphrase if I understand correctly:

* Attributes are defined in the HTML
* Attributes are set on each element by the user-agent
* Properties are also set on each element, but the property name can vary
from the attribute name.
* Changing the property does /should not/ reflect backwards to a
change in the attribute. (Although some user agents are broken.)
* Changing the attribute /should/ reflect into a change on the
associated property.

If I am following that correctly, I still fail to see any benefit of
Element::setAttribute() and Element::getAttribute() over direct property
access. There /would/ be an advantage in Element::getAttribute() to get
the original value iff certain user-agents (IE) were not broken.

 

[Thomas 'PointedEars' Lahn]

I believe that I found the post you were referring to:
< http://groups.google.com/group/comp.lang.javascript/browse_thread/
thread/84e5d305bc453f6a/9ad5e3f7840fb19f?q=pointedears+attribute+property
+group:comp.lang.javascript#9ad5e3f7840fb19f >

To paraphrase if I understand correctly:

* Attributes are defined in the HTML
Yes.

* Attributes are set on each element by the user-agent

Attributes (in the markup sense) are primarily specified by the Web
developer as in

<a href="foo" target="bar" title="baz">42</a>
^^^^ ^^^^^^ ^^^^^

(or scripted variants thereof). However, some attributes have defined
default values while others are declared #IMPLIED where the user agent
defines the default value. (Which in combination with DOM implementation's
flaws makes it hard to write a standards-compliant replacement for
`innerHTML' read accesses.)

* Properties are also set on each element, but the property name can vary
from the attribute name.

Properties are set on element _objects_ (that implement DOM interfaces).

* Changing the property does /should not/ reflect backwards to a
change in the attribute. (Although some user agents are broken.)

Not always.

* Changing the attribute /should/ reflect into a change on the
associated property.

Not always.

If I am following that correctly, I still fail to see any benefit of
Element::setAttribute() and Element::getAttribute() over direct property
access. There /would/ be an advantage in Element::getAttribute() to get
the original value iff certain user-agents (IE) were not broken.

Not all DOM APIs provide property attributes on all of their interfaces, so
not all implementations of DOM APIs provide attribute properties on the
objects that implement those interfaces. There are not only HTML documents.


PointedEars

 

[Jorge]

I believe that I found the post you were referring to:
<http://groups.google.com/group/comp.lang.javascript/browse_thread/
thread/84e5d305bc453f6a/9ad5e3f7840fb19f?q=pointedears+attribute+property
+group:comp.lang.javascript#9ad5e3f7840fb19f >

To paraphrase if I understand correctly:

* Attributes are defined in the HTML
* Attributes are set on each element by the user-agent
* Properties are also set on each element, but the property name can vary
  from the attribute name.
* Changing the property does /should not/ reflect backwards to a
  change in the attribute. (Although some user agents are broken.)
* Changing the attribute /should/ reflect into a change on the
  associated property.

If I am following that correctly, I still fail to see any benefit of
Element::setAttribute() and Element::getAttribute() over direct property
access.  There /would/ be an advantage in Element::getAttribute() to get
the original value iff certain user-agents (IE) were not broken.

Also, attributes belong to DOM-land, and properties belong to
JavaScript-land.
And the attributes' values are strings.
And only a bunch of -legal, validable- DOM-land attributes are
reflected as properties (in JavaScript-land) and viceversa.
OTOH, properties can hold any type of value, not just strings.

 

[Thomas 'PointedEars' Lahn]

Not all DOM APIs provide property attributes on all of their interfaces,
so not all implementations of DOM APIs provide attribute properties on
the objects that implement those interfaces. There are not only HTML
documents.

And, lest you forget, sometimes you do want the (original) attribute value
instead of the (current) property value (which would be easy were it not for
flaws in DOM implementations).


PointedEars

 

[Jorge]

And, lest you forget, sometimes you do want the (original) attribute value
instead of the (current) property value (which would be easy were it not for
flaws in DOM implementations).

How would you recover the original value of a reflected attribute
that's been modified ?
Looking for it in the source ?