Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New jQuery announced!

72 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?

David Mark

unread,
Dec 14, 2009, 8:59:09 AM12/14/09
to
On Dec 14, 2:23 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> 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.

Yes.

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

Absolutely.

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

Yes. I don't like the constructor names either. At the time, I was
demonstrating an alternative to the less-descriptive "$".

>
> 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.

NP.

David Mark

unread,
Dec 14, 2009, 9:09:38 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,

You've realized shit. That was in the next couple of sentences, which
you handily snipped. What a weasel.

Quoting the part snipped with simplified translations:-

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

_He_ thinks those test(s) (one anyway) are appropriate to test _his_
design.

"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."

_You_ don't quite understand these terms either.

"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."

_I_ explained it to you again.

"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."

Note that last sentence.

"The biggest unanswered question, which Resig seems unwilling to
address, is what the hell is his attr method supposed to do?"

So, what is it supposed to do? What about the "companion"
removeAttr? And how can you be wasting time "explaining" this shit to
me?

Matt Kruse

unread,
Dec 14, 2009, 11:19:56 AM12/14/09
to
On Dec 14, 7:57 am, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 13, 11:00 pm, Matt Kruse <m...@thekrusefamily.com> wrote:

> > 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?
> Now you are parroting Resig? You really don't get it either, do you?

I'm trying to imagine a case where this actually matters. Digging into
code and finding logic flaws that will pop up in real cases is one
thing. Dreaming up edge cases that may in theory fail under obscure
conditions for obscure input is another, and not necessarily useful.

On Dec 12, 2:06 pm, David Mark <dmark.cins...@gmail.com> wrote:
> So, an element like this:-
> <div></div>
> ...will produce a test like this:-
> return (" null ").indexOf( match ) > -1;
> ...in some browsers and modes.

So? I guess if you are trying to match elements where class=="null"
this will cause problems? Or did I miss something?

> 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.

Why would you be writing a query to match the 'onclick' attribute, or
anything that might return a stringified function? Or a
CSSStyleDeclaration?

> 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.  :)

"enabled" is a poor word choice. The intent is different than what
many might expect.

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

> Wrong.  That includes user input.  

Because it's supposed to, of course. If I want to get a reference to
all checkboxes that are currently checked, I of course want to
consider user input.

> 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.

I am curious as to the origins of this.

> So how could you possibly trust any script from these people, let
> alone something as convoluted and confused as jQuery?  

You seem very interested in pointing out every little potential
logical flaw in the source code, without any consideration for whether
the flaw will ever be practically applicable. Sure, it would be great
to have 100% perfect code that considers every possible scenario
ideally. But in reality, this isn't always possible (no software is
perfect). Just because you dream up a potential case where the logic
will fail does not invalidate its usefulness in all the realistic
cases where it will work correctly.

It makes no sense to throw out functionality that will work correctly
for almost every case just because you find one case that is difficult
or impossible to handle correctly - especially if no one actually
needs that case in practice!

Your tunnel vision prevents you from seeing the bigger picture, where
this code is useful for many cases that work just fine.

Matt Kruse

David Mark

unread,
Dec 14, 2009, 11:36:15 AM12/14/09
to

Squawk! Show me an example (as if examples will help you understand
the underlying logic). And what is a "real test-case" anyway?

I took five minutes to put together a demonstration, which touches
upon most of the issues discussed in this thread.

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

There are three images. The middle one is forced to use the border-
box model (a la IE quirks mode). All I want to do is get the height
and then put it back the same as it was. In DOM terms:-

img.height = img.height;

In "concise" jQuery terms:-

$(img).attr('height', $(img).attr('height'));

I believe that would have worked in all (most?) previous jQuery
versions, where the attr method remained a "glorified way to set
properties" (with a few detours into attributes).

It's pretty easy to visualize, but there is also a log.

FF3.5

attr height #1 = 32
attr height #1 after put back = 32
attr height #2 = 32
attr height #2 after put back = 0
attr height #3 = 32
attr height #3 after put back = 32

IE8 (standards)

attr height #1 = 32
attr height #1 after put back = 32
attr height #2 = 32
attr height #2 after put back = 0
attr height #3 = 0
attr height #3 after put back = 0

IE8 (compatibility)

attr height #1 = 32
attr height #1 after put back = 32
attr height #2 = 72
attr height #2 after put back = 72
attr height #3 = 0
attr height #3 after put back = 0

IE8 (quirks)

attr height #1 = 12
attr height #1 after put back = 0
attr height #2 = 52
attr height #2 after put back = 32
attr height #3 = 0
attr height #3 after put back = 0

Looks like random numbers to me. ;)

I'll skip the middle (user input) tests as they will only confuse you
further. But the last one should be obvious. One of the images is a
map:-

<img id="testimage" src="images/cinsoft.gif" height="32" width="32"
ismap alt="">

I tried to query it in two ways (one right, one wrong).

FF3.5

Image map (right way) : [object HTMLImageElement]
Image map (wrong way) : undefined

IE8 (standards)

Image map (right way) : [object HTMLImageElement]
Image map (wrong way) : undefined

IE8 (compatibility)

Image map (right way) : undefined
Image map (wrong way) : [object]

IE8 (quirks)

Image map (right way) : undefined
Image map (wrong way) : [object]

Yeah, that's just the sort of inconsistency that "programmers" often
need. :)

Those were the first tests I tried. I'm sure you can come up with
more. If you understand the code, attributes, properties, box models,
etc., the results are fairly trivial to predict. But why bother when
the author is clearly beyond help?

Don't bring up documentation or community again as the documentation
is invariably wrong (hardly surprising) and the community, right up to
the leader, is clueless. Just admit that it was (and is) a terrible
mistake to trust jQuery.

And understand that My Library is 100% box model _agnostic_ and
handles attributes properly (more or less, the new wrappers are
slightly improved). And, as we've seen, it has the toddler interface
you so covet for your team. You've spent two years defending and
fighting with jQuery, without any understanding of what is going on
under the hood. You can't even upgrade from 1.3 as it will break your
apps, so you are stuck with UA sniffing as well. Every time there is
an inkling of understanding, you talk to Resig and he confuses you
again. The code's logic (or lack thereof) remains constant throughout
your endless waffling.

Matt Kruse

unread,
Dec 14, 2009, 11:49:23 AM12/14/09
to
On Dec 14, 7:55 am, David Mark <dmark.cins...@gmail.com> wrote:
> You are very confused.  I never claimed it was a get/setAttribute
> wrappers at all.  

I may have misunderstood your constant criticisms to the effect of
"jQuery can't even handle attributes correctly!"

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

I pointed this out in the jQuery-dev thread. Hopefully he takes this
seriously, since it can only help improve the attr() method, or at
least clarify what it is intended to do. I suspect the result will be
new test cases derived from the clarified documentation, and possibly
improved code to handle those cases.

> 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?

Clearly, it is possible. It just doesn't behave the way you think it
should.

What if the method were documented as "retrieve the property value
from an element if it exists (with exceptions x, y, z), otherwise fall
back to retrieving the attribute value if possible."? Maybe you think
that functionality is stupid, but oh well.

> 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.

It would be more accurate to say that for some cases, it is futile. In
many other cases, it's simple and works just fine cross-browser.

> No, it shows I am not about to let Resig steal my code.  I _gave_ him
> the fix for broken attributes two years ago.  

It's always an ego thing for you. Unfortunate.

> He apparently couldn't
> understand it.  I thought you did at one point.  Are you drunk or
> what?

Likely.

Matt Kruse

David Mark

unread,
Dec 14, 2009, 11:58:52 AM12/14/09
to
On Dec 14, 11:19 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 14, 7:57 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Dec 13, 11:00 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> > > 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?
> > Now you are parroting Resig?  You really don't get it either, do you?
>
> I'm trying to imagine a case where this actually matters. Digging into
> code and finding logic flaws that will pop up in real cases is one
> thing. Dreaming up edge cases that may in theory fail under obscure
> conditions for obscure input is another, and not necessarily useful.

You just don't get it. Lets start from the beginning. In what way
are the attribute methods broken in IE < 8 and IE8 compatibility
mode? It's not something you should have to memorize as the
"wonderful" script's authors should have known about it and dealt with
it.

>
> On Dec 12, 2:06 pm, David Mark <dmark.cins...@gmail.com> wrote:

A two-fer?

>
> > So, an element like this:-
> > <div></div>
> > ...will produce a test like this:-
> > return (" null ").indexOf( match ) > -1;
> > ...in some browsers and modes.
>
> So? I guess if you are trying to match elements where class=="null"
> this will cause problems? Or did I miss something?

You missed that this is obviously broken logic. If one line is
broken, how do you trust the next (and the thousands that follow that
one)?

>
> > 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.
>
> Why would you be writing a query to match the 'onclick' attribute, or
> anything that might return a stringified function? Or a
> CSSStyleDeclaration?

I wouldn't be writing a query to match _any_ attribute with this piece
of crap. I've seen inside the $ black box and the mechanism is
rusting and broken.

>
> > 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.  :)
>
> "enabled" is a poor word choice. The intent is different than what
> many might expect.

What many might expect? What are you talking about?

>
> > disabled: function(elem){
> >         return elem.disabled === true;},
> > checked: function(elem){
> >         return elem.checked === true;
> > Wrong.  That includes user input.  
>
> Because it's supposed to, of course.

And that's defined where? Since when does a document query include
user input? XPath certainly doesn't. Same for QSA I'm sure.
Furthermore, what sort of document query includes DOM defaults?

> If I want to get a reference to
> all checkboxes that are currently checked, I of course want to
> consider user input.

Then you better hope they short-circuited the QSA fork for the related
pseudo-selectors (e.g. selected, checked, etc.) ISTM they did because
they thought they were "buggy". :) And how does any of this parallel
what an XML query would do?

>
> > 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.
>
> I am curious as to the origins of this.

I'm not. It is funny that, rather than use their own attr method,
they are re-inventing it elsewhere.

>
> > So how could you possibly trust any script from these people, let
> > alone something as convoluted and confused as jQuery?  
>
> You seem very interested in pointing out every little potential
> logical flaw in the source code, without any consideration for whether
> the flaw will ever be practically applicable.

Practically applicable? Do code monkeys consider practicality? Who
educates them about what is practical?

And see the test cases. Querying the document for a single image
should not be impractical for a CSS selector query engine. Isn't that
what they set out to write?

> Sure, it would be great
> to have 100% perfect code that considers every possible scenario
> ideally.

These are not "edge cases". They represent a complete
misunderstanding of the DOM (specifically the MSHTML DOM).

> But in reality, this isn't always possible (no software is
> perfect).

"Nobody is perfect" doesn't fly here. It never takes more than ten
seconds to spot an outrageous gaffe in their code. They've been
working on it for years. Hell, I gave them the one answer that could
have saved all of this MSHTML confusion. Remember?

> Just because you dream up a potential case where the logic
> will fail does not invalidate its usefulness in all the realistic
> cases where it will work correctly.

And who maintains the "realistic" use case list? Do you not
understand that this stuff is handed out to people who haven't the
faintest concept of programming? Of course you do as that's what you
claim to do with it. Do you tell them "just use jQuery", but be
"realistic" about it? :)

>
> It makes no sense to throw out functionality that will work correctly
> for almost every case just because you find one case that is difficult
> or impossible to handle correctly - especially if no one actually
> needs that case in practice!

Difficult or impossible? Where do you get this stuff? The evidence
is right in front of you this time.

As for no one actually needing whatever case you are talking about,
that's a ludicrous argument as all of the tutorials use the attr
method and none explains what it does. The typical explanation is
that it makes it easier to get "attributes" from elements. I've seen
every use case imaginable, no matter how "unrealistic".

>
> Your tunnel vision prevents you from seeing the bigger picture, where
> this code is useful for many cases that work just fine.

Your mind's gone. You are just frustrated and confused. That I
understand, but it is hardly due to my "tunnel vision".

Matt Kruse

unread,
Dec 14, 2009, 12:02:52 PM12/14/09
to
On Dec 14, 10:36 am, David Mark <dmark.cins...@gmail.com> wrote:
> I took five minutes to put together a demonstration, which touches
> upon most of the issues discussed in this thread.
> http://www.cinsoft.net/jquerysucks.html

The attr('height') argument is obvious. I objected to that in the
jQuery-dev thread also. I think it is an absurd addition to the code.
Your example page illustrates that nicely.

> But the last one should be obvious.  One of the images is a
> map:-
> <img id="testimage" src="images/cinsoft.gif" height="32" width="32"
> ismap alt="">
> I tried to query it in two ways (one right, one wrong).

Interesting. I'm not sure that anyone would ever actually do this, but
it does illustrate a potential problem.

> Don't bring up documentation or community again as the documentation
> is invariably wrong (hardly surprising) and the community, right up to
> the leader, is clueless.  Just admit that it was (and is) a terrible
> mistake to trust jQuery.

It has its limitations, the API choices are unwise, and some of the
code inside is definitely "oh look an obscyre failing test case lets
apply some blogged-about browser-specific hack to fix it rather than
really understanding the root cause and correct logical solution."
I'll admit that, certainly. Always have.

Matt Kruse

David Mark

unread,
Dec 14, 2009, 12:15:37 PM12/14/09
to
On Dec 14, 11:49 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 14, 7:55 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > You are very confused.  I never claimed it was a get/setAttribute
> > wrappers at all.  
>
> I may have misunderstood your constant criticisms to the effect of
> "jQuery can't even handle attributes correctly!"

You have. I was referring to the _use_ of get/set/removeAttribute
inside jQuery. I've repeated numerous times that they'd be better off
without those methods, _except_ when it comes to the queries, which
should _not_ take DOM defaults into account. I never looked past attr
before, but it appears the attribute-based queries are similarly
botched.

>
> > Nobody knows exactly what his requirements are.  Including him, of
> > course.
>
> I pointed this out in the jQuery-dev thread. Hopefully he takes this
> seriously, since it can only help improve the attr() method, or at
> least clarify what it is intended to do. I suspect the result will be
> new test cases derived from the clarified documentation, and possibly
> improved code to handle those cases.

Yeah, you were really rolling there (with one minor misconception)
until Resig confused you again. ;) I laughed when I saw Resig trying
to correlate the test results for _my_ two wrappers with the results
for his. I'll put up a jQuery set when I get a chance, but I'll have
to guess at what the thing is supposed to do. Likely will put 1.3 and
1.4 on the same page to compare and contrast. I can tell you that at
least a half dozen attributes will throw exception on calling
removeAttr and at least another dozen more will fail silently. And -
this is the point - it can all be traced to the same misunderstanding,
which has already been explained to them (more than once). They are
never going to figure it out by observing test cases (those just
produce more confused patches).

>
> > 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?
>
> Clearly, it is possible. It just doesn't behave the way you think it
> should.

It doesn't behave the way anyone (sane) thinks it should. BTW, what
do you think this thing returns for XML documents?

>
> What if the method were documented as "retrieve the property value
> from an element if it exists (with exceptions x, y, z), otherwise fall
> back to retrieving the attribute value if possible."?  Maybe you think
> that functionality is stupid, but oh well.

Of course it is stupid and that description is not accurate. Does it
return a string (attribute) or a number (property) for tabindex?
Well, it depends on the browser, mode, jQuery version, etc. It even
changes based on the element type.

>
> > 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.
>
> It would be more accurate to say that for some cases, it is futile. In
> many other cases, it's simple and works just fine cross-browser.

Odd that mine, which were thrown together over a weekend and barely
touched since, have no such problems. And who maintains the matrix of
working features per browser, jQuery version, etc.?

>
> > No, it shows I am not about to let Resig steal my code.  I _gave_ him
> > the fix for broken attributes two years ago.  
>
> It's always an ego thing for you. Unfortunate.

It has nothing to do with me. Various incarnations of this idiotic
and obviously broken script are all over the Web (largely thanks to
parroting by people like you). That's not going to be good for
anyone. Except me perhaps as I've been recently fielding queries
about jQuery abatement. I figured IE8 would be the point where most
people figured it out it was poison. :)

>
> > He apparently couldn't
> > understand it.  I thought you did at one point.  Are you drunk or
> > what?
>
> Likely.
>

That's what I figured. Don't waste my time. :(

David Mark

unread,
Dec 14, 2009, 1:04:47 PM12/14/09
to
On Dec 14, 12:02 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 14, 10:36 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I took five minutes to put together a demonstration, which touches
> > upon most of the issues discussed in this thread.
> >http://www.cinsoft.net/jquerysucks.html
>
> The attr('height') argument is obvious. I objected to that in the
> jQuery-dev thread also. I think it is an absurd addition to the code.
> Your example page illustrates that nicely.

Thank you, but I could have sworn you were swinging back the other way
on that one. ;)

>
> > But the last one should be obvious.  One of the images is a
> > map:-
> > <img id="testimage" src="images/cinsoft.gif" height="32" width="32"
> > ismap alt="">
> > I tried to query it in two ways (one right, one wrong).
>
> Interesting. I'm not sure that anyone would ever actually do this, but
> it does illustrate a potential problem.

Always with the same preface. It's not the only attribute that will
fail. You should be able to recite most of the others. Then there
are the ones that fail in stranger ways (e.g. class, href, etc.). As
for href (and the like), _those_ they try to treat like attributes
(returning unresolved paths). Of course, their attempts don't work
consistently at all. I am sure as I already solved this problem (some
code needs resolved paths, some needs unresolved paths, so they both
need to be available).

>
> > Don't bring up documentation or community again as the documentation
> > is invariably wrong (hardly surprising) and the community, right up to
> > the leader, is clueless.  Just admit that it was (and is) a terrible
> > mistake to trust jQuery.
>
> It has its limitations, the API choices are unwise, and some of the
> code inside is definitely "oh look an obscyre failing test case lets
> apply some blogged-about browser-specific hack to fix it rather than
> really understanding the root cause and correct logical solution."

That's the story of all of the "major" libraries. They are dumping
grounds for misconceptions, guarded by bitchy neophytes who think they
are browser scripting Gods. I saw how Resig referred to your
questioning of his obviously idiotic design and code as "drama".
That's the mindset and it has no place in programming. :)

> I'll admit that, certainly. Always have.

You change your tune daily. It's tiresome.

David Mark

unread,
Dec 14, 2009, 3:26:02 PM12/14/09
to
On Dec 14, 12:02 pm, Matt Kruse <m...@thekrusefamily.com> wrote:

[...]

>
> Interesting. I'm not sure that anyone would ever actually do this, but
> it does illustrate a potential problem.
>

Second try at a successful (and very basic) test failed as well. Just
wanted to know which link in the document had the tabindex specified.
Various IE versions and modes think there are two of them (1 != 2).

See, these are trivial to do with XPath or QSA. How many of jQuery's
"supported" browsers lack both? IE6/7 I presume and those are the
browsers least likely to work with jQuery (that's why they never stop
bitching about them and threatening to drop support). Of course, if
they did drop those two (as if they ever had them), what possible
justification would there be for jQuery's crumbling monolith? The
active community? ;)

Matt Kruse

unread,
Dec 15, 2009, 11:03:00 AM12/15/09
to
On Dec 14, 2:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
> Second try at a successful (and very basic) test failed as well.  Just
> wanted to know which link in the document had the tabindex specified.
> Various IE versions and modes think there are two of them (1 != 2).

Hmmm...

Using "My Library" source here:
http://www.cinsoft.net/mylib-build.asp?version=1.0&helptopic=setattribute&dom=on&setattribute=on&action=Build

Sample html:
<table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
table>

Using IE6 and "My Library":
API.getAttribute(document.getElementById('x'),'onlyonce') => null
API.getAttribute(document.getElementById('x'),'cellspacing') => null

Using jQuery:
$('#x').attr('onlyonce') => "yes"
$('#x').attr('cellspacing') => 5

Seems like jQuery gives me the right answers, and "My Library" fails.

Matt Kruse

David Mark

unread,
Dec 15, 2009, 11:14:55 AM12/15/09
to
On Dec 15, 11:03 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 14, 2:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Second try at a successful (and very basic) test failed as well.  Just
> > wanted to know which link in the document had the tabindex specified.
> > Various IE versions and modes think there are two of them (1 != 2).
>
> Hmmm...
>
> Using "My Library" source here:http://www.cinsoft.net/mylib-build.asp?version=1.0&helptopic=setattri...

>
> Sample html:
> <table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
> table>
>
> Using IE6 and "My Library":
> API.getAttribute(document.getElementById('x'),'onlyonce') => null

Yeah, I told you the new wrappers were slightly improved. Custom (non-
standard) attribute support is one such improvement. :)

> API.getAttribute(document.getElementById('x'),'cellspacing') => null

A workaround for broken "cell span attributes" in IE (as they are
called by the tester) are another. The new Blackberry browser had a
similar problem. I'll transplant the updated version back into My
Library when I get a chance.

>
> Using jQuery:
> $('#x').attr('onlyonce') => "yes"
> $('#x').attr('cellspacing') => 5
>
> Seems like jQuery gives me the right answers, and "My Library" fails.

You don't have a clue what the "right" answers are from jQuery as attr
has no defined behavior. All it did was read the cellSpacing property
(which it would do whether an attribute existed or not). And, as you
know, it would have missed had you used cellPadding. I suggest you
revisit your tests here:-

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

And realize that jQuery fails for _dozens_ of these tests, no matter
how you attempt to define the behavior. No matter how many times I
tell Resig (or whomever) about the MSHTML attribute problem, it never
seems to sink in.

David Mark

unread,
Dec 15, 2009, 11:23:54 AM12/15/09
to
On Dec 15, 11:03 am, Matt Kruse <m...@thekrusefamily.com> wrote:

> $('#x').attr('cellspacing') => 5

As this was the only real bug you found, I looked (and I'm sure you
did too). As I expected, the older version is missing attribute
aliases:-

This is from the newer version and it is clear I added the two cell-
related attribute names last. As I mentioned a month ago, I need to
put this newer version into My Library, but it is hardly a priority
for me.

var attributeAliases = {'for':'htmlFor', accesskey:'accessKey',
codebase:'codeBase', frameborder:'frameBorder',
framespacing:'frameSpacing', nowrap:'noWrap', maxlength:'maxLength',
'class':'className', readonly:'readOnly', longdesc:'longDesc',
tabindex:'tabIndex', rowspan:'rowSpan', colspan:'colSpan',
ismap:'isMap', usemap:'useMap', cellpadding:'cellPadding',
cellspacing:'cellSpacing'};

That's a silly omission by one person from two years ago. Now, how do
you correlate that with jQuery's failings in this area? I know they
are batting .500 on the cell* attributes as of today. :) But those
are the _least_ of the mistakes. ;)

David Mark

unread,
Dec 15, 2009, 11:40:20 AM12/15/09
to
On Dec 15, 11:03 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 14, 2:26 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Second try at a successful (and very basic) test failed as well.  Just
> > wanted to know which link in the document had the tabindex specified.
> > Various IE versions and modes think there are two of them (1 != 2).
>
> Hmmm...
>
> Using "My Library" source here:http://www.cinsoft.net/mylib-build.asp?version=1.0&helptopic=setattri...

>
> Sample html:
> <table cellspacing="5" id="x" onlyonce="yes"><tr><td>Data</td></tr></
> table>
>
> Using IE6 and "My Library":
> API.getAttribute(document.getElementById('x'),'onlyonce') => null
> API.getAttribute(document.getElementById('x'),'cellspacing') => null
>
> Using jQuery:
> $('#x').attr('onlyonce') => "yes"
> $('#x').attr('cellspacing') => 5
>
> Seems like jQuery gives me the right answers, and "My Library" fails.
>

I updated the alias list to match the one from the sequel. No massive
rewrite necessary (unlike jQuery). Custom attributes are not
supported by that function (you _can_ use the native attribute methods
for those in all browsers).

I'll bet you don't get that sort of support from the jQuery "team".
Special orders don't upset me. :)

Matt Kruse

unread,
Dec 15, 2009, 11:41:25 AM12/15/09
to
On Dec 15, 10:14 am, David Mark <dmark.cins...@gmail.com> wrote:
> Yeah, I told you the new wrappers were slightly improved.  Custom (non-
> standard) attribute support is one such improvement.  :)

To quote yourself:

|You missed that this is obviously broken logic. If one line is
|broken, how do you trust the next (and the thousands that follow that
|one)?

> > Seems like jQuery gives me the right answers, and "My Library" fails.


> You don't have a clue what the "right" answers are from jQuery as attr
> has no defined behavior.

I looked at your documentation for getAttribute() and found even less
documentation then attr(). So I guess returning null in these cases is
just fine, as your method has no defined behavior either.

Pot, Kettle, etc.

Matt Kruse

Matt Kruse

unread,
Dec 15, 2009, 11:45:21 AM12/15/09
to
On Dec 15, 10:23 am, David Mark <dmark.cins...@gmail.com> wrote:
> > $('#x').attr('cellspacing') => 5
> As this was the only real bug you found [...]

It took me all of 5 minutes to download your code, look at the code,
and easily identify two problems in the logic. By your own strict
standards of testing, you've had two years to spot these easily-
identified problems, yet they have remained unfixed in the publicly
downloadable version.

I'm sure I could find other problems in your code (seeing as how
easily these were found) if I had the desire to look at it, but I
don't.

Matt Kruse

David Mark

unread,
Dec 15, 2009, 11:50:12 AM12/15/09
to
On Dec 15, 11:41 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 15, 10:14 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Yeah, I told you the new wrappers were slightly improved.  Custom (non-
> > standard) attribute support is one such improvement.  :)
>
> To quote yourself:
>
> |You missed that this is obviously broken logic.  If one line is
> |broken, how do you trust the next (and the thousands that follow that
> |one)?

No, you have a child-like view of all of this. Missing those two
attributes when I slapped together that list of aliases two years ago
was a silly omission, which I documented here a long time ago (just
never bothered to fix it). Completely botching attributes and
properties in a mess like jQuery's attr method is altogether
different. ;)

>
> > > Seems like jQuery gives me the right answers, and "My Library" fails.
> > You don't have a clue what the "right" answers are from jQuery as attr
> > has no defined behavior.
>
> I looked at your documentation for getAttribute() and found even less
> documentation then attr().

And how many times have I told you that the documentation is
incomplete? But it does not betray a complete lack of understanding
like jQuery's. Last I checked, they defined attr as retrieving
attributes from elements. And, as we know, that's not what it does at
all. :)

> So I guess returning null in these cases is
> just fine, as your method has no defined behavior either.

It does have defined behavior. It's a get/setAttribute wrapper that
actually works across all IE versions. The only one of its kind
AFAIK. ;)

>
> Pot, Kettle, etc.

Not even close.

David Mark

unread,
Dec 15, 2009, 11:58:30 AM12/15/09
to
On Dec 15, 11:45 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 15, 10:23 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > $('#x').attr('cellspacing') => 5
> > As this was the only real bug you found [...]
>
> It took me all of 5 minutes to download your code, look at the code,
> and easily identify two problems in the logic.

You did not identify any problems in the _logic_. That's the
difference.

> By your own strict
> standards of testing, you've had two years to spot these easily-
> identified problems, yet they have remained unfixed in the publicly
> downloadable version.

Yes, I've stated repeatedly that I abandoned the project for more
lucrative ventures. :) So what? It's still light years ahead of
jQuery with _nobody_ working on it.

>
> I'm sure I could find other problems in your code (seeing as how
> easily these were found) if I had the desire to look at it, but I
> don't.

That's a cop-out. If you really wanted a better jQuery, you would
have participated in this project two years ago (maybe even spotting
those two missing attribute names). But you chose to stick with
jQuery through endless rewrites and now you can't upgrade the stupid
thing because they've mangled backward compatibility. :)

And I looked up the documentation for getAttribute:-

"The getAttribute function retrieves the value of the specified
attribute of the specified element.
Syntax

v = getAttribute(el, name);

Return Value

The function returns a string or null if the specified attribute does
not exist."

Yep. That's what it does. :) Now what does attr do again? Can
Resig define it at all?

Matt Kruse

unread,
Dec 15, 2009, 11:59:12 AM12/15/09
to
On Dec 15, 10:40 am, David Mark <dmark.cins...@gmail.com> wrote:
> Custom attributes are not supported by that function

I must have missed that in the documentation. I guess when calling
API.getAttribute() you just don't know what to expect.

> I'll bet you don't get that sort of support from the jQuery "team".
> Special orders don't upset me.  :)

Definitely not! Amazing!

I guess there are definite advantages to having your code be used by
only a handful of users. You can make a release quickly and
efficiently without worrying about a release process, backwards
compatibility, compatibility with 3rd party code, test cases,
examples, documentation, and a huge developer/user community. That
must be a big relief. Way to go on that one.

Matt Kruse

Matt Kruse

unread,
Dec 15, 2009, 12:04:13 PM12/15/09
to
On Dec 15, 10:50 am, David Mark <dmark.cins...@gmail.com> wrote:
> No, you have a child-like view of all of this.  Missing those two
> attributes when I slapped together that list of aliases two years ago
> was a silly omission, which I documented here a long time ago (just
> never bothered to fix it).
> [...]

> And how many times have I told you that the documentation is
> incomplete?
> [...]

> > Pot, Kettle, etc.
> Not even close.

Right.

I think the point has been sufficiently made for the archives, so I'm
done.

Matt Kruse

David Mark

unread,
Dec 15, 2009, 12:12:55 PM12/15/09
to
On Dec 15, 11:59 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 15, 10:40 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Custom attributes are not supported by that function
>
> I must have missed that in the documentation. I guess when calling
> API.getAttribute() you just don't know what to expect.

Did it say that you can make up any attribute name? Granted, I agree
that it should disallow them in the docs, but then I've stated a
thousand times that the docs were never finished. Last I heard,
somebody was working on updating them and whenever that happens, I'll
post the results.

>
> > I'll bet you don't get that sort of support from the jQuery "team".
> > Special orders don't upset me.  :)
>
> Definitely not! Amazing!
>
> I guess there are definite advantages to having your code be used by
> only a handful of users.

You haven't got a clue (as usual).

> You can make a release quickly and
> efficiently without worrying about a release process,

What do you know about my release process? I'll tell you that one
thing I always do is to run the script through JSLint. As there are
only a half dozen things it flags, it is easy to spot typos. Now, as
jQuery has so many failings that the lint quits prematurely, it is not
possible to spot typos like this at all.

> backwards
> compatibility, compatibility with 3rd party code,

All ridiculous. Adding those two alias isn't going to break anything.

> test cases,

As you well know, I wrote the proverbial book on attribute-related
test cases:-

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

> examples, documentation,

The documentation for that method is correct (and it has an example).

> and a huge developer/user community.

> That
> must be a big relief. Way to go on that one.

You come off like a petulant child. Just face it, you were wrong all
along. Do I have to go back two years and dig up all of the similar
discussions between you, me and Resig? Didn't I tell you he would
have to rewrite everything _and_ break compatibility badly to "keep
up" with the new browsers (specifically IE8). And didn't I tell you
that feature testing (as used in mine) was the key to avoiding such
problems.

Look at yourself, stuck with a two-year-old version of jQuery, because
they _broke_ compatibility (and fixed almost _nothing_ in doing so).
Way to go, indeed. :)

David Mark

unread,
Dec 15, 2009, 12:27:49 PM12/15/09
to
On Dec 15, 12:12 pm, David Mark <dmark.cins...@gmail.com> wrote:

[...]

>
> All ridiculous.  Adding those two alias isn't going to break anything.
>

An addendum, it's OT, but why the hell aren't those two cell*
attributes deprecated? Thinking back, I'm sure I thought they were
(or should have been). They seem strictly decorative to me (and
covered by CSS rules). I know I haven't used them since last century.

Garrett Smith

unread,
Dec 16, 2009, 8:25:33 PM12/16/09
to
David Mark wrote:
> On Dec 15, 11:03 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>

[].]]]

> That's a silly omission by one person from two years ago.

Sometimes less is more. For example, my dom attributes/property wrapper
source code:-

|

- 0 SLOC and no bugs whatsoever.

:-D

David Mark

unread,
Dec 17, 2009, 9:35:24 AM12/17/09
to
On Dec 16, 8:25 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> David Mark wrote:
> > On Dec 15, 11:03 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> [].]]]
>
> > That's a silly omission by one person from two years ago.  
>
> Sometimes less is more. For example, my dom attributes/property wrapper
> source code:-
>
> |
>
> - 0 SLOC and no bugs whatsoever.

I'm sure your time machine has never broken down either. ;)

John G Harris

unread,
Dec 17, 2009, 10:12:14 AM12/17/09
to
On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith
wrote:

<snip>


>- 0 SLOC and no bugs whatsoever.

How can you be sure your test code had no bugs in it ?

John
--
John Harris

David Mark

unread,
Dec 17, 2009, 10:37:46 AM12/17/09
to
On Dec 17, 10:12 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith
> wrote:
>
>   <snip>
>
> >- 0 SLOC and no bugs whatsoever.
>
> How can you be sure your test code had no bugs in it ?
>

ISTM you would need imaginary test code for a non-existent wrapper. :)

Garrett Smith

unread,
Dec 17, 2009, 5:25:21 PM12/17/09
to
John G Harris wrote:
> On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith
> wrote:
>
> <snip>
>> - 0 SLOC and no bugs whatsoever.
>
> How can you be sure your test code had no bugs in it ?

Good point. Code maintenance involves maintenance of tests. The more
code, and especially the more /complicated/ code is going to have more
variables that require testing. SRP, or "do one thing only" is
applicable to methods and also to tests.

I look back on the unit tests I wrote 18 months ago and they are way too
complex. I try and keep the unit tests to one assertion. If there are
two assertions, I break it up and make another test. The result is the
testing becomes clearer. Instead of "test this particular usage
pattern", the test is more pure to what unit testing actually is -
testing the smallest, testable parts of the code.

On the matter of testing, I'd really like something better than YUI
test. There are several problems I've grown too frustrated with. There
are many improvements that coudl be made, if the author would dedicate
the time to it.

David Mark

unread,
Dec 17, 2009, 5:58:03 PM12/17/09
to
On Dec 17, 5:25 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> John G Harris wrote:
> > On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith
> > wrote:
>
> >   <snip>
> >> - 0 SLOC and no bugs whatsoever.
>
> > How can you be sure your test code had no bugs in it ?
>
> Good point. Code maintenance involves maintenance of tests. The more
> code, and especially the more /complicated/ code is going to have more
> variables that require testing. SRP, or "do one thing only" is
> applicable to methods and also to tests.
>

Yes, and the point that I've made repeatedly regarding get/
setAttribute is that _most_ apps don't need them at all in an HTML
DOM. A very recent example where one could have helped:-

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/9c479ab572e72557#

For whatever reason, the OP wants to set the value attribute of an
input. Of course, I wouldn't recommend a GP wrapper for this one
case. I don't recommend GP solutions at all. But seeing as GP
solutions are all the rage and you can't expect neophytes to figure
these things out, an interface like this would have helped:-

attr(el, 'value', 'myvalue');

(If it actually works, of course).

I dislike the get/set being in one function (it's not like that in My
Library), but these new wrappers were originally designed to replace
Dojo's similar methods. Better would be (from My Library):-

API.setAttribute(el, 'value', 'myvalue');

-or-

E('myid').setAttribute('value', 'whatever');

So, depending on the audience, such wrappers can be useful. Certainly
they are a requirement for a CSS selector query engines, parsers,
serializers, etc. All of the "major" libraries have some sort of half-
hearted attempts.

As for the other methods, outside of a test page, you virtually never
need removeAttribute. But hasAttribute is occasionally needed (and
spottily supported). An example is form serialization.

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

Garrett Smith

unread,
Dec 17, 2009, 6:36:49 PM12/17/09
to
Matt Kruse 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.
> 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.
>

Didn't John Resig just make a post on jquery-dev about how he refuses to
read comp.lang.javascript?

It is hard to understand anything when the thing that is to be
understood is intentionally ignored.

>>> $(':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

The w3c standards are at least as well documented.

> Lots of examples

There are some examples in HTML 4 spec.

> Printed material available for developers to read from

Books?

> An active support community

ciwas, ciwah, c.l.js.

> Active development and bug fixing

Modern browsers have fixed many standards-related bugs in the past 10 years.

> Supported by various editors and environments
> etc
>

What do you want the library code to do?

> 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.
>

That is where code reviews and pair programming come into play.

Code reviews do many things. They force the person who is doing the
review to look closely and understand th code. That right there is a
huge benefit because now two people understand the code. Code reviews
find bugs before they ship. This avoids QA churn. Code reviews can cause
the person writing the code scrutinize check their work more carefully
knowing someone is going to be scrunitize the work.

I once did blocking code reviews for the offshore team. Their HTML and
CSS ath te start of the project was awful. Towars the end, they were
much better than the in house guys. It was a huge success. Unfortunately
the inhouse people were fucking lazy. The laziness was demonstrated by
their hiring brows people overseas for sub-standard wage to do their
work while they took "OOO" or "WFH" days which were actually vacation
(Disneyland, etc).

The benefits of code reviews are also benefits for Pair. Now sometimes
pair is a waste of time, but it can be extremely productive. Pair may
include a little goofing, but usually not much.

A lot of people get nervious about code review but like pair. I guess it
depends who you are working with or who is revieing your code. The
decision to choose one over the other comes down to preference and
logistics (kind of hard to remotely pair).

Even if jQuery is used, there should be code reviews or pair. And for
code reviews with jQuery, it woul make sense to advise against using the
inefficient ready function, the inefficient selectors, the attr or
removeAttr functions, the inefficient animation. Possibly a bette way to
use jQueyr woul be:-

var el = document.getElementById("redBox");
wrappedEl = jQuery(el)[0];

This, at least, would avoid the initial inefficiency of finding the element.

The next step would be writing code that actually does something useful
to fulfill requirements.

>>> 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 :)

What is the reason for having jQuery in the first place?

The patterns jQuery encourages are:

1) wait for document ready,
2) select some nodes,
3) do something with nodes (add event callbacks, etc).

The design I have always favored is:
1) add an event callback to document
2) in the callback, if the target is something were' innterested in,
act accordingly (delegate to the relevant factory, etc).

This second type of design is much simpler and much more efficient.
There is not any query selector, no looping through each and every node.
No waiting for "ready". The only thing that happens while the page is
loading is a event handlers (click, etc) get attached.

Consider what jQuery actually does with ready, and then with:-

var el = jQuery("redBox")[0];

- compared to what happens with:-

var el = document.getElementById("redBox");

- or:-

if(hasClass(target, "ape-calendar")) {
Calendar.getById(target.id);
}

jQuery's ID Command checks each element to see if the ID matches the id
specified. The overhead of matching every element is proportional to the
size of the document. The larger the document, the slower jQuery will be
at matching. This is a much less efficient than document.getElementById.

Looping through the dom during page load can temporarily lock up the UI.
Google search had that problem for a few days but they seem to have
removed that feature.

The jQuery css selector ID matcher could use getElementById, but then it
would not match mutliple IDs. I don't see the point in matching multiple
IDs, but then again, I don't see much point in jquery at all. Perhaps
someone can explain it to me.

A piece of code should exist to solve a problem. In the case of jQuery
selector, the problem solved is finding an element.

The jQuery approach is much more complicated and much slower. It also
requires a significantly large dependency.

Garrett Smith

unread,
Dec 17, 2009, 6:41:39 PM12/17/09
to
David Mark wrote:
> On Dec 17, 5:25 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> John G Harris wrote:
>>> On Wed, 16 Dec 2009 at 17:25:33, in comp.lang.javascript, Garrett Smith
>>> wrote:
>>> <snip>
>>>> - 0 SLOC and no bugs whatsoever.
>>> How can you be sure your test code had no bugs in it ?
>> Good point. Code maintenance involves maintenance of tests. The more
>> code, and especially the more /complicated/ code is going to have more
>> variables that require testing. SRP, or "do one thing only" is
>> applicable to methods and also to tests.
>>
>
> Yes, and the point that I've made repeatedly regarding get/
> setAttribute is that _most_ apps don't need them at all in an HTML
> DOM. A very recent example where one could have helped:-
>
> http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/9c479ab572e72557#
>
> For whatever reason, the OP wants to set the value attribute of an
> input. Of course, I wouldn't recommend a GP wrapper for this one

No, the solution provided in the thread, using defaultValue, is shorter,
faster. there is no abstraction code download, debug, maintain, and test.

Garrett Smith

unread,
Dec 17, 2009, 7:15:36 PM12/17/09
to
Garrett Smith wrote:
> Matt Kruse 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.

[...]


ng is a event handlers (click, etc) get attached.
>
> Consider what jQuery actually does with ready, and then with:-
>
> var el = jQuery("redBox")[0]

correction:
var el = jQuery("#redBox")[0];

Hans-Georg Michna

unread,
Dec 18, 2009, 9:29:39 AM12/18/09
to
On Sun, 13 Dec 2009 09:44:29 -0800 (PST), David Mark wrote:

>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);

Looks good. The problem is that jQuery already has lots of
groupies, including myself. The discussions here have made me
warier though.

Hans-Georg

David Mark

unread,
Dec 18, 2009, 9:44:51 AM12/18/09
to
On Dec 17, 7:15 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Garrett Smith wrote:
> > Matt Kruse 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.
>
> [...]
> ng is a event handlers (click, etc) get attached.
>
> > Consider what jQuery actually does with ready, and then with:-
>
> >    var el = jQuery("redBox")[0]
>
> correction:
>      var el = jQuery("#redBox")[0];

One other correction:-

jQuery("#redBox")[0] == document.getElementById('redBox');

They don't have a single element abstraction, so the wrappedEl
mentioned previously was just a plain node reference.

I agree with the points made. It's even worse when you consider that
jQuery uses QSA for some browsers and its own attribute-botching BS
for others. Similar XPath-based forks exist in other "major"
libraries as well. There are lots of cases (some demonstrated
recently) where the two forks will diverge, even in HTML DOM's (XML/
XHTML are certainly out of the question if consistency is desired).

In a nutshell, the "silver bullet" solutions just make basic concepts
harder to grasp (see the recent jQuery Summit on Attributes), less
consistent across browsers and prone to obscure errors (especially
when new browser versions are released). Handing these scripts (and
accompanying books) to neophytes is not likely to turn out well. And
expecting the authors of these things to gain understanding one "show
me" at a time is dreaming. :)

Garrett Smith

unread,
Dec 18, 2009, 4:22:59 PM12/18/09
to
David Mark wrote:
> On Dec 17, 7:15 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Garrett Smith wrote:
>>> Matt Kruse 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.
>> [...]
>> ng is a event handlers (click, etc) get attached.
>>
>>> Consider what jQuery actually does with ready, and then with:-
>>> var el = jQuery("redBox")[0]
>> correction:
>> var el = jQuery("#redBox")[0];
>
> One other correction:-
>
> jQuery("#redBox")[0] == document.getElementById('redBox');
>
> They don't have a single element abstraction, so the wrappedEl
> mentioned previously was just a plain node reference.
>

Yep. wrappedEl was a very misleading variable name. The second example
using - var el - got it right.

Garrett Smith

unread,
Dec 18, 2009, 10:49:48 PM12/18/09
to
Garrett Smith 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;
>>>>

[snip]

>>
>> 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?
>
> <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.

One more time: Can anyone demonstrate the problem that the workaround
exists for?

Matt Kruse

unread,
Dec 19, 2009, 12:28:20 AM12/19/09
to
On Dec 18, 9:49 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>>> | if ( name == "selected" && elem.parentNode )
> One more time: Can anyone demonstrate the problem that the workaround
> exists for?

Yes:
http://ejohn.org/files/bugs/selected/

The bug (or quirk) is valid, but should be documented better, and it's
debatable whether it should even be "fixed" to begin with.

Here was my recommended change to the jQuery source:

// In Safari, if no option is explicitly selected and the first
// option gets selected by default, this option will report
// selected==false _while the page is still loading_. Accessing the
// containing select element causes the option to set its
// selected state correctly. Since options may be nested in
// <optgroup> elements, access two levels up just to be safe.
// Simply accessing the .selectedIndex property even if it doesn't
// exist shouldn't cause a problem in any browsers.
// http://ejohn.org/files/bugs/selected/


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

if (elem.parentNode.parentNode) {
elem.parentNode.parentNode.selectedIndex;
}
}

Matt Kruse

Garrett Smith

unread,
Dec 19, 2009, 1:25:27 AM12/19/09
to
Matt Kruse wrote:
> On Dec 18, 9:49 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>>>> | if ( name == "selected" && elem.parentNode )
>> One more time: Can anyone demonstrate the problem that the workaround
>> exists for?
>
> Yes:
> http://ejohn.org/files/bugs/selected/
>
> The bug (or quirk) is valid, but should be documented better, and it's
> debatable whether it should even be "fixed" to begin with.

Ah, so the selected property is true after onload, but false while the
page is loading. I can reproduce that.

The workaround of accessign - selectedIndex - of the parent causes the
OPTION's - selected - to be true.

That is considerably different then what the comment states:
| // Safari mis-reports the default selected property of a hidden option

>
> Here was my recommended change to the jQuery source:
>

[snip]

HTat's a totally different comment then what appears in the jQUery source.

You wrote earlier that attr() deals only with string values. After I
posted that code, you wrote:-

| I didn't look at the source closely enough.

Did you propose that and then think they did not integrate that proposed
change, and instead decided to not return values from boolean properties?

Matt Kruse

unread,
Dec 19, 2009, 10:46:34 AM12/19/09
to
On Dec 19, 12:25 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Ah, so the selected property is true after onload, but false while the
> page is loading. I can reproduce that.
> The workaround of accessign - selectedIndex - of the parent causes the
> OPTION's - selected - to be true.
> That is considerably different then what the comment states:
> | // Safari mis-reports the default selected property of a hidden option

Indeed, the source is misleading.

> > Here was my recommended change to the jQuery source:

> HTat's a totally different comment then what appears in the jQUery source.

Yup, I re-wrote it.

> You wrote earlier that attr() deals only with string values. After I
> posted that code, you wrote:-
> | I didn't look at the source closely enough.
> Did you propose that and then think they did not integrate that proposed
> change, and instead decided to not return values from boolean properties?

I don't really follow. I posted my corrected comment and code for the
above issue to the jquery-dev mailing list a few days ago. I'm not
sure any attention was paid to it.

Matt Kruse

David Mark

unread,
Dec 19, 2009, 11:43:41 AM12/19/09
to
On Dec 19, 12:28 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 18, 9:49 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > >>>> | if ( name == "selected" && elem.parentNode )
> > One more time: Can anyone demonstrate the problem that the workaround
> > exists for?
>
> Yes:http://ejohn.org/files/bugs/selected/
>
> The bug (or quirk) is valid, but should be documented better, and it's
> debatable whether it should even be "fixed" to begin with.
>
> Here was my recommended change to the jQuery source:
>
> // In Safari, if no option is explicitly selected and the first
> // option gets selected by default, this option will report
> // selected==false _while the page is still loading_. Accessing the
> // containing select element causes the option to set its
> // selected state correctly. Since options may be nested in
> // <optgroup> elements, access two levels up just to be safe.
> // Simply accessing the .selectedIndex property even if it doesn't
> // exist shouldn't cause a problem in any browsers.
> //http://ejohn.org/files/bugs/selected/

> if ( name == "selected" && elem.parentNode ) {
>   elem.parentNode.selectedIndex;
>   if (elem.parentNode.parentNode) {
>     elem.parentNode.parentNode.selectedIndex;
>   }
>
> }
>

Ridiculous. Try detecting the problem you are trying to solve (once
preferably). There's just no basis for this "solution" (which is also
outrageously inefficient). Blind faith has no place in programming
(especially not browser scripting).

During initial feature detection, you could create a SELECT, add a
selected option and check the selectedIndex property. If the SELECT
must be in a document to duplicate the quirk, wait until one is passed
and do the test on it (perhaps replacing the method as a result).
This stuff is not rocket science. :)

And didn't they just "punt" (again) on the "issue" of frames?
Something about "common use cases?" Why are you going for it here?
It's fourth and a mile. ;)

David Mark

unread,
Dec 19, 2009, 11:48:22 AM12/19/09
to
On Dec 19, 10:46 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 19, 12:25 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
> > Ah, so the selected property is true after onload, but false while the
> > page is loading. I can reproduce that.
> > The workaround of accessign - selectedIndex - of the parent causes the
> > OPTION's - selected - to be true.
> > That is considerably different then what the comment states:
> > | // Safari mis-reports the default selected property of a hidden option
>
> Indeed, the source is misleading.

As usual. That's a by-product of the authors' general confusion.
Similar clueless comments are strewn throughout all of the "major"
libraries and the related code is now etched across the Web like a
scar. Even worse, newcomers reference these things like they were
bibles, gleefully re-posting the "wisdom" within, so the
misconceptions multiply.

>
> > > Here was my recommended change to the jQuery source:
> > HTat's a totally different comment then what appears in the jQUery source.
>
> Yup, I re-wrote it.

One baby step for mankind. :)

>
> > You wrote earlier that attr() deals only with string values. After I
> > posted that code, you wrote:-
> > | I didn't look at the source closely enough.
> > Did you propose that and then think they did not integrate that proposed
> > change, and instead decided to not return values from boolean properties?
>
> I don't really follow. I posted my corrected comment and code for the
> above issue to the jquery-dev mailing list a few days ago. I'm not
> sure any attention was paid to it.
>

Probably not. What does that tell you?

Matt Kruse

unread,
Dec 19, 2009, 4:40:03 PM12/19/09
to
On Dec 19, 10:43 am, David Mark <dmark.cins...@gmail.com> wrote:
> Ridiculous.  Try detecting the problem you are trying to solve (once
> preferably).  There's just no basis for this "solution" (which is also
> outrageously inefficient).

Detecting the problem would surely be less efficient than simply
accessing a property, when the latter works just fine.

>  Blind faith has no place in programming
> (especially not browser scripting).

It's not blind faith, it's tested and proven successful.

> During initial feature detection, you could create a SELECT, add a
> selected option and check the selectedIndex property.

What does selectedIndex have to do with anything? It returns the
correct value. It's the <option> tag's 'selected' property that is
incorrect.

> If the SELECT
> must be in a document to duplicate the quirk, wait until one is passed
> and do the test on it (perhaps replacing the method as a result).
> This stuff is not rocket science.  :)

If you wait until the document is ready, then the problem goes away.

It's a weird quirk, but it looks like you are just spewing "answers"
when you've never actually looked at the problem.

Matt Kruse

David Mark

unread,
Dec 19, 2009, 6:05:01 PM12/19/09
to
On Dec 19, 4:40 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> On Dec 19, 10:43 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Ridiculous.  Try detecting the problem you are trying to solve (once
> > preferably).  There's just no basis for this "solution" (which is also
> > outrageously inefficient).
>
> Detecting the problem would surely be less efficient than simply
> accessing a property, when the latter works just fine.

Nonsense. You detect it _once_.

>
> >  Blind faith has no place in programming
> > (especially not browser scripting).
>
> It's not blind faith, it's tested and proven successful.

Proven? It's certainly reasonable to expect the line will be
discarded as a noop. It's unreasonable to expect it will magically
updated the state of the DOM, particularly in the presented case where
the document hasn't finished parsing.

>
> > During initial feature detection, you could create a SELECT, add a
> > selected option and check the selectedIndex property.
>
> What does selectedIndex have to do with anything? It returns the
> correct value. It's the <option> tag's 'selected' property that is
> incorrect.

So you can eliminate that as a possible test, but it would certainly
make for a more logical workaround. ;)

>
> > If the SELECT
> > must be in a document to duplicate the quirk, wait until one is passed
> > and do the test on it (perhaps replacing the method as a result).
> > This stuff is not rocket science.  :)
>
> If you wait until the document is ready, then the problem goes away.

I didn't say to wait until the document is ready.

>
> It's a weird quirk, but it looks like you are just spewing "answers"

No, if there is one thing you should have picked up by now is that I
have the answers and they are virtually always the same. ;)

You seem sure you've isolated a quirk. Now write a test for it. You
couldn't get an answer from selectedIndex. What next? :)

> when you've never actually looked at the problem.

I don't need to. I often solve such problems without seeing them
(usually in advance of their manifestation). ;)

Garrett Smith

unread,
Dec 19, 2009, 7:40:31 PM12/19/09
to
Matt Kruse wrote:
> On Dec 19, 10:43 am, David Mark <dmark.cins...@gmail.com> wrote:
>> Ridiculous. Try detecting the problem you are trying to solve (once
>> preferably). There's just no basis for this "solution" (which is also
>> outrageously inefficient).
>
> Detecting the problem would surely be less efficient than simply
> accessing a property, when the latter works just fine.
>

It works, but should it?

You noticed the problem in a page that was not completed (your linked
example). The OPTION's selected property was false before onload and
true after that. So if the OPTION's selected value were related to the
loaded state of the page, then it would make sense to check the state of
the page in the loop. However your observation was limited. The problem
is not related to the page state, but to whether the option is rendered.

You probably tried reading the selectedIndex, and then found that
worked, then tried to read the option.selected, and then found that
worked, and then figured that by simply accessing selectedIndex, the
selected property was achieved. Did I get that right?

Then you went to propose the workaround as a solution. That's a hack.

The problem was identified as: The default OPTION in a non-rendered
SELECT is false, when the option will be selected by default.

That is not a bug.

It would be a bug if, say, the option had the selected property set
before being rendered. For example, given a SELECT that is not yet part
of the dom, adding a selected OPTION to the SELECT should result in the
OPTION selected property being true.

var s = document.createElement("select");
s.options[0] = new Option("a", "a");
s.options[1] = new Option("a", "a", true, true); // Should be selected.

alert(s.options[1].selected); // Should be true.

Safari correctly elerts "true".

OTOH, if the browser is to make the determination of which option to set
the selected property on, you should not expect that information to be
available when the element is not in the DOM.

If we create two OPTIONs, set disabled=true on the first OPTION, the
second OPTION will be selected when the SELECT is rendered on the page.
There is no guarantee that the second OPTION will be selected before the
dom for that object is ready.

var s = document.createElement("select"),
o = new Option("a", "a"),
o2 = new Option("a", "a");

o.disabled = true;
s.add(o);
s.add(o2);

alert(o2.selected); // expect true or false.

To feature test the problem, create a SELECT, add an OPTION, and check
the OPTION's selected property. Save the result in a variable.

var s = document.createElement("select");
s.add(new Option("a"));
IS_NOT_DEFAULT_OPTION_IN_NONRENDRED_SELECTED = s.options[0].selected;

I suggest moving the workaround (and whatever comments may accompany)
with it and moved it out of the loop.

if(prop === "selected" && IS_NOTDEFAULT_OPTION_IN_NONRENDRED_NOTSELECTED) {
updateOptionSelected(elem);
}

function updateOptionSelected(elem) {
// If we're getting a false value, it may be that the option
// will be selected when fully rendered, but has not happened yet.
if(elem.selected === false) {
var selectedOption = elem.parentNode.options[s.selectedIndex];
selectedOption.selected = true;
}
}

Doesn't that make teh loop a lot clearer?

It will be a little slower in Safari but does not punish every browser
with that workaround.

>> Blind faith has no place in programming
>> (especially not browser scripting).
>
> It's not blind faith, it's tested and proven successful.
>
>> During initial feature detection, you could create a SELECT, add a
>> selected option and check the selectedIndex property.
>
> What does selectedIndex have to do with anything? It returns the
> correct value. It's the <option> tag's 'selected' property that is
> incorrect.
>

Accessign the selectedIndex is a hack. It "works" but by no guarantee of
any official or "de facto" standdard.

>> If the SELECT
>> must be in a document to duplicate the quirk, wait until one is passed
>> and do the test on it (perhaps replacing the method as a result).
>> This stuff is not rocket science. :)
>
> If you wait until the document is ready, then the problem goes away.
>

RIght, but your observation was limited. Based on what you observed,
checking isReady would seem like a sensible workaround. However, that
does not address the fact that the SELECT's DOM may not be ready.

> It's a weird quirk, but it looks like you are just spewing "answers"
> when you've never actually looked at the problem.
>

You provide a nonstandard workaround to get non-standard behavior
without looking closely enough at the problem. Your observations of the
problem are limited to "while the page is loading".

Your proposed workaround relies on an even bigger non-standard quirk. It
is possible that bigger quirk (your workaround) will not be present in
Safari 5 and the smaller quirk will remain. If and when that happens,
you're back to trying to figure out the problem.

David Mark

unread,
Dec 19, 2009, 8:15:08 PM12/19/09
to
On Dec 19, 7:40 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Matt Kruse wrote:
> > On Dec 19, 10:43 am, David Mark <dmark.cins...@gmail.com> wrote:
> >> Ridiculous.  Try detecting the problem you are trying to solve (once
> >> preferably).  There's just no basis for this "solution" (which is also
> >> outrageously inefficient).
>
> > Detecting the problem would surely be less efficient than simply
> > accessing a property, when the latter works just fine.
>
> It works, but should it?

No. It's clearly a side effect. The loophole could close any time
(perhaps it already has in some nightly somewhere).

>
> You noticed the problem in a page that was not completed (your linked
> example). The OPTION's selected property was false before onload and
> true after that. So if the OPTION's selected value were related to the
> loaded state of the page, then it would make sense to check the state of
> the page in the loop.

Would still not be a direct test.

> However your observation was limited. The problem
> is not related to the page state, but to whether the option is rendered.
>
> You probably tried reading the selectedIndex, and then found that
> worked, then tried to read the option.selected, and then found that
> worked, and then figured that by simply accessing selectedIndex, the
> selected property was achieved. Did I get that right?

Sounds like a reasonable explanation to me. That's how these things
are cobbled together, one misconception at a time.

>
> Then you went to propose the workaround as a solution. That's a hack.

Exactly.

>
> The problem was identified as: The default OPTION in a non-rendered
> SELECT is false, when the option will be selected by default.
>
> That is not a bug.

Certainly not. It's an "inconvenience" for the odd script(s) that
want to run queries before the document is ready though.

>
> It would be a bug if, say, the option had the selected property set
> before being rendered.

That would be odd. But still not a bug IMO.

> For example, given a SELECT that is not yet part
> of the dom, adding a selected OPTION to the SELECT should result in the
> OPTION selected property being true.

Yes.

>
>   var s = document.createElement("select");
>   s.options[0] = new Option("a", "a");
>   s.options[1] = new Option("a", "a", true, true); // Should be selected.
>
>   alert(s.options[1].selected); // Should be true.
>
> Safari correctly elerts "true".
>
> OTOH, if the browser is to make the determination of which option to set
> the selected property on, you should not expect that information to be
> available when the element is not in the DOM.

Right. A feature test for this can be run immediately as adding the
element to the DOM would defeat its purpose (so no need to wait for
load).

>
> If we create two OPTIONs, set disabled=true on the first OPTION, the
> second OPTION will be selected when the SELECT is rendered on the page.

Yes.

> There is no guarantee that the second OPTION will be selected before the
> dom for that object is ready.

Right.

>
>   var s = document.createElement("select"),
>       o = new Option("a", "a"),
>       o2 = new Option("a", "a");
>
>   o.disabled = true;
>   s.add(o);
>   s.add(o2);
>
> alert(o2.selected); // expect true or false.

Right.

>
> To feature test the problem, create a SELECT, add an OPTION, and check
> the OPTION's selected property. Save the result in a variable.
>
> var s = document.createElement("select");
> s.add(new Option("a"));
> IS_NOT_DEFAULT_OPTION_IN_NONRENDRED_SELECTED = s.options[0].selected;

I like it.

>
> I suggest moving the workaround (and whatever comments may accompany)
> with it and moved it out of the loop.
>
> if(prop === "selected" && IS_NOTDEFAULT_OPTION_IN_NONRENDRED_NOTSELECTED) {
>    updateOptionSelected(elem);
>
> }
>
> function updateOptionSelected(elem) {
>    // If we're getting a false value, it may be that the option
>    // will be selected when fully rendered, but has not happened yet.
>    if(elem.selected === false) {
>      var selectedOption = elem.parentNode.options[s.selectedIndex];


Exactly. :)


>      selectedOption.selected = true;
>    }
>
> }
>
> Doesn't that make teh loop a lot clearer?

Yes and it actually makes logical sense (always a plus in
programming).

>
> It will be a little slower in Safari but does not punish every browser
> with that workaround.

Right. And the other rendition had severe penalties for all.

> >>  Blind faith has no place in programming
> >> (especially not browser scripting).
>
> > It's not blind faith, it's tested and proven successful.
>
> >> During initial feature detection, you could create a SELECT, add a
> >> selected option and check the selectedIndex property.
>
> > What does selectedIndex have to do with anything? It returns the
> > correct value. It's the <option> tag's 'selected' property that is
> > incorrect.
>
> Accessign the selectedIndex is a hack. It "works" but by no guarantee of
> any official or "de facto" standdard.

What I was getting at is that selectedIndex could be used to determine
if there was a contradiction. As expected, it could.

>
> >>  If the SELECT
> >> must be in a document to duplicate the quirk, wait until one is passed
> >> and do the test on it (perhaps replacing the method as a result).
> >> This stuff is not rocket science.  :)
>
> > If you wait until the document is ready, then the problem goes away.
>
> RIght, but your observation was limited. Based on what you observed,
> checking isReady would seem like a sensible workaround.

It would be a bizarre inference, especially considering the
straightforward solution. ;)

RobG

unread,
Dec 19, 2009, 11:10:12 PM12/19/09
to
On Dec 19, 4:25 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> Matt Kruse wrote:
> > On Dec 18, 9:49 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>>>>> | if ( name == "selected" && elem.parentNode )
> >> One more time: Can anyone demonstrate the problem that the workaround
> >> exists for?
>
> > Yes:
> >http://ejohn.org/files/bugs/selected/
>
> > The bug (or quirk) is valid, but should be documented better, and it's
> > debatable whether it should even be "fixed" to begin with.
>
> Ah, so the selected property is true after onload, but false while the
> page is loading. I can reproduce that.
>
> The workaround of accessign - selectedIndex - of the parent causes the
> OPTION's - selected - to be true.

I think it's a crock. The issue is that during load, if no option has
the selected attribute, the select's selectedIndex property will be
set to 0 but no option's selected property is set to true. That can
also be characterised as a problem with selectedIndex, as it should be
-1 at that moment.

If an option is given the selected attribute, it all works as
expected.

If the load event hasn't occurred yet, and the user *has* selected a
value, is the value reported correctly? I suspect it will be.

If the user hasn't selected an option and the form is submitted before
load has occurred, what will be the value of the select? Should this
be fixed by script, HTML or server code? Should it be fixed at all? Is
this only an issue for serialising forms prior to load? If so, should
it be dealt with there, and only if load hasn't occurred?

Anyhow, it is resolved by following advice in the HTML specification
from a decade ago:

"Since user agent behavior differs, authors should ensure that each
[select] includes a default pre-selected OPTION."

<URL: http://www.w3.org/TR/html4/interact/forms.html#h-17.6.1 >

I'd just document it, job done.

>
> That is considerably different then what the comment states:
> | // Safari mis-reports the default selected property of a hidden option

Which points to an inability to clearly identify the issue in the
first place.

And that reflects on the attr() method in general - there is no clear
idea of what it should do, other than some vague idea of John Resig's
that it should do "what the developer expects". Perhaps he knows the
mind of everyone using jQuery.

It seems to me he wants attr() to do what *he* thinks the developer
expects, despite being told by developers that it doesn't do what
*they* expect. The whole issue would go away if attr() reported
attribute values, a prop() method reported property values and css()
reported (say) computed CSS values.

Then users need only learn the difference between attributes and
properties once. Heaven forbid that they should understand the
technology they're working with.


--
Rob

It is loading more messages.
0 new messages