Nice try (seriously) in your recent attempt to educate John Resig
about his own attr/removeAttr methods.
It's even worse than I thought. I always wondered what the logic in
the "crown jewel" (and only reason for existence) CSS selector query
engine. I remembered that it didn't actually call attr, but it
actually might have been better off doing so.
CLASS: function(elem, match){
return (" " + (elem.className || elem.getAttribute("class")) + "
").indexOf( match ) > -1;
Focus on this bit:-
(elem.className || elem.getAttribute("class"))
If elem.className === '' the first is falsy, so the second is
consulted. There are two possible results for the second: '' and
null. Results will vary according to browser and mode.
- IE6/7 and 8 in compatibility mode always return ''
- IE8 in standards mode will return null if the attribute is missing
or '' if it is empty.
- Previous applies to other quasi-standards based browsers.
So, an element like this:-
<div></div>
....will produce a test like this:-
return (" null ").indexOf( match ) > -1;
....in some browsers and modes.
Of course, if Resig and co. understood how attributes and properties
work, they would know that this:-
(elem.className || elem.getAttribute("class"))
....is much better written as:-
elem.className
It's simpler, more concise, actually works cross-browser, etc. Of
course, the second part may be a perverse attempt to support XML, but
that's as maybe. They really need to figure out HTML first.
},
ATTR: function(elem, match){
var name = match[1],
result = Expr.attrHandle[ name ] ?
Expr.attrHandle[ name ]( elem ) :
elem[ name ] != null ?
elem[ name ] :
elem.getAttribute( name ),
value = result + "",
There it is. The selector engine is broken too and incompatible
with... everything. XPath and QSA are popular alternate approaches
(IIRC, jQuery and/or "Sizzle" uses the latter). Neither of those will
work anything like this.
elem[ name ] != null
That's everything but null or undefined. So property values that are
neither end up converting this to a string:-
elem[ name ]
....which could end up as "true" or "function anonymous() { ... }" or
"[object CSSStyleDeclaration]" or whatever.
On the contrary, properties that are non-existent or have null values
end up converting:-
elem.getAttribute( name )
....which, as (hopefully) everyone knows by now is a crap shoot. Here
the converted "result" will either be "null" or "undefined" or the
value of a custom attribute (which may well be "null" or
"undefined"). I'm sure that won't cause any confusion.
In conclusion, results for attribute-related queries would make decent
seeds for random number generators. I assume the answer can't be
"don't use those" as they've gone to "great" pains to "support" them
over the years. Are they all blind or mad? And how can they demand
examples in the face of such obviously incorrect logic?
Here's more madness:-
enabled: function(elem){
return elem.disabled === false && elem.type !== "hidden";
},
Sure, hidden inputs are always disabled. We needed that smoothed
over.
disabled: function(elem){
return elem.disabled === true;
},
checked: function(elem){
return elem.checked === true;
},
Wrong. That includes user input. But they'll never be able to change
it at this point.
selected: function(elem){
// Accessing this property makes selected-by-default
// options in Safari work properly
elem.parentNode.selectedIndex;
return elem.selected === true;
},
LOL. There's _that_ again. Look at what it says: "selected-by-
default". Sure sounds like they are after the defaultSelected
property, which reflects the presence or absence of the SELECTED
attribute. Or maybe they just have no clue what they want at all
(that's my guess at this point).
And I wonder how well that incantation will work if the option is in
an OPTGROUP. Poorly I assume, but then it likely doesn't do anything
anyway.
So how could you possibly trust any script from these people, let
alone something as convoluted and confused as jQuery? It's not even a
stationery target as they keep "optimizing" (changing the logic) and
introducing bizarre "overloading" like using attribute names to call
jQuery methods.
I can understand how code monkeys can look at sites built with jQuery
(in a few browsers) and protest that it "just works" and any perceived
gaps in its internal logic must be imagined. But any programmer knows
such an unpredictable and illogical interface is poison (particularly
for browser scripting). Working on an app with this thing, I would
cringe changing even one attr call or query, let alone "upgrading" the
library.