D
David Mark
White on black with blue links. Well, turns out they aren't links.
The blue underlined text can't be clicked as some unfortunately
positioned tooltips fade in over top of them (and sometimes partially
off-screen).
* Lightweight Footprint
* CSS3 Compliant
* Cross-browser
The first point it meaningless without context. Compared to starting
with nothing, it's 70K of extra baggage.
The latter two points are simply false. They are qualified by the
tooltips as "Supports CSS 1 - 3 Selectors and More!" and a list of
selected browsers (so by definition, not cross-browser). Hard to
believe they had the gall to include IE in that list.
I'll just focus on one method this time as I'm tired of reading their
bullshit. This is attr's opposite:-
removeAttr: function( name, fn ) {
return this.each(function(){
jQuery.attr( this, name, "" );
if ( this.nodeType === 1 ) {
this.removeAttribute( name );
}
});
},
Same old confused nonsense. Can the documentation shed any light?
".removeAttr( attributeName ) Returns: jQuery"
Seems like they all return jQuery.
"Description: Remove an attribute from each element in the set of
matched elements.
version added: 1.0
..removeAttr( attributeName )"
No indication of what an attributeName might be. Oh wait, here it
is:-
"attributeName
An attribute to remove."
I find it hard to believe that it's an attribute. More likely a
string.
"The .removeAttr() method uses the JavaScript removeAttribute()
function, but it has the advantage of being able to be called directly
on a jQuery object and it accounts for different attribute naming
across browsers."
There's no such thing as a "JavaScript removeAttribute() function".
There is a DOM method, but the DOM has nothing to do with Javascript
(or any language). Got to figure the standard DOM method is better
documented than this thing.
And what of these alleged advantages? Calling it "directly on a
jQuery object" would seem like a 70K negative, considering the method
is available on element objects. Oh wait, I forgot the loop!
As for accounting for "different attribute naming across browsers", it
is clear that it does nothing of the sort.
The first line inside the loop is:-
jQuery.attr( this, name, "" );
That's just plain wrong. Setting a property or attribute of an
element will not remove an attribute. In fact, it might create one.
This code may throw an exception, add an attribute or change an
attribute's value, but it won't remove anything. It's purely a
mystical incantation (as is most of the attr method).
And yes, they've been told about that. These sorts of obvious
mistakes are ignored for years as voodoo code can only inspire so much
confidence. They do seem more than happy to tack on "cool" new
wrinkles at the drop of a hat though.
Then it silently fails in the case where the generic jQuery wrapper
contains something other than an element node:-
if ( this.nodeType === 1 ) {
this.removeAttribute( name );
}
That's counter-productive. If my app tried to remove an attribute
from a document node, I'd want to know about it immediately (in the
form of an exception). I don't get the feeling that the developers
have sufficient experience debugging Web applications. Otherwise they
wouldn't do things to make it harder on themselves.
And no, it didn't do anything to the name (in stark contrast to
attr). So this will do all sorts of unpredictable things in IE6/7/
Compat Mode. The documentation is simply wrong (and has been for as
long as I can remember) and the community has for years refused to fix
any of it (or even acknowledge there are problems). Considering that
"normalizing" such "offbeat" browsers as IE6/7 is one of the prime
excuses for jQuery's existence, it's hard to figure. The only theory
I have is that they don't fully understand their code, so are less
than confident to change it. They feel secure in one dark room, so
why traipse off to another?
As mentioned, there's plenty of reliable documentation for the
standard removeAttribute method. There is also reliable information
about the IE attribute problem, which has been around since at least
1999.
http://www.cinsoft.net/attributes.html
You would think that with as many reminders as the jQuery team has
received on these issues, they'd have it patched up by 2011.
But even if their rendition were perfect, would it really "simplify
DOM traversal" (from their front page) in any way? You could loop
over query results, removing an attribute of each element. Of course,
being tethered to a large, buggy, non-standard CSS selector engine can
hardly be seen as an advantage today. If you must use queries, learn
the Selectors API, stick with the basics and don't rely on it for
anything critical (as old IE users will be left out).
var el = document.getElementById('myid');
if (el) {
el.removeAttribute('onclick');
}
The test of the element reference (which may not be null for any
number of reasons) may seem like overkill in this example. Figure a
real application will have additional code in the - if - clause. As
the "myid" element is needed, it makes no sense to carry on without
it.
But if you insist on making debugging harder and the code more error-
prone, you can do chaining in JS:-
document.getElementById('myid').removeAttribute('onclick');
Too verbose? If you want to slow things down, you can write a one-
line wrapper for gEBI.
This is the sole jQuery example:-
Example:
Clicking the button enables the input next to it.
<!DOCTYPE html>
Have to use the latest cool doctype (no matter how invalid the
markup).
<html>
<head>
<script src="http://code.jquery.com/jquery-1.5.js"></script>
What a shining example for beginning developers. What's missing
there?
</head>
The HEAD isn't done.
<body>
<button>Enable</button>
That may be the worst button in history.
<input type="text" disabled="disabled" value="can't edit this" />
<script>
At least they are consistent.
$("button").click(function () {
$(this).next().removeAttr("disabled")
.focus()
.val("editable now");
});
</script>
</body>
And why so complicated? I just wanted to know how to remove an
attribute.
It's not as if this is an isolated example. As mentioned, attr is
similar voodoo. If it can't read/write/remove attributes, it's not
possible for it to simplify DOM anything (they only mention traversal,
but they likely meant manipulation as well). I've heard it argued
that these methods are irrelevant. Of course, one or both is used in
virtually every jQuery example out there. After all, setting
properties (not attributes) makes up the bulk of what most DOM scripts
do. There never was a problem with setting properties in IE (just
attributes), so jQuery created a huge problem where none existed.
And if the above is the extent of the formal documentation, you have
to wonder who keeps up the secret binder with compatibility charts
mapping the various jQuery versions to browser versions and modes.
Rather than trying to track down that elusive information (or God
forbid breaking down and testing the jQuery code), I suggest reading
the W3C's recommendation for the removeAttribute method. Know that
there is a well-known issue with some versions (and modes) of IE. See
my examples as jQuery is clearly no help in this department.
But ultimately, like a lot of things "enhanced" by jQuery (and
others), you may find you never need it. Most applications don't need
to do anything to attributes. If you find yourself setting or
removing an attribute, you are probably making a mistake and should
find the appropriate property (also listed on the W3C site).
Unfortunately, jQuery is one sort of application (a query engine) that
must at least read attributes properly.
http://www.cinsoft.net/slickspeed.html
As a quick glance in IE (particularly Compatibility mode) will tell
you, it predictably fails as a query engine. Considering the
underlying code, it would have taken a miracle to succeed. Doesn't do
much better in browsers outside those listed on jQuery's front page
either. IIRC, Sizzle (the query and lion's share of jQuery) does not
use the "advantageous" attribute methods at all. It uses its own
botched logic, which shouldn't come as any big surprise as, despite
the name and documentation, the attr method mostly returns property
values. And I'd be surprised if they improved on any of that in 1.5.
Perhaps someone else feels like testing that.
There's also the "addEvent" rendition that creates circular
references. And the "Live" thing is a mess of unwieldy hacks,
hopelessly tangled up with queries.
IIRC, passing "onclick" to attr will invoke jQuery's event methods
rather than doing anything to the attribute. So this:-
$('myid').removeAttr('onclick');
....will then do nothing. That's hardly intuitive and more
unfortunately the above will throw an exception in IE < 8 and
Compatibility Mode (due to the call to attr). They really haven't
improved on this removeAttribute thing at all. And they've done a
pretty poor job of documenting their thoughts on the matter.
And then there's the height/width methods (which attr also manages to
invoke) that make no sense, all of that ugly, over-complicated string
manipulation and RegExp abuse, incessant overloading, forgiving
interfaces, no select-one, etc., etc. Little of that has changed in
five years and much of it can't be improved due to the constraints of
the original design.
There's just no magic solution for cross-browser scripting. And if
there was, it wouldn't look anything like jQuery. I know that brings
down those who want to believe otherwise and angers those who would
sell you otherwise. But it was true five years ago and it couldn't be
more apparent today, particularly as the code is still nowhere close
to "mature" (a buzzword frequently associated with jQuery). Even the
worst sort of pessimist couldn't have predicted it would age as poorly
as it has (considering both technical and practical aspects). I think
"rotten" would be more apt at this point (and it was never fresh to
begin with).
You don't send a battery-powered mobile device a useless, complicated
and redundant 70K of junk code. Some of them won't cache it. Some
will choke on it. Virtually none will benefit from jQuery's take on
the Selectors API. Fewer still need jQuery's flailing IE hacks. It's
never been easier to write basic DOM manipulation code that runs
virtually anywhere, except for old versions of IE (and Compatibility
Mode). That's where conditional comments come in (to include
proprietary code and workarounds for old but still much-used
browsers). But jQuery can't be broken up, so now they are looking to
do for mobile what they've done for the desktop.
Are there really any takers for something that? These new devices
present much greater challenges than the old IE versions. So look
ahead five years or so...
The blue underlined text can't be clicked as some unfortunately
positioned tooltips fade in over top of them (and sometimes partially
off-screen).
* Lightweight Footprint
* CSS3 Compliant
* Cross-browser
The first point it meaningless without context. Compared to starting
with nothing, it's 70K of extra baggage.
The latter two points are simply false. They are qualified by the
tooltips as "Supports CSS 1 - 3 Selectors and More!" and a list of
selected browsers (so by definition, not cross-browser). Hard to
believe they had the gall to include IE in that list.
I'll just focus on one method this time as I'm tired of reading their
bullshit. This is attr's opposite:-
removeAttr: function( name, fn ) {
return this.each(function(){
jQuery.attr( this, name, "" );
if ( this.nodeType === 1 ) {
this.removeAttribute( name );
}
});
},
Same old confused nonsense. Can the documentation shed any light?
".removeAttr( attributeName ) Returns: jQuery"
Seems like they all return jQuery.
"Description: Remove an attribute from each element in the set of
matched elements.
version added: 1.0
..removeAttr( attributeName )"
No indication of what an attributeName might be. Oh wait, here it
is:-
"attributeName
An attribute to remove."
I find it hard to believe that it's an attribute. More likely a
string.
"The .removeAttr() method uses the JavaScript removeAttribute()
function, but it has the advantage of being able to be called directly
on a jQuery object and it accounts for different attribute naming
across browsers."
There's no such thing as a "JavaScript removeAttribute() function".
There is a DOM method, but the DOM has nothing to do with Javascript
(or any language). Got to figure the standard DOM method is better
documented than this thing.
And what of these alleged advantages? Calling it "directly on a
jQuery object" would seem like a 70K negative, considering the method
is available on element objects. Oh wait, I forgot the loop!
As for accounting for "different attribute naming across browsers", it
is clear that it does nothing of the sort.
The first line inside the loop is:-
jQuery.attr( this, name, "" );
That's just plain wrong. Setting a property or attribute of an
element will not remove an attribute. In fact, it might create one.
This code may throw an exception, add an attribute or change an
attribute's value, but it won't remove anything. It's purely a
mystical incantation (as is most of the attr method).
And yes, they've been told about that. These sorts of obvious
mistakes are ignored for years as voodoo code can only inspire so much
confidence. They do seem more than happy to tack on "cool" new
wrinkles at the drop of a hat though.
Then it silently fails in the case where the generic jQuery wrapper
contains something other than an element node:-
if ( this.nodeType === 1 ) {
this.removeAttribute( name );
}
That's counter-productive. If my app tried to remove an attribute
from a document node, I'd want to know about it immediately (in the
form of an exception). I don't get the feeling that the developers
have sufficient experience debugging Web applications. Otherwise they
wouldn't do things to make it harder on themselves.
And no, it didn't do anything to the name (in stark contrast to
attr). So this will do all sorts of unpredictable things in IE6/7/
Compat Mode. The documentation is simply wrong (and has been for as
long as I can remember) and the community has for years refused to fix
any of it (or even acknowledge there are problems). Considering that
"normalizing" such "offbeat" browsers as IE6/7 is one of the prime
excuses for jQuery's existence, it's hard to figure. The only theory
I have is that they don't fully understand their code, so are less
than confident to change it. They feel secure in one dark room, so
why traipse off to another?
As mentioned, there's plenty of reliable documentation for the
standard removeAttribute method. There is also reliable information
about the IE attribute problem, which has been around since at least
1999.
http://www.cinsoft.net/attributes.html
You would think that with as many reminders as the jQuery team has
received on these issues, they'd have it patched up by 2011.
But even if their rendition were perfect, would it really "simplify
DOM traversal" (from their front page) in any way? You could loop
over query results, removing an attribute of each element. Of course,
being tethered to a large, buggy, non-standard CSS selector engine can
hardly be seen as an advantage today. If you must use queries, learn
the Selectors API, stick with the basics and don't rely on it for
anything critical (as old IE users will be left out).
var el = document.getElementById('myid');
if (el) {
el.removeAttribute('onclick');
}
The test of the element reference (which may not be null for any
number of reasons) may seem like overkill in this example. Figure a
real application will have additional code in the - if - clause. As
the "myid" element is needed, it makes no sense to carry on without
it.
But if you insist on making debugging harder and the code more error-
prone, you can do chaining in JS:-
document.getElementById('myid').removeAttribute('onclick');
Too verbose? If you want to slow things down, you can write a one-
line wrapper for gEBI.
This is the sole jQuery example:-
Example:
Clicking the button enables the input next to it.
<!DOCTYPE html>
Have to use the latest cool doctype (no matter how invalid the
markup).
<html>
<head>
<script src="http://code.jquery.com/jquery-1.5.js"></script>
What a shining example for beginning developers. What's missing
there?
</head>
The HEAD isn't done.
<body>
<button>Enable</button>
That may be the worst button in history.
<input type="text" disabled="disabled" value="can't edit this" />
<script>
At least they are consistent.
$("button").click(function () {
$(this).next().removeAttr("disabled")
.focus()
.val("editable now");
});
</script>
</body>
And why so complicated? I just wanted to know how to remove an
attribute.
It's not as if this is an isolated example. As mentioned, attr is
similar voodoo. If it can't read/write/remove attributes, it's not
possible for it to simplify DOM anything (they only mention traversal,
but they likely meant manipulation as well). I've heard it argued
that these methods are irrelevant. Of course, one or both is used in
virtually every jQuery example out there. After all, setting
properties (not attributes) makes up the bulk of what most DOM scripts
do. There never was a problem with setting properties in IE (just
attributes), so jQuery created a huge problem where none existed.
And if the above is the extent of the formal documentation, you have
to wonder who keeps up the secret binder with compatibility charts
mapping the various jQuery versions to browser versions and modes.
Rather than trying to track down that elusive information (or God
forbid breaking down and testing the jQuery code), I suggest reading
the W3C's recommendation for the removeAttribute method. Know that
there is a well-known issue with some versions (and modes) of IE. See
my examples as jQuery is clearly no help in this department.
But ultimately, like a lot of things "enhanced" by jQuery (and
others), you may find you never need it. Most applications don't need
to do anything to attributes. If you find yourself setting or
removing an attribute, you are probably making a mistake and should
find the appropriate property (also listed on the W3C site).
Unfortunately, jQuery is one sort of application (a query engine) that
must at least read attributes properly.
http://www.cinsoft.net/slickspeed.html
As a quick glance in IE (particularly Compatibility mode) will tell
you, it predictably fails as a query engine. Considering the
underlying code, it would have taken a miracle to succeed. Doesn't do
much better in browsers outside those listed on jQuery's front page
either. IIRC, Sizzle (the query and lion's share of jQuery) does not
use the "advantageous" attribute methods at all. It uses its own
botched logic, which shouldn't come as any big surprise as, despite
the name and documentation, the attr method mostly returns property
values. And I'd be surprised if they improved on any of that in 1.5.
Perhaps someone else feels like testing that.
There's also the "addEvent" rendition that creates circular
references. And the "Live" thing is a mess of unwieldy hacks,
hopelessly tangled up with queries.
IIRC, passing "onclick" to attr will invoke jQuery's event methods
rather than doing anything to the attribute. So this:-
$('myid').removeAttr('onclick');
....will then do nothing. That's hardly intuitive and more
unfortunately the above will throw an exception in IE < 8 and
Compatibility Mode (due to the call to attr). They really haven't
improved on this removeAttribute thing at all. And they've done a
pretty poor job of documenting their thoughts on the matter.
And then there's the height/width methods (which attr also manages to
invoke) that make no sense, all of that ugly, over-complicated string
manipulation and RegExp abuse, incessant overloading, forgiving
interfaces, no select-one, etc., etc. Little of that has changed in
five years and much of it can't be improved due to the constraints of
the original design.
There's just no magic solution for cross-browser scripting. And if
there was, it wouldn't look anything like jQuery. I know that brings
down those who want to believe otherwise and angers those who would
sell you otherwise. But it was true five years ago and it couldn't be
more apparent today, particularly as the code is still nowhere close
to "mature" (a buzzword frequently associated with jQuery). Even the
worst sort of pessimist couldn't have predicted it would age as poorly
as it has (considering both technical and practical aspects). I think
"rotten" would be more apt at this point (and it was never fresh to
begin with).
You don't send a battery-powered mobile device a useless, complicated
and redundant 70K of junk code. Some of them won't cache it. Some
will choke on it. Virtually none will benefit from jQuery's take on
the Selectors API. Fewer still need jQuery's flailing IE hacks. It's
never been easier to write basic DOM manipulation code that runs
virtually anywhere, except for old versions of IE (and Compatibility
Mode). That's where conditional comments come in (to include
proprietary code and workarounds for old but still much-used
browsers). But jQuery can't be broken up, so now they are looking to
do for mobile what they've done for the desktop.
Are there really any takers for something that? These new devices
present much greater challenges than the old IE versions. So look
ahead five years or so...