Velocity Reviews - David Mark's Javascript Tip of the Day - Volume #1

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)

- Javascript (http://www.velocityreviews.com/forums/f68-javascript.html)

- - David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C (http://www.velocityreviews.com/forums/t943553-david-marks-javascript-tip-of-the-day-volume-1-tip-14-c.html)

David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C

In an (X)HTML DOM, don't read/manipulate DOM attributes (e.g.
"class"). Use the corresponding properties (e.g. "className"). It's
more intuitive, with less code, less calls and no legacy IE nonsense
(e.g. broken get/setAttribute, no hasAttribute, etc.) to worry about.
This has been the rule forever.

In all the time I've worked with DOM elements, there is only one
exception that comes to mind. Something like this, IIRC:-

var elButton = document.createElement('button');
//elButton.type = 'button';
elButton.setAttribute('type', 'button');

....was required in Webkit-based browsers at the time. From a quick
console session, it appears this is still the case as the "type" set
on the BUTTON fails silently, so the default of "submit" remains. Not
sure if this is a bug or if there is an allowance for such behavior in
the recommendation for BUTTON elements. Doesn't seem reasonable to
make the "type" property of a button write-once unless the caller is
afforded a chance to write it once.

I normally use INPUT of type "button", which has no such ambiguity, so
don't really care one way or the other. Whether due to a browser bug
or recommendation shortcoming; it's the one time I can think of where
I had to resort to using setAttribute in an HTML DOM operation.
Operative word is "one". :)

Buttons created with innerHTML will not have this problem as the
parser will take care of setting the "type" property to "button".

Anyway, in an XML DOM (e.g. XHR result), there are only attributes, so
you must use the attribute-related methods.

So there is really nothing to worry about, is there? :)

It's unfortunate that most of the "major" JS libraries feature an
"attr" method that attempts to deal with *both* HTML and XML (though
not normally XHTML). Even worse, they seem to have been written with
little understanding of the above concepts, IE bugs and shortcomings,
etc., ending up as gobbledygook after years of guesswork and patching.

The documentation for the recently added "prop" function demonstrates
just how confused that effort is.

http://api.jquery.com/prop/

First off, it says it returns a string. :(

Then there's this:-

"Concerning boolean attributes, consider a DOM element defined by the
HTML markup <input type="checkbox" checked="checked" />, and assume it
is in a JavaScript variable named elem:"

The DOM element defined by the "HTML markup" is "in a JavaScript
variable". Never mind the awkward wording and XHTML; it's clear what
they are trying to say. But would it be clear to a beginner trying to
forget the "troubles" of basic DOM scripting?

And this is their result matrix:-

elem.checked true (Boolean) Will change with
checkbox state
$(elem).prop("checked") true (Boolean) Will change with
checkbox state
elem.getAttribute("checked") "checked" (String) Initial state of the
checkbox; does not change
$(elem).attr("checked")(1.6) "checked" (String) Initial state
of the checkbox; does not change
$(elem).attr("checked")(1.6.1+) "checked" (String) Will change with
checkbox state
$(elem).attr("checked")(pre-1.6) true (Boolean) Changed with checkbox
state

Third one down is not going to yield anything close to consistent
results in their "core browsers". Does change too, just not by the
user.

After that, the wheels fall off. No mention of 1.6.2, either.

http://pengbos.com/blog/a-bug-in-jqu...-releasev1-6-2

There's no mention of how XML DOM's are handled. Certainly "prop" does
nothing with those, yet it is often pitched as a "better" replacement
for "attr". The "attr" method requires *attribute* names (as it
sometimes uses attribute-related methods). The "prop" method requires
property names. Studying such "documentation" and following such
recommendations will only lead to worse confusion.

http://sunnyarpit.wordpress.com/2011...vs-removeattr/

What could be the effect of all this waffling on plug-ins, widgets and
such? The effect on the libraries is to cause them to scrap their
previous efforts and start anew. jQuery has indicated they are going
down that path too. Of course, there's nothing good down that path;
will divide the project in two, sapping any momentum it had left. :(

http://www.cinsoft.net/
http://www.twitter.com/cinsoft/
http://jsperf.com/browse/david-mark