Any reason to ever use <node>.setAttribute (or getAttribute)?
in [JavaScript]
|
Prev: QUESTION: how to add/remove classes to web browsers Javascript implementation?
Next: Execute code from text file
From: Thomas 'PointedEars' Lahn on 8 Apr 2010 16:07 Jeremy J Starcher wrote: > 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 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 -- 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: Jorge on 8 Apr 2010 16:08 On Apr 8, 9:22 pm, Jeremy J Starcher <r3...(a)yahoo.com> wrote: > 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. 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. -- Jorge.
From: Thomas 'PointedEars' Lahn on 8 Apr 2010 16:12 Thomas 'PointedEars' Lahn wrote: > Jeremy J Starcher wrote: >> 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. 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 -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Jorge on 8 Apr 2010 16:33
On Apr 8, 10:12 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > > 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 ? -- Jorge. |