Javascript Library

[Brian Adkins]

It was intended to be obviously unreasonable.

Thank you for your honesty.

YUI and other libraries

Care to name even one in addition to YUI. Don't worry about
requirements, specs, contexts. Since YUI is the only one folks have
offered up, I'm just curious if another exists. Even a small one
that's used by more than a handful of people would be good.

I was being an ass
Agreed.

Perhaps "valuable, time saving libraries" are readily available in the
Common Lisp world but not in the JavaScript world.

Gee, do you think that's the question I've been vainly trying to get
answered? But Peter, how can you make that conjecture without a spec,
requirement or context? That's a joke - don't answer it.

Somewhere communication has broken down.
Yes.

It seems you think you have
clearly stated your library specs.

Peter, only an idiot would think that I had clearly stated "library
specs", or more importantly that it was my intention to do so, so I
must assume that you consider me an idiot. There will be no Christmas
card forthcoming.

How can you miss something so simple? I am^H^Hwas simply trying to get
a feel for which "preexisting code written by people other than me" is
worthwhile to consider using in future projects before I reinvent the
wheel myself. Does that make sense to you? It makes sense to others.
Does it seem like a reasonable quest? It does to others.

Really - ask some people at your workplace as a poll. This group is
biased beyond hope at this point. Just ask them, "Hey, some guy on
comp.lang.javascript asked whether there were any publicly available
JavaScript libraries that were worthwhile to use. So he's an idiot,
right? I mean, he didn't even provide a spec or set of requirements
for that question! How can we possibly interpret that question without
a spec. So, really, he's an idiot, right? There was no context to
guides us or anything." Something like that. Let me know how it goes.

You've assumed people will imply
the same things you have implied in you requirements but that hasn't
appeared to be the case.

Wrong, and you know it, as you admitted with respect to your little
game with the logging code. You knew that was ridiculous, yet you
couldn't think of something that wasn't? Peter, you act as if the
question was so vague as to imply there were far too many answers to
post, and yet the only thing mentioned in hundreds of posting is that
YUI might be worth checking out. Imagine if I had provided a detailed
set of requirements - the options would have been narrowed from 1 to
0.

Currently it takes a newcomer an
unreasonably long time to gather all the information.

I wonder why that is?

 

[Doug Miller]

On Oct 30, 1:27 pm, (e-mail address removed) (Doug Miller) wrote:


But don't you think a large portion of that market would just steal
the code?

Well, sure, if you're silly enough to post it someplace where it can be
downloaded without paying for it first.

 

[Peter Michaux]

Thank you for your honesty.



Care to name even one in addition to YUI. Don't worry about
requirements, specs, contexts. Since YUI is the only one folks have
offered up, I'm just curious if another exists. Even a small one
that's used by more than a handful of people would be good.

I already offered mine and the code in the group's faq notes. Also
checkout JavaScript toolbox and Ajax Toolbox my Matt Kruse. Google
will help you find them. I don't know if any of them will be helpful
with your task at hand.

Peter, only an idiot would think that I had clearly stated "library
specs", or more importantly that it was my intention to do so, so I
must assume that you consider me an idiot. There will be no Christmas
card forthcoming.

How can you miss something so simple? I am^H^Hwas simply trying to get
a feel for which "preexisting code written by people other than me" is
worthwhile to consider using in future projects before I reinvent the
wheel myself. Does that make sense to you? It makes sense to others.
Does it seem like a reasonable quest? It does to others.

But "reasonable scope" and "any scope" have both been part of the
requirements. Its been a moving target.

People are very reluctant to give such general recommendations. There
must be a reason for being so cautious.

It seems now you've made it concrete and want to know if there is
*any* code at all worth reusing with no other requirements at all.

There is almost an infinite amount of JavaScript code available. Use
google to find code related to your task and evaluate the code if it
is worth reuse. You can at least use reuse the code educationally.

Really - ask some people at your workplace as a poll. This group is
biased beyond hope at this point. Just ask them, "Hey, some guy on
comp.lang.javascript asked whether there were any publicly available
JavaScript libraries that were worthwhile to use. So he's an idiot,
right? I mean, he didn't even provide a spec or set of requirements
for that question! How can we possibly interpret that question without
a spec. So, really, he's an idiot, right? There was no context to
guides us or anything." Something like that. Let me know how it goes.


Wrong, and you know it,

Actually I think that has been the problem.

as you admitted with respect to your little
game with the logging code. You knew that was ridiculous, yet you
couldn't think of something that wasn't?

That is how difficult the question was.

Peter, you act as if the
question was so vague as to imply there were far too many answers to
post, and yet the only thing mentioned in hundreds of posting is that
YUI might be worth checking out.

Take something from that.

Imagine if I had provided a detailed
set of requirements - the options would have been narrowed from 1 to
0.

If you had said form validation then YUI would not have been
mentioned. If you said event libraries it might.

I wonder why that is?

When new, it is difficult to even know the questions to ask. That was
a big problem for me.

I don't know if it will help with your task I think you should use YUI
for a while.

Peter

 

[beegee]

I don't know if it will help with your task I think you should use YUI
for a while.

I have been using YUI for almost two years. I use the Tree, Panel,
Container, Menu, Event modules and at times have used the Connection
(AJAX) module. They are all solid and do not obfuscate the language
like JQuery, Prototype etc. The documentation is good and the code is
so well written that tweaks to the library are easy to make. I have
used the datatable module for one project and have backed off a bit
because it is lacking in a few features that seem essential to me (the
ability to load from local XML for one).

There are two downsides to this library that I can see. One is that
if you are using many modules on a page, the load is slow although YUI
has an experimental Loader module that may help with this. The other
downside is that some of their releases have been backwardly
incompatible and though they provide extensive notes as to most of
these backward incompatibilities, it is a pain with a large site.

I have come to believe lately that there are no real helpful AJAX
libraries and that the task of cobbling together your own AJAX object
or set of functions is pretty easy and the best solution.

But hey, you want some real library nastiness, try creating javascript
proxies for .NET web services. We should all be grateful for
mootools,jquery,prototype,yui,dojo and on and on, excuse the incorrect
capitalization.

Bob

 

[Brian Adkins]

I already offered mine and the code in the group's faq notes.

I did bother to check http://www.jibbering.com/faq/ before posting and
didn't find anything. That site mentions faq_notes here:
http://www.jibbering.com/faq/faq_notes/faq_notes.html

but I didn't see your code there, nor were you listed as a
contributor, so maybe there's another set of "group's faq notes"
somewhere?

Also
checkout JavaScript toolbox and Ajax Toolbox my Matt Kruse.
Thanks

It seems now you've made it concrete and want to know if there is
*any* code at all worth reusing with no other requirements at all.

That's been that case for quite some time. I proceeded as follows:

1) it seems people here think all libraries suck
*therefore*
2) I wonder if there is *any* code that can be recommended

If the responses showed that there were many libraries worth looking
into, then I naturally would need to ask a more specific question, but
that has hardly been the case.

There is almost an infinite amount of JavaScript code available. Use
google to find code related to your task and evaluate the code if it
is worth reuse.

Peter, I don't understand why you made this statement. The purpose in
asking a question such as the one I asked is to avoid spending an
"infinite" amount of time evaluating code, but instead to attempt to
gain from the experience of others. The value of the experience of
other people can range from harmful to helpful, but it can sometimes
narrow down the search to a feasible set of candidates nonetheless.

That is how difficult the question was.

I'm still waiting for the workplace poll results

 

[Thomas 'PointedEars' Lahn]

I have been using YUI for almost two years. I use the Tree, Panel,
Container, Menu, Event modules and at times have used the Connection
(AJAX) module. They are all solid and do not obfuscate the language
like JQuery, Prototype etc. The documentation is good and the code is
so well written that tweaks to the library are easy to make. I have
used the datatable module for one project and have backed off a bit
because it is lacking in a few features that seem essential to me (the
ability to load from local XML for one).

The important question is: Could the UI features they provide generally
display without client-side script support, do they degrade gracefully?
If the answer to that is no, then they are not suited for general use.

But hey, you want some real library nastiness, try creating javascript
proxies for .NET web services.

That there is someone who does a (bad) thing even worse and therefore
the (bad) thing was good is a loser's argument, or IOW a logical fallacy.

We should all be grateful for mootools,jquery,prototype,yui,dojo and
on and on, excuse the incorrect capitalization.

No, "we" should not, with *maybe* the exception of YUI. And if you had
cared to consider the arguments already provided, you would know why.


PointedEars

 

[Peter Michaux]

I did bother to check http://www.jibbering.com/faq/ before posting and
didn't find anything. That site mentions faq_notes here:http://www.jibbering.com/faq/faq_notes/faq_notes.html

There are many code snips on those pages and on the pages to which
they link. You have to at least want to see the code for which you
search. For example, the FAQ has three functions for trimming string
whitespace without using regular expressions.

function LTrim(str) {
for (var k=0; k<str.length && str.charAt(k)<=" " ; k++) ;
return str.substring(k,str.length);
}
function RTrim(str) {
for (var j=str.length-1; j>=0 && str.charAt(j)<=" " ; j--) ;
return str.substring(0,j+1);
}
function Trim(str) {
return LTrim(RTrim(str));
}


Perhaps you have a particular format in which you need to see the code
libraries you are after. That could be baggage you carry coming from
another programming language and development style. There is no
established CPAN or PEAR for JavaScript. There is an attempt called
JSAN but that hasn't gained much traction and likely has not been
evaluated by many regulars here so has not been even a candidate for
recommendation in this thread. The baggage you carry could prevent you
from finding what you are after.

but I didn't see your code there, nor were you listed as a
contributor, so maybe there's another set of "group's faq notes"
somewhere?

There is only one set.



There is plenty in the group faq and faq notes. There is plenty in the
group archives. There is plenty on the web. There is plenty in the big
name libraries. It may not be in the finalized "library" format you
have been after at certain times in these threads but if you've
removed that requirement then there is plenty. It should be clear now
that there is not some ready made library that can be handed to the
newcomer that is "approved" for reuse in all situations. That is
either unfortunate or impossible.

That's been that case for quite some time. I proceeded as follows:

1) it seems people here think all libraries suck

They don't. They do see many flaws in the big name libraries and
prefer to use their own libraries. Some people use their own libraries
as modules they use as is and release versions to themselves. Some
people use their libraries as cut and paste resources.

*therefore*
2) I wonder if there is *any* code that can be recommended

I hope it is quite clear now that there is at least some code that can
be recommended and this question can die. The trim examples above are
enough to show there is some code that can be recommended.

If the responses showed that there were many libraries worth looking
into, then I naturally would need to ask a more specific question, but
that has hardly been the case.


Peter, I don't understand why you made this statement. The purpose in
asking a question such as the one I asked is to avoid spending an
"infinite" amount of time evaluating code

Just because there is an plethora of JavaScript on the web to evaluate
it doesn't mean you have to spend much time evaluating it. You can
look at the first few hits that google returns and that is usually
sufficient.

, but instead to attempt to
gain from the experience of others.

Much advice has been offered.

The value of the experience of
other people can range from harmful to helpful, but it can sometimes
narrow down the search to a feasible set of candidates nonetheless.


I'm still waiting for the workplace poll results

I'm not asking.

Peter

 

[RobG]

Thank you for your honesty.



Care to name even one in addition to YUI. Don't worry about
requirements, specs, contexts. Since YUI is the only one folks have
offered up, I'm just curious if another exists. Even a small one
that's used by more than a handful of people would be good.


Gee, do you think that's the question I've been vainly trying to get
answered? But Peter, how can you make that conjecture without a spec,
requirement or context? That's a joke - don't answer it.


Peter, only an idiot would think that I had clearly stated "library
specs", or more importantly that it was my intention to do so, so I
must assume that you consider me an idiot. There will be no Christmas
card forthcoming.

How can you miss something so simple? I am^H^Hwas simply trying to get
a feel for which "preexisting code written by people other than me" is
worthwhile to consider using in future projects before I reinvent the
wheel myself. Does that make sense to you? It makes sense to others.
Does it seem like a reasonable quest? It does to others.

I think your question was answered fairly quickly and thoroughly.
Peter pointed you to an existing thread, others chimed in with
opinions on major libraries within a couple of days and others
responded with their opinions of those libraries. Which goes back to
why you won't see them recommended here.

I suggest you lurk for awhile in news groups related to the libraries
you'd like to try and see if you like what you see.

Really - ask some people at your workplace as a poll. This group is
biased beyond hope at this point. Just ask them, "Hey, some guy on
comp.lang.javascript asked whether there were any publicly available
JavaScript libraries that were worthwhile to use. So he's an idiot,
right? I mean, he didn't even provide a spec or set of requirements
for that question! How can we possibly interpret that question without
a spec. So, really, he's an idiot, right? There was no context to
guides us or anything." Something like that. Let me know how it goes.

There is certainly an attitude that the standard of code in most
general libraries is not very high and that the time and effort
required to learn the library may be better spent writing a bespoke
framework. Those opinions will be supported by examples if you ask
(there are some in threads from your OP). So while you may not like
the attitude, there is a sound reason for the bias.

But don't be discouraged, the bottom line is that those who like and
use libraries are probably using news groups dedicated to those
libraries. That is because most libraries introduce their own API
that masks the underlying built-in javascript objects and methods and
the W3C DOM API, so it is a bit pointless asking questions in a
general javascript news group.

Those who are regulars here mostly don't use libraries because they
have decided not to (most probably because they don't like what's on
offer) and are therefore unlikely to recommend one.

 

[David Mark]

you could also argue that an "Ultimate Javascript Library" that I cant
have is infinitley more useless than a badly coded, in-efficient
library that I can have.

There is no such thing as an "Ultimate JavaScript Library." Clearly
you can't have what doesn't exist. However, as noted several times,
there are other options besides using code that is known to be lousy.

 

[John Resig]

Yawwwwnnnnn.... this is, quite possibly, the most inane set of
ramblings set up by someone who has obviously never created a
JavaScript library of any kind, nor has used JavaScript code in any
sort of production environment.

I'll reply to your alleged critiques to the code below.

To start with, jQuery only supports the following browsers:
- IE 6+
- Firefox 2+
- Opera 9
- Safari 2+

Anything outside that jurisdiction is not guaranteed to work. But
considering that that selection is something like 99% of all browsers
(and considering that the selection of supported browsers is "good
enough" for Google, Amazon, NBC, IBM, Oracle, etc. etc.) I think it's
safe to say that we've made a good choice.

Hardly. It is woven into many important low-level functions. Here is
a particularly stupid snippet from the get/setAttribute wrapper called
attr:

} else if ( jQuery.browser.msie && name == "style" )

return jQuery.attr( elem.style, "cssText", value );

Do you have any idea how many agents jQuery will identify as IE?

The ones we care about?

Do
you have any idea how trivial it is to properly feature detect IE's
broken get/setAttribute functionality?

Pray tell! I must've missed the boolean property that tells me that
it's broken as all get out.

Forget that for the moment, why is this function passing a style
object to itself?

The .attr() function can be a little futzy (it's long due for a
rewrite). For now, it's written this way to keep all attribute/css
special-case logic contained to a single location.

if ( jQuery.browser.msie && /href|src/.test(name) && !
jQuery.isXMLDoc(elem) )
return elem.getAttribute( name, 2 );

Just what sort of XML document runs script in IE? Certainly not an
XHTML document. Realize that this absurd line of code is evaluated
every time jQuery looks at an element's attribute.

Huh? That gets the interpreted value of an attribute, only in IE, and
only if it isn't within an XML document (and only for the href and src
attributes - which are the ones that have the specific URL-
interpretation problems).

Then there is this gem:

// Certain attributes only work when accessed via the old DOM 0 way
if ( fix[name] ) {
if ( value != undefined ) elem[fix[name]] = value;
return elem[fix[name]];

This demonstrates a stunning lack of understanding of attributes (and
IE's problems with them.) Where's the sniff (or feature detect) for
IE? This IE-specific workaround runs on everything.

This has nothing to do with being IE-specific, or not. Look at the fix
object - it contains a number of properties (both CSS and regular
attribute) that need to be re-written or defer to another attribute.
(For example, this is also used to fix cases where a user
types .attr("readonly") instead of .attr("readOnly")).

Still in the same function:

else if ( value == undefined && jQuery.browser.msie &&
jQuery.nodeName(elem, "form") && (name == "action" || name ==
"method") )
return elem.getAttributeNode(name).nodeValue;

No comment for this magic spell, so there is no telling what it is
trying to do.

The action and method attributes can be overwritten in IE, like so:
<form>
<input type="text" id="action"/>
</form>

Thus, this code handles that case and gets the correct value, special.

One thing is certain. This code will run on lots of
non-IE agents.

It only runs on the ones that we care about - but apparently this
mythical, ultra-popular, StrawMan v1.0 is all the rage these days.

if ( value != undefined ) {
if ( name == "type" && jQuery.nodeName(elem,"input") &&
elem.parentNode )
throw "type property can't be changed";
elem.setAttribute( name, value );
}

Another example of confusing attributes with properties. This is also
an IE-specific workaround with no sniff (or feature detect.)

This was done completely intentionally - we don't support dynamically
changing the type attribute on input elements, since it causes an
exception to be thrown in IE (we would rather have a consistent code
base, across all browsers that we support, than have problems arise
later for users).

And just when you think you have seen every conceivable miscue (all in
a single function mind you.)

if ( name == "opacity" && jQuery.browser.msie ) {
if ( value != undefined ) {
// IE has trouble with opacity if it does not have layout
// Force it by setting the zoom level
elem.zoom = 1;

What in God's name do opacity (and other styles) have to do with
attributes?

See above.

That's enough of that function. Keep in mind that the code therein is
called constantly by jQuery. Unfortunately for those who rely on
jQuery, it is error-prone, confused, inefficient and convoluted.

Error-prone? Doubtful. Where's your test suite-backed attribute/css
manipulation code, I'd love to see it!

Inefficient, possibly. We've already made a number of optimizations
wherever possible - but many of the checks can't be circumvented.

Convoluted - sure. As I mentioned before, it's due for a re-write.

The
design (and documentation) is of such poor quality that it is an
assault on the senses of anyone unfortunate enough to glance at it.

Sigh. Where's your ultra-documented, totally-awesome, perfect-in-every-
way JavaScript library? That's what I thought - you don't have one,
nor does one exist.

And speaking of opacity. In the curCSS function:

if (prop == "opacity" && jQuery.browser.msie) {
ret = jQuery.attr(elem.style, "opacity");
return ret == "" ? "1" : ret;

}

So any agent that identifies as IE and will be re-routed to the attr
function, which has nothing to do with style, but does contain more
sniffing and some IE-specific DirectX twiddling, which will have no
(positive) effect on non-IE agents.

See above - it works for everything that we support. We make no
illusions as to otherwise.

It would seem that querying style rules would be almost as critical to
querying attributes in a library like jQuery. Yet, in this same
function you find this gem:

// A helper method for determining if an element's values are broken
function color(a){
if ( !jQuery.browser.safari )
return false;

var ret = document.defaultView.getComputedStyle(a,null);
return !ret || ret.getPropertyValue("color") == "";

}

This is the author's idea of a feature detect for getComputedStyle.
Why Safari-like browsers are excluded is a mystery. After that
inauspicious start, it blunders into the defaultView, getComputedStyle
and getPropertyValue properties with the impunity of somebody who
hasn't got a clue as to what they are doing.

Wow. WowWowWow. Spoken like a true babe! It's damn simple to detect it
in all browsers but Safari. In Safari 2, in an element that is
display: none, getComputedStyle() returns null. In Safari 3, it
returns a style object, but within with all values return "" (which
may, or may not, be a valid return value - it's impossible to tell!).
Thus, you have to check for the existence of the computed color value
(which will always exist) and if it's empty, then we're inside a
corrupted element.

It goes on and on. From the clean function:

if ( jQuery.browser.msie ) { // String was a <table>, *may* have
spurious <tbody>
if ( !s.indexOf("<table") && s.indexOf("<tbody") < 0 )
tb = div.firstChild && div.firstChild.childNodes;

div *may* have a firstChild property.

Yes? Your point? IE can, sometimes, not auto-generate a <tbody>
wrapper (when there's no contents to the table). This verifies when a

From the same function:

// IE can't serialize <link> and <script> tags normally
jQuery.browser.msie && [1, "div<div>", "</div>"]

You have to keep in mind while reading this stuff that
jQuery.browser.msie is meaningless on the Web. It isn't of much use
on an Intranet either, unless you use the same version and
configuration of IE forever.

Huh? Show me a drastically improved version of IE and I'll show you an
updated copy of jQuery.

From merge:

// Also, we need to make sure that the correct elements are being
returned
// (IE returns comment nodes in a '*' query)
if ( jQuery.browser.msie ) {
for ( var i = 0; second; i++ )
if ( second.nodeType != 8 )
first.push(second);
} else

Same problem different function. What if some agent that doesn't
identify as IE has the same problem?

These browsers that you keep talking about must be amazing! They're,
quite literally, everywhere! At every turn there's a browser that we
support that also claims to be IE, but it isn't IE! What have we been
doing wrong all this time? How could we have been so naive?

Also note how hard it is to
follow with all of the missing brackets.

*shrug*

More madness:

var styleFloat = jQuery.browser.msie ? "styleFloat" : "cssFloat";

Obviously you should just check (or set) them both. What happens if
IE8 switches gears on this? And what of an IE-spoofing agent that
doesn't use "styleFloat?"

The same argument, over and over, is getting incredibly old. Where's
your ultra-popular library that is 100% future proof?

Considering that IE is going to be backwards compatible for, most
likely, many many years to come, I'm not worried. When the year 2031
arrives, jQuery can, and will adapt.

// Check to see if the W3C box model is being used
boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",

That could have far-reaching implications. A quick search found it in
an attempt to measure the viewport:

return this[0] == window ?
jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
Math.max(document.documentElement["client" + name],
document.body["client" + name]) ||
document.body["client" + name] :
this[0] == document ?
Math.max( document.body["scroll" + name], document.body["offset" +
name] ) :
h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
this.css( n, h.constructor == String ? h : h + "px" );

I characterized this as a "million monkey" project earlier and I want
to take a moment to apologize to monkeys everywhere. I think even a
single monkey could write a better solution to this very common
problem. Certainly there are many better solutions floating around on
the Internet.

Certainly! They are, literally, everywhere! I mean, I can't go
anywhere without tripping over a test-suite-backed, cross browser,
quirksmode-handling, browser width and height detection script.

Your "arguments" consist of nothing but assumptions dressed up as
criticism.

And boxmodel can also be observed in the positioning code:

// IE adds the HTML element's border, by default it is medium which is
2px
// IE 6 and IE 7 quirks mode the border width is overwritable by the
following css html { border: 0; }
// IE 7 standards mode, the border is always 2px
if ( msie ) {
var border = jQuery("html").css("borderWidth");
border = (border == "medium" || jQuery.boxModel &&
parseInt(version) >= 7) && 2 || border;
add( -border, -border );
}
There are so many misconceptions here it is hard to know where to
begin. Suffice to say that the clientLeft/Top properties hold the
needed information in IE.

Yes, we are well aware of the clientLeft/Top properties -
unfortunately there are edge cases where they are not sufficient
(especially when moving between standards and quirksmode).

You're definitely proving that it's much easier to make off-the-cuff
criticisms than to actually provide working, tested, cross-browser
solutions. All of which we've done, and supported, for almost 2 years
now.

In the same function:

// Mozilla and Safari > 2 does not include the border on offset
parents
// However Mozilla adds the border for table cells
if ( mozilla && /^t[d|h]$/i.test(parent.tagName) || !safari2 )
border( offsetParent );

Apparently, in the jQuery universe there is only Opera, Mozilla,
Safari and IE. IE never gets here. Opera (and Safari <= 2 if you
believe the comments) adds borders when it shouldn't. So this logic
excludes everything the author has ever heard of that isn't Opera.

Right. See above.

Speaking of Mozilla. Does this look like a good indication of Mozilla-
based browsers?

mozilla: /mozilla/.test(userAgent) && !/(compatible|
webkit)/.test(userAgent)

Why not call that the everything-under-the-sun property?

Because it's not? It captures everything that we care about.

Getting back to border issue, in the mozilla-and-newer-Safari-only
(and oddly named) border function:

add( jQuery.css(elem, "borderLeftWidth"), jQuery.css(elem,
"borderTopWidth") );

What an outrage. The author apparently never heard of clientLeft/Top.

See above.

Backing up to where boxModel was first spotted, this is deja vu:

styleFloat: jQuery.browser.msie ? "styleFloat" : "cssFloat",

Yes, this logic is repeated just three lines below the first instance.

This was already fixed in SVN:
http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1180

Moving on. In the ready function:

if ( jQuery.browser.mozilla || jQuery.browser.opera )
document.removeEventListener( "DOMContentLoaded", jQuery.ready,
false );

So if it is virtually any agent, assume there is a document object (a
fair assumption) and assume that it has a removeEventListener method
(an outrageous assumption.) Why the event listener needs to be
removed at all is another interesting question. The comments
mentioned memory leaks.

Man, why am I not using this StrawMan browser? It is, apparently, used
everywhere. Once again, if it's not in the 99% of all browsers that we
support, we don't care.

We remove the event to be tidy - if we don't need to keep it bound,
then there's no reason to waste any perfectly-good memory on it. I
don't understand why this is an issue for you. Do you prefer that
libraries keep everything bound indefinitely? Do you want them to have
high overhead and run slow?

Here is the flip-side of this in bindReady:

// If Mozilla is used
if ( jQuery.browser.mozilla || jQuery.browser.opera )
// Use the handy event callback
document.addEventListener( "DOMContentLoaded", jQuery.ready,
false );

So two of the four browsers that the author knows of are known to
support DOMContentLoaded. Of course, it wouldn't hurt to add this
listener for everything. Come to think of it, he did (unknowingly)
add it for virtually everything.

Except for half the browsers - Safari and IE. Which is not "virtually
everything".

You've got to love the comments. "Use the handy event callback" may
be the least informative one yet. Here's another interesting one from
makeArray:

// Need to use typeof to fight Safari childNodes crashes
if ( typeof a != "array" )
for ( var i = 0, al = a.length; i < al; i++ )
r.push( a );
else
r = a.slice( 0 );

And why would you pass an array to a "makeArray" function anyway?

..makeArray() is designed to take any array-like object and return a
clone of itself. Thus this will work for both NodeLists and regular
arrays (for example). Note the key word there: clone - it doesn't
return the original (hence it's only used for when an array needs to
be cloned).

This reminds me of the function test code, which was blistered in
another recent "jQuery is a joke" thread.

I assume that you're referring to jQuery.isFunction(). If you have a
comparable method that's able to pass all of these tests in all modern
browsers, let me know! I'll be happy to take a look.

http://dev.jquery.com/browser/trunk/jquery/test/unit/core.js#L62

Enough is enough. If you use jQuery after reading this, you are
deserve everything you get.

Apparently, a thoroughly tested and comprehensively written JavaScript
library - who knew?

Asked and answered? I still want to know what reak-world you are
from.

Probably the same one that Google, Amazon, IBM, AOL, etc. are from.

Really? Define packed. Minified it is roughly 50K. GZIP doesn't
enter into it (unless you can't comprehend why it is silly to compare
file sizes after compression.) How small would a 20K library be after
compression? Regardless, you shouldn't manually compress JavaScript
files.

Run through Dean Edwards' Packer script. jQuery is ~14K minified +
gzipped.

[snip non-discussion]

So besides .attr() needing a rewrite (I fully admit that) - I see
absolutely no valid criticism of the library - and if anything, a
gross misunderstanding of common cross browser issues and of how test
driven development works.

Let me know when you release your library, as I'd love to take a look
and see what I've been missing.

--John

 

[David Mark]

Do you think you are solving extremely unique problems?

Yes.


I assume you have assembled your low-level functions into high-level
functionality at some point, so surely you have developed enough
functionality to accomplish complex tasks. Why not post all the code
you have - even if undocumented - as a great jump-start to anyone want
to assemble those pieces into something they would find useful?

Why not stop badgering me to post all of my code and make do with what
I have posted to this point?

I think you misjudge the intent. IMO, these libraries intend to be a
solid framework that combine low-level reusable functions with an
intuitive API. They don't try to solve every problem. They give the
developer a different set of tools to use. Tools which are often more
compact, easier to use, and provide good browser abstraction.

Provide good browser abstraction? What library are you talking about?

Inserting jquery.js into a page will do nothing for you. It's just a

Isn't that the trust. In fact, it will add 50K of weight to it. As
previously noted, your packer argument doesn't hold water.

tool. You still need to write code.

How is this approach any different from your own set of low-level
functions? Libraries like jQuery just assemble the most often-used set
of tools and give them a consistent API. In under 30k of code, you

For the love of God. It is not 30K of code. It is 50K. When served
compressed by a Web server, it will likely be about 30K. Using that
ridiculous packer tool does not improve on that at all. In fact, it
may make things worse. In any case, it is ridiculous and misleading
to call a 50K minified script 30K. What do you call a 50K image
asset? Do you GZIP it and then cite the compressed size? Wouldn't
that make it hard to compare to everything else on you server?

have a large set of functionality that you know will always be
available without having to piece together various functions to do
exactly what you want. How is that bad?


Which is ridiculous. So you have nothing to really offer anyone except
bashing the solutions others are developing. Great approach!

You are a moron. Perhaps it hasn't occurred to you (or the OP) that
if you have n libraries to research and somebody pokes a hundred holes
in one of them, then your task is reduced to n - 1 libraries. You are
just upset because it happened to be the one you recommended.

I suggest you stop crying for me to hand you every line of code I ever
wrote for free. I am not a charity for challenged JavaScript coders.

 

[Matt Kruse]

Yes.

How so? You don't deal with reading/writing attributes, positioning
elements, showing/hiding objects, animating objects, ajax, etc?

Why not stop badgering me to post all of my code and make do with what
I have posted to this point?

Because you continue to say my way is stupid and your way is far
better, but you refuse to actually show your cards.
I'm calling your bluff, and you have nothing to show.

Isn't that the trust. In fact, it will add 50K of weight to it. As
previously noted, your packer argument doesn't hold water.

Packed, jQuery is 26k. That has nothing to do with compression or gzip
or anything. It's ~26,000 bytes of code. Plain text. Ascii. How is
that confusing?

You are a moron. Perhaps it hasn't occurred to you (or the OP) that
if you have n libraries to research and somebody pokes a hundred holes
in one of them, then your task is reduced to n - 1 libraries. You are
just upset because it happened to be the one you recommended.

I'm sure you could poke similar ridiculous "holes" in other libraries.
You're just an anti-library zealot who likes to complain about others
and yet has nothing to show for himself.

And on that note, I've started a discussion on the jQuery dev group
about some of the points you've made, and also some of my own
observations about the attr() function you singled out. You seem to be
unaware of some browser quirks and special cases that jQuery attempts
to address, so I wonder how well your own low-level code handles these
cases. In any case, I've recommended some alternate ways of coding
some parts and hopefully the code will only continue to improve. Much
to your dismay, I'm sure.

Matt Kruse

 

[David Mark]

How so? You don't deal with reading/writing attributes, positioning
elements, showing/hiding objects, animating objects, ajax, etc?


Because you continue to say my way is stupid and your way is far
better, but you refuse to actually show your cards.
I'm calling your bluff, and you have nothing to show.

LOL. You are obviously very desperate to see my "cards." The funny
thing is that if you actually read this newsgroup (other than threads
about JavaScript libraries), you could piece together a fair amount of
my code. You want me to put it all together in a pretty package for
you. Forget it.

Packed, jQuery is 26k. That has nothing to do with compression or gzip
or anything. It's ~26,000 bytes of code. Plain text. Ascii. How is
that confusing?

You don't get it. Packer has everything to do with compression. And
it makes the standard GZIP compression less effective. It's stupid.
Do you use it for your scripts? Does anybody of note? It is
misleading to throw this "packed" length out there. Does a 50K
minified script download any faster if it is "packed" to 30K? Of
course not. It may in fact download slower. So it is stupid to use
it as a comparison. jQuery is 50K. Prototype is 80K. A 20K image is
20K. A 10K HTML page is 10K. HTTP and/or modems will compress these
assets during delivery, but most people (and tools) disregard that
when figuring page weights. A meaningful comparison requires all
things equal.

I'm sure you could poke similar ridiculous "holes" in other libraries.
Ridiculous?

You're just an anti-library zealot who likes to complain about others
and yet has nothing to show for himself.

You sound desperate. Why don't you use your own "toolkit" and stop
trying to wheedle code out of me.

And on that note, I've started a discussion on the jQuery dev group
about some of the points you've made, and also some of my own
observations about the attr() function you singled out. You seem to be
unaware of some browser quirks and special cases that jQuery attempts
to address, so I wonder how well your own low-level code handles these

Wrong. Apart from library threads, do you read this group at all? I
know all too well what they were trying to do and not only did they
botch it, but their comments indicate they have no idea what they were
doing or why.

cases. In any case, I've recommended some alternate ways of coding

In other words, you took all of my suggestions and ran with them. I
am sure the jQuery group will be eternally grateful for "your"
vigilence. Now you want more help. I would give your toolkits the
treatment, but I don't specifically want to help you and I know they
have already been panned ad nauseum here.

some parts and hopefully the code will only continue to improve. Much
to your dismay, I'm sure.

Why would I care?

 

[Matt Kruse]

Probably the same one that Google, Amazon, IBM, AOL, etc. are from.

I think this is a point that needs to be made again -

If your arguments are that:
1) Large "do-everything" libraries are a bad design decision and the
wrong way to develop javascript for public sites
and/or
2) Limiting "officially" supported browsers to a subset of all
browsers that cover all but the most fringe users is a bad decision
and/or
3) Writing generalized functions that solve common problems in most
contexts and applying them liberally is a terrible, bloated,
inaccurate way to write code

then you are calling some of the biggest players on the web idiots.
The arguments I'm presenting here are not just those of some random
developer on the web - these are some of the same arguments used by
Google, Yahoo, Amazon, etc, etc when they develop their own public
sites. To call my arguments in favor of using libraries stupid is to
also call all these other sites stupid for making similar decisions.
And these are sites making millions and billions of dollars on what
you consider to be "bad design decisions"!

And in spite of all this, you claim to have a better way... the
"right" way. Yet you won't post up your code to prove to everyone that
you have truly found something superior. You know what they say,
"extraordinary claims require extraordinary evidence". If you are to
claim that you have found a better way than all of these sites that
employee extremely intelligent people and have billions of dollars to
throw at development, then you need to either prove it to the world or
continue looking like an arrogant idiot. IMO.

Matt Kruse

 

[Brian Adkins]

I think this is a point that needs to be made again -

If your arguments are that:

Matt, in my newsreader it appears you've quoted John, but you're
addressing David with your comments, right? Just wanted to clarify.

 

[Matt Kruse]

Matt, in my newsreader it appears you've quoted John, but you're
addressing David with your comments, right? Just wanted to clarify.

Yeah, sorry, John quoted David and if there was an attribution it
didn't come through in my Google Groups reply. My comments were
directed towards David, not John.

Matt Kruse

 

[Yehuda Katz]

LOL. You are obviously very desperate to see my "cards." The funny
thing is that if you actually read this newsgroup (other than threads
about JavaScript libraries), you could piece together a fair amount of
my code. You want me to put it all together in a pretty package for
you. Forget it.





You don't get it. Packer has everything to do with compression. And
it makes the standard GZIP compression less effective. It's stupid.
Do you use it for your scripts? Does anybody of note? It is
misleading to throw this "packed" length out there. Does a 50K
minified script download any faster if it is "packed" to 30K? Of
course not. It may in fact download slower. So it is stupid to use
it as a comparison. jQuery is 50K. Prototype is 80K. A 20K image is
20K. A 10K HTML page is 10K. HTTP and/or modems will compress these
assets during delivery, but most people (and tools) disregard that
when figuring page weights. A meaningful comparison requires all
things equal.

The reason we care about 20k vs. 50k when we typically could care less
about such small libraries (what's the size of the C standard
library?) is because the open web involves downloading files from
central servers over (sometimes) slow connections. As a result
*download* size is actually the relevant size.

When minified and gzipped, jQuery is 14k. That is the number of bytes
a browser will need to get from a remote server in order to use
jQuery. It ungzips the files using a native decompressor (as opposed
to the packer, which must be run in JavaScript), so the gzipping
doesn't have any noticeable performance impact. Minified/gzipped is
the correct metric when handling JS files, unless you can give me
another reason why we give a damn about the difference between 20k and
30k.

You sound desperate. Why don't you use your own "toolkit" and stop
trying to wheedle code out of me.




Wrong. Apart from library threads, do you read this group at all? I
know all too well what they were trying to do and not only did they
botch it, but their comments indicate they have no idea what they were
doing or why.


In other words, you took all of my suggestions and ran with them. I
am sure the jQuery group will be eternally grateful for "your"
vigilence. Now you want more help. I would give your toolkits the
treatment, but I don't specifically want to help you and I know they
have already been panned ad nauseum here.


Why would I care?

-- Yehuda Katz

 

[Peter Michaux]

To start with, jQuery only supports the following browsers:
- IE 6+
- Firefox 2+
- Opera 9
- Safari 2+

Anything outside that jurisdiction is not guaranteed to work.

But considering that that selection is something like 99% of all browsers

Web browser statistics have been claimed to be useless many times on
this newsgroup. I didn't claim that but I need to recognize that claim
before the following.

The w3schools site posts their statistics

http://www.w3schools.com/browsers/browsers_stats.asp

The browser subset you stated above is a maximum of 94.2%.

There was no automatic upgrade from FF1.5 to FF2.0 and all FF releases
have been lumped into the 35.4% for FF. Conservatively I would guess
that 10% of FF users are still on versions before FF2. I still have
friends using IE5 on Mac so I think many people using FF may not even
know that FF2 has been released. Think about parents who's children
installed FF for them a while ago. So now we are down to 84.2% in your
browser subset.

Safari and Opera versions are similarly lumped so I'll knock off 0.75%
there. We are down to 83.45%.

I'm going to assume that w3schools stats are based on substrings of
navigator.userAgent. We also need to subtract all the browsers that
have navigator.userAgent strings that the w3schools site is
misinterpreting to fall into your subset. For example, I'm told that
some cell phones claim to be in the IE6+ group but have very old
JavaScript capabilities. I don't have much confidence here but I'll
knock off 3.45% which leaves us at an even 80%. This is all very ball
park but even 85% is not close to 99%, in my opinion.

The w3schools site is a site for people interested in technology. On a
site about tomato soup, charity, travel or banking I would imagine the
percentage is substantially lower. It could be as low as 70%. That is
way too low and even if it is 85% that is still too low to call a
success. It is low enough to declare it a complete failure to write a
script applicable to the general web. jQuery might be fine for an
application behind a login but not for the general web.

Even if these statistics are way off, do you still think that your
browser subset represents 99% of all browsers? I don't.

Considering jQuery uses navigator.userAgent sniffing, there will
likely be problems in what now looks like a reasonably sized chunk of
the browsers out there. So what happens with a jQuery site that is
used outside the supported browser subset? A real problem occurs when
a script starts down an execution path and part way along the script
fails. If DOM manipulations are involved the page could be left in
some mangled state that is useless. This is more likely to happen then
not as the bulk of unsupported browsers will be just a little older
and only a little less capable than the supported browsers. Does
jQuery have features to help avoid this important problem?

(and considering that the selection of supported browsers is "good
enough" for Google, Amazon, NBC, IBM, Oracle, etc. etc.) I think it's
safe to say that we've made a good choice.

I don't think that is a strong argument at the very least from a
professional pride point of view. I use and like many pages from
google but their scripts throw many errors and screw up all the time
in FF2. If just dollars matter then it is a fine argument in some
peoples judgment but a colossal loss to others that would made enough
money to survive had they used no JavaScript at all. Regardless of
dollars, we are mainly having a discussion about library code quality
here.

Peter

 

[David Mark]

Yawwwwnnnnn.... this is, quite possibly, the most inane set of
ramblings set up by someone who has obviously never created a
JavaScript library of any kind, nor has used JavaScript code in any
sort of production environment.

Wrong on all counts.

I'll reply to your alleged critiques to the code below.

To start with, jQuery only supports the following browsers:
- IE 6+
- Firefox 2+
- Opera 9
- Safari 2+

Which is why it is amazing that it has to resort to browser sniffing.
Of course, it likely won't wory very well in say IE8, Opera 10,
Firefox 3, etc.

Anything outside that jurisdiction is not guaranteed to work. But
considering that that selection is something like 99% of all browsers
(and considering that the selection of supported browsers is "good
enough" for Google, Amazon, NBC, IBM, Oracle, etc. etc.) I think it's

Google as an example?! The worst JavaScript developers in history?
Same goes for Amazon. Whatever you support, you shouldn't have to
parse the userAgent string to support it. That was clear 10 years
ago. Where have you been?

safe to say that we've made a good choice.





The ones we care about?

So your library is inappropriate for a site on the public Internet?

Pray tell! I must've missed the boolean property that tells me that
it's broken as all get out.

You simply not thinking.

The .attr() function can be a little futzy (it's long due for a
rewrite). For now, it's written this way to keep all attribute/css
special-case logic contained to a single location.

It is a crock any way you slice it.

Huh? That gets the interpreted value of an attribute, only in IE, and
only if it isn't within an XML document (and only for the href and src
attributes - which are the ones that have the specific URL-
interpretation problems).

Just like I said. Every time through it is interpreted. You don't
"know" it is IE until you test that useless msie property. And the
question remains: what sort of XML document runs script in IE?

Then there is this gem:

// Certain attributes only work when accessed via the old DOM 0 way
if ( fix[name] ) {
if ( value != undefined ) elem[fix[name]] = value;
return elem[fix[name]];

This demonstrates a stunning lack of understanding of attributes (and
IE's problems with them.) Where's the sniff (or feature detect) for
IE? This IE-specific workaround runs on everything.

This has nothing to do with being IE-specific, or not. Look at the fix
object - it contains a number of properties (both CSS and regular
attribute) that need to be re-written or defer to another attribute.
(For example, this is also used to fix cases where a user
types .attr("readonly") instead of .attr("readOnly")).

And that has everything to do with IE. The fact that you don't
realize that speaks volumes. Do you even understand what the problem
is with get/setAttribute in IE?

The action and method attributes can be overwritten in IE, like so:
<form>
<input type="text" id="action"/>
</form>

Thus, this code handles that case and gets the correct value, special.

Your magic spell is botched. Did it occur to you detect when
attributes are mistakenly treated as properties (hint #2 on that
subject) and then to test getAttributeNode before blindly inferring
its existence from a useless flag?

It only runs on the ones that we care about - but apparently this
mythical, ultra-popular, StrawMan v1.0 is all the rage these days.

What does that mean? There are hundreds of agents in use today that
identify as IE and any Website that uses your script will break them.

This was done completely intentionally - we don't support dynamically
changing the type attribute on input elements, since it causes an
exception to be thrown in IE (we would rather have a consistent code

Read your code again. It causes an exception under some circumstances
and other problems under other circumstances. Your parentNode test is
incorrect. Try using that code to create a new radio button and you
will see what I mean.

base, across all browsers that we support, than have problems arise
later for users).

Oddly enough, I don't have any trouble setting the type attribute for
input elements, dynamically created or not. Of course, to do this you
have to go back and re-think your strategy concerning finding a
boolean flag that will alert you to IE's botched attribute handling.

See above.

See what above? A tangled mess?

Error-prone? Doubtful. Where's your test suite-backed attribute/css
manipulation code, I'd love to see it!

I bet you would. My test suite covers quite a few more agents than
yours. And of course, I don't have to worry too much about ones I
don't use or future revisions as I don't employ browser sniffing. See
how that works?

Inefficient, possibly. We've already made a number of optimizations
wherever possible - but many of the checks can't be circumvented.

The whole structure is rotten. It's only 80K. Why not tear it down
and rewrite it?

Convoluted - sure. As I mentioned before, it's due for a re-write.

The whole thing, right?

Sigh. Where's your ultra-documented, totally-awesome, perfect-in-every-
way JavaScript library? That's what I thought - you don't have one,
nor does one exist.

That is the Matt Kruse school of baiting. I am not going to help you
rewrite your library any more than I already have. Sorry.

See above - it works for everything that we support. We make no
illusions as to otherwise.

But many delusions as to why you need to support only five browsers
and why you need to sniff the userAgent string to do it.

Wow. WowWowWow. Spoken like a true babe! It's damn simple to detect it

You come off as an idiot.

in all browsers but Safari. In Safari 2, in an element that is
display: none, getComputedStyle() returns null. In Safari 3, it

That problem is not limited to Safari.

returns a style object, but within with all values return "" (which

Not in Windows Safari 3. Regardless, I was referring to something
else entirely. It looks like you do have a feature detect for
getComputedStyle, but the section of code is so convoluted that I
missed it. Adjusted score is about negative a million plus one.

Also, the handling of this issue is typically inept. You should never
try to query the computed style of an element that isn't part of the
layout. Barring (!important) user style sheet overrides, calling
programs should be aware when an element is part of the layout and
when it is not. All of those hoops you are going through to display
parentNodes (with an arbitrary rule no less) is a waste of time.
You've got much bigger and more important problems.

may, or may not, be a valid return value - it's impossible to tell!).
Thus, you have to check for the existence of the computed color value
(which will always exist) and if it's empty, then we're inside a
corrupted element.




Yes? Your point? IE can, sometimes, not auto-generate a <tbody>

You missed the point completely. The general theme is feature
detection (and the lack thereof.) I didn't spell everything out for
you as this was not a support request ticket. Look a couple of lines
down from that and find:

for ( var n = tb.length-1; n >= 0 ; --n )

This assumes that tb was actually set to something. What if the agent
had no firstChild property? Certainly many agents that identify as IE
fall into that category. Isn't this script supposed to make it easier
to build a Website? Seems odd that it is completely unsuitable for
the Internet.

wrapper (when there's no contents to the table). This verifies when a
<table></table> is passed in makes sure that a tbody is constructed.
Again, everything here is backed by a test suite.

But even if it aces your limited tests, it is still unsuitable for
building Web applications. So what is it good for?

// IE can't serialize <link> and <script> tags normally
jQuery.browser.msie && [1, "div<div>", "</div>"]

You have to keep in mind while reading this stuff that
jQuery.browser.msie is meaningless on the Web. It isn't of much use
on an Intranet either, unless you use the same version and
configuration of IE forever.

Huh? Show me a drastically improved version of IE and I'll show you an
updated copy of jQuery.

What does that mean? If you had written it right to begin with, you
wouldn't have to go back and rewrite it every time a new version is
released. And the other browsers you support are updated constantly.
Any way you slice it, people that rely on your code are actually
relying on you. That is a scary thought as you clearly don't know the
first thing about JavaScript, let alone browser scripting.

// Also, we need to make sure that the correct elements are being
returned
// (IE returns comment nodes in a '*' query)
if ( jQuery.browser.msie ) {
for ( var i = 0; second; i++ )
if ( second.nodeType != 8 )
first.push(second);
} else

Same problem different function. What if some agent that doesn't
identify as IE has the same problem?

These browsers that you keep talking about must be amazing! They're,
quite literally, everywhere! At every turn there's a browser that we
support that also claims to be IE, but it isn't IE! What have we been
doing wrong all this time? How could we have been so naive?

You read it backwards apparently. The point is that the problem may
exist in browsers that are NOT IE. Why make stupid assumptions? Here
is that portion of the code:

if ( jQuery.browser.msie ) {
for ( var i = 0; second; i++ )
if ( second.nodeType != 8 )
first.push(second);
} else
for ( var i = 0; second; i++ )
first.push(second);

What's wrong with that picture? I don't mean the missing brackets
that make it nearly impossible to follow and easy to foul up during
the inevitable maintenance.

*shrug*

That captures the essence of your code and comments perfectly.

The same argument, over and over, is getting incredibly old. Where's
your ultra-popular library that is 100% future proof?

The difference between you and me is that I don't give away code for
beer money donations. Get it? And I gave you the answer to that
one. So why not get rid of at least that one browser sniff. Do you
really need to peek at my style functions to do this?

Considering that IE is going to be backwards compatible for, most
likely, many many years to come, I'm not worried. When the year 2031
arrives, jQuery can, and will adapt.

It is absurd to think the jQuery will be around even a few more years,
let alone decades.

// Check to see if the W3C box model is being used
boxModel: !jQuery.browser.msie || document.compatMode == "CSS1Compat",

That could have far-reaching implications. A quick search found it in
an attempt to measure the viewport:

return this[0] == window ?
jQuery.browser.safari && self["inner" + name] || jQuery.boxModel &&
Math.max(document.documentElement["client" + name],
document.body["client" + name]) ||
document.body["client" + name] :
this[0] == document ?
Math.max( document.body["scroll" + name], document.body["offset" +
name] ) :
h == undefined ?( this.length ? jQuery.css( this[0], n ) : null ) :
this.css( n, h.constructor == String ? h : h + "px" );

I characterized this as a "million monkey" project earlier and I want
to take a moment to apologize to monkeys everywhere. I think even a
single monkey could write a better solution to this very common
problem. Certainly there are many better solutions floating around on
the Internet.

Certainly! They are, literally, everywhere! I mean, I can't go
anywhere without tripping over a test-suite-backed, cross browser,
quirksmode-handling, browser width and height detection script.

Idiot. I posted one here not three weeks ago. It was tested on
virtually everything, all the way back to IE5/NS6 and you can be sure
that the word "userAgent" does not appear in it. It is a good idea to
read the newsgroup and its FAQ (to quote another regular's sig.)

Your "arguments" consist of nothing but assumptions dressed up as
criticism.

I don't have to assume. I have dealt with all of the same problems
that you are stumbling over.

Yes, we are well aware of the clientLeft/Top properties -
unfortunately there are edge cases where they are not sufficient
(especially when moving between standards and quirksmode).

Gibberish. If you had any idea what you were doing, you wouldn't make
patently false comments like:

"IE 7 standards mode, the border is always 2px"

Do you understand that in quirks mode there is no HTML element present
in the layout. That 2px (which is not always 2px) represents part of
the chrome. It has nothing to do with the border style of the HTML
element. You can give the HTML element a border of 200px and it will
have no affect on the layout and certainly no affect on positioning.
In quirks mode it is the BODY border that gets subtracted from the
coordinates returned by getBoundingClientRect. No magic spells are
needed when you understand what is going on. Edge cases indeed.

It is pretty clear that you don't know what you are doing, which is
why you shouldn't be doing it. Not in public anyway. The fact that
you are also snotty towards criticism comes as no surprise. Most
incompetents have the same attitude.

You're definitely proving that it's much easier to make off-the-cuff
criticisms than to actually provide working, tested, cross-browser
solutions. All of which we've done, and supported, for almost 2 years
now.

Working? Cross-browser? Hardly. If you tested, then why are you
still clueless about simple things like the effect of borders on
positioning? Try turning on HTML borders in any other of your
supported browsers and see what happens to your positioning tests.
Same goes for margins. BODY borders are more prevalent and will also
cause problems in some cases. From the above comment about "edge
cases" for "HTML borders" in quirks mode, it appears you never tested
those at all.

In the same function:

// Mozilla and Safari > 2 does not include the border on offset
parents
// However Mozilla adds the border for table cells
if ( mozilla && /^t[d|h]$/i.test(parent.tagName) || !safari2 )
border( offsetParent );

Apparently, in the jQuery universe there is only Opera, Mozilla,
Safari and IE. IE never gets here. Opera (and Safari <= 2 if you
believe the comments) adds borders when it shouldn't. So this logic
excludes everything the author has ever heard of that isn't Opera.

Right. See above.

But you still don't see why the logic and comments are senseless?
Opera (and Safari 2) are the exceptions, not the rule. The "borders-
included-in-offsets" anomaly is easy enough to feature test.
Coincidentally, I have posted examples of it in the past. They
weren't posts about jQuery, so I guess you didn't read them. Every
time a new version of Opera or Mozilla (or whatever) comes out, you've
got a lot of re-testing and (possibly re-working) to do, which can
easily introduce new bugs, which leads to more re-testing, etc. Then
the dialog pops up telling you that Firefox has a new version and do
you still think this is a good strategy? Since all of your testing is
based on browser names, what exactly will you do when Opera fixes
their border problem? Add another flag based on the version number?
You mentioned something about 2035 (or some ridiculously far off year)
earlier. How long will jQuery's browser sniffing branches be by
then? It is a rhetorical question. Obviously it will have long since
gone the way of the dodo.

Because it's not? It captures everything that we care about.

Does it indicate Mozilla? IE has spoofed Mozilla in its userAgent
string since the beginning. So is IE Mozilla? Or perhaps in the
various branches it never checks Mozilla unless it has branched away
from IE? Does any of this sound like good coding practice to you?
Variable that have meaningless names, strange twisting branches based
on a string of characters that has no relation to the terrain, adding
more branches every time a new browser version comes out, etc.? Why
would anybody do that? A better question is why would anybody rely on
somebody who does it (especially when the person refuses to listen to
the advice of those who know better.)

See above.

LOL. I think you need to see above. More "edge cases?" You have got
to be kidding. To find the border of an element, you start with
clientLeft/Top. Computing styles is the last resort for browsers that
do not support clientLeft/Top. Considering how outrageously
inefficient your style wrappers are, you would be well advised to use
the clientLeft/Top properties when they are available.

This was already fixed in SVN:http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1180

It should have been fixed before it was released.

Man, why am I not using this StrawMan browser? It is, apparently, used
everywhere. Once again, if it's not in the 99% of all browsers that we
support, we don't care.

You are deluded. You don't support anywhere near 99% of all
browsers. And whether you care is not the point. Who was talking to
you?

We remove the event to be tidy - if we don't need to keep it bound,
then there's no reason to waste any perfectly-good memory on it. I
don't understand why this is an issue for you. Do you prefer that
libraries keep everything bound indefinitely? Do you want them to have
high overhead and run slow?

GC is automatic. Do you understand that a memory leak is an exception
to GC? Your comment indicated that you thought the event might leak.
What do you base that suspicion on? Do you automatically remove every
listener every time the page unloads, just in case it might cause a
memory leak?

Except for half the browsers - Safari and IE. Which is not "virtually
everything".

Not IE? Are you sure? Last I checked, IE spoofed Mozilla. I think
it was about ten years ago. I doubt it has changed.

You've got to love the comments. "Use the handy event callback" may
be the least informative one yet. Here's another interesting one from
makeArray:

// Need to use typeof to fight Safari childNodes crashes
if ( typeof a != "array" )
for ( var i = 0, al = a.length; i < al; i++ )
r.push( a );
else
r = a.slice( 0 );

And why would you pass an array to a "makeArray" function anyway?

.makeArray() is designed to take any array-like object and return a
clone of itself. Thus this will work for both NodeLists and regular
arrays (for example). Note the key word there: clone - it doesn't
return the original (hence it's only used for when an array needs to
be cloned).

You should try coming up with logical names for your functions. You
notice you how had to explain what that function did?

Regardless, you can't see what is wrong with this line?

if ( typeof a != "array" )

What (in any JavaScript implementation) will evaulate that to false?
What is an array in JavaScript?

I assume that you're referring to jQuery.isFunction(). If you have a
comparable method that's able to pass all of these tests in all modern
browsers, let me know! I'll be happy to take a look.

We just went over this a few weeks ago. Search the group before
posting. It might help you avoid shooting yourself in the foot next
time.

http://dev.jquery.com/browser/trunk/jquery/test/unit/core.js#L62

Test your own code.

Apparently, a thoroughly tested and comprehensively written JavaScript
library - who knew?

Nobody knew that, though some thought they did.

Probably the same one that Google, Amazon, IBM, AOL, etc. are from.

Again with the Google and Amazon (and AOL?!) nonsense. Is that
supposed to be funny?

Run through Dean Edwards' Packer script. jQuery is ~14K minified +
gzipped.

Which would imply that packer does a worse job than GZIP, so it should
not be used. And of course, GZIP doesn't factor into page weight
comparisons. The server might GZIP it, it might not. All things
equal, it is a 50K script minified.

[snip non-discussion]

So besides .attr() needing a rewrite (I fully admit that) - I see
absolutely no valid criticism of the library - and if anything, a

You are blind. Others certainly did. Even the jQuery fanboy Matt
Kruse agreed with enough of it to open up tickets on your site. I
wondered where he got the idea that you knew better about some of this
stuff as I didn't realize you were nuts enough to actually post a
retort here. When I saw that Matt "re-printed" one of his earlier
responses to you, I couldn't believe my eyes. I knew it would be a
bunch of clueless nonsense, but this exceeded my expectations by far.

gross misunderstanding of common cross browser issues and of how test
driven development works.

Let me know when you release your library, as I'd love to take a look
and see what I've been missing.

I bet you would like to crib from me. And who said I was releasing a
public general-purpose JavaScript library? Seems to me I said just
recently that I would never do that (much to the chagrin of several
people in this thread.) Apparently you don't read before you post.

 

[David Mark]

The reason we care about 20k vs. 50k when we typically could care less
about such small libraries (what's the size of the C standard
library?) is because the open web involves downloading files from
central servers over (sometimes) slow connections. As a result

No kidding.

*download* size is actually the relevant size.

Not for easy comparison to other Web assets it isn't. You would have
to GZIP everything by hand to level the field and then measure. And
of cousse, compression is not guaranteed.

When minified and gzipped, jQuery is 14k. That is the number of bytes

You just made my argument for me. Using Packer will slow things down.

a browser will need to get from a remote server in order to use
jQuery. It ungzips the files using a native decompressor (as opposed
to the packer, which must be run in JavaScript), so the gzipping

No kidding. Another reason that nobody (sane) uses Packer.

doesn't have any noticeable performance impact. Minified/gzipped is
the correct metric when handling JS files, unless you can give me
another reason why we give a damn about the difference between 20k and
30k.

What is 20K? The difference is between 14K and 50K. The former is
not useful for comparisons, unless you manually GZIP everything you
want to compare it to. Wouldn't that be particularly stupid when
comparing JavaScript files? They will all compress at roughly the
same rate (when and if compression has been successfully negotatied
during the request), so the ratios of the uncompressed versions will
be roughly equivalent to the ratios of the compressed versions.