New jQuery announced!

71 views
Skip to first unread message

David Mark

unread,
Dec 7, 2009, 11:59:15 AM12/7/09
to
But it has the same old attr method. :(

attr: function( elem, name, value ) {

// don't set attributes on text and comment nodes

Don't pass them! Put that in the docs. :)


if (!elem || elem.nodeType == 3 || elem.nodeType == 8) {
return undefined;
}

Don't pass null, 0, '', undefined, etc. for elem either. What would
be the point of this, other than to make it harder to find bugs?


if ( name in jQuery.fn && name !== "attr" ) {
return jQuery(elem)[name](value);
}


It's the do-everything function. ;)


var notxml = elem.nodeType !== 1 || !jQuery.isXMLDoc( elem ),
// Whether we are setting (or getting)
set = value !== undefined;


They still seem to think this method is appropriate for XML. Why not
call get/setAttribute on XML nodes? That's all this ends up doing.


// Try to normalize/fix the name
name = notxml && jQuery.props[ name ] || name;


Normalize/fix? And jQuery.props is still a long way from complete:-

jQuery.props = {
"for": "htmlFor",
"class": "className",
readonly: "readOnly",
maxlength: "maxLength",
cellspacing: "cellSpacing",
rowspan: "rowSpan",
colspan: "colSpan",
tabindex: "tabIndex",
usemap: "useMap",
frameborder: "frameBorder"
};

How many years does it take for a million code monkeys to come up with
the list of attributes that have camel-case property names? More than
three apparently.


// Only do all the following if this is a node (faster for style)


What?!

if ( elem.nodeType === 1 ) {

// These attributes require special treatment
var special = /href|src|style/.test( name );


What sort of "special" treatment? How are href, src and style
related?


// Safari mis-reports the default selected property of a hidden
option
// Accessing the parent's selectedIndex property fixes it
if ( name == "selected" && elem.parentNode ) {
elem.parentNode.selectedIndex;
}

Mystical incantation.

// If applicable, access the attribute via the DOM 0 way

Read its property?

if ( name in elem && notxml && !special ) {

So, if it is - in - the elem, elem is not an XML node and it is not
href, src or style, get or set the property.


if ( set ) {
// We can't allow the type property to be changed (since it
causes problems in IE)
if ( name == "type" && /(button|input)/i.test(elem.nodeName) &&
elem.parentNode ) {
throw "type property can't be changed";
}

Misguided waste of space.

elem[ name ] = value;
}

// browsers index elements by id/name on forms, give priority to
attributes.
if( jQuery.nodeName( elem, "form" ) && elem.getAttributeNode
(name) ) {
return elem.getAttributeNode( name ).nodeValue;
}
// elem.tabIndex doesn't always return the correct value when it
hasn't been explicitly set
// http://fluidproject.org/blog/2008/01/09/getting-setting-and-removing-tabindex-values-with-javascript/


That article is very confused. :)


if ( name == "tabIndex" ) {
var attributeNode = elem.getAttributeNode( "tabIndex" );
return attributeNode && attributeNode.specified
? attributeNode.value

That's a string. :(


: /(button|input|object|select|textarea)/i.test(elem.nodeName)
? 0

That's a number.


: /^(a|area)$/i.test(elem.nodeName) && elem.href
? 0
: undefined;
}


So, tabindex is treated very oddly, returning a string, number or
undefined. This attribute is singled out because that article singled
it out. This is programming by observation of misinterpreted
observations. :(


return elem[ name ];
}

Then it switches gears to attributes.

if ( !jQuery.support.style && notxml && name == "style" ) {
if ( set ) {
elem.style.cssText = "" + value;

What sort of value would this be that it would make sense to convert
it to a string?


}
return elem.style.cssText;
}

if ( set ) {
// convert the value to a string (all browsers do this but IE) see
#1070


LOL. I'll pass on #1070. They seem to think all IE's are the same.
Of course, IE8 varies wildly here depending on the mode.


elem.setAttribute( name, "" + value );


But they already "fixed" the name (converted to a property name):-

// Try to normalize/fix the name
name = notxml && jQuery.props[ name ] || name;

This doesn't make any sense. By coincidence, the - in - check above
keeps some properties out of here. One that would fall through (in
some browsers, e.g. FF) is "onclick". Passing a function like this:-

attr(el, 'onclick', function() { ... });

Would set an odd attribute indeed, considering what
Function.prototype.toString does. Of course, if the property existed
previously, the previous fork would apply and the method would seem to
work. :)

}
var attr = !jQuery.support.hrefNormalized && notxml && special
// Some attributes require a special call on IE

More than they know. ;)


? elem.getAttribute( name, 2 )
: elem.getAttribute( name );

This will vary across IE versions and modes.

http://www.cinsoft.net/attributes.html


// Non-existent attributes return null, we normalize to undefined


They don't in IE (except IE8 standards mode).

return attr === null ? undefined : attr;
}

// elem is actually elem.style ... set the style
// Using attr for specific style information is now deprecated. Use
style insead.
return jQuery.style(elem, name, value);
}

I thought they were going to re-factor this for 2010? I thought they
would install at least some versions of IE for testing as well. Maybe
next year. :(

So they still have trouble reading documents. Odd handicap for a DOM
library. And how many times have they been told about these
problems? They did like the event detection bit. I don't care for
the copy and paste implementation though.

// Technique from Juriy Zaytsev

I guess they didn't read the article. :(

// http://thinkweb2.com/projects/prototype/detecting-event-support-without-browser-sniffing/
var eventSupported = function( eventName ) {
var el = document.createElement("div");
eventName = "on" + eventName;

var isSupported = (eventName in el);

Spotty inference. Keeps IE out of the following:-

if ( !isSupported ) {
el.setAttribute(eventName, "return;");
isSupported = typeof el[eventName] === "function";

Won't work in IE6/7 or 8 in compatibility mode. But by coincidence,
those never get here. Standard IE8 should get here, but relies on the
weaker inference above.

}
el = null;

return isSupported;
};

David Mark

unread,
Dec 7, 2009, 4:59:38 PM12/7/09
to
On Dec 7, 11:59 am, David Mark <dmark.cins...@gmail.com> wrote:
> But it has the same old attr method.  :(

And a new removeAttr "companion" method!

removeAttr = function(el, name ) {
attr( el, name, "" );
if (el.nodeType == 1) {
el.removeAttribute( name );
}
};

Keeping with the confusion about attributes/properties, this also
tries to do both (poorly). Basically, this sets a property or an
attribute to "" (creating one if it does not exist). Then it tries to
remove the attribute.

The first line attempts to set a property in IE. So this, for
example, will throw a wonderful exception in IE < 8 or IE8 in
compatibility mode:-

removeAttr(el, 'colspan'); // Boom

I added a jQuery set to the attribute tests and found that, in
addition to all manner of inconsistencies and errors in IE, FF throws
an exception on using attr to set DOM0 event handler properties (due
to the aforementioned Function to string conversion). They've really
got the DOM bumps smoothed over now. ;)

After three years of testing and discussion, how can these bugs exist
so deep in the core? The only answer is that the authors and
community have failed to live up to their press clippings. The
revered unit tests are obviously flawed to the point of being useless
(not surprising as they were written by the same people who wrote the
code). Same for the docs. You just can't test or document what you
don't understand. But when things go wrong, you can always blame the
browsers, users, etc. Those heroic Ninjas are doing the best they
can. ;)

Matt Kruse

unread,
Dec 7, 2009, 5:33:43 PM12/7/09
to
On Dec 7, 3:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
> removeAttr(el, 'colspan'); // Boom

Why would you do this, other than to break things?

> I added a jQuery set to the attribute tests and found that, in
> addition to all manner of inconsistencies and errors in IE, FF throws
> an exception on using attr to set DOM0 event handler properties (due
> to the aforementioned Function to string conversion).

Why would you do this, other than to break things?

Obviously the code is still not perfect, but as long as you use it for
its intended purposes, does it cause problems?

I don't think a lib should be bullet-proof against users trying to do
things that they aren't supposed to do.

Matt Kruse

Hans-Georg Michna

unread,
Dec 7, 2009, 6:03:43 PM12/7/09
to
On Mon, 7 Dec 2009 14:33:43 -0800 (PST), Matt Kruse wrote:

>On Dec 7, 3:59�pm, David Mark <dmark.cins...@gmail.com> wrote:

>> removeAttr(el, 'colspan'); // Boom

>Why would you do this, other than to break things?

Because some user wants to replace a colspanned table cell with
two not colspanned ones? That's not far-fetched at all.

I'd say, send John Resig some qUnit tests. (:-)

Hans-Georg

Michael Haufe ("TNO")

unread,
Dec 7, 2009, 6:04:31 PM12/7/09
to
On Dec 7, 4:33 pm, Matt Kruse <m...@thekrusefamily.com> wrote:

> Why would you do this, other than to break things?

Quality code is measured not only by common usages, but by how it
handles edge cases as well. I for one welcome these types of reviews,
not having time to do them myself.

> Obviously the code is still not perfect, but as long as you use it for
> its intended purposes, does it cause problems?

If a method claims to remove an attribute, you would assume it could
remove an attribute regardless of what it is.

> I don't think a lib should be bullet-proof against users trying to do
> things that they aren't supposed to do.

If you're a developer trying to maintain someone else's code, and you
see that they are using library X, it would be nice to know that you
can look at a method library and assume it does what it's advertised
to do.

Michael Haufe ("TNO")

unread,
Dec 7, 2009, 6:07:48 PM12/7/09
to
On Dec 7, 5:04 pm, "Michael Haufe (\"TNO\")"
<t...@thenewobjective.com> wrote:

> If you're a developer trying to maintain someone else's code, and you
> see that they are using library X, it would be nice to know that you
> can look at a method library and assume it does what it's advertised
> to do.

correction: "method library" -> "method of that library"

David Mark

unread,
Dec 7, 2009, 6:20:00 PM12/7/09
to
On Dec 7, 5:33 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 7, 3:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > removeAttr(el, 'colspan'); // Boom
>
> Why would you do this, other than to break things?

Why would I do what? Remove an attribute? To get back to the default
colspan, I expect. Why does the method exist at all?

And you do understand that this is but one example.

>
> > I added a jQuery set to the attribute tests and found that, in
> > addition to all manner of inconsistencies and errors in IE, FF throws
> > an exception on using attr to set DOM0 event handler properties (due
> > to the aforementioned Function to string conversion).
>
> Why would you do this, other than to break things?

See above.

>
> Obviously the code is still not perfect, but as long as you use it for
> its intended purposes, does it cause problems?

First you would have to define its intended purposes. The logic of
jQuery's attr/removeAttr "pair" demonstrates a stunning lack of
comprehension about basic DOM operations? The unfounded assumptions
that stick out are:

1. Attributes and properties are the same thing
2. All versions and of IE treat attributes and properties the same

As for #1, the domain and range for an attribute-based function is
quite different from that of a property-based function. If you look
at what jQuery does in attr, it clearly shows a botched design that
has been fiddled with just enough to make their limited unit tests
work. There's no rational logic present, so clearly the authors have
no idea what they are doing with attributes or properties. (!)

As for #2, pressing the compatility mode button in IE8 changes the
behavior of these functions. As these functions (attr at least) are
used in every jQuery example and book ever written, it seems ludicrous
that they should fail even in an IE8-only environment (unless you
somehow locked out compatibility mode as an option).

And the mere demonstration (even if these functions weren't used
pervasively) of such monumental incompetence and apathy (as you know,
they've been told about this problem numerous times) should be enough
to convince you that the effort is worthless. If a DOM library makes
it _harder_ to read/write/remove attributes and/or read/write
properties (note the difference), what purpose is it serving?
Browsers don't have any trouble doing the latter and you rarely need
to do the former.

It also displays that the unit testing is worthless. How can it pass
such obviously broken logic (and why would you need them to tell you
it is wrong?) When you write software as a series of haphazard
observations, you end up with a haphazard collection of unit tests,
each confirming a sighting. It's the bugs (or implementation
variations) they don't see (and therefore don't test for) that cause
the problems.

>
> I don't think a lib should be bullet-proof against users trying to do
> things that they aren't supposed to do.

What the hell does that mean? What is it you think these functions
are supposed to do? Is there some white list of attributes/properties
that are allowed by jQuery? And I can't believe I'm asking you any of
this. Are you some other Matt Kruse or are seriously starting this
ridiculous discussion again?

jQuery does _not_ simplify DOM scripting. The authors do _not_
understand DOM scripting or the Javascript language and especially not
IE. The CSS selector stuff is ludicrous and incompatible with QSA.
Almost every browser "supported" by jQuery _has_ QSA now anyway. The
animations are third-rate, everything it does is incredibly slow,
inefficient and resource intensive. It leaks memory, throws
exceptions, sets expandos and many other bad practices (and yes it
still uses forms of browser sniffing too). And the much-cited
documentation is horrible (look up attr and removeAttr for examples).
You couldn't pick a worse script and you know it (and the whole idea
of picking one script for every context is the ludicrous anyway).

I think that about says it. Feel free to silently skulk off.

David Mark

unread,
Dec 7, 2009, 6:48:27 PM12/7/09
to
On Dec 7, 6:04 pm, "Michael Haufe (\"TNO\")"

<t...@thenewobjective.com> wrote:
> On Dec 7, 4:33 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > Why would you do this, other than to break things?
>
> Quality code is measured not only by common usages, but by how it
> handles edge cases as well. I for one welcome these types of reviews,
> not having time to do them myself.

Seems most who don't are using or advocating the library in question.

>
> > Obviously the code is still not perfect, but as long as you use it for
> > its intended purposes, does it cause problems?
>
> If a method claims to remove an attribute, you would assume it could
> remove an attribute regardless of what it is.

Yes and it seems reasonable to assume it will not throw an
exception. :)

>
> > I don't think a lib should be bullet-proof against users trying to do
> > things that they aren't supposed to do.
>
> If you're a developer trying to maintain someone else's code, and you
> see that they are using library X, it would be nice to know that you
> can look at a method library and assume it does what it's advertised
> to do.

Yes, that's the main selling point for these libraries. That and the
great support. Unfortunately, as is the case here, the support from
the community often turns into chiding (you are using it wrong),
defensiveness (it's just an edge case) and ultimately petulance. No
wonder seemingly every "Dear jQuery" message in the forums starts out
with "I really love jQuery, but..," or "Don't get me wrong, it's
great, but..."

It's not enough you have to put up with bugs and constant revisions,
but you must be positively obsequious to deluded neophytes just to get
them to field questions. Then their answers are invariably and
predictably of the shit variety. Seems a very rough way to go, mostly
taken by those without an alternative.

RobG

unread,
Dec 7, 2009, 8:10:43 PM12/7/09
to
On Dec 8, 8:33 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 7, 3:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > removeAttr(el, 'colspan'); // Boom
>
> Why would you do this, other than to break things?

To test the code?

Given the vaguaries of browsers, I would expect a unit test for
library methods that add and remove HTML attributes and properties
would test every standard attribute and property in as many browsers
as is reasonable - adding, modifying and deleting, including cases
where attributes are set or omitted in the source HTML.

[...]


> Obviously the code is still not perfect, but as long as you use it for
> its intended purposes, does it cause problems?

If there are shortcomings, they should be documented. Paricularly if
there are methods to modify attributes and properties that will fail
with particular values that should be expected to work.


> I don't think a lib should be bullet-proof against users trying to do
> things that they aren't supposed to do.

You can only say users "aren't suppposed to do" something if either it
is *very* well known that something causes an issue or there's
documentation to say "don't to it".

Is there any jQuery documentation listing the standard HTML attributes
that won't be correctly handled by removeAttr?


--
Rob

rf

unread,
Dec 7, 2009, 8:16:15 PM12/7/09
to
RobG wrote:
> On Dec 8, 8:33 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>> On Dec 7, 3:59 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>>> removeAttr(el, 'colspan'); // Boom
>>
>> Why would you do this, other than to break things?
>
> To test the code?
>
>
> Is there any jQuery documentation listing the standard HTML attributes
> that won't be correctly handled by removeAttr?

Perhaps the function should be called
removeSomeAttrsButPotLuckWhichOnes.


David Mark

unread,
Dec 8, 2009, 9:59:05 AM12/8/09
to

The _very_ funny thing is that (as mentioned) it's a two line
function. Let us see if we can pin its failings on the hapless
users. :)

removeAttr = function(el, name ) {
attr( el, name, "" );
if (el.nodeType == 1) {
el.removeAttribute( name );
}
};

Hmmm. First line looks out of place. You'd think it would be in the
conditional clause (or not there at all as it is doing the opposite of
removing an attribute).

Question #1: What other type of node makes sense here?

The second line is obviously the right host method call.

Question #2: What could have gone wrong with this call to make them
add the first line?

Question #3: Why would a function designed to remove attributes add
one (or set a property to '' in some cases) as its first order of
business?

That's more questions than there are lines of code, so I think it
makes sense to simplify the equation at this point:-

removeAttr = function(el, name ) {

if (el.nodeType == 1) {
el.removeAttribute( name );
}
};

Don't really need that nodeType test (should be documented). But more
importantly, the host method call will fail for _some_ attributes in
IE < 8 and IE8 compatibility mode. Anybody who has scripted an MSHTML
DOM (or read this group) knows exactly why. Broken MSHTML
implementations want a property name here (in most cases). It's been
like that since the 90's and was only recently fixed in IE8 (standards
mode).

Now imagine you have no idea of the cause. There are two ways to go:
research (e.g. try MSDN) or haphazard observations. Clearly the
latter was chosen, leading to a mystical incantation rather than a
solution. Should have been clear to the authors that their
incantation is not only illogical, but it doesn't work at all. Surely
the unit tests would catch this, but then the unit tests were written
by the same confused people.

So these examples (among others) will not work:-

removeAttr(el, 'colspan'); // Boom

removeAttr(el, 'rowspan'); // Boom
removeAttr(el, 'longdesc'); // Silent failure

Imagine one of the Ninjas testing that last one, which has a
corresponding string property. They can't figure out why the
attribute won't go away. It might seem a reasonable "workaround" to
them to set the corresponding property to '' as they clearly don't
understand the difference between attributes and properties. Perhaps
they dismissed the other two as "edge cases". :)

So three years into building this "wonderful" DOM scripting library,
jQuery still can't read (or write) documents. And it's not as if they
haven't been schooled. ;)

That covers #2 and #3, as for the first:-

The attr method tangles up properties, attributes _and_ style.

removeAttr(el.style, 'color'); // el.style.color = '';

That's just silly, but there it is. Great API. Concise and simple
and "just works" as long as you avoid attributes/properties that throw
errors or fail silently.

It's obvious why most Web developers see basic DOM scripting as
impossible. Never mind cross-browser scripting, this crap won't even
be consistent in an IE-only environment. Something that seems to work
in IE7 may well fail in IE8 (and vice versa). If developers only know
jQuery, the only recourse is to post to their mailing list. A typical
synopsis would be "My app used to work in IE and now it doesn't.
PLEASE HELP!!" As even well thought out messages on this subject have
been ignored or mistakenly dismissed over the years, the chance of
getting any satisfaction from the Ninjas seems nil.

So I can't see the selling points. Perhaps those completely
unfamiliar with browser scripting might be able to copy and paste an
example from a book and modify it a bit. I suppose that gullible site
owners might look at such things in IE and FF and think they are
really cool, but the honeymoon won't last. ;)

Matt Kruse

unread,
Dec 8, 2009, 4:07:56 PM12/8/09
to
On Dec 7, 5:48 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 7, 6:04 pm, "Michael Haufe (\"TNO\")"
> > On Dec 7, 4:33 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> > > Why would you do this, other than to break things?
> > Quality code is measured not only by common usages, but by how it
> > handles edge cases as well.

Agreed. I make exceptions for client-side js, because the size and
speed of code is important. It is better to make it clear in the API
docs what should and shouldn't be passed into functions rather than
doing lots of type-checking of arguments, etc. That stuff can be left
in a "debug" version, however.

As David says early in his criticism:

> // don't set attributes on text and comment nodes
> Don't pass them! Put that in the docs. :)

...

> > I for one welcome these types of reviews,
> > not having time to do them myself.
> Seems most who don't are using or advocating the library in question.

I definitely welcome these kinds of reviews and criticisms. I only
wish there was less snarkiness, better formatting, and a lot less
bias. I am thankful for David's continued criticism of jQuery et al,
because it lets people know of the short-comings and also points of
things that the developers can work on. These aren't perfect
solutions, but are works in progress. jQuery especially has made
progress and addressed some criticisms like browser sniffing, etc. Yet
some people ignore the progress and instead focus on the stuff that
still needs work.

> > > Obviously the code is still not perfect, but as long as you use it for
> > > its intended purposes, does it cause problems?
> > If a method claims to remove an attribute, you would assume it could
> > remove an attribute regardless of what it is.

That may not be a justified assumption. It can do whatever it wants,
but should be clear and documented. There are exceptions and
unsupported conditions to many methods and algorithms.

If the docs are not clear about the exceptions and situations where
the assumed behavior will not work as you might expect, then the docs
should certainly be corrected if the code is not. For example,
obviously the attr() method is meant to only set string properties.
I'm not sure why anyone would want to pass a function(){} to attr()
when you can use the event methods instead. But as David points out,
if you try to it will fail. This kind of stuff should be clearly
documented. I don't think it's a bug (it's unintended use of the
function) but the decision to NOT work in this way should be
intentional, not just an unintended side-effect of poor coding. Which
may be the case here, I don't know.

Matt Kruse

David Mark

unread,
Dec 8, 2009, 4:50:27 PM12/8/09
to
On Dec 8, 4:07 pm, Matt Kruse <m...@thekrusefamily.com> wrote:

[...]

For example,
> obviously the attr() method is meant to only set string properties.

It is not set up, nor is it designed for string properties. Which of
these will check a box in jQuery?

attr(el, 'checked', true);
attr(el, 'checked', 'true');
attr(el, 'checked', '');
attr(el, 'checked', 'checked');

Bonus, in which browsers?

I've seen all of them in practice and lots of questions about this and
similar issues in the various jQuery support forums, blog posts, etc.

I know the first works for most, except for XML, which jQuery seems to
want to support with this method. See how mixing up attributes and
properties and trying to support both XML and HTML DOM's all in one
magic function has led to an interface with so many wires crossed it's
hard to predict the outcome of even one single menial line of code.
Now imagine an array of components and plug-ins built on top of this
rickety foundation. Of course, you don't have to imagine it. You've
blogged about it. Predictably, it's all a bunch of unpredictable,
ever-shifting rubbish.

Don't ask me what the other three do (or in which browsers). I'd have
to go back and look at the code again. That cannot be a good sign
when I have to read the code to predict what the thing will do to the
DOM. Where does that leave the average code monkey? In the jQuery
mailing list where nobody has a clue what is going on under the hood
of this clunker.

Glad you liked the review (as much as I could be glad about it). Now
stop using this junk. :)

Hans-Georg Michna

unread,
Dec 9, 2009, 10:58:55 AM12/9/09
to
On Mon, 7 Dec 2009 15:20:00 -0800 (PST), David Mark wrote:

>incompatible with QSA.
>Almost every browser "supported" by jQuery _has_ QSA now anyway.

David,

what does QSA stand for?

Hans-Georg

Hans-Georg Michna

unread,
Dec 9, 2009, 11:19:46 AM12/9/09
to
David,

it is really a pity. The fundamental ideas of jQuery,
particularly to use CSS selectors and a functional style of
programming, are sound, as far as I can tell, and they often
allow you to write as a one-liner, what would otherwise be half
a page of JavaScript code.

Why is nobody writing a competing library, maybe a good subset
of jQuery, but without the foul spots? There is an obvious need
for such a critter, otherwise people wouldn't flock to jQuery,
and I wouldn't like to miss it either.

Why isn't anyone sending John Resig a big, fat set of test
cases?

Hans-Georg

Jake Jarvis

unread,
Dec 9, 2009, 11:22:49 AM12/9/09
to

querySelectorAll
http://www.w3.org/TR/selectors-api/#nodeselector

--
Jake Jarvis

Michael Haufe ("TNO")

unread,
Dec 9, 2009, 12:16:32 PM12/9/09
to
On Dec 9, 10:19 am, Hans-Georg Michna <hans-

georgNoEmailPle...@michna.com> wrote:
>
> Why is nobody writing a competing library, maybe a good subset
> of jQuery, but without the foul spots?

No doubt there are, but I think its safe to say they don't have the
same marketing and/or don't care to share.

> There is an obvious need for such a critter, otherwise people wouldn't flock to jQuery,
> and I wouldn't like to miss it either.

Define what you mean when you say "...such a critter"

> Why isn't anyone sending John Resig a big, fat set of test
> cases?

Time better spent elsewhere?

Matt Kruse

unread,
Dec 9, 2009, 12:37:51 PM12/9/09
to
On Dec 8, 3:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > obviously the attr() method is meant to only set string properties.
> It is not set up, nor is it designed for string properties.

Oops, meant to say attributes.

> Which of
> these will check a box in jQuery?
> attr(el, 'checked', true);
> attr(el, 'checked', 'true');
> attr(el, 'checked', '');
> attr(el, 'checked', 'checked');

I don't even know, because I'm not sure why anyone would do that.

> I've seen all of them in practice and lots of questions about this and
> similar issues in the various jQuery support forums, blog posts, etc.

Agreed. It is a side-effect of people trying to "jQuery-ize"
everything in their code. It's ridiculous to use a lib method like attr
() just to check a checkbox.

Although, I have done something like this:

$(':checkbox[name=foo]').run("this.checked==true");

run() is obviously a little eval wrapper that I plugged into jQuery. I
like using jQuery to conveniently grab a set of elements that I want
in order to manipulate them, but I don't really like it's methods that
do the manipulation.

> I know the first works for most, except for XML, which jQuery seems to
> want to support with this method.

I think they try to support XML because of XHTML. It seems terribly
misguided, and I don't know what rationale they have for doing it, if
any.

> Glad you liked the review (as much as I could be glad about it).  Now
> stop using this junk.  :)

I will when there is a suitable replacement that fills a variety of
needs better than jQuery does (despite its problems, if you use jQuery
only for the things it does do well and avoid the problem areas, it's
very convenient). How's the Dojo work coming?

I would really like to see a long, formal analysis of jQuery. Since it
still seems to be the dominant js framework available, I would like to
have a polished, well-written critique of its design decisions and
code quality, pros and cons, so everyone could properly evaluate the
library and decide if and when to use it. If it were written as a
wiki, it would allow multiple contributors to this group to refine the
writing and would probably become a valuable resource for the
thousands of developers on the web who are using the library.
Unfortunately, those who have the knowledge and expertise to write up
such an analysis rarely have the time or interest in doing so. So the
blind following the blind continues...

Matt Kruse

David Mark

unread,
Dec 9, 2009, 12:43:44 PM12/9/09
to
On Dec 9, 11:19 am, Hans-Georg Michna <hans-

georgNoEmailPle...@michna.com> wrote:
> David,
>
> it is really a pity. The fundamental ideas of jQuery,
> particularly to use CSS selectors and a functional style of
> programming, are sound, as far as I can tell, and they often
> allow you to write as a one-liner, what would otherwise be half
> a page of JavaScript code.

I suppose any library of functions can make that claim. ;) I don't
care for querying by CSS selectors though. To do it in older browsers
requires a heart-stopping amount of error-prone code. The typical
jQuery line takes 10,000 function calls to do what a few lines of JS
could do with standard host methods. I think reliability trumps the
number of lines of code every time (and what do lines of code matter
if the end result is minified?)

>
> Why is nobody writing a competing library, maybe a good subset
> of jQuery, but without the foul spots? There is an obvious need
> for such a critter, otherwise people wouldn't flock to jQuery,
> and I wouldn't like to miss it either.

Most professionals who write JS can see the folly in choosing one
monolith in advance for every context, so they don't write such
things. I made an exception a couple of years back (Google "browser
scripting library" and click the first hit). It is a functional API
with an optional jQuery-like (but competently designed) "chainable" OO
interface (or you could write your own that is exactly like jQuery if
that's what you really want). I don't recommend using such interfaces
as they just slow things down, but at least mine is a fairly
"unobtrusive" layer.

I don't really care to market a free library, but if anyone cares to
help with the documentation, evangelizing, etc. they have whatever
limited support I can muster.

>
> Why isn't anyone sending John Resig a big, fat set of test
> cases?
>

What good would that do? He needs to understand why. It was
explained to him years ago (by me). He didn't get it then and
apparently he's still in the dark today. :(

Garrett Smith

unread,
Dec 11, 2009, 2:06:08 AM12/11/09
to
Matt Kruse wrote:
> On Dec 8, 3:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> obviously the attr() method is meant to only set string properties.
>> It is not set up, nor is it designed for string properties.
>
> Oops, meant to say attributes.
>
As in:
| obviously the attr() method is meant to only set string attributes.

jQuery.attr has specific handling for many odd cases. What does attr
have to do with:

| if ( name == "selected" && elem.parentNode )
| elem.parentNode.selectedIndex;

That's a boolean property, not an attribute, right?

Or:
| if ( !jQuery.support.opacity && name == "opacity" ) {
| if ( set ) {
| // IE has trouble with opacity if it does not have layout
| // Force it by setting the zoom level
| elem.zoom = 1;

A method dealing with attributes working to do modify style properties
of objects, then providing workarounds for IE, not checking to see
currentStyle.hasLayout (the object migh have a layout already).

That method is doing way too much.

>> Which of
>> these will check a box in jQuery?
>> attr(el, 'checked', true);
>> attr(el, 'checked', 'true');
>> attr(el, 'checked', '');
>> attr(el, 'checked', 'checked');
>
> I don't even know, because I'm not sure why anyone would do that.
>

Probably to try and check a checkbox. What attr does is not entirely
distinct. It's sometimes attributes, other times properties.

>> I've seen all of them in practice and lots of questions about this and
>> similar issues in the various jQuery support forums, blog posts, etc.
>
> Agreed. It is a side-effect of people trying to "jQuery-ize"
> everything in their code. It's ridiculous to use a lib method like attr
> () just to check a checkbox.
>
> Although, I have done something like this:
>
> $(':checkbox[name=foo]').run("this.checked==true");
>
> run() is obviously a little eval wrapper that I plugged into jQuery.

That sounds dangerous. Calling eval, you know the thisArg and Variable
is from the calling context. Eval works differntly in ES5, but that's on
the horizon as far as implementations are concerned. Passing in
something that is used in the calling context would be modifying variables.

[sni[p]

>
>> Glad you liked the review (as much as I could be glad about it). Now
>> stop using this junk. :)
>
> I will when there is a suitable replacement that fills a variety of
> needs better than jQuery

Such as?

> I would really like to see a long, formal analysis of jQuery. Since it
> still seems to be the dominant js framework available, I would like to
> have a polished, well-written critique of its design decisions and
> code quality, pros and cons, so everyone could properly evaluate the
> library and decide if and when to use it. If it were written as a
> wiki, it would allow multiple contributors to this group to refine the
> writing and would probably become a valuable resource for the
> thousands of developers on the web who are using the library.
> Unfortunately, those who have the knowledge and expertise to write up
> such an analysis rarely have the time or interest in doing so. So the
> blind following the blind continues...
>

If you really want it, then do it. I'll provide feedback on it and
comments to your efforts.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/

Garrett Smith

unread,
Dec 11, 2009, 2:35:10 AM12/11/09
to
Garrett Smith wrote:
> Matt Kruse wrote:
>> On Dec 8, 3:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>> obviously the attr() method is meant to only set string properties.
>>> It is not set up, nor is it designed for string properties.
>>
>> Oops, meant to say attributes.
>>
> As in:
> | obviously the attr() method is meant to only set string attributes.
>
> jQuery.attr has specific handling for many odd cases. What does attr
> have to do with:
>
> | if ( name == "selected" && elem.parentNode )
> | elem.parentNode.selectedIndex;
>

Note that the statement inside the if test is entirely useless, as it is
not assigned to anything.

Stefan Weiss

unread,
Dec 11, 2009, 6:40:25 AM12/11/09
to
On 11/12/09 08:35, Garrett Smith wrote:

> Garrett Smith wrote:
>> jQuery.attr has specific handling for many odd cases. What does attr
>> have to do with:
>>
>> | if ( name == "selected" && elem.parentNode )
>> | elem.parentNode.selectedIndex;
>>
>
> Note that the statement inside the if test is entirely useless, as it is
> not assigned to anything.

The two lines above the quoted part are:

// Safari mis-reports the default selected property of a hidden option
// Accessing the parent's selectedIndex property fixes it

It would appear that this was intended as a bug workaround, and that
reading the selectedIndex property is all that's required. Still, it's a
strange thing to do, and could very well be optimized away by a minifier
tool or by the JS engine itself.


stefan

Matt Kruse

unread,
Dec 11, 2009, 9:03:46 AM12/11/09
to
On Dec 11, 1:06 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:

> Matt Kruse wrote:
> | obviously the attr() method is meant to only set string attributes.
> jQuery.attr has specific handling for many odd cases. What does attr
> have to do with:
> | if ( name == "selected" && elem.parentNode )
> |    elem.parentNode.selectedIndex;
> That's a boolean property, not an attribute, right?

I didn't look at the source closely enough. I thought they got rid of
accessing properties of elements and went purely to get/setAttribute.
I was incorrect. Disappointing.

> >>  Which of
> >> these will check a box in jQuery?
> >> attr(el, 'checked', true);
> >> attr(el, 'checked', 'true');
> >> attr(el, 'checked', '');
> >> attr(el, 'checked', 'checked');
> > I don't even know, because I'm not sure why anyone would do that.
> Probably to try and check a checkbox. What attr does is not entirely
> distinct. It's sometimes attributes, other times properties.

Indeed, which has been David's criticism for a long time. It looks
like Resig still doesn't get it.

> > $(':checkbox[name=foo]').run("this.checked==true");
> > run() is obviously a little eval wrapper that I plugged into jQuery.
> That sounds dangerous.

Not if you know what you are doing. I use it for very simple things,
to avoid lots of anonymous functions.

> >> Glad you liked the review (as much as I could be glad about it).  Now
> >> stop using this junk.  :)
> > I will when there is a suitable replacement that fills a variety of
> > needs better than jQuery
> Such as?

Documented well
Lots of examples
Printed material available for developers to read from
An active support community
Active development and bug fixing
Supported by various editors and environments
etc

If you're just a stand-alone developer choosing the best tool, jQuery
may not be the best pick. If you're trying to organize a team of 10-20
developers, some onshore some offshore, all of differing experience
levels, who all need to touch the js of the webapp, then having a tool
like jQuery is very important. In my experience, I have found that
without such a library the code quality is consistently lower and the
number of problems is way higher. jQuery sure has its problems, and
it's not a perfect solution, but it's way better than the other
alternatives I've found. When I find a better option, I'll switch.

> > Unfortunately, those who have the knowledge and expertise to write up
> > such an analysis rarely have the time or interest in doing so. So the
> > blind following the blind continues...
> If you really want it, then do it. I'll provide feedback on it and
> comments to your efforts.

That would be great, but I have no desire to write it. I know what
problems I have with jQuery, and I code around them. If I were being
paid for it, I would certainly write such an article :)

Matt Kruse


David Mark

unread,
Dec 11, 2009, 9:38:56 AM12/11/09
to
On Dec 9, 12:37 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 8, 3:50 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > obviously the attr() method is meant to only set string properties.
> > It is not set up, nor is it designed for string properties.
>
> Oops, meant to say attributes.
>
> > Which of
> > these will check a box in jQuery?
> > attr(el, 'checked', true);
> > attr(el, 'checked', 'true');
> > attr(el, 'checked', '');
> > attr(el, 'checked', 'checked');
>
> I don't even know, because I'm not sure why anyone would do that.
>
> > I've seen all of them in practice and lots of questions about this and
> > similar issues in the various jQuery support forums, blog posts, etc.
>
> Agreed. It is a side-effect of people trying to "jQuery-ize"
> everything in their code. It's ridiculous to use a lib method like attr
> () just to check a checkbox.
>
> Although, I have done something like this:
>
> $(':checkbox[name=foo]').run("this.checked==true");
>
> run() is obviously a little eval wrapper that I plugged into jQuery.

Dear God.

> I
> like using jQuery to conveniently grab a set of elements that I want
> in order to manipulate them, but I don't really like it's methods that
> do the manipulation.

That is inconvenient. All grabbed up and nothing to do with them.

>
> > I know the first works for most, except for XML, which jQuery seems to
> > want to support with this method.
>
> I think they try to support XML because of XHTML. It seems terribly
> misguided, and I don't know what rationale they have for doing it, if
> any.

That applies to most of the script. :(

>
> > Glad you liked the review (as much as I could be glad about it).  Now
> > stop using this junk.  :)
>
> I will when there is a suitable replacement that fills a variety of
> needs better than jQuery does (despite its problems, if you use jQuery
> only for the things it does do well and avoid the problem areas, it's
> very convenient).

And... how would one know what the problem areas are? Also, how is
it convenient to have to upgrade something that is constantly changed
to (sort of) keep up with just the latest major browsers, usually
breaking backwards compatibility in lots of little ways?

> How's the Dojo work coming?

I rewrote virtually all of it in competent fashion last summer. Of
course...

So, in my limited spare time, I have been working on a new scrapbook
of code (working title is My Library, Too) and accompanying book.
Basically, it's the foundation that jQuery, Dojo, etc. should have
started with in the first place (they can't really go back now). ;)

>
> I would really like to see a long, formal analysis of jQuery.

Haven't you seen enough?

> Since it
> still seems to be the dominant js framework available, I would like to
> have a polished, well-written critique of its design decisions and
> code quality, pros and cons, so everyone could properly evaluate the
> library and decide if and when to use it.

I've done all I can do in that area. Perhaps somebody else should
aggregate and format the information as they see fit.

> If it were written as a
> wiki, it would allow multiple contributors to this group to refine the
> writing and would probably become a valuable resource for the
> thousands of developers on the web who are using the library.

So set it up.

> Unfortunately, those who have the knowledge and expertise to write up
> such an analysis rarely have the time or interest in doing so. So the
> blind following the blind continues...
>

Exactly.

David Mark

unread,
Dec 11, 2009, 9:56:29 AM12/11/09
to

It's a mystical incantation. See the related comment.

And yes, jQuery's attr doesn't know what it wants to be. Some of it
deals with attributes (substituting undefined for null when they are
missing), other bits will cheerfully return DOM defaults/
interpretations and even user input. (!)

I tried to replicate both the realAttr and prop patterns from my
attribute test page and neither was do-able with the jQuery methods.
As it sits, I have almost 100 picky unit tests for each method and
nothing outside of the presented wrappers can come close to passing
them. jQuery can't even pass the gauntlet without blowing up (several
times). (!) I will post the results shortly (new chapter: J is for
Junk).

For something that is focused on querying the document, jQuery is
startlingly illiterate. As for writing (e.g. removing attributes), it
is prone to throwing exceptions, failing silently, stepping on user
input, etc. It's a stretch to think the authors are going to suddenly
"get it" after all of these years of futility. Same goes for the rest
of the open source Frankenscript projects. Those who can rarely
bother constructing ill-advised monoliths as context is what keys
competent browser scripting designs.

You had asked before about why such methods would ever be necessary
and as I'm working on that chapter, I have given it some more
thought. For one, a CSS selector query should ignore DOM defaults,
user input, etc. For two, a more practical concern is form
serialization. We know that determining the value of a SELECT
requires at least a hasAttribute wrapper (in case the selected option
has a value of ''). ISTM that WYSIWYG editors would need a clear and
consistent view of the underlying markup as well.

David Mark

unread,
Dec 11, 2009, 10:03:48 AM12/11/09
to
On Dec 11, 6:40 am, Stefan Weiss <krewech...@gmail.com> wrote:
> On 11/12/09 08:35, Garrett Smith wrote:
>
> > Garrett Smith wrote:
> >> jQuery.attr has specific handling for many odd cases. What does attr
> >> have to do with:
>
> >> | if ( name == "selected" && elem.parentNode )
> >> |    elem.parentNode.selectedIndex;
>
> > Note that the statement inside the if test is entirely useless, as it is
> > not assigned to anything.
>
> The two lines above the quoted part are:
>
>   // Safari mis-reports the default selected property of a hidden option
>   // Accessing the parent's selectedIndex property fixes it

This looks like another confused "bug report" that has been translated
to "logic". It is clear that the "default selected property" is not
what this function is after (defaultSelected corresponds to the
SELECTED _attribute_).

We know they intend for this thing to read properties (mostly), so
talk of defaults is evidence of them losing their way. The mention of
a "hidden option" confirms the confusion as there is no way a user
could select something they can't see.

>
> It would appear that this was intended as a bug workaround, and that
> reading the selectedIndex property is all that's required. Still, it's a
> strange thing to do, and could very well be optimized away by a minifier
> tool or by the JS engine itself.

Definitely not something to rely on.

David Mark

unread,
Dec 11, 2009, 10:31:25 AM12/11/09
to
On Dec 11, 9:03 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 11, 1:06 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > Matt Kruse wrote:
> > | obviously the attr() method is meant to only set string attributes.
> > jQuery.attr has specific handling for many odd cases. What does attr
> > have to do with:
> > | if ( name == "selected" && elem.parentNode )
> > |    elem.parentNode.selectedIndex;
> > That's a boolean property, not an attribute, right?
>
> I didn't look at the source closely enough. I thought they got rid of
> accessing properties of elements and went purely to get/setAttribute.

Quite the contrary, their hybrid is mostly property-centric, with a
few detours into attributes. Take the tabIndex property. Some "smart
egg" observed that DIV's have 0 for a default in some browsers and -1
in others and decided to write a long blog ranting about it rather
than research what those values mean (typical). So Resig (or
whomever) saw the article, copied the code and pasted in a cite. The
end result is that a significant detail is lost due to a silly
misunderstanding. DIV's missing that attribute all return 0 (number),
while others return a string (e.g. "1"). It's wrong but in their mind
it is "consistent". :)

> I was incorrect. Disappointing.

Yes.

>
> > >>  Which of
> > >> these will check a box in jQuery?
> > >> attr(el, 'checked', true);
> > >> attr(el, 'checked', 'true');
> > >> attr(el, 'checked', '');
> > >> attr(el, 'checked', 'checked');
> > > I don't even know, because I'm not sure why anyone would do that.
> > Probably to try and check a checkbox. What attr does is not entirely
> > distinct. It's sometimes attributes, other times properties.
>
> Indeed, which has been David's criticism for a long time. It looks
> like Resig still doesn't get it.

He's not alone. ;)

>
> > > $(':checkbox[name=foo]').run("this.checked==true");
> > > run() is obviously a little eval wrapper that I plugged into jQuery.
> > That sounds dangerous.
>
> Not if you know what you are doing. I use it for very simple things,
> to avoid lots of anonymous functions.

Lots of anonymous functions is often a sign of trouble (i.e. same
functions are created over and over).

var myCheckerFunction = function() {
this.checked = true; // Assume above == is a typo
};

Now you know where to find it. :)

>
> > >> Glad you liked the review (as much as I could be glad about it).  Now
> > >> stop using this junk.  :)
> > > I will when there is a suitable replacement that fills a variety of
> > > needs better than jQuery
> > Such as?
>
> Documented well

Read the docs for the basic functions (e.g. attr, removeAttr). If
they couldn't understand or explain what those do, how can you trust
the rest of it?

> Lots of examples

Virtually every jQuery example out there uses attr, including checking
checkboxes. They might as well not exist as that function has no
defined behavior.

> Printed material available for developers to read from

Print whatever you want.

> An active support community

Um. A support community of two managed to get a basic attribute
wrapper working consistently in virtually every browser overnight.
jQuery's community doesn't understand the basic concepts so they just
tell people they are using the functions wrong (for three years).
Once in a blue moon, somebody will go in and introduce a new wrinkle
(e.g. tabIndex handling), breaking compatibility, further ballooning
the code, etc. How is that seem helpful (unless you don't know any
better).

> Active development and bug fixing

See above. Active development doesn't mean twiddling with the same
code for years just to tread water in the very latest browsers in
their default configurations. Nor does it mean piling new crap on to
existing code that has never worked properly in the first place.
That's called wasting time.

> Supported by various editors and environments
> etc

Intellisense? For one, who cares. For two, anything can hook into
that.

>
> If you're just a stand-alone developer choosing the best tool, jQuery
> may not be the best pick. If you're trying to organize a team of 10-20
> developers, some onshore some offshore, all of differing experience
> levels, who all need to touch the js of the webapp, then having a tool
> like jQuery is very important.

You mean if you are trying to fail?

> In my experience, I have found that
> without such a library the code quality is consistently lower and the
> number of problems is way higher.

Sounds like you need new programmers. What could be lower than
jQuery's code?

> jQuery sure has its problems, and
> it's not a perfect solution, but it's way better than the other
> alternatives I've found. When I find a better option, I'll switch.

Whatever.

>
> > > Unfortunately, those who have the knowledge and expertise to write up
> > > such an analysis rarely have the time or interest in doing so. So the
> > > blind following the blind continues...
> > If you really want it, then do it. I'll provide feedback on it and
> > comments to your efforts.
>
> That would be great, but I have no desire to write it. I know what
> problems I have with jQuery, and I code around them. If I were being
> paid for it, I would certainly write such an article :)

There's the rub.

Matt Kruse

unread,
Dec 11, 2009, 11:13:30 AM12/11/09
to
On Dec 11, 9:31 am, David Mark <dmark.cins...@gmail.com> wrote:
> > In my experience, I have found that
> > without such a library the code quality is consistently lower and the
> > number of problems is way higher.
> Sounds like you need new programmers.  What could be lower than
> jQuery's code?

You must live in a bubble.

I regularly see code that is much, MUCH worse. Less predictable. Less
robust. Less stable.

Telling a team that is writing bad code to "just use jQuery" can
instantly improve performance, reduce bugs, and improve cross-browser
support. Is it perfect? No. But it's better than the status quo. And
it's regularly updated, documented, supported, etc. It takes very
little effort to make a big improvement in code quality. That's why
jQuery is valuable.

Now, if you never have to deal with such a situation, then you're in
luck. No wonder you can't see the value in jQuery.

Think of it this way - When js code quality is at a 1 or 2 on a scale
of 1-10 (10 being best), then introducing jQuery and raising it to a 4
or 5 with virtually no pain is an obvious win. Versus trying to raise
it to an 8 or 9 with considerable coding, time, cost, coaching,
documentation, testing, etc. In a perfect world we could all set our
sights high to ideal coding practices, but in the real world many
people deal with, lowered expectations helps maintain sanity.
Especially when js code quality is less of a concern compared to
other, bigger problems.

Matt Kruse

Michael Haufe ("TNO")

unread,
Dec 11, 2009, 11:27:34 AM12/11/09
to
On Dec 11, 10:13 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> Telling a team that is writing bad code to "just use jQuery" can
> instantly improve performance, reduce bugs, and improve cross-browser
> support. Is it perfect? No. But it's better than the status quo. And
> it's regularly updated, documented, supported, etc. It takes very
> little effort to make a big improvement in code quality. That's why
> jQuery is valuable.

Ever try a code review instead?

Matt Kruse

unread,
Dec 11, 2009, 11:39:56 AM12/11/09
to
On Dec 11, 10:27 am, "Michael Haufe (\"TNO\")"

<t...@thenewobjective.com> wrote:
> Ever try a code review instead?

Me: "This code is bad. Fix it."

Developers: "???"

That was useful.

Matt Kruse

David Mark

unread,
Dec 11, 2009, 11:47:08 AM12/11/09
to
On Dec 11, 11:13 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 11, 9:31 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > In my experience, I have found that
> > > without such a library the code quality is consistently lower and the
> > > number of problems is way higher.
> > Sounds like you need new programmers.  What could be lower than
> > jQuery's code?
>
> You must live in a bubble.

No, I deal with JS and JS developers every day.

>
> I regularly see code that is much, MUCH worse. Less predictable. Less
> robust. Less stable.

Take just he basic attr and removeAttr methods. They can't even run
the basic gamut of attributes without throwing exceptions. Other
cases fail silently. These quirky behaviors vary across browsers
_and_ jQuery versions. So, what could be worse than that? Random
gibberish? Don't use that either?

>
> Telling a team that is writing bad code to "just use jQuery" can
> instantly improve performance, reduce bugs, and improve cross-browser
> support.

No, it might create the illusion that they are all suddenly competent.

> Is it perfect? No. But it's better than the status quo.

It a team is writing bad code, you teach them how to write good code.
That's primarily what I do for a living. ;)

> And
> it's regularly updated, documented, supported, etc.

The regular updates are indicative of 60K of JS that has been in
endless Alpha for years. That's certainly detrimental to anyone
foolish enough to plop a snapshot of their efforts on a Website.
Documented? As I mentioned, you can't document what you don't
understand. And we've been over their "support" too. Same principle
applies. Three strikes.

> It takes very
> little effort to make a big improvement in code quality.

It's like a magic trick! :)

> That's why
> jQuery is valuable.

No, that's why it is poison.

>
> Now, if you never have to deal with such a situation, then you're in
> luck. No wonder you can't see the value in jQuery.

You are jumping to conclusions to say the least.

>
> Think of it this way - When js code quality is at a 1 or 2 on a scale
> of 1-10 (10 being best),

Easy. Get new programmers.

> then introducing jQuery and raising it to a 4
> or 5 with virtually no pain is an obvious win.

Not in my book. Looks like a punt.

> Versus trying to raise
> it to an 8 or 9 with considerable coding, time, cost, coaching,
> documentation, testing, etc.

All bullshit. What considerable coding? What project are we talking
about? These generalizations are just not reality.

> In a perfect world we could all set our
> sights high to ideal coding practices, but in the real world many
> people deal with, lowered expectations helps maintain sanity.

No, they help incompetents keep a toe-hold on their precarious
positions. It's not good for business in any way, shape or form. I
_know_ a lot of code monkeys will tell you (and anyone who will
listen) different.

> Especially when js code quality is less of a concern compared to
> other, bigger problems.

I don't know what that means. The typical Website uses ten times the
script needed. So code quality concerns are magnified ten times.
There is nothing with more power to wreck a site than script
(especially of poor to middling quality), so the obvious best strategy
is to use as little of it as possible. Therefore, your proposed
strategy of starting out with 60K of thoughtless "4 level" code is
counter-productive. If it fools code monkeys into thinking they are
Ninjas, that will lead to further ruin down the road as things break,
libraries are "upgraded" to "fix" them, apps are re-tested (or not)
from scratch, etc. I've seen it a thousand times (and we've discussed
this almost as many).

And exceptions and other land mines are not covered by variations in
"code quality". Code can be of poor quality and still work. Code
that doesn't work isn't really code at all. It's called trash and
there's only one place for it.

Matt Kruse

unread,
Dec 11, 2009, 12:08:39 PM12/11/09
to
On Dec 11, 10:47 am, David Mark <dmark.cins...@gmail.com> wrote:
> > You must live in a bubble.
> No, I deal with JS and JS developers every day.

There's no point in going over this again. You cannot relate to those
who face development situations and business cases different than
yours. There are some really bad projects out there, being completed
by really poor developers, at a quality level that is very low. If you
never see or touch those, good for you. But they still exist.

> Take just he basic attr and removeAttr methods.  They can't even run
> the basic gamut of attributes without throwing exceptions.  Other
> cases fail silently.  These quirky behaviors vary across browsers
> _and_ jQuery versions.  So, what could be worse than that?

Oh, things can be much worse.

> > Is it perfect? No. But it's better than the status quo.
> It a team is writing bad code, you teach them how to write good code.

If only it were that easy.

> > Think of it this way - When js code quality is at a 1 or 2 on a scale
> > of 1-10 (10 being best),
> Easy.  Get new programmers.

Of course! Everyone should just fire the people they have and hire the
best!

> > then introducing jQuery and raising it to a 4
> > or 5 with virtually no pain is an obvious win.
> Not in my book.  Looks like a punt.

It's progress. It's better than it was. Idealism is not always
realistic. Sometimes "just make it work" is a lofty goal.

> > Especially when js code quality is less of a concern compared to
> > other, bigger problems.
> I don't know what that means.

When the js is running in a pseudo-xhtml document containing invalid
markup, elements with multiple duplicated id's, 80k of whitespace
bloat, styles and js embedded directly into the tags, css that is not
cross-browser, table-based layouts, and spacer gif's... well, jQuery
messing up an attr() call condition that will never actually be called
seems like a minor concern.

But seriously... this is the same old discussion of "don't you
understand how bad it can get and why something like jQuery is
actually an improvement?!" and there's really no point to it. I'm fine
with just seeing it differently than you.

Matt Kruse

Garrett Smith

unread,
Dec 11, 2009, 1:42:46 PM12/11/09
to
Matt Kruse wrote:
> On Dec 11, 10:27 am, "Michael Haufe (\"TNO\")"
> <t...@thenewobjective.com> wrote:
>> Ever try a code review instead?
>
> Me: "This code is bad. Fix it."
>
Looks like a straw code review.

Two documents are in order:
1) Code authoring guidelines
2) Code review guidelines

The FAQ covers (1) in a general sense. Number 2 would be very helpful
for a FAQ note/addendum, to be linked from #postCode.

The organization that is making the sorts of messes you described in
another post could benefit from making such document.

Would you like to work on #2?

E.g.
| A code review should focus on problems. Saying "the code is bad" is
| not a helpful review.
|
| Rebuttals
| The reveiwee may challenge a criticism and...

For example, where the markup is invalid, the reviewee will often say:
"literal ampersand doesn't cause problems". Or "but the browser
detection works."

This is where the guidelines doc comes in handy, so you don't have to go
over again the importance of eliminating all validator errors, or what
sorts of harm is caused by browser detection, using the HTML doctype, etc.

The validator results either with green PASS or with one or more errors
at which point it is clear that the reviewee's code is not completed to
standard.

The benefit is that the w3c validation tools can be used to quickly find
errors that cause problems.

Nobody should have to pore over a long list of validation errors for
'&', et al, to find the validation error(s) that could be related to
whatever it is that the invalid code created. In that scenario when an
HTML error is found to cause a problem, the next task finding when the
"error" creeped in, why it is there, what other code is relying on the
problematic area, who wrote that other code, where is he now, so a
possible fix can be discussed, etc. At this point it is obvious how much
of a waste of time using invalid HTML is.

Working with invalid code like can be very time consuming. Running the
w3c validator is a little extra effort that saves a lot of time.

Problems with the code should be clearly explained so that they can be
understood. The solutions to the types of code obscenities you described
in your other post are usually self-evident. Where they aren't, then
further discussion can help find solutions.

S.T.

unread,
Dec 11, 2009, 4:26:08 PM12/11/09
to
On 12/7/2009 8:59 AM, David Mark wrote:
> But it has the same old attr method. :(
>
> attr: function( elem, name, value ) {

>
> // don't set attributes on text and comment nodes
>
>... and on and on and on.

For all these massive bugs, future browser incompatibility issues, code
breaking on every library update and inept coding that you claim litters
jQuery -- I don't seem to see any effects of them. Ever. Nor do my
users. Nor other developers I communicate with.

Weird, isn't it?

Guess I'm just really, really lucky.

Garrett Smith

unread,
Dec 11, 2009, 5:15:18 PM12/11/09
to
A workaround, but to what problem?

<body onload ="alert(document.getElementById('c').selected)">
<select id="x">
<option id="a">a</option>
<option id="b">b</option>
<option id="c" style="visibility: hidden;" selected>c</option>
<option id="d">d</option>
</select>

In Safari, the 'c' is selected, the alert is - true - and when the
select is expanded, the 'c' option is blacked out.

Perhaps someone can demonstrate what the workaround actually fixes.

Anyway, attr is dealing with non-string value property.

Andrew Poulos

unread,
Dec 12, 2009, 4:30:23 AM12/12/09
to

Here's how I've seen it "work":

- A company's director lands a job

- The company's "technical" manager contacts the client and requests a
spec asking them to be sure to set out the target browser.

- The client, not knowing any better specifies, say IE 6 (or whatever
browser the client's company lets them use).

- The company builds the job and tests it only in the target browser

- The company, "happy" with job, sends it to client to verify

- The client tests it with their browser. By "testing" I mean the
client, who has no understanding of software testing procedure, runs
through the job for 15 minutes before they sign it off.

- The company happily adds the client's company's logo to their portfolio.

- Some time later after the client releases the completed job into the
wild and problems begin to be reported the company, with a avuncular
tone, points the client to the part of the client's own spec where they
nominated the target browser.

Yes, many developers are lucky.

Andrew Poulos

David Mark

unread,
Dec 12, 2009, 6:11:38 AM12/12/09
to
On Dec 11, 4:26 pm, "S.T." <a...@anon.com> wrote:
> On 12/7/2009 8:59 AM, David Mark wrote:
>
> > But it has the same old attr method.  :(
>
> > attr: function( elem, name, value ) {
>
> >    // don't set attributes on text and comment nodes
>
> >... and on and on and on.
>
> For all these massive bugs

You deny their existence? Go back a few years and start reading...

> , future browser incompatibility issues,

Well, of course. They have to constantly fiddle with the code to keep
up with the latest browsers. Where does that leave your site(s)? Do
you think the owners want a subscription development service with you
coming back every six months to swap out 60K of crap that you don't
understand. I don't. ;)

> code
> breaking on every library update and inept coding that you claim litters

They always introduce incompatibilities with each release. Some they
know about. Some they don't.

> jQuery -- I don't seem to see any effects of them. Ever.

What can you say to that? Your testing must be for shit. :) It's
very easy to test in a handful of the latest browsers and dismiss
everything that came before as "out of date" and "unsupported".

> Nor do my
> users.

How do you know? Users aren't QA testers. You can't assume that a
lack of bug reports from users means... anything.

> Nor other developers I communicate with.

Other jQuery developers? You are in a cult. How can you figure your
fellow cult members' silence on issues they don't understand at all
trumps the broken logic detailed here? Do you not understand that the
broken logic indicates broken thinking? These are the "experts" you
have entrusted with browsers scripting and they are clearly lost.

>
> Weird, isn't it?

Not really.

>
> Guess I'm just really, really lucky.

Or really, really loopy.

RobG

unread,
Dec 12, 2009, 6:11:38 AM12/12/09
to

Or don't read the jQuery GG forum. A quick scan over the last two days
of posts turned up the following:

Random problems with load()?????
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/cc155eede7fcc562?hl=en
>

Problem with Jquery Superfish in IE7
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/422d435663db6f65?hl=en#
>

IE 7-8 bug on menu loading when mouse is over the menu
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/87d54847af752079?hl=en#
>

load() function and IE8
<URL: http://groups.google.com.au/group/jquery-en/browse_frm/thread/a12e5d47c17e93a3?hl=en#
>


--
Rob.

David Mark

unread,
Dec 12, 2009, 6:20:18 AM12/12/09
to
On Dec 11, 12:08 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 11, 10:47 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > You must live in a bubble.
> > No, I deal with JS and JS developers every day.
>
> There's no point in going over this again. You cannot relate to those
> who face development situations and business cases different than
> yours. There are some really bad projects out there, being completed
> by really poor developers, at a quality level that is very low. If you
> never see or touch those, good for you. But they still exist.
>
> > Take just he basic attr and removeAttr methods.  They can't even run
> > the basic gamut of attributes without throwing exceptions.  Other
> > cases fail silently.  These quirky behaviors vary across browsers
> > _and_ jQuery versions.  So, what could be worse than that?
>
> Oh, things can be much worse.

Sure, you could hire a trained chimp to bang away at the keyboard at
random.

>
> > > Is it perfect? No. But it's better than the status quo.
> > It a team is writing bad code, you teach them how to write good code.
>
> If only it were that easy.

It really is. They typically don't have to write a CSS selector query
engine. You teach them how to do basic DOM scripting and soon they
are laughing at jQuery's foibles.

>
> > > Think of it this way - When js code quality is at a 1 or 2 on a scale
> > > of 1-10 (10 being best),
> > Easy.  Get new programmers.
>
> Of course! Everyone should just fire the people they have and hire the
> best!

Not everyone can afford the best, nor do most projects need them.
There's a big difference between the best and incompetents.

>
> > > then introducing jQuery and raising it to a 4
> > > or 5 with virtually no pain is an obvious win.
> > Not in my book.  Looks like a punt.
>
> It's progress. It's better than it was.

No, it's just trading one set of problems for another. A 4 or 5 is a
failing grade BTW. Why program for failure?

> Idealism is not always
> realistic. Sometimes "just make it work" is a lofty goal.

If something doesn't work, what good is it?

>
> > > Especially when js code quality is less of a concern compared to
> > > other, bigger problems.
> > I don't know what that means.
>
> When the js is running in a pseudo-xhtml document containing invalid
> markup, elements with multiple duplicated id's, 80k of whitespace
> bloat, styles and js embedded directly into the tags, css that is not
> cross-browser, table-based layouts, and spacer gif's...

And you don't care to fire the bums that slapped that together?
That's your problem.

> well, jQuery
> messing up an attr() call condition that will never actually be called
> seems like a minor concern.

You don't have any idea what arguments work with attr (or for which
version(s) of jQuery). And the messed up attr/removeAttr "pair" (just
two of many botched functions in jQuery) is indicative that your
chosen saviors are false prophets. It's been years and they are still
using the same old nonsense code. That's the main point.

>
> But seriously... this is the same old discussion of "don't you
> understand how bad it can get and why something like jQuery is
> actually an improvement?!" and there's really no point to it. I'm fine
> with just seeing it differently than you.
>

That's not the typical spin anyway. Persuse sites like Ajaxian and
you will see that many developers think jQuery is the greatest thing
to ever happen to the Web. :)

David Mark

unread,
Dec 12, 2009, 6:29:23 AM12/12/09
to
On Dec 11, 5:15 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Stefan Weiss wrote:
> > On 11/12/09 08:35, Garrett Smith wrote:
> >> Garrett Smith wrote:
> >>> jQuery.attr has specific handling for many odd cases. What does attr
> >>> have to do with:
>
> >>> | if ( name == "selected" && elem.parentNode )
> >>> |    elem.parentNode.selectedIndex;
>
> >> Note that the statement inside the if test is entirely useless, as it is
> >> not assigned to anything.
>
> > The two lines above the quoted part are:
>
> >   // Safari mis-reports the default selected property of a hidden option
> >   // Accessing the parent's selectedIndex property fixes it
>
> > It would appear that this was intended as a bug workaround, and that
> > reading the selectedIndex property is all that's required. Still, it's a
> > strange thing to do, and could very well be optimized away by a minifier
> > tool or by the JS engine itself.
>
> A workaround, but to what problem?

Something in their head likely.

>
> <body onload ="alert(document.getElementById('c').selected)">
> <select id="x">
> <option id="a">a</option>
> <option id="b">b</option>
> <option id="c" style="visibility: hidden;" selected>c</option>
> <option id="d">d</option>
> </select>
>
> In Safari, the 'c' is selected, the alert is - true - and when the
> select is expanded, the 'c' option is blacked out.
>
> Perhaps someone can demonstrate what the workaround actually fixes.

Unlikely. But they won't take it out because somebody has fuzzy
memories of a "problem" that they can't really explain.

>
> Anyway, attr is dealing with non-string value property.

Certainly, except when it branches off into attributes (e.g. "special
properties" href and src). It makes absolutely no sense and provides
a far less consistent interface than the "buggy" DOM implementations.
The indoctrinated neophytes don't see it because they don't know any
better. One of their luminaries remarked recently that it "uses
properties and always has" and couldn't understand why people are
claiming it is broken. :)

David Mark

unread,
Dec 12, 2009, 12:03:00 PM12/12/09
to
On Dec 11, 12:08 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 11, 10:47 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > You must live in a bubble.
> > No, I deal with JS and JS developers every day.
>
> There's no point in going over this again. You cannot relate to those
> who face development situations and business cases different than
> yours.

Nice try (seriously) in your recent attempt to educate John Resig
about his own attr/removeAttr methods.

He's obviously confused about what those test results mean, so let me
explain.

The first two strictly deal with attributes. You made one mistake in
your explanation to Resig in that manipulating most DOM properties by
script will reflect back to the attributes. It's the DOM defaults and
user input that must be filtered to gain a clear view of the document
structure.

The latter two do the exact same thing, but resolve the "raw"
attributes to their DOM interpretations, still returning null for
missing attributes (except for booleans, of course). For example,
URI's are resolved, booleans return true/false, numeric attributes
return numbers, etc.

All four are attempts to produce a consistent interface for reading
the DOM, filtering out DOM defaults. I recently modified the two
wrappers slightly to filter out user input as well. I'll post as soon
as I finish updating the tests (there are about 100 now). That's the
view you need for a CSS selector query engine, WYSIWYG editor or like
application. As you mentioned, it is _not_ a view that the typical
Web app needs to see.

The biggest unanswered question, which Resig seems unwilling to
address, is what the hell is his attr method supposed to do? Who
knows? Is it a view of the underlying document structure, does it
include DOM defaults, user input, etc.? It clearly does nothing
predictable or consistent in any browser. As an aside, notice that he
only ever tests your suggestions in FF3.5. ;)

He did mention that it is _not_ "designed" to read DOM properties. So
now I am really confused. It's clearly not designed to read
attributes either (except for "special" properties). Are file paths
to be resolved or not? Are DOM defaults to be ignored, embraced or
stepped on? His method does a little of each. What about user
input? I get the idea that he doesn't comprehend the various layers
at all.

And yeah, spot on about the new jQuery method entanglement, which
makes this thing even worse (hard to believe). I forgot they had
methods called "height", "width", etc. So his "solution" to "onclick"
throwing an exception (in FF!) is to use "click" instead as it will
then call the jQuery click method, which does... God knows what. And
somehow he thinks this "improves" his already muddled API. (!)

The guy is clearly not qualified to write even the simplest DOM
scripts. He doesn't understand the basic concepts. The attr and
removeAttr methods and the years of confusion and twiddling that have
followed, leading up to this latest pathetic denial, are all the proof
you should need. But the typical code monkey will load up their app
(which may well have straddled the land mines in the specific version
of jQuery used) in IE8 and FF3.5, note that it appears to work (just
don't disable ActiveX in IE!) and chafe that such "petty" criticism is
unrealistic for such an obviously magical script (turned them into a
programmer!)

I'll post similar tests with the jQuery methods when I get a chance.
I'll have to guess at what they are trying to do, but there are only
so many possibilities. I know they are incapable of providing a
consistent and symmetrical interface for anything though. Initial
testing shows that removeAttr throws exceptions and fails silently for
several attribute names. If the caller switches gears and passes
property names instead, a few of the failures go away. but new ones
take their place.

As for licensing, which I see Resig is interested in, tell him he can
license the whole test suite, wrappers, etc., but it won't be cheap.
Hell, tell the "foundation" to pick up the bill. :) And if he copies
one word or the tiniest aspect of the design, brutal legal action will
follow. I'm tired of seeing my ideas show up in his "cutting edge"
script years later.

David Mark

unread,
Dec 12, 2009, 3:06:07 PM12/12/09
to
On Dec 12, 12:03 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 11, 12:08 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > On Dec 11, 10:47 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > You must live in a bubble.
> > > No, I deal with JS and JS developers every day.
>
> > There's no point in going over this again. You cannot relate to those
> > who face development situations and business cases different than
> > yours.
>
> Nice try (seriously) in your recent attempt to educate John Resig
> about his own attr/removeAttr methods.
>

It's even worse than I thought. I always wondered what the logic in
the "crown jewel" (and only reason for existence) CSS selector query
engine. I remembered that it didn't actually call attr, but it
actually might have been better off doing so.

CLASS: function(elem, match){
return (" " + (elem.className || elem.getAttribute("class")) + "
").indexOf( match ) > -1;


Focus on this bit:-

(elem.className || elem.getAttribute("class"))

If elem.className === '' the first is falsy, so the second is
consulted. There are two possible results for the second: '' and
null. Results will vary according to browser and mode.

- IE6/7 and 8 in compatibility mode always return ''
- IE8 in standards mode will return null if the attribute is missing
or '' if it is empty.
- Previous applies to other quasi-standards based browsers.

So, an element like this:-

<div></div>

...will produce a test like this:-

return (" null ").indexOf( match ) > -1;

...in some browsers and modes.

Of course, if Resig and co. understood how attributes and properties
work, they would know that this:-

(elem.className || elem.getAttribute("class"))

...is much better written as:-

elem.className

It's simpler, more concise, actually works cross-browser, etc. Of
course, the second part may be a perverse attempt to support XML, but
that's as maybe. They really need to figure out HTML first.

},
ATTR: function(elem, match){
var name = match[1],
result = Expr.attrHandle[ name ] ?
Expr.attrHandle[ name ]( elem ) :
elem[ name ] != null ?
elem[ name ] :
elem.getAttribute( name ),
value = result + "",

There it is. The selector engine is broken too and incompatible
with... everything. XPath and QSA are popular alternate approaches
(IIRC, jQuery and/or "Sizzle" uses the latter). Neither of those will
work anything like this.

elem[ name ] != null

That's everything but null or undefined. So property values that are
neither end up converting this to a string:-

elem[ name ]

...which could end up as "true" or "function anonymous() { ... }" or
"[object CSSStyleDeclaration]" or whatever.

On the contrary, properties that are non-existent or have null values
end up converting:-

elem.getAttribute( name )

...which, as (hopefully) everyone knows by now is a crap shoot. Here
the converted "result" will either be "null" or "undefined" or the
value of a custom attribute (which may well be "null" or
"undefined"). I'm sure that won't cause any confusion. ;)

In conclusion, results for attribute-related queries would make decent
seeds for random number generators. I assume the answer can't be
"don't use those" as they've gone to "great" pains to "support" them
over the years. Are they all blind or mad? And how can they demand
examples in the face of such obviously incorrect logic?

Here's more madness:-

enabled: function(elem){
return elem.disabled === false && elem.type !== "hidden";
},

Sure, hidden inputs are always disabled. We needed that smoothed
over. :)

disabled: function(elem){
return elem.disabled === true;
},
checked: function(elem){
return elem.checked === true;
},

Wrong. That includes user input. But they'll never be able to change
it at this point.

selected: function(elem){
// Accessing this property makes selected-by-default
// options in Safari work properly
elem.parentNode.selectedIndex;
return elem.selected === true;
},

LOL. There's _that_ again. Look at what it says: "selected-by-
default". Sure sounds like they are after the defaultSelected
property, which reflects the presence or absence of the SELECTED
attribute. Or maybe they just have no clue what they want at all
(that's my guess at this point).

And I wonder how well that incantation will work if the option is in
an OPTGROUP. Poorly I assume, but then it likely doesn't do anything
anyway.

So how could you possibly trust any script from these people, let
alone something as convoluted and confused as jQuery? It's not even a
stationery target as they keep "optimizing" (changing the logic) and
introducing bizarre "overloading" like using attribute names to call
jQuery methods.

I can understand how code monkeys can look at sites built with jQuery
(in a few browsers) and protest that it "just works" and any perceived
gaps in its internal logic must be imagined. But any programmer knows
such an unpredictable and illogical interface is poison (particularly
for browser scripting). Working on an app with this thing, I would
cringe changing even one attr call or query, let alone "upgrading" the
library.

David Mark

unread,
Dec 12, 2009, 3:46:54 PM12/12/09
to
On Dec 12, 6:11 am, RobG <rg...@iinet.net.au> wrote:
> On Dec 12, 7:26 am, "S.T." <a...@anon.com> wrote:
>
>
>
> > On 12/7/2009 8:59 AM, David Mark wrote:
>
> > > But it has the same old attr method.  :(
>
> > > attr: function( elem, name, value ) {
>
> > >    // don't set attributes on text and comment nodes
>
> > >... and on and on and on.
>
> > For all these massive bugs, future browser incompatibility issues, code
> > breaking on every library update and inept coding that you claim litters
> > jQuery -- I don't seem to see any effects of them. Ever. Nor do my
> > users. Nor other developers I communicate with.
>
> > Weird, isn't it?
>
> > Guess I'm just really, really lucky.
>
> Or don't read the jQuery GG forum. A quick scan over the last two days
> of posts turned up the following:
>
> Random problems with load()?????
> <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/cc155ee...

>
>
>
> Problem with Jquery Superfish in IE7
> <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/422d435...

>
>
>
> IE 7-8 bug on menu loading when mouse is over the menu
> <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/87d5484...
>
>
>
> load() function and IE8
> <URL:http://groups.google.com.au/group/jquery-en/browse_frm/thread/a12e5d4...
>

On a positive note, posts to that list are dwindling. I guess people
are tired of wrong (or no) answers. :)

Quoting from that last one:-

"I fat fingered the last one so...

I have this piece of code

$("#AP_PONum").live("change", function(){
ap_po = $("option:selected",this).val();
$("#content-box").load("webapps/finished_jewelry/PurReq/display/
dsp_addPurchaseRequest.cfm?poNum="+ap_po);

});

which works like a champ in firefox.

it's called from a drop down grabs the ColdFusion template and load it
in a div called content-box.

This does nothing in IE8, no error, no load, no love.. nothing

any ideas on how to work around this?"

They better test in more than IE8 and FF. :)

Look at the three (!) queries in this one line. Two can be replaced
with document.getElementById. The other one is sure to be a disaster
as it uses ":selected".

http://groups.google.com/group/comp.lang.javascript/msg/05416b9fc93b2092

And what is that other one doing? Looking for the selected option of
a SELECT? jQuery makes it so easy... to shoot yourself in the foot,
even when the target is right in front of your face. ;)

Assuming there are no options with empty or missing values:-

var el = document.getElementById('AP_PONum');

el.onchange = function() {
ap_po = this.options[this.selectedIndex].value;
...
};

In modern browsers, you can even get away with:-

el.onchange = function() {
ap_po = this.value;
...
};

Something like that is much faster, easier to read and understand, not
prone to bizarre inconsistencies, etc. For the macro-challenged, the
keystroke count is reduced as well.

The jQuery list's answer to this is (typically) no answer at all
(literally). ;)

Garrett Smith

unread,
Dec 12, 2009, 6:07:58 PM12/12/09
to
Andrew Poulos wrote:
> On 12/12/2009 8:26 AM, S.T. wrote:
>> On 12/7/2009 8:59 AM, David Mark wrote:
>>> But it has the same old attr method. :(
>>>
>>> attr: function( elem, name, value ) {
>>>
>>> // don't set attributes on text and comment nodes
>> >
>>> ... and on and on and on.
>>
>> For all these massive bugs, future browser incompatibility issues, code
>> breaking on every library update and inept coding that you claim litters
>> jQuery -- I don't seem to see any effects of them. Ever. Nor do my
>> users. Nor other developers I communicate with.
>>
>> Weird, isn't it?
>>
>> Guess I'm just really, really lucky.

Probably.

Bugs do not always manifest in the scenario. If they did, there would be
value in unit testing.

[...]


> Yes, many developers are lucky.
>

Like all things in life, there is more than meets the eye.

Hans-Georg Michna

unread,
Dec 13, 2009, 11:55:23 AM12/13/09
to
On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote:

>... I made an exception a couple of years back (Google "browser
>scripting library" and click the first hit). It is a functional API
>with an optional jQuery-like (but competently designed) "chainable" OO
>interface (or you could write your own that is exactly like jQuery if
>that's what you really want). I don't recommend using such interfaces
>as they just slow things down, but at least mine is a fairly
>"unobtrusive" layer.

Thanks, interesting!

A compatible jQuery replacement may be something interesting
too. Ever thought of that?

Or maybe a jQuery add-on that fixes jQuery's worst errors,
perhaps by replacing the worst functions with new ones?

Hans-Georg

Hans-Georg Michna

unread,
Dec 13, 2009, 11:55:23 AM12/13/09
to
On Fri, 11 Dec 2009 06:03:46 -0800 (PST), Matt Kruse wrote:

>I know what
>problems I have with jQuery, and I code around them.

Matt,

it would be nice to have a list of these. Care to publish one?

Hans-Georg

Hans-Georg Michna

unread,
Dec 13, 2009, 11:55:23 AM12/13/09
to
On Wed, 09 Dec 2009 17:22:49 +0100, Jake Jarvis wrote:

>Hans-Georg Michna wrote:

>> On Mon, 7 Dec 2009 15:20:00 -0800 (PST), David Mark wrote:

>>> incompatible with QSA.
>>> Almost every browser "supported" by jQuery _has_ QSA now anyway.

>> what does QSA stand for?

>querySelectorAll
>http://www.w3.org/TR/selectors-api/#nodeselector

Thanks.

Hans-Georg

David Mark

unread,
Dec 13, 2009, 12:44:29 PM12/13/09
to
On Dec 13, 11:55 am, Hans-Georg Michna <hans-

georgNoEmailPle...@michna.com> wrote:
> On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote:
> >...  I made an exception a couple of years back (Google "browser
> >scripting library" and click the first hit).  It is a functional API
> >with an optional jQuery-like (but competently designed) "chainable" OO
> >interface (or you could write your own that is exactly like jQuery if
> >that's what you really want).  I don't recommend using such interfaces
> >as they just slow things down, but at least mine is a fairly
> >"unobtrusive" layer.
>
> Thanks, interesting!
>
> A compatible jQuery replacement may be something interesting
> too. Ever thought of that?

The stock OO interfaces are just a thin (and optional) layer over the
API (as they should be). You could put whatever "face" you want on
the API, including jQuery's grotesque profile. Mine is somewhat
jQuery like, but instead of $ to create a single type of object, it
has:-

E - element
Q - one or more elements (query)
D - document
W - window

Also, inheriting from E with a few augmentations:-

F - form
I - image

I didn't put a lot of thought into them and I never use them, so they
haven't been tested thoroughly. But the typical method is 2-3 lines
long. As you might expect, reading those short methods gives quite an
insight into the API and how to create an alternative interface. And,
of course, they are all "chainable".

Q('.myclass').fadeIn().onclick(function() {
this.fadeOut();
}, this);

Something like that. Perhaps somebody should explore and document
these features, but it won't be me. I'm working on something else
(and was never particularly interested in the OO interfaces).

>
> Or maybe a jQuery add-on that fixes jQuery's worst errors,
> perhaps by replacing the worst functions with new ones?

What I typically do for those who are married to the jQuery interface
is to figure out what parts of jQuery they actually use and provide
reliable alternatives wrapped in a jQuery-like object. That
eliminates the biggest maintenance headache (upgrading jQuery to "keep
up" with the latest browsers) and, of course, the parts under the hood
actually work. ;)

There's no way to write an add-on for jQuery that fixes it. The
design was terribly flawed from day one and now they are stuck with
it. Sure, there are lots of things that could be improved internally,
but who has time to fight with the jQuery people? When it comes to
logic and interface design, they are clearly insane (and you just
can't argue with crazy people).

David Mark

unread,
Dec 13, 2009, 2:36:05 PM12/13/09
to

Oops, that second argument is obviously wrong. Looking at the
prototype, I had the method name wrong too. And I forgot to wrap the
- this - identifier.

var q = Q('.myclass');

q.fadeIn().on('click', function() {
this.fadeOut();
}, q);

That would fade all of them out on clicking any. The second argument
is the context (the query object in this case).

To fade out one at a time:-

Q('.myclass').fadeIn().on('click', function() {
E(this).fadeOut();
});

Want to remove the click listener for each in turn?

var fn = function() {
E(this).fadeOut().off('click', fn);
};

Q('.myclass').fadeIn().on('click', fn);

As for these (poorly named) on/off methods, they do no munging of
events (e.g. mouseenter means mouseenter). Cross-browser "smoothing"
is done through higher-level methods (e.g. onhover, onmousewheel,
oncontextclick). That's the way it should be for clarity (i.e.
knowing what to expect from the call) and flexibility (i.e. not
restricting the events that can be attached). Such layering is done
throughout. For example, setting the opacity style means just that.
The higher-level setOpacity method provides the cross-browser opacity
solution (which may or may not set that specific style). In contrast,
jQuery smashes everything together so that you have no recourse when
it's meddling fails (other than to "step outside" of jQuery).

For me, I can't see coding like this. But the interface is there (and
works efficiently) for those who can.

David Mark

unread,
Dec 13, 2009, 4:19:16 PM12/13/09
to
On Dec 13, 2:36 pm, David Mark <dmark.cins...@gmail.com> wrote:

[...]

>
> var q = Q('.myclass');
>
> q.fadeIn().on('click', function() {
>      this.fadeOut();
>
> }, q);
>
> That would fade all of them out on clicking any.  The second argument
> is the context (the query object in this case).
>
> To fade out one at a time:-
>
> Q('.myclass').fadeIn().on('click', function() {
>      E(this).fadeOut();
> });

On closer inspection, those *in/out methods need a first argument,
which is an object specifying various options. Minimum needed to make
sense is a duration as the default is 0.

Q('.myclass').fadeIn({ duration: 500 }).on('click', function() {
E(this).fadeOut({ duration: 500 });
});

At a glance, it appears the other options are ease (easing function--
see API.ease), repeat, revert (reverts altered styles after hide), dir
(reversals and "round trip" transitions), to, from (both percentages)
and fps (frames per second).

The stock reveal effects include "fade", "slide", "drop", "fold",
"zoom", "horizontalblinds" and "verticalblinds" (see API.effects).

And, as with everything in the library, it is trivial to detect
features, allowing for controlled degradation. There are various host
methods and properties that must be present and functional to make
these animation methods work. Those are taken care of behind the
scenes. The calling app only needs to detect the methods on the API
objects. For example, if an enhancement requires fadeIn/out and will
use the OO interface, the gateway would look like this:-

if (E.prototype.fadeIn) { // undefined if not supported
// Cool enhancement goes here
}

It's interesting that libraries like jQuery preach progressive
enhancement, yet there is no way to determine if their methods are
viable in the given environment. Seems a huge contradiction to me.
If you have no way of knowing what will fail, you have no way of
knowing what to present to the user. Present something that fails
unexpectedly (i.e. throws an exception) and the aspiring enhancement
ends up an annoyance at best and a hindrance at worst.

Matt Kruse

unread,
Dec 13, 2009, 10:57:25 PM12/13/09
to
On Dec 12, 11:03 am, David Mark <dmark.cins...@gmail.com> wrote:
> Nice try (seriously) in your recent attempt to educate John Resig
> about his own attr/removeAttr methods.

I've read a few replies on the thread here and there over the weekend
but haven't had a chance to reply until now.

I've had a thought on the attr() method which might frame it
differently. Basically, I've realized that it's not a wrapper for get/
setAttribute, which is what you always criticize it for. It is a
method that attempts to get an attribute value that makes sense to the
user. And by attribute, I mean "a characteristic of an entity" which
is one good definition I found. It does _not_ necessarily mean the
same as getAttribute().

So if you frame it that way, which makes sense, then the requirements
change. It does not have to pass your test suite to be correct. When a
user wants the "height" attribute of an element, they don't really
want the height="x" attribute in the source. They want the height of
the element. So calling the jQuery height() method makes sense.

And if the element has a property that matches the attribute name the
user is looking for, it makes sense to return it rather than the
underlying getAttribute() value. A call to .attr('checked') should
return a boolean, because that just makes sense! In that sense, it's
similar to search engines or things like Wolfram|Alpha that take user
input and try to figure out what it is that the user really wants, and
give it to them. Attr() seems to try to do that. Unfortunately, for
computer programming, logical and predictable results are what matter
most, so such a "magical" function is surely asking for trouble.
Nevertheless, I think many developers find the convenience and
"magical accuracy" of attr() to be very handy.

Now, is it documented correctly? Surely not. Is it robust? Surely not.
Does it have some issues? Of course. But in the end, I bet that
jQuery's attr() method returns what the average developer wants more
consistently than your attribute wrappers.

So your issues with it seem to be:
1) It doesn't do what you think it should do
2) It doesn't behave the same way your methods do
3) The documentation doesn't describe in detail what its purpose is or
how it works

So perhaps the real problem is NOT that attr() doesn't do what it
should, but that you don't like what it is or how it works.

> As for licensing, which I see Resig is interested in, tell him he can
> license the whole test suite, wrappers, etc., but it won't be cheap.
> Hell, tell the "foundation" to pick up the bill.  :)  And if he copies
> one word or the tiniest aspect of the design, brutal legal action will
> follow.

It amazes me to see the extent that you go to prove (again) that
you're an ass.

Matt Kruse

Matt Kruse

unread,
Dec 13, 2009, 11:00:00 PM12/13/09
to
On Dec 12, 2:06 pm, David Mark <dmark.cins...@gmail.com> wrote:
> In conclusion, results for attribute-related queries would make decent
> seeds for random number generators.

Can you come up with a real test-case that fails?

Matt Kruse

Garrett Smith

unread,
Dec 14, 2009, 2:23:43 AM12/14/09
to
David Mark wrote:
> On Dec 13, 12:44 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Dec 13, 11:55 am, Hans-Georg Michna <hans-
>>
>> georgNoEmailPle...@michna.com> wrote:
>>> On Wed, 9 Dec 2009 09:43:44 -0800 (PST), David Mark wrote:
>>>> ... I made an exception a couple of years back (Google "browser


[sni[\

> Want to remove the click listener for each in turn?
>
> var fn = function() {
> E(this).fadeOut().off('click', fn);
> };
>
> Q('.myclass').fadeIn().on('click', fn);
>

[sni[


> For me, I can't see coding like this. But the interface is there (and
> works efficiently) for those who can.

It is a pity that this style of programming has become so widely adopted.

The design of making a query and performing an action is inherently
inefficient.

A simple event library can go much further, with much fewer bugs, much
less code, much faster performance.

Long menthod chains and complex expressions are harder to debug, then
again, one-letter functions like 'E' aren't very descriptive, either.

Aside: I do mean to get back to that getWindowSize post, I am sorry I
have many things going on right now. I have not forgotten that one.

David Mark

unread,
Dec 14, 2009, 8:55:21 AM12/14/09
to
On Dec 13, 10:57 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 12, 11:03 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Nice try (seriously) in your recent attempt to educate John Resig
> > about his own attr/removeAttr methods.
>
> I've read a few replies on the thread here and there over the weekend
> but haven't had a chance to reply until now.
>
> I've had a thought on the attr() method which might frame it
> differently. Basically, I've realized that it's not a wrapper for get/
> setAttribute, which is what you always criticize it for. It is a
> method that attempts to get an attribute value that makes sense to the
> user. And by attribute, I mean "a characteristic of an entity" which
> is one good definition I found. It does _not_ necessarily mean the
> same as getAttribute().

You are very confused. I never claimed it was a get/setAttribute
wrappers at all. Quite the opposite. The "attr" name has always been
a source of irony. I explained this (again) in the post you replied
to. :) What I have always criticized is that it _uses_ getAttribute,
which is broken in various IE versions and modes.

The thing you describe is the - prop - wrapper from the test page,
which is closer to what jQuery's attr does (but as noted, not
exactly).

>
> So if you frame it that way, which makes sense, then the requirements
> change.

Nobody knows exactly what his requirements are. Including him, of
course.

> It does not have to pass your test suite to be correct.

That's exactly what I said. It's not necessarily what he is after.
The trouble is that nobody (including him) knows what he is after.

> When a
> user wants the "height" attribute of an element, they don't really
> want the height="x" attribute in the source. They want the height of
> the element. So calling the jQuery height() method makes sense.

Not even close. Read this:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/4c5043cffb1826fa#


>
> And if the element has a property that matches the attribute name the
> user is looking for, it makes sense to return it rather than the
> underlying getAttribute() value.

If that is what the design calls for, which is what the - prop -
wrapper does. I covered _both_ bases with _two_ wrappers. The jQuery
thing tries to cram them both into one, which is impossible. Get it?

> A call to .attr('checked') should
> return a boolean, because that just makes sense!

Except for the unfortunate name, that does make sense. Who needs a
string for that?

> In that sense, it's
> similar to search engines or things like Wolfram|Alpha that take user
> input and try to figure out what it is that the user really wants, and
> give it to them.

Similar to what?! It's a "glorified" way to read DOM properties.
Quoting from Resig:-

"It's only a backwards step if you're attempting to use .attr() as a
glorified way to set DOM 0 events - which is not really something that
jQuery is designed for nor does it encourage"

Or is it? :)

http://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd714033

> Attr() seems to try to do that.

Seems to try.

> Unfortunately, for
> computer programming, logical and predictable results are what matter
> most, so such a "magical" function is surely asking for trouble.
> Nevertheless, I think many developers find the convenience and
> "magical accuracy" of attr() to be very handy.

Then they'd find one that doesn't produce random results even
handier. That's been the point all along.

>
> Now, is it documented correctly? Surely not. Is it robust? Surely not.

It's B-R-O-K-E-N. Always has been. You've been talked into something
else, but whatever.

> Does it have some issues? Of course. But in the end, I bet that
> jQuery's attr() method returns what the average developer wants more
> consistently than your attribute wrappers.

My "attribute wrappers" were never marketed as magic tools, nor do
they deal only in attributes. The idea is that they prove how futile
it is for most scripts to try to read/write/remove attributes. And,
of course, jQuery does those things, unnecessarily and inaccurately.

>
> So your issues with it seem to be:
> 1) It doesn't do what you think it should do

No. That's _never_ what I was saying. As mentioned, nobody knows
what the hell that thing is supposed to do,l

> 2) It doesn't behave the same way your methods do

No. I specifically told you my tests were not appropriate for testing
jQuery. I laughed when I saw Resig run with them (as if they were
magic tests for _his_ logic).;

> 3) The documentation doesn't describe in detail what its purpose is or
> how it works

Nothing does and how it "works" keeps changing.

>
> So perhaps the real problem is NOT that attr() doesn't do what it
> should, but that you don't like what it is or how it works.

You are just making a fool of yourself now. Too bad, it seeemed like
you almost understood at one point. Go back and re-read this whole
thread from the start.

>
> > As for licensing, which I see Resig is interested in, tell him he can
> > license the whole test suite, wrappers, etc., but it won't be cheap.
> > Hell, tell the "foundation" to pick up the bill.  :)  And if he copies
> > one word or the tiniest aspect of the design, brutal legal action will
> > follow.
>
> It amazes me to see the extent that you go to prove (again) that
> you're an ass.

No, it shows I am not about to let Resig steal my code. I _gave_ him
the fix for broken attributes two years ago. He apparently couldn't
understand it. I thought you did at one point. Are you drunk or
what?

And he's an idiot too. He thinks I'm talking about the "common sense"
tests. Hell, even if I was, tell him to get his own common sense. :)

David Mark

unread,
Dec 14, 2009, 8:57:01 AM12/14/09
to

Now you are parroting Resig? You really don't get it either, do you?