Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > New jQuery announced!

Reply
Thread Tools

New jQuery announced!

 
 
David Mark
Guest
Posts: n/a
 
      12-07-2009
But it has the same old attr method.

attr: function( elem, name, value ) {

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

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


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

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


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


It's the do-everything function.


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


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


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


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

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

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


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


What?!

if ( elem.nodeType === 1 ) {

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


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


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

Mystical incantation.

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

Read its property?

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

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


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

Misguided waste of space.

elem[ name ] = value;
}

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


That article is very confused.


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

That's a string.


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

That's a number.


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


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


return elem[ name ];
}

Then it switches gears to attributes.

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

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


}
return elem.style.cssText;
}

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


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


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


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

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

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

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

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

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

More than they know.


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

This will vary across IE versions and modes.

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


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


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

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

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

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

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

// Technique from Juriy Zaytsev

I guess they didn't read the article.

// http://thinkweb2.com/projects/protot...wser-sniffing/
var eventSupported = function( eventName ) {
var el = document.createElement("div");
eventName = "on" + eventName;

var isSupported = (eventName in el);

Spotty inference. Keeps IE out of the following:-

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

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

}
el = null;

return isSupported;
};
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      12-07-2009
On Dec 7, 11:59*am, David Mark <(E-Mail Removed)> wrote:
> But it has the same old attr method. *


And a new removeAttr "companion" method!

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

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

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

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

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

After three years of testing and discussion, how can these bugs exist
so deep in the core? The only answer is that the authors and
community have failed to live up to their press clippings. The
revered unit tests are obviously flawed to the point of being useless
(not surprising as they were written by the same people who wrote the
code). Same for the docs. You just can't test or document what you
don't understand. But when things go wrong, you can always blame the
browsers, users, etc. Those heroic Ninjas are doing the best they
can.
 
Reply With Quote
 
 
 
 
Matt Kruse
Guest
Posts: n/a
 
      12-07-2009
On Dec 7, 3:59*pm, David Mark <(E-Mail Removed)> wrote:
> removeAttr(el, 'colspan'); // Boom


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

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


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

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

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

Matt Kruse

 
Reply With Quote
 
Michael Haufe (\TNO\)
Guest
Posts: n/a
 
      12-07-2009
On Dec 7, 4:33*pm, Matt Kruse <(E-Mail Removed)> wrote:

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


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

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


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

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


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

 
Reply With Quote
 
Michael Haufe (\TNO\)
Guest
Posts: n/a
 
      12-07-2009
On Dec 7, 5:04*pm, "Michael Haufe (\"TNO\")"
<(E-Mail Removed)> wrote:

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


correction: "method library" -> "method of that library"
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-07-2009
On Dec 7, 5:33*pm, Matt Kruse <(E-Mail Removed)> wrote:
> On Dec 7, 3:59*pm, David Mark <(E-Mail Removed)> wrote:
>
> > removeAttr(el, 'colspan'); // Boom

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


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

And you do understand that this is but one example.

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

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


See above.

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


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

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

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

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

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

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

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


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

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

I think that about says it. Feel free to silently skulk off.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-07-2009
On Dec 7, 6:04*pm, "Michael Haufe (\"TNO\")"
<(E-Mail Removed)> wrote:
> On Dec 7, 4:33*pm, Matt Kruse <(E-Mail Removed)> wrote:
>
> > Why would you do this, other than to break things?

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


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

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

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


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

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

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


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

It's not enough you have to put up with bugs and constant revisions,
but you must be positively obsequious to deluded neophytes just to get
them to field questions. Then their answers are invariably and
predictably of the **** variety. Seems a very rough way to go, mostly
taken by those without an alternative.
 
Reply With Quote
 
RobG
Guest
Posts: n/a
 
      12-08-2009
On Dec 8, 8:33*am, Matt Kruse <(E-Mail Removed)> wrote:
> On Dec 7, 3:59*pm, David Mark <(E-Mail Removed)> wrote:
>
> > removeAttr(el, 'colspan'); // Boom

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


To test the code?

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

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


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


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


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

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


--
Rob
 
Reply With Quote
 
rf
Guest
Posts: n/a
 
      12-08-2009
RobG wrote:
> On Dec 8, 8:33 am, Matt Kruse <(E-Mail Removed)> wrote:
>> On Dec 7, 3:59 pm, David Mark <(E-Mail Removed)> wrote:
>>
>>> removeAttr(el, 'colspan'); // Boom

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

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


Perhaps the function should be called
removeSomeAttrsButPotLuckWhichOnes.


 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      12-08-2009
On Dec 7, 8:16*pm, "rf" <(E-Mail Removed)> wrote:
> RobG wrote:
> > On Dec 8, 8:33 am, Matt Kruse <(E-Mail Removed)> wrote:
> >> On Dec 7, 3:59 pm, David Mark <(E-Mail Removed)> wrote:

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

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

>
> > To test the code?

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

>
> Perhaps the function should be called
> removeSomeAttrsButPotLuckWhichOnes.


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

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

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

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

The second line is obviously the right host method call.

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

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

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

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

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

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

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

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

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

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

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

The attr method tangles up properties, attributes _and_ style.

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

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

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

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

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Microsoft expanding it use of jQuery & involvement with jQuery lorlarz Javascript 6 03-25-2010 10:14 PM
jQuery Query about comparing jQuery references Aaron Gray Javascript 20 07-27-2008 01:53 PM
JQuery and ASP.NET. shapper ASP .Net 0 11-21-2007 11:45 PM
jquery .js file = windows authentication dialogue? Darrel ASP .Net 2 11-12-2007 01:35 PM
Anyone using JQuery witth ASP.net? darrel ASP .Net 2 09-06-2007 01:22 PM



Advertisments