More attribute-related jQuery futility

Discussion in 'Javascript' started by David Mark, May 15, 2010.

  1. David Mark

    David Mark Guest

    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).
     
    David Mark, May 15, 2010
    #1
    1. Advertising

  2. David Mark

    David Mark Guest

    David Mark wrote:
    > 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. :)
     
    David Mark, May 15, 2010
    #2
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Aaron Gray
    Replies:
    20
    Views:
    429
    Lasse Reichstein Nielsen
    Jul 27, 2008
  2. David Mark
    Replies:
    137
    Views:
    1,066
    David Mark
    Apr 22, 2009
  3. David Mark
    Replies:
    11
    Views:
    493
    NickFitz
    Dec 14, 2009
  4. David Mark

    jQuery Attribute Summit--Latest Coverage

    David Mark, Dec 20, 2009, in forum: Javascript
    Replies:
    16
    Views:
    433
    David Mark
    Dec 23, 2009
  5. lorlarz
    Replies:
    6
    Views:
    234
    David Mark
    Mar 25, 2010
Loading...

Share This Page