Test for null or undefined?

[David Mark]

Just re-joined for one last message because, frankly, this is
priceless:

http://www.reddit.com/r/programming/comments/7vul9/some_technical_cri...

Joe Six-Pack late for the ball again.

Apparently I'm not alone.

No. Not by a long shot.

I had a twilight zone moment there my code
seemed like utter shite because I was taking David Mark seriously.

No, you had a brief moment of clarity that was apparently interrupted
by something you thought you saw on Reddit. I see that evem after
your visit, the link to the jQuery review has more up votes than
down.

Perhaps you mean the pro-jQuery commentators who attempted a
filibuster? In any event, that is old news and originally published
here (again, you could have saved some time.)

Good to know

There you go.

[snip]

 

[Jon Gómez]

Thomas Allen, quoting Jorge, wrote,
David Mark in response wrote,

I didn't write that you pugnacious little pissant. Learn to quote or
go back to jQuery-land. Sheesh.

The "forget that nonsense" text wasn't properly quoted--that is true.
However, it seemed pretty clear to me from context that Thomas was
referring to Jorge's post.

He is responding to negative statements about Jorge, and that seems to
be the referent of "the guy" he is asking us to give a break. So the
"he" to whom Thomas attributes the "forget" text is pointing to its
antecedent, "the guy", who must be Jorge.

So Thomas didn't want to make David look bad. He wasn't being
intentionally aggressive, i.e., pugnacious--he was just imprecise to the
point of error.

I was already cutting Jorge slack. Regardless, I appreciate the
underlying sentiment of Thomas' post. Those who feel otherwise, very
well, everyone as they wish.

Jon.

 

[Jon Gómez]

Thomas Allen wrote:
[...]

Anyway, good luck DUDE (since it seems that ticks you off).

Well, now that is fractious.
Jon.

 

[David Mark]

Thomas Allen, quoting Jorge, wrote,


David Mark in response wrote,


The "forget that nonsense" text wasn't properly quoted--that is true.
However, it seemed pretty clear to me from context that Thomas was
referring to Jorge's post.

He is responding to negative statements about Jorge, and that seems to
be the referent of "the guy" he is asking us to give a break.  So the
"he" to whom Thomas attributes the "forget" text is pointing to its
antecedent, "the guy", who must be Jorge.

So Thomas didn't want to make David look bad.  He wasn't being
intentionally aggressive, i.e., pugnacious--he was just imprecise to the
point of error.

LOL. You aren't familiar with his larger body of work.

[snip]

 

[David Mark]

<snip>

Remember that when someone does not know enough about the subject to
apply any informed judgment, while suffering an unrealistic
overconfidence in their own abilities in the filed, they are likely do
jump to all sorts of conclusions about an interlocutor who disagrees
with them.

A similarly misguided reaction to David's criticisms of JQuery can be
found here:-

<URL:http://groups.google.com/group/jquery-dev/msg/69f2b44340d42648>

But having read that take a step back and look at the contents of the
thread that contains that post. Particularly observe that the vast
majority of the code that David criticised at the time is no longer in
JQuery, indeed his primary criticism at that time cantered around the
use of user agent string based browser detection, which has now been
completely removed from JQuery as of version 1.3. That alone makes a
significant point, perhaps a point about who is following and who is
leading.

Another point was the attribute/property mix-up. I think Resig's only
comment at the time was that the "attr" method "could use a rewrite."

Hard to believe that the new version hasn't improved a whit (other
than to remove the browser sniffing.) Of course, the documentation
has the same identity crisis as the code, so it is hard to say what
Resig imagines this method does.

As it is called "attr" and the most used path calls get/setAttribute
and the first argument is an attribute name, I think it is fair to say
he was trying to smooth out differences between the standards and IE's
broken as designed renditions, which debuted before the turn of the
century. As of today, his effort is a complete failure.

Obviously it was lost on him that most applications do not need those
methods at all. As noted, the results are farcically confusing,
inconsistent and occasionally illegal. Thrown exceptions should be an
expected behavior (certainly in 1.2x.)

As written, the code is liable to pass virtually anything to get/
setAttribute (incorrect attribute names, bad values), or may veer off
and get/set a property instead. The behavior varies wildly between
1.2x and 1.3x (as well as between browsers) and it is perhaps the most
used method in jQuery (after - each - probably.)

I suspect that projects like jQuery get away with such inept efforts
as the users of these tools are preconditioned to blame everything on
browser quirks. They are sure that cross-browser scripting is Mission
Impossible and jQuery reinforces their poor image of Javascript and
DOM implementations by making everything painfully complicated and
inconsistent. The dev group doesn't make anything look easy.

Perspectives differ.

Yeah. jQuery's site starts out:

"jQuery is a fast and concise JavaScript Library that simplifies..."

We know that, relatively speaking, it isn't fast at anything. I don't
know what a "concise library" is, but that doesn't sound like jQuery
either. Doesn't simplify anything from what I can see. Community
seems clueless about the code they use, documentation is confused and
the author can't seem to stop demonstrating his ignorance in public.
What was the selling point again?

 

[Jorge]

<snip>

Remember that when someone does not know enough about the subject to
apply any informed judgment, while suffering an unrealistic
overconfidence in their own abilities in the filed, they are likely do
jump to all sorts of conclusions about an interlocutor who disagrees
with them.

I'm seeing what you've (purposedly) quoted, Cornford, and you're an
idiot, puto inglesito de mierda.

 

[Dr J R Stockton]

In comp.lang.javascript message <b13f44ef-260a-451c-ab58-9d78e601aae1@u9
g2000pre.googlegroups.com>, Mon, 30 Mar 2009 11:49:54, Alan Gutierrez

I'm wondering how I check for a missing argument.

Only you can tell that. It would be better to wonder how you should
check for a missing argument.

Testing in FF 3.0.7 & IE 7 :

One cannot have a hole in the arguments list of a function call (that's
a syntax error); missing arguments will be at the end. Therefore,
consulting arguments.length will tell you which arguments are
missing.

Within the routine, a missing argument is not missing, but has the type
and value of undefined . However, an argument which is present in the
call, but is undefined, also has that value internally.

Some, but few, functions do anything useful with an argument of more
than one type. Therefore, you can often do better by testing whether an
argument of the required type is present at that position. That will
restrict the use of automatic type conversion, requiring sometimes
conversion before or within the argument list - that might be considered
to be advantageous for legibility. But a function such as pad-to-length
ought to be able to pad any type or value that might be presented, even
if that type or value is an error.

I find the following to be successful (it makes the test brief) :

function F(A, B) { var U
if (B==U) alert ("Wot no B!")
/* ... */ }

Use something like this to test, in a textarea with eval :
function ff(a, b, c) {
return [arguments.length, " -- ", a, b, c, typeof c, " + ", b+c] }
var U
ff(1, 2) + " " + ff(1, 2, U, 4)

 

[Lasse Reichstein Nielsen]

And all known agents will dutifully throw an exception.

.... because "arguments" shouldn't be capitalized.
Oh, do try to be a little helpful, instead of wasting time on typos.

Anyway, I wouldn't use "arguments.length", because it makes the
Javascript engine need to create the arguments object. Depending
on how often the function is called, it can be a significant overhead.

Actually, I'd only use arguments.length if there is a variable number
of arguments, or if it should make a difference whether the user
passed "undefined" as an argument, or omitted the argument (which it
shouldn't ever do!).

For something like this, I'd just us
if (type === null) { type = "text"; }

/L

 

[David Mark]

... because "arguments" shouldn't be capitalized.
Oh, do try to be a little helpful, instead of wasting time on typos.

I doubt that was a typo. Read his other posts from yesterday. And
everybody else knows what the mistake is. Mind your own time.

[snip]

/L

^^^^^^^^^^

You misspelled "destructive." Try to pay attention.

 

[David Mark]

   ^^^^^^^^
Should have been "centred" (though maybe not s funny).



My recollection is that Resig did not explain/justify any of criticised
code, beyond implying that he knew what heat he was doing, and then
rapidly descending to the nonsensical position that nobody who had not
created their own general-purpose javascript library was qualified to
criticise his code.

How interesting for the thousands of sites that deployed jQuery 1.2x
in the last year. Resig was busy putting up (and immediately taking
down) rock star Websites, instead of cleaning up his mess. He waits
until IE8 is upon us to release a new version that might not fall on
its face in the default mode (and is apparently unsupported in other
modes.)

And yeah, their arguments always devolve to things like:

1. Why aren't you helping out? Where's your library?
2. As if Web developers could do better (of course they could, by
avoiding browser scripting until they are ready.)

And as is patently obvious, Resig and his buddies tried to make jQuery
look more like My Library. Three years of bumbling and in the end the
solution is to copy from me. You know, not a thank you from any of
them (just more shrill whining and insults.)

<snip>

There have been more internal improvements than just that. Those bloody
silly isFunction and isArray methods are much changed, and some of the
method overloading has been taken down a notch so that it is more in
line with what realistically can be achieved in javascript.(and
re-documented so that it no longer asserts an ability to do the
impossible). There is even a move towards modularising the internal
structure, with the selector engine becoming a discrete component.

I was referring only to the attr method (though - each - qualifies as
well.) The former is clearly a disaster and has barely been touched
in 1.3x. We know about the latter.

Of course the public API is still largely set in concrete, and likely to
stay that way, which pretty much precludes entire categories of initial
design mistakes ever being addressed. The dilemma of not wanting to pull
the rug out from under the feet of the people already using it. But
since in reality libraries do get releases in new versions that are not
back-compatible with previous versions there are opportunities at those
points do a major re-working of the API/general structure, though kangax
came close to expressing an alternative issue with doing that in:-

<URL:http://groups.google.com/group/prototype-core/msg/3904f48e1774cc75
 >

- where he wrote; "It's not clear what will be left of Prototype if it
was to change its
core way of doing things - ... ". That issue being the library's
identity; if you have been marketing an identity how far can things be
changed before its existing users start taking offence? Lasse may
suggest that these things will 'win' in the long run, but if they change
out of recognition before they 'win' would they have won at all?

I don't think they will win in any form. They are creating a vacuum
for something much better to fill (just don't know what it is yet.)

It does seem that all the relative speed testing is carried out against
other general-purpose libraries. And against that benchmark 'concise'
comes down in JQuery's favour (for the time being). There doesn't seem
much interest in doing the comparisons on an absolute basis.


Presumably it is supposed to be short/small. But it is probably best to
regard the whole thing as pure marketing-speak.

Certainly. It is along the lines of "it just works", "do more with
less", etc.

Yes, I often read people promoting JQuery as 'whatever' and end up
thinking what on earth where you doing before that makes *this* look
simple, intuitive, intelligible, easy to maintain/debug, etc.?

In most cases they weren't doing anything before, so they have nothing
to compare it to. It's a bandwagon effect (so many others are doing
it, it must be good!)

An observation on these 'communities'; on:-

<URL:http://groups.google.com/group/jquery-en/>

- what proport1ion of questions asked receive no answer at all? I make it
more than 25%; more than 1 in 4.

And how many of those are accurate answers?

Full money back guarantee if not completely satisfied (excluding
merchandising)?

Yeah, good luck returning the books. I suppose they could be used to
line bird cages, start fires, etc.

 

[Matt Kruse]

Another point was the attribute/property mix-up.  I think Resig's only
comment at the time was that the "attr" method "could use a rewrite."

I'd like to see some specific test cases where the attr() method
fails. I'm sure they exist, but I'm not personally interested enough
to hunt them down. I never use attr(). But with some failing test
cases, I think an attr() re-write might get some attention.

Hard to believe that the new version hasn't improved a whit (other
than to remove the browser sniffing.)

There are other improvements, as Richard points out. Change is slow,
especially in collaborative efforts. At least they are moving in the
right direction, even if it's slow and not quite straight.

"jQuery is a fast and concise JavaScript Library that simplifies..."
We know that, relatively speaking, it isn't fast at anything.  I don't
know what a "concise library" is, but that doesn't sound like jQuery
either.  Doesn't simplify anything from what I can see.

I do think it simplifies many things.

The use of CSS selectors to create a group of elements to operate on
is very handy, and the main draw of jQuery and similar libs. I know
it's possible to use other stand-alone selector libraries, but if it's
built into jQuery and jQuery has a large and growing userbase, why not
just use it?

I also find some of its manipulation handy - slideUp(), fadeOut(),
etc. Although quirky in IE6 (at least), it does what I personally need
it to do, and very easily for me.

The AJAX functionality, while imperfect under the covers, works well
for what I need it to. I like being able to do $('.content
div.description').load(url). It's handy, and it does simplify things.

Matt Kruse

 

[Matt Kruse]

And as is patently obvious, Resig and his buddies tried to make jQuery
look more like My Library.  Three years of bumbling and in the end the
solution is to copy from me.  You know, not a thank you from any of
them (just more shrill whining and insults.)

"You're so vain. You probably think this library's about you."

Matt Kruse

 

[Thomas 'PointedEars' Lahn]

.... because "arguments" shouldn't be capitalized.
Oh, do try to be a little helpful, instead of wasting time on typos.

However, that guy is notorious for not understanding what he's doing and
thinking otherwise.

Anyway, I wouldn't use "arguments.length", because it makes the
Javascript engine need to create the arguments object.

That the arguments object is not created when not used is an unfounded
assumption, or rather wishful thinking on your part in order to support your
argument. The ECMAScript Specification, Edition 3 Final, widely implemented
as opposed to the ES 4+(!) dreaming, says otherwise.

So much for being helpful.


PointedEars

 

[David Mark]

I'd like to see some specific test cases where the attr() method
fails. I'm sure they exist, but I'm not personally interested enough
to hunt them down. I never use attr(). But with some failing test
cases, I think an attr() re-write might get some attention.

I suggest you read this thread again. I'd like to hear your concept
of what that method is *supposed* to do in the first place. The first
argument in a set operation is obviously supposed to be an attribute
name. The second is anyone's guess.

Whatever it is, it goes about it in an inconceivable manner and the
results are predictably inconsistent across jQuery versions, as well
as browsers.

It can't be lost on you that IE8 fixed get/setAttribute, yet this
jQuery abomination is still trying to use a "black list" to determine
when to use DOM properties instead. And, of course, everyone who
hasn't upgraded is stuck with browser sniffing in that function, most
of which makes inferences about *IE*.

Barring that, I suggest you look at the code again. It is only a
couple of dozen lines and the mistakes are obvious (at least for
anyone who has used get/setAttribute in the last ten years.)

The reason you persist in your misconceptions is that you are lucky
enough to have rearranged code that has been demonstrated to work in a
handful of environments and those are the only environments you test
(what a happy coincidence!) Now, the poor slob that comes after you
will be in a world of shit if they need to venture outside of your
comfort zone. How would they even understand your code if you don't?
Obviously you know nothing about the attr method, yet you rely on it
for everything and recommend for others to follow suit.

Seriously, in six paragraphs or less, what does the jQuery attr method
do?

There are other improvements, as Richard points out. Change is slow,
especially in collaborative efforts. At least they are moving in the
right direction, even if it's slow and not quite straight.

Like a broken record that goes on forever.

[snip]

 

[David Mark]

"You're so vain. You probably think this library's about you."

Hmmm. John Resig publishes a library. I personally explain to him
exactly where he fouled up (at least in part), publish examples of how
to do it right and a year later code shows up in jQuery that is
obviously influenced by mine (right down to the variable names.)
That's reality, not vanity.

 

[David Mark]

I suggest you read this thread again.  I'd like to hear your concept

Actually, I meant this thread:

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/95c4bbfe39f19ce4#

I presume you missed it.

So, assuming you are not up to the task of explaining (in simple
terms) what this lynch-pin method does, I'll try to give you a head
start. You can't fix it if you don't understand what it does (and
what it should be doing.) One could argue that you shouldn't use or
recommend something you don't understand, but we've been over that ad
nauseum. Consider this the final exam for your credibility.

In jQuery, the attr method will do one of the following, depending on
its arguments:

1. Get a DOM property
2. Set a DOM property
3. Get an attribute
4. Set an attribute

The course taken depends on:

1. DOM type (XML or HTML)
2. Element type
3. Browser
4. jQuery version

The first argument is an attribute name, which jQuery might mutate,
depending on:

1. An incomplete list of properties, which changes per version
2. Nothing else.

The second point alludes to the fact that the attr method couldn't
care less about the second argument, which is completely
undocumented. The decision about when to use get/setAttribute or not
(remember the name is already mutated) is unrelated to the "black
list" result, allowing all sorts of invalid names and/or values to
slip through. Get it?

In other words, at a glance, what do these do?

$(el).attr('disabled', 'disabled');
$(el).attr('disabled', true);

As expected, the results vary as described above. Contrast that with:

el.disabled = true;

How about these?

$(el).attr('onclick', 'alert("test")');
$(el).attr('onclick', function() { alert('test'); });

Contrast with:

el.onclick = function() { alert('test'); };

Bonus question, what would this be expected to return?

${el).attr('rowspan');

What about this?

${el).attr('rowSpan');

That's why I'd never read your code (or anything like it.) Confronted
with such illegible nonsense, it is best to throw it away and start
over (losing at least 50K in the process.)

Regardless of any of this, this outrageous over-complication was never
needed. You've got four functions here (getProperty, setProperty,
getAttribute, setAttribute) and two are rarely needed in an HTML DOM.
Resig has mashed them all up into one idiotic function, which can't do
any of them right. He runs this crap through his crystal ball (a
patchwork quilt of unit tests that mirror his meanderings and
misconceptions), pronounces it as "working" and now half the Web is
running on his latest attempt to "pave over" differences in browsers.

So what does "moving in the right direction" mean to... anybody? Do
you mark your calendar to deploy jQuery a year from now, assuming
Resig will figure out his mistakes by then? Are you a glutton for
upgrades? BTW, have *you* even upgraded yet? If not, you best stop
wasting time on futile arguments.

Why would anyone start out in browser scripting trying to learn the
attr method when even the author is clueless about its purpose, as
well as its execution (and there are much simpler and more concise
techniques to be found in Javascript?) Ironic that those who peddle
paranoia about browser differences could be so completely unable to
deal with them.

Anyway, I await your explanation of the attr method and just what
makes it so simple and concise.

 

[Matt Kruse]

I suggest you read this thread again.

I'll pass. Better things to do.

 I'd like to hear your concept
of what that method is *supposed* to do in the first place.

I'm unclear about what exactly it intends to do.

Obviously you know nothing about the attr method, yet you rely on it
for everything and recommend for others to follow suit.

I don't use it. I'm pretty sure I said that.

Seriously, in six paragraphs or less, what does the jQuery attr method
do?

Set or get DOM properties/node attributes, I presume. Apparently it
doesn't do this well, which is one of the reasons I don't use it. That
and the fact that I have never found a need for it.

Like a broken record that goes on forever.

Pot. Kettle. Blah blah blah.

Matt Kruse

 

[Matt Kruse]

Actually, I meant this thread:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...
I presume you missed it.

I did. I'll read through it at some point.

So what does "moving in the right direction" mean to... anybody?

To me it means that jQuery is a major library that is improving, not
getting worse. It removed browser sniffing - something other major
libs haven't even touched. It has improved the amazingly broken
isFunction kind of detection. It has isolated its selector engine and
sped it up. It has fixed some of the junk that was remaining in the
code, based on recommendations and discussions. It's getting better,
not worse. IMO. So I have hope that it will overcome some of the
problems it still has.

BTW, have *you* even upgraded yet?

No, but I don't use it that much. No need to upgrade something that
isn't broken.

 If not, you best stop
wasting time on futile arguments.

This has never worked for me in the past

Anyway, I await your explanation of the attr method and just what
makes it so simple and concise.  

I'm sure you do, but I've got more interesting challenges to tackle. I
participate in threads like these to try to get a good idea of what
problems exist and where the solution might lie, and maybe to find a
way to get those things fixed in arguably the most popular js
framework on the web. I'd like to think that the removal of browser
sniffing and some other improvements in jQuery were partly due to my
participation. I don't do the deep analysis, the code fixing, or the
testing, but I can help the process along where possible. But I'm not
going to spend lots of time analyzing and trying to explain code.
There are better uses of my time.

Matt Kruse

 

[David Mark]

I'll pass. Better things to do.

But you said:

"I'd like to see some specific test cases where the attr() method
fails."

You also said something about a rewrite. Of course, a rewrite of this
would likely break a lot of apps, plug-ins, Websites, etc.

I'm unclear about what exactly it intends to do.

So you recommend something that you are unclear about. We aren't
talking about some obscure backwater method here. This is what jQuery
developers use to get and set properties on DOM nodes (among other
things.) How can you not know this? It's especially vexing as you
were told this over a year ago. You specifically and you have been
popping up like some indefatible toon to plug jQuery ever since.

Let me make it clear to you. That method is poorly designed and
executed and is completely unnecessary. The method to get a property
is one line. To set is two. You didn't need to invoke the get/
setAttribute methods at all. You certainly didn't need to invoke them
with incorrect names and/or values. What a ridiculous thing to do,
turning the simple and critical task of getting and setting DOM
properties into a series of misadventures that guarantee cross-browser
incompatibility. Hell, as designed it doesn't work properly in *any*
browser.

I don't use it. I'm pretty sure I said that.

So you did. Have to wonder why you would bypass the wonderful
convenience. What do you load lists of elements into his wrappers
for? Regardless, all of the other jQuery "programmers" use it to
death. And, of course, you are using it whether you know it or not as
jQuery itself uses it (in for a penny, in for a pound.)

And you do realize this is but one function. It is just ironic that
it is the very first botched jQuery function I explained to you (and
Resig) and here you are a year and a half later parroting the same old
song and claiming ignorance. I remember quite specifically that you
chimed in about XML documents retrieved via XHR, prompting a warning
that this attr method was hardly suitable for such tasks. It wasn't
then and it still isn't. Resig's fanciful mungineering isn't suitable
for HTML DOM's either.

Set or get DOM properties/node attributes, I presume.

Brilliantly put. That's more or less what the documentation says.
Are you sure you want to hand that in?

Apparently it
doesn't do this well, which is one of the reasons I don't use it.

Yet you will recommend it. Again, these issues are right up front.

[snip]

 

[David Mark]

I did. I'll read through it at some point.

Hopefully not with a mouth full of food.

To me it means that jQuery is a major library that is improving, not

There's nothing major about. Improving means nothing to someone
putting up a site *today*. Matter of fact, improving implies defects
and the prospect of imminent upgrades. Those are bad things.

getting worse. It removed browser sniffing - something other major

I know. Well, they sort of removed browser sniffing.

libs haven't even touched. It has improved the amazingly broken

You are so colossally ignorant. Is this a competition? Resig is way
late on the feature detection kick anyway. All of the people who put
their faith into pre-epiphany versions are now screwed. Who won?

isFunction kind of detection. It has isolated its selector engine and
sped it up.

It was always a tortoise. A big, bloated, unnecessary tortoise.

It has fixed some of the junk that was remaining in the
code, based on recommendations and discussions. It's getting better,

Yet nobody thought to check the two most used functions in the script
(attr and each.) Both have huge holes in the latest (?) release,
which is two releases since 1.3. Collaboration indeed. You don't
need an army to be this impotent. It's either the worst software
effort or the greatest chimp act ever.

not worse. IMO. So I have hope that it will overcome some of the
problems it still has.

But will anyone care when it does? That's a rhetorical question.

No, but I don't use it that much. No need to upgrade something that
isn't broken.

LOL. You used to use it all the time in some controlled environment.
What happened? And you fail to grasp that time has broken anything
written with 1.2x. Not that it worked before as it hinged largely on
finding "MSIE" in the UA string. At this time, you can't possibly
call such a script usable. If perchance your previous jQuery output
still appears to work in some limited set of browsers, what makes you
think they aren't as brittle as snowflakes?

This has never worked for me in the past


I'm sure you do, but I've got more interesting challenges to tackle. I

What a cop-out.

participate in threads like these to try to get a good idea of what
problems exist and where the solution might lie, and maybe to find a

I told you about this problem a year and a half ago in a thread very
much like this one. It's not as if it is a little problem.

way to get those things fixed in arguably the most popular js
framework on the web.

Both you and Resig had these answers on a silver platter. You didn't
listen or you didn't understand. I don't know what your deal is now
(apparently you abandoned the "most popular js framework on the web.")

I'd like to think that the removal of browser
sniffing and some other improvements in jQuery were partly due to my
participation.

Yes. I remember it well. I mentioned jQuery was a trainwreck. You
mentioned it wasn't. I mentioned it sniffed browsers incessantly.
You mentioned it didn't. I posted a lot of code and comments. You
ran off to tell John Resig. John Resig mentioned I didn't have
anything to say as I didn't write a cool library like jQuery. I wrote
a much cooler library than jQuery and continued to pressure that moron
to change his code. Finally he did. Some of it resembles my code
now. Most is still a shambles.

And you forgot the stuff about the attributes and properties.

I don't do the deep analysis, the code fixing, or the

Deep analysis? That method is two dozen lines long and I dissected it
for you once. Who does the "code fixing?" Nobody from what I have
seen.

testing, but I can help the process along where possible.

Don't break your arm patting yourself on the back. And when did this
become the point of this discussion?

But I'm not
going to spend lots of time analyzing and trying to explain code.
There are better uses of my time.

I didn't ask you to explain code. I asked you to explain, in simple
terms, what the attr method is supposed to do. For a well-documented,
well-supported effort like jQuery, that should be a snap for you or
anyone. Certainly it is crucial to know.

It's a trick question. The thing is so monstrously convoluted and
broken that the only explanation would be very long-winded (see my
initial assessments) and prove beyond a shadow of a doubt that jQuery
does not smooth out differences between browsers (it does the exact
opposite in many cases.) Furthermore, it inhibits understanding of
simple and critical concepts like DOM properties vs. attributes. Even
worse, the API can't really be changed at this point, so it will be
hard to break it up without breaking lots of existing code.