«

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

On Tue, 08 Nov 2011 04:17:19 -0800, David Mark wrote:

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

I tried dropping gentle hints. Obviously there's some high density
material in your skull.

We have a faq server, we have Thomas 'pointed ears' Lahn, we don't need a
(nother) self appointed wannabe guru trying to build a rep by spouting
twaddle that we're not interested in reading on a daily basis.

Rgds

Denis McMahon

On 11/08/2011 01:17 PM, David Mark wrote:
> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
> [snip]

The indexing of this new "service" is confusing. Could you please
explain it?

So far we have had:

Volume 1 - Tip 1 ---------David Mark 5th Nov.2011
Volume 1 - Tip 3A --------David Mark 7th Nov.2011
Volume #1 - #Tip 14-C ----David Mark 8th Nov.2011

On Nov 8, 1:17*pm, SteveYoungTbird <stephen.yo...@chello.at> wrote:
> On 11/08/2011 01:17 PM, David Mark wrote:
>
> > David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
> > [snip]
>
> The indexing of this new "service" is confusing. Could you please
> explain it?
>
> So far we have had:
>
> Volume 1 - Tip 1 ---------David Mark 5th Nov.2011
> Volume 1 - Tip 3A --------David Mark 7th Nov.2011
> Volume #1 - #Tip 14-C ----David Mark 8th Nov.2011

It's designed to confuse morons.

On Nov 8, 12:41*pm, Denis McMahon <denismfmcma...@gmail.com> wrote:
> On Tue, 08 Nov 2011 04:17:19 -0800, David Mark wrote:
> > David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
>
> I tried dropping gentle hints. Obviously there's some high density
> material in your skull.
>
> We have a faq server, we have Thomas 'pointed ears' Lahn, we don't need a
> (nother) self appointed wannabe guru trying to build a rep by spouting
> twaddle that we're not interested in reading on a daily basis.
>

Who the hell is "we"? I own this dump.

Denis McMahon wrote:

> On Tue, 08 Nov 2011 04:17:19 -0800, David Mark wrote:
>> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
>
> […]
> We have a faq server,

It is spelled _FAQ_, and the server is frequently down, unfortunately.
Also, I do not think that the FAQ covers this subject.

I value David's pointing out that the Webkit bug with dynamically created
`button' elements can be worked around with setAttribute(), as I had
problems with that when creating widgets (for a quick solution I had opted
to use `input[type="button"]' elements instead of `button' elements, but the
latter are more flexible).

Also, it is important to realize that the value of an attribute as retrieved
with getAttribute() can be misleading. For a practical example, there is
(was?) a jQuery UI component which attempted to provide a fallback for
HTML5's type="date". But it used jQuery's attr() method for detection.
Since the attr() method always uses the getAttribute() method in Gecko-based
browsers, the plugin was unable to detect that Firefox did not support the
attribute's `date' value (the attribute property yielded "text" which would
have shown that), and that applying the fallback was indicated. As a
result, the corresponding `input' element stopped working in Firefox (text-
based date input impossible, as all keyboard events had been canceled by the
plugin) until that jQuery plugin had been eliminated from the project's code
base.

> we have Thomas 'pointed ears' Lahn,

_PointedEars_, please.
--
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$>

On 11/8/2011 4:17 AM, David Mark wrote:
> sapping any momentum [jQuery] had left.
>

lol

On Nov 8, 10:17 pm, David Mark <dmark.cins...@gmail.com> wrote:
> 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.

Yes, but if you want to use non-standard attributes, get/setAttribute
is the only way to go.

I don't think non-standard attributes should be used, but as soon as
the design heads down that route, get/setAttribute looms large.

Also, there seem to be many programmers from other languages who like
using a function call like get/setAttribute rather than direct
property access. It seems to give them comfort and is a difficult
habit to shake.

[...]
>
> 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/

Unfortunately the authors of various W3C specifications haven't made
life any easier with their muddled handling of the issue. HTML5 only
makes it worse, particularly as it introduces a heap of new
attributes. Anyone using them will prefer get/setAttribute to property
access to deal with older browsers where:

element.getAttribute('data-foo');

"works" but

element.data-foo;

does not.


--
Rob

On 11/8/2011 6:41 PM, Denis McMahon wrote:
> On Tue, 08 Nov 2011 04:17:19 -0800, David Mark wrote:
>
>> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
>
> I tried dropping gentle hints. Obviously there's some high density
> material in your skull.
>
> We have a faq server, we have Thomas 'pointed ears' Lahn, we don't need a
> (nother) self appointed wannabe guru trying to build a rep by spouting
> twaddle that we're not interested in reading on a daily basis.
>
> Rgds
>
> Denis McMahon

Denis, I, for one, like to read David's contributions.
He is an experienced Javascript/DOM programmer, hence I learn a lot (and
get warned for shitty practices) simply reading his posts.
I am glad David decided to participate more actively in this newsgroup
again.

And Thomas Lahn? When he has a good day, and takes the time to explain
something in detail, his post are very worth your while.
(Or at least my while.)

You are of course entitled to your own opinion, but don't say "we",
since that clearly doesn't include all lurkers/posters in here.

And one last thing: Why would you object to anybody writing a
daily/weekly/whatever opinion in here?
It keeps usenet alive.
I applaud the initiative.

Regards,
Erwin Moller


--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

Denis McMahon wrote:
> David Mark wrote:
>> David Mark's Javascript Tip of the Day - Volume #1 - #Tip 14-C
> We have a faq server, we have Thomas 'pointed ears' Lahn, we don't need a
> (nother) self appointed wannabe guru trying to build a rep by spouting
> twaddle that we're not interested in reading on a daily basis.

I know you've been around long enough to recognize that David Mark is
not new here. His posts are often repetitive, self-aggrandizing, and
bullying, but there is also a lot of useful content in them. His
manner is among the most obnoxious I've seen on USENET, and I've given
up on responding to him (a fact he celebrated [1].) But I'm not sorry
to have him participate here. When he does respond to requests for
help (as opposed to his more common messages promoting his library or
denigrating all others), he often does so with some skill and with
genuinely helpful responses.

If you're interested in discussions where his usual bluster is not
welcomed, try JSMentors. The discussion there is much more civilized,
generally helpful, and often more interesting than what's here. Some
of the more interesting and helpful participants from
comp.lang.javascript also participate there. But I find there is
still much to learn here and many fascinating dialogs, if you can
stomach the nonsense.

-- Scott

[1] http://groups.google.com/group/comp....0d6233dd2c8bf6