More attribute-related jQuery futility

D

David Mark

File this under things that jQuery developers don't care about. :)

Throw a dart at a printout of the jQuery forum and chances are you will
hit a question like this:-

http://forum.jquery.com/topic/ajax-working-with-firefox-not-ie

"Ajax working with Firefox not IE"

Who could imagine such a thing? The really sick thing is that it (once
again) demonstrates the futility of jQuery's raison d'être, which has
ridiculous problems in IE that the jQuery developers have been notified
about ad nauseam since around the end of 2007.

"I have a jQuery code to allow users to login using a lightbox
(http://colorpowered.com/colorbox/) and immediately start downloading
files, without being redirected or having the page reloaded. It's
perfectly working in Firefox but Internet Explorer keeps showing the
login box until I reload the page :("

$(document).ready(function() {
$('a[href^="/link/"]').click(function(event){
var status = $.ajax({
url: "/status",
async: false
}).responseText;
if (status != 'USER_LOGGED_IN')
{
$.fn.colorbox({href:"/login"});
event.preventDefault();
}
});
});

Synchronous XHR? It's beside the point, but certainly suicidal for a
Web page (see also Dojo).

It's hard to say exactly what the problem is as a plug-in (colorBox) is
involved, which means any answers will likely be of the "try this"
guesswork variety.

Regardless, what else is wrong with the above picture? It should be
obvious from the start:-

$('a[href^="/link/"]')

Hmmm. A query that tries to match the start of an attribute containing
a URI. Talk about programming for failure.

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

It gets repetitive, doesn't it? Not my fault. I've tried everything to
get the jQuery developers to see these (and related) issues. Seems all
I ever get for my trouble is apologists squawking that I am not being
helpful. It's really mind-boggling. Think if I posted an answer in
that forum mentioning this issue that it would get past the jQuery
censor/moderator? I don't as they would seemingly rather save face than
help their users. Or perhaps they are still trying to wrap their
collective brains around this basic IE issue, which has existed since
the late 90's (and continues today in some modes of the latest version).
It's hard to say as their communication skills are lacking as well.

Even if the poster figures out the root problem, do you think they have
tested (or ever will test) in IE < 8 (or IE8 compatibility view?) No
wonder the trend is to shirk such responsibilities as "wastes of time".
The results would really mess with their fantasies, so the blinders are
kept squarely in place. You've really got to pity the people paying for
these efforts. Those are the ones who need to sign up for my support
service. I can spot these (and similar) gaffes from miles away. ;)

Furthermore, do you think any of the "many eyes" in that forum will spot
the mistake? I can't imagine, else the underlying problem in jQuery
would have been fixed by now (roughly 2 and a half years after I first
reported it directly to Resig).

Businesses that are trying to lean on developers who lean on jQuery are
dreaming. How much time is wasted each day on guesswork and head
scratching? It's got to run into the millions of dollars. It's
sickening, but not nearly as offensive as the apologists who brush off
such critical (and patently obvious) failures in the low-level code of
this "mature" framework as unimportant.

So what's the answer? The best one is to avoid using queries.
Furthermore, this is a very good candidate for delegation (and I don't
mean the "Live" bastardization).

Something like this (in a "ready" listener) would do nicely:-

var reDownload = /\/link\//;

document.body.onclick = function(e) {
if (!e) {
e = window.event;
}
var target = e.target || e.srcElement;
if (target.tagName.toLowerCase() == 'a' && reDownload.test(target.href)) {

// Put (async) XHR machinations here.
// In the XHR success callback, depending on the returned result,
// set window.location.href to target.href or open the dialog.
// Post credentials and try again in the dialog success callback.
// Bail out if the dialog fails (is canceled).

return false;
}
};

Pretty simple, but developers will never learn to solve such problems by
copying and pasting jQuery spells. The end result is that baffling
failures lead to unanswered questions in the support forum and
incalculable amounts of wasted time.

The missing scene would require about three lines of code using my XHR
module and alert/dialog add-on. No idea about the colorBox thing, but I
presume that, like most jQuery plug-ins, it is best avoided.

You could also use the rel or class attributes to signal which links
represent downloads. As I've mentioned, I don't care for using the
latter for this purpose and others have stated a distaste for rel in
general. But for portability, virtually anything beats hard-wiring a
partial path in the code.

There's no reliance on convoluted and incompetently written query code
and only one listener is attached, which saves memory. Neither is the
much-maligned "Live" marketecture required (it never is). Win-win-win.
As always, the key to effectively using jQuery is avoiding as much of
it as possible (quite a paradox).

Eventually, you will realize that you can scrape off the last bits and
be rid of it for good (and think of all you will learn in the process).
After all, take away queries (which are provided by most host
environments that jQuery claims to support) and "Live", and what is
left? Basically, a few sub-standard effects and simple utilities
tangled up in an ill-advised and interdependent mess of a design.

DOM0 is used for simplicity in the example. Alternatively, an
addEventListener/attachEvent wrapper could be employed. I'm sure jQuery
has one somewhere.

And, as an aside, why in hell is that method called "click"? The
interface fails as a metaphor as well, so the typical "concise" code
results are illegible to all but jQuery mavens. It's a
self-perpetuating sham on every level. It's no wonder there is so much
anger directed towards criticism of jQuery. The marketers know this
thing will wither and die if exposed to light (and that would be bad for
book sales).
 
D

David Mark

David said:
File this under things that jQuery developers don't care about. :)

Throw a dart at a printout of the jQuery forum and chances are you will
hit a question like this:-

http://forum.jquery.com/topic/ajax-working-with-firefox-not-ie

"Ajax working with Firefox not IE"

Who could imagine such a thing? The really sick thing is that it (once
again) demonstrates the futility of jQuery's raison d'être, which has
ridiculous problems in IE that the jQuery developers have been notified
about ad nauseam since around the end of 2007.

"I have a jQuery code to allow users to login using a lightbox
(http://colorpowered.com/colorbox/) and immediately start downloading
files, without being redirected or having the page reloaded. It's
perfectly working in Firefox but Internet Explorer keeps showing the
login box until I reload the page :("

$(document).ready(function() {
$('a[href^="/link/"]').click(function(event){
var status = $.ajax({
url: "/status",
async: false
}).responseText;
if (status != 'USER_LOGGED_IN')
{
$.fn.colorbox({href:"/login"});
event.preventDefault();
}
});
});

Synchronous XHR? It's beside the point, but certainly suicidal for a
Web page (see also Dojo).

It's hard to say exactly what the problem is as a plug-in (colorBox) is
involved, which means any answers will likely be of the "try this"
guesswork variety.

Regardless, what else is wrong with the above picture? It should be
obvious from the start:-

$('a[href^="/link/"]')

Hmmm. A query that tries to match the start of an attribute containing
a URI. Talk about programming for failure.

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

It gets repetitive, doesn't it? Not my fault. I've tried everything to
get the jQuery developers to see these (and related) issues. Seems all
I ever get for my trouble is apologists squawking that I am not being
helpful. It's really mind-boggling. Think if I posted an answer in
that forum mentioning this issue that it would get past the jQuery
censor/moderator? I don't as they would seemingly rather save face than
help their users. Or perhaps they are still trying to wrap their
collective brains around this basic IE issue, which has existed since
the late 90's (and continues today in some modes of the latest version).
It's hard to say as their communication skills are lacking as well.

Even if the poster figures out the root problem, do you think they have
tested (or ever will test) in IE < 8 (or IE8 compatibility view?) No
wonder the trend is to shirk such responsibilities as "wastes of time".
The results would really mess with their fantasies, so the blinders are
kept squarely in place. You've really got to pity the people paying for
these efforts. Those are the ones who need to sign up for my support
service. I can spot these (and similar) gaffes from miles away. ;)

Furthermore, do you think any of the "many eyes" in that forum will spot
the mistake? I can't imagine, else the underlying problem in jQuery
would have been fixed by now (roughly 2 and a half years after I first
reported it directly to Resig).

Businesses that are trying to lean on developers who lean on jQuery are
dreaming. How much time is wasted each day on guesswork and head
scratching? It's got to run into the millions of dollars. It's
sickening, but not nearly as offensive as the apologists who brush off
such critical (and patently obvious) failures in the low-level code of
this "mature" framework as unimportant.

So what's the answer? The best one is to avoid using queries.
Furthermore, this is a very good candidate for delegation (and I don't
mean the "Live" bastardization).

Something like this (in a "ready" listener) would do nicely:-

var reDownload = /\/link\//;

document.body.onclick = function(e) {
if (!e) {
e = window.event;
}
var target = e.target || e.srcElement;
if (target.tagName.toLowerCase() == 'a' && reDownload.test(target.href)) {

// Put (async) XHR machinations here.
// In the XHR success callback, depending on the returned result,
// set window.location.href to target.href or open the dialog.
// Post credentials and try again in the dialog success callback.
// Bail out if the dialog fails (is canceled).

return false;
}
};

Pretty simple, but developers will never learn to solve such problems by
copying and pasting jQuery spells. The end result is that baffling
failures lead to unanswered questions in the support forum and
incalculable amounts of wasted time.

The missing scene would require about three lines of code using my XHR
module and alert/dialog add-on. No idea about the colorBox thing, but I
presume that, like most jQuery plug-ins, it is best avoided.

You could also use the rel or class attributes to signal which links
represent downloads. As I've mentioned, I don't care for using the
latter for this purpose and others have stated a distaste for rel in
general. But for portability, virtually anything beats hard-wiring a
partial path in the code.

There's no reliance on convoluted and incompetently written query code
and only one listener is attached, which saves memory. Neither is the
much-maligned "Live" marketecture required (it never is). Win-win-win.
As always, the key to effectively using jQuery is avoiding as much of
it as possible (quite a paradox).

Eventually, you will realize that you can scrape off the last bits and
be rid of it for good (and think of all you will learn in the process).
After all, take away queries (which are provided by most host
environments that jQuery claims to support) and "Live", and what is
left? Basically, a few sub-standard effects and simple utilities
tangled up in an ill-advised and interdependent mess of a design.

DOM0 is used for simplicity in the example. Alternatively, an
addEventListener/attachEvent wrapper could be employed. I'm sure jQuery
has one somewhere.

And, as an aside, why in hell is that method called "click"? The
interface fails as a metaphor as well, so the typical "concise" code
results are illegible to all but jQuery mavens. It's a
self-perpetuating sham on every level. It's no wonder there is so much
anger directed towards criticism of jQuery. The marketers know this
thing will wither and die if exposed to light (and that would be bad for
book sales).

Addendum: though it doesn't solve whatever problem the OP is having with
his dialog, and depending on which jQuery version he's using, he may be
in luck with his query. As I remembered, the "Sizzle" query engine
doesn't use the - attr - method at all, instead relying on this
gobbledygook:-

result = Expr.attrHandle[ name ] ?
Expr.attrHandle[ name ]( elem ) :
elem[ name ] != null ?
elem[ name ] :
elem.getAttribute( name ),

....which makes absolutely no sense at all (and this is from the latest
and presumably greatest version of jQuery). It's been previously
documented to death (here and elsewhere). That code could only come
about from complete confusion on the part of the authors. It's like
they rearranged the logic until whatever inadequate tests they had
appeared to work. This is not about older or otherwise neglected
browsers either. That code doesn't make sense in _any_ browser ever
made. It will never make sense. They are browser Ninjas, so you'd
think they would know this. Worse still, they didn't even have to
figure it out on their own as they have been told about it repeatedly.

Anyway, the - attr - method "fixes" two of the dozen or so affected
attributes (HREF and SRC). Quotes indicate that it makes the returned
result attribute-flavored, whereas it otherwise returns property values
(another famous source of confusion for this effort). Furthermore,
that's two down with about ten to go, roughly halfway through 2010. The
rules haven't changed. A proper solution from 1999 would work just fine
today.

So, in 1.3's "Sizzle" query engine, they bypassed their own attribute
logic (odd for a project so concerned about weight) and duplicated
_half_ of its URI-related corrections with this patch:-

// Check to see if an attribute returns normalized href attributes
div.innerHTML = "<a href='#'></a>";
if ( div.firstChild && typeof div.firstChild.getAttribute !== "undefined" &&
div.firstChild.getAttribute("href") !== "#" ) {
Expr.attrHandle.href = function(elem){
return elem.getAttribute("href", 2);
};
}

The comment is classic jQuery-speak. It raises the question: what about
the SRC attribute? They already had that one covered in the - attr -
method. And I'm sure I've seen this test pattern (or something very
similar) before. Can't put my finger on it. I remember this stuff was
all UA-sniffing before Resig and I had our little "discussion" here
about browser detection and attributes (followed almost immediately by
the publication of My Library). Imitation is certainly a form of
flattery, but this is one hell of a poor imitation. :)

How does something like this happen on a project with so many eyes on it
(not to mention my repeated critiques?) 70K of script, divided by -
let's say - 70 contributors means they each have 1K to maintain. They
must not talk to each other (and apparently none of them read this
group). These shortcomings should literally jump off the page (of the
code or any one of my reviews) at them, even at a glance. And the glare
of the spotlight on these particular issues has been withering.
Seemingly everyone knows about them at this point; everyone except the
authors. Such a scenario doesn't seem possible in the Internet age,
certainly not for a project as ubiquitous as this one has become.

But I digress. It appears the "test swarm" noticed that the HREF
attributes were being handled incorrectly for queries, so the above
patch was added, duplicating a previous "feature test" and ignoring half
of the two attributes it addressed. It's typical observe-and-patch
behavior. At this rate, it will be ten years before they spot the rest
of the attributes that hold URI's. If they only understood the
underlying issues (which I have explained endlessly and demonstrated to
death), they (and their users) wouldn't have to wait. How many upgrade
and re-test cycles will be imposed between now and then? And I suppose
I'm the bad guy as I finally put my foot down about them stealing my
code. :) This is the one that spent a night in their repository:-

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

....until I pointed out that it was copyrighted.

I'm sorry, but if they are going to save the world from JS, they are
going to have to get their own experience and common sense. Or they
could just search this group's archive (granted, that would involve some
actual work on their part).

Well, at least it is better than YUI's query engine, which makes no
attempt at all to deal with these issues (and neither did Prototype last
I checked). None of them seem to realize that the answers can't be
found on Ajaxian or StackOverflow.

When it comes to attributes, the "major" moniker seems to be short for
"major disaster". I find this very odd for such basic and critical
functionality, particularly as applications built on top of these things
tend to use queries for virtually everything. It's like engineering
with a calculator that sporadically adds wrong.

But the good news is they put a piece of plywood over one of the
land-mines. If that is the only mine you care about, you are in luck.
Watch out in the future though as the foundation tends to shift. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top