From: Jeremy J Starcher on
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?
From: Thomas 'PointedEars' Lahn on
Jeremy J Starcher wrote:

> 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
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
From: Jeremy J Starcher on
On Thu, 08 Apr 2010 19:53:04 +0200, Thomas 'PointedEars' Lahn wrote:

> Jeremy J Starcher wrote:
>
>> 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.

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%28v=VS.85%29.aspx


So.. what is the difference between properties and attributes?
From: Thomas 'PointedEars' Lahn on
Jeremy J Starcher wrote:

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

I have explained that at great length not long ago.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Jeremy J Starcher on
On Thu, 08 Apr 2010 20:26:11 +0200, Thomas 'PointedEars' Lahn wrote:

> Jeremy J Starcher wrote:
>
>> So.. what is the difference between properties and attributes?
>
> 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.