New jQuery announced!

Discussion in 'Javascript' started by David Mark, Dec 7, 2009.

  1. David Mark

    David Mark Guest

    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 == 8) {
    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/0...and-removing-tabindex-values-with-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/prototype/detecting-event-support-without-browser-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;
    };
    David Mark, Dec 7, 2009
    #1
    1. Advertising

  2. David Mark

    David Mark Guest

    On Dec 7, 11:59 am, David Mark <> 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. ;)
    David Mark, Dec 7, 2009
    #2
    1. Advertising

  3. David Mark

    Matt Kruse Guest

    On Dec 7, 3:59 pm, David Mark <> 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
    Matt Kruse, Dec 7, 2009
    #3
  4. On Dec 7, 4:33 pm, Matt Kruse <> 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.
    Michael Haufe (\TNO\), Dec 7, 2009
    #4
  5. On Dec 7, 5:04 pm, "Michael Haufe (\"TNO\")"
    <> 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"
    Michael Haufe (\TNO\), Dec 7, 2009
    #5
  6. David Mark

    David Mark Guest

    On Dec 7, 5:33 pm, Matt Kruse <> wrote:
    > On Dec 7, 3:59 pm, David Mark <> 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.
    David Mark, Dec 7, 2009
    #6
  7. David Mark

    David Mark Guest

    On Dec 7, 6:04 pm, "Michael Haufe (\"TNO\")"
    <> wrote:
    > On Dec 7, 4:33 pm, Matt Kruse <> 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 shit variety. Seems a very rough way to go, mostly
    taken by those without an alternative.
    David Mark, Dec 7, 2009
    #7
  8. David Mark

    RobG Guest

    On Dec 8, 8:33 am, Matt Kruse <> wrote:
    > On Dec 7, 3:59 pm, David Mark <> 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
    RobG, Dec 8, 2009
    #8
  9. David Mark

    rf Guest

    RobG wrote:
    > On Dec 8, 8:33 am, Matt Kruse <> wrote:
    >> On Dec 7, 3:59 pm, David Mark <> 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.
    rf, Dec 8, 2009
    #9
  10. David Mark

    David Mark Guest

    On Dec 7, 8:16 pm, "rf" <> wrote:
    > RobG wrote:
    > > On Dec 8, 8:33 am, Matt Kruse <> wrote:
    > >> On Dec 7, 3:59 pm, David Mark <> 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. ;)
    David Mark, Dec 8, 2009
    #10
  11. David Mark

    Matt Kruse Guest

    On Dec 7, 5:48 pm, David Mark <> wrote:
    > On Dec 7, 6:04 pm, "Michael Haufe (\"TNO\")"
    > > On Dec 7, 4:33 pm, Matt Kruse <> 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.


    Agreed. I make exceptions for client-side js, because the size and
    speed of code is important. It is better to make it clear in the API
    docs what should and shouldn't be passed into functions rather than
    doing lots of type-checking of arguments, etc. That stuff can be left
    in a "debug" version, however.

    As David says early in his criticism:

    > // don't set attributes on text and comment nodes
    > Don't pass them! Put that in the docs. :)


    ....

    > > 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.


    I definitely welcome these kinds of reviews and criticisms. I only
    wish there was less snarkiness, better formatting, and a lot less
    bias. I am thankful for David's continued criticism of jQuery et al,
    because it lets people know of the short-comings and also points of
    things that the developers can work on. These aren't perfect
    solutions, but are works in progress. jQuery especially has made
    progress and addressed some criticisms like browser sniffing, etc. Yet
    some people ignore the progress and instead focus on the stuff that
    still needs work.

    > > > 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.


    That may not be a justified assumption. It can do whatever it wants,
    but should be clear and documented. There are exceptions and
    unsupported conditions to many methods and algorithms.

    If the docs are not clear about the exceptions and situations where
    the assumed behavior will not work as you might expect, then the docs
    should certainly be corrected if the code is not. For example,
    obviously the attr() method is meant to only set string properties.
    I'm not sure why anyone would want to pass a function(){} to attr()
    when you can use the event methods instead. But as David points out,
    if you try to it will fail. This kind of stuff should be clearly
    documented. I don't think it's a bug (it's unintended use of the
    function) but the decision to NOT work in this way should be
    intentional, not just an unintended side-effect of poor coding. Which
    may be the case here, I don't know.

    Matt Kruse
    Matt Kruse, Dec 8, 2009
    #11
  12. David Mark

    David Mark Guest

    On Dec 8, 4:07 pm, Matt Kruse <> wrote:

    [...]

    For example,
    > obviously the attr() method is meant to only set string properties.


    It is not set up, nor is it designed for string properties. Which of
    these will check a box in jQuery?

    attr(el, 'checked', true);
    attr(el, 'checked', 'true');
    attr(el, 'checked', '');
    attr(el, 'checked', 'checked');

    Bonus, in which browsers?

    I've seen all of them in practice and lots of questions about this and
    similar issues in the various jQuery support forums, blog posts, etc.

    I know the first works for most, except for XML, which jQuery seems to
    want to support with this method. See how mixing up attributes and
    properties and trying to support both XML and HTML DOM's all in one
    magic function has led to an interface with so many wires crossed it's
    hard to predict the outcome of even one single menial line of code.
    Now imagine an array of components and plug-ins built on top of this
    rickety foundation. Of course, you don't have to imagine it. You've
    blogged about it. Predictably, it's all a bunch of unpredictable,
    ever-shifting rubbish.

    Don't ask me what the other three do (or in which browsers). I'd have
    to go back and look at the code again. That cannot be a good sign
    when I have to read the code to predict what the thing will do to the
    DOM. Where does that leave the average code monkey? In the jQuery
    mailing list where nobody has a clue what is going on under the hood
    of this clunker.

    Glad you liked the review (as much as I could be glad about it). Now
    stop using this junk. :)
    David Mark, Dec 8, 2009
    #12
  13. On Dec 9, 10:19 am, Hans-Georg Michna <hans-
    > wrote:
    >
    > Why is nobody writing a competing library, maybe a good subset
    > of jQuery, but without the foul spots?


    No doubt there are, but I think its safe to say they don't have the
    same marketing and/or don't care to share.

    > There is an obvious need for such a critter, otherwise people wouldn't flock to jQuery,
    > and I wouldn't like to miss it either.


    Define what you mean when you say "...such a critter"

    > Why isn't anyone sending John Resig a big, fat set of test
    > cases?


    Time better spent elsewhere?
    Michael Haufe (\TNO\), Dec 9, 2009
    #13
  14. David Mark

    Matt Kruse Guest

    On Dec 8, 3:50 pm, David Mark <> wrote:
    > > obviously the attr() method is meant to only set string properties.

    > It is not set up, nor is it designed for string properties.


    Oops, meant to say attributes.

    > Which of
    > these will check a box in jQuery?
    > attr(el, 'checked', true);
    > attr(el, 'checked', 'true');
    > attr(el, 'checked', '');
    > attr(el, 'checked', 'checked');


    I don't even know, because I'm not sure why anyone would do that.

    > I've seen all of them in practice and lots of questions about this and
    > similar issues in the various jQuery support forums, blog posts, etc.


    Agreed. It is a side-effect of people trying to "jQuery-ize"
    everything in their code. It's ridiculous to use a lib method like attr
    () just to check a checkbox.

    Although, I have done something like this:

    $(':checkbox[name=foo]').run("this.checked==true");

    run() is obviously a little eval wrapper that I plugged into jQuery. I
    like using jQuery to conveniently grab a set of elements that I want
    in order to manipulate them, but I don't really like it's methods that
    do the manipulation.

    > I know the first works for most, except for XML, which jQuery seems to
    > want to support with this method.


    I think they try to support XML because of XHTML. It seems terribly
    misguided, and I don't know what rationale they have for doing it, if
    any.

    > Glad you liked the review (as much as I could be glad about it).  Now
    > stop using this junk.  :)


    I will when there is a suitable replacement that fills a variety of
    needs better than jQuery does (despite its problems, if you use jQuery
    only for the things it does do well and avoid the problem areas, it's
    very convenient). How's the Dojo work coming?

    I would really like to see a long, formal analysis of jQuery. Since it
    still seems to be the dominant js framework available, I would like to
    have a polished, well-written critique of its design decisions and
    code quality, pros and cons, so everyone could properly evaluate the
    library and decide if and when to use it. If it were written as a
    wiki, it would allow multiple contributors to this group to refine the
    writing and would probably become a valuable resource for the
    thousands of developers on the web who are using the library.
    Unfortunately, those who have the knowledge and expertise to write up
    such an analysis rarely have the time or interest in doing so. So the
    blind following the blind continues...

    Matt Kruse
    Matt Kruse, Dec 9, 2009
    #14
  15. David Mark

    David Mark Guest

    On Dec 9, 11:19 am, Hans-Georg Michna <hans-
    > wrote:
    > David,
    >
    > it is really a pity. The fundamental ideas of jQuery,
    > particularly to use CSS selectors and a functional style of
    > programming, are sound, as far as I can tell, and they often
    > allow you to write as a one-liner, what would otherwise be half
    > a page of JavaScript code.


    I suppose any library of functions can make that claim. ;) I don't
    care for querying by CSS selectors though. To do it in older browsers
    requires a heart-stopping amount of error-prone code. The typical
    jQuery line takes 10,000 function calls to do what a few lines of JS
    could do with standard host methods. I think reliability trumps the
    number of lines of code every time (and what do lines of code matter
    if the end result is minified?)

    >
    > Why is nobody writing a competing library, maybe a good subset
    > of jQuery, but without the foul spots? There is an obvious need
    > for such a critter, otherwise people wouldn't flock to jQuery,
    > and I wouldn't like to miss it either.


    Most professionals who write JS can see the folly in choosing one
    monolith in advance for every context, so they don't write such
    things. I made an exception a couple of years back (Google "browser
    scripting library" and click the first hit). It is a functional API
    with an optional jQuery-like (but competently designed) "chainable" OO
    interface (or you could write your own that is exactly like jQuery if
    that's what you really want). I don't recommend using such interfaces
    as they just slow things down, but at least mine is a fairly
    "unobtrusive" layer.

    I don't really care to market a free library, but if anyone cares to
    help with the documentation, evangelizing, etc. they have whatever
    limited support I can muster.

    >
    > Why isn't anyone sending John Resig a big, fat set of test
    > cases?
    >


    What good would that do? He needs to understand why. It was
    explained to him years ago (by me). He didn't get it then and
    apparently he's still in the dark today. :(
    David Mark, Dec 9, 2009
    #15
  16. Matt Kruse wrote:
    > On Dec 8, 3:50 pm, David Mark <> wrote:
    >>> obviously the attr() method is meant to only set string properties.

    >> It is not set up, nor is it designed for string properties.

    >
    > Oops, meant to say attributes.
    >

    As in:
    | obviously the attr() method is meant to only set string attributes.

    jQuery.attr has specific handling for many odd cases. What does attr
    have to do with:

    | if ( name == "selected" && elem.parentNode )
    | elem.parentNode.selectedIndex;

    That's a boolean property, not an attribute, right?

    Or:
    | if ( !jQuery.support.opacity && name == "opacity" ) {
    | if ( set ) {
    | // IE has trouble with opacity if it does not have layout
    | // Force it by setting the zoom level
    | elem.zoom = 1;

    A method dealing with attributes working to do modify style properties
    of objects, then providing workarounds for IE, not checking to see
    currentStyle.hasLayout (the object migh have a layout already).

    That method is doing way too much.

    >> Which of
    >> these will check a box in jQuery?
    >> attr(el, 'checked', true);
    >> attr(el, 'checked', 'true');
    >> attr(el, 'checked', '');
    >> attr(el, 'checked', 'checked');

    >
    > I don't even know, because I'm not sure why anyone would do that.
    >


    Probably to try and check a checkbox. What attr does is not entirely
    distinct. It's sometimes attributes, other times properties.

    >> I've seen all of them in practice and lots of questions about this and
    >> similar issues in the various jQuery support forums, blog posts, etc.

    >
    > Agreed. It is a side-effect of people trying to "jQuery-ize"
    > everything in their code. It's ridiculous to use a lib method like attr
    > () just to check a checkbox.
    >
    > Although, I have done something like this:
    >
    > $(':checkbox[name=foo]').run("this.checked==true");
    >
    > run() is obviously a little eval wrapper that I plugged into jQuery.


    That sounds dangerous. Calling eval, you know the thisArg and Variable
    is from the calling context. Eval works differntly in ES5, but that's on
    the horizon as far as implementations are concerned. Passing in
    something that is used in the calling context would be modifying variables.

    [sni[p]

    >
    >> Glad you liked the review (as much as I could be glad about it). Now
    >> stop using this junk. :)

    >
    > I will when there is a suitable replacement that fills a variety of
    > needs better than jQuery


    Such as?

    > I would really like to see a long, formal analysis of jQuery. Since it
    > still seems to be the dominant js framework available, I would like to
    > have a polished, well-written critique of its design decisions and
    > code quality, pros and cons, so everyone could properly evaluate the
    > library and decide if and when to use it. If it were written as a
    > wiki, it would allow multiple contributors to this group to refine the
    > writing and would probably become a valuable resource for the
    > thousands of developers on the web who are using the library.
    > Unfortunately, those who have the knowledge and expertise to write up
    > such an analysis rarely have the time or interest in doing so. So the
    > blind following the blind continues...
    >


    If you really want it, then do it. I'll provide feedback on it and
    comments to your efforts.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 11, 2009
    #16
  17. Garrett Smith wrote:
    > Matt Kruse wrote:
    >> On Dec 8, 3:50 pm, David Mark <> wrote:
    >>>> obviously the attr() method is meant to only set string properties.
    >>> It is not set up, nor is it designed for string properties.

    >>
    >> Oops, meant to say attributes.
    >>

    > As in:
    > | obviously the attr() method is meant to only set string attributes.
    >
    > jQuery.attr has specific handling for many odd cases. What does attr
    > have to do with:
    >
    > | if ( name == "selected" && elem.parentNode )
    > | elem.parentNode.selectedIndex;
    >


    Note that the statement inside the if test is entirely useless, as it is
    not assigned to anything.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
    Garrett Smith, Dec 11, 2009
    #17
  18. David Mark

    Matt Kruse Guest

    On Dec 11, 1:06 am, Garrett Smith <> wrote:
    > Matt Kruse wrote:
    > | obviously the attr() method is meant to only set string attributes.
    > jQuery.attr has specific handling for many odd cases. What does attr
    > have to do with:
    > | if ( name == "selected" && elem.parentNode )
    > |    elem.parentNode.selectedIndex;
    > That's a boolean property, not an attribute, right?


    I didn't look at the source closely enough. I thought they got rid of
    accessing properties of elements and went purely to get/setAttribute.
    I was incorrect. Disappointing.

    > >>  Which of
    > >> these will check a box in jQuery?
    > >> attr(el, 'checked', true);
    > >> attr(el, 'checked', 'true');
    > >> attr(el, 'checked', '');
    > >> attr(el, 'checked', 'checked');

    > > I don't even know, because I'm not sure why anyone would do that.

    > Probably to try and check a checkbox. What attr does is not entirely
    > distinct. It's sometimes attributes, other times properties.


    Indeed, which has been David's criticism for a long time. It looks
    like Resig still doesn't get it.

    > > $(':checkbox[name=foo]').run("this.checked==true");
    > > run() is obviously a little eval wrapper that I plugged into jQuery.

    > That sounds dangerous.


    Not if you know what you are doing. I use it for very simple things,
    to avoid lots of anonymous functions.

    > >> Glad you liked the review (as much as I could be glad about it).  Now
    > >> stop using this junk.  :)

    > > I will when there is a suitable replacement that fills a variety of
    > > needs better than jQuery

    > Such as?


    Documented well
    Lots of examples
    Printed material available for developers to read from
    An active support community
    Active development and bug fixing
    Supported by various editors and environments
    etc

    If you're just a stand-alone developer choosing the best tool, jQuery
    may not be the best pick. If you're trying to organize a team of 10-20
    developers, some onshore some offshore, all of differing experience
    levels, who all need to touch the js of the webapp, then having a tool
    like jQuery is very important. In my experience, I have found that
    without such a library the code quality is consistently lower and the
    number of problems is way higher. jQuery sure has its problems, and
    it's not a perfect solution, but it's way better than the other
    alternatives I've found. When I find a better option, I'll switch.

    > > Unfortunately, those who have the knowledge and expertise to write up
    > > such an analysis rarely have the time or interest in doing so. So the
    > > blind following the blind continues...

    > If you really want it, then do it. I'll provide feedback on it and
    > comments to your efforts.


    That would be great, but I have no desire to write it. I know what
    problems I have with jQuery, and I code around them. If I were being
    paid for it, I would certainly write such an article :)

    Matt Kruse
    Matt Kruse, Dec 11, 2009
    #18
  19. David Mark

    David Mark Guest

    On Dec 9, 12:37 pm, Matt Kruse <> wrote:
    > On Dec 8, 3:50 pm, David Mark <> wrote:
    >
    > > > obviously the attr() method is meant to only set string properties.

    > > It is not set up, nor is it designed for string properties.

    >
    > Oops, meant to say attributes.
    >
    > > Which of
    > > these will check a box in jQuery?
    > > attr(el, 'checked', true);
    > > attr(el, 'checked', 'true');
    > > attr(el, 'checked', '');
    > > attr(el, 'checked', 'checked');

    >
    > I don't even know, because I'm not sure why anyone would do that.
    >
    > > I've seen all of them in practice and lots of questions about this and
    > > similar issues in the various jQuery support forums, blog posts, etc.

    >
    > Agreed. It is a side-effect of people trying to "jQuery-ize"
    > everything in their code. It's ridiculous to use a lib method like attr
    > () just to check a checkbox.
    >
    > Although, I have done something like this:
    >
    > $(':checkbox[name=foo]').run("this.checked==true");
    >
    > run() is obviously a little eval wrapper that I plugged into jQuery.


    Dear God.

    > I
    > like using jQuery to conveniently grab a set of elements that I want
    > in order to manipulate them, but I don't really like it's methods that
    > do the manipulation.


    That is inconvenient. All grabbed up and nothing to do with them.

    >
    > > I know the first works for most, except for XML, which jQuery seems to
    > > want to support with this method.

    >
    > I think they try to support XML because of XHTML. It seems terribly
    > misguided, and I don't know what rationale they have for doing it, if
    > any.


    That applies to most of the script. :(

    >
    > > Glad you liked the review (as much as I could be glad about it).  Now
    > > stop using this junk.  :)

    >
    > I will when there is a suitable replacement that fills a variety of
    > needs better than jQuery does (despite its problems, if you use jQuery
    > only for the things it does do well and avoid the problem areas, it's
    > very convenient).


    And... how would one know what the problem areas are? Also, how is
    it convenient to have to upgrade something that is constantly changed
    to (sort of) keep up with just the latest major browsers, usually
    breaking backwards compatibility in lots of little ways?

    > How's the Dojo work coming?


    I rewrote virtually all of it in competent fashion last summer. Of
    course...

    So, in my limited spare time, I have been working on a new scrapbook
    of code (working title is My Library, Too) and accompanying book.
    Basically, it's the foundation that jQuery, Dojo, etc. should have
    started with in the first place (they can't really go back now). ;)

    >
    > I would really like to see a long, formal analysis of jQuery.


    Haven't you seen enough?

    > Since it
    > still seems to be the dominant js framework available, I would like to
    > have a polished, well-written critique of its design decisions and
    > code quality, pros and cons, so everyone could properly evaluate the
    > library and decide if and when to use it.


    I've done all I can do in that area. Perhaps somebody else should
    aggregate and format the information as they see fit.

    > If it were written as a
    > wiki, it would allow multiple contributors to this group to refine the
    > writing and would probably become a valuable resource for the
    > thousands of developers on the web who are using the library.


    So set it up.

    > Unfortunately, those who have the knowledge and expertise to write up
    > such an analysis rarely have the time or interest in doing so. So the
    > blind following the blind continues...
    >


    Exactly.
    David Mark, Dec 11, 2009
    #19
  20. David Mark

    David Mark Guest

    On Dec 11, 2:35 am, Garrett Smith <> wrote:
    > Garrett Smith wrote:
    > > Matt Kruse wrote:
    > >> On Dec 8, 3:50 pm, David Mark <> wrote:
    > >>>> obviously the attr() method is meant to only set string properties.
    > >>> It is not set up, nor is it designed for string properties.

    >
    > >> Oops, meant to say attributes.

    >
    > > As in:
    > > | obviously the attr() method is meant to only set string attributes.

    >
    > > jQuery.attr has specific handling for many odd cases. What does attr
    > > have to do with:

    >
    > > | if ( name == "selected" && elem.parentNode )
    > > |    elem.parentNode.selectedIndex;

    >
    > Note that the statement inside the if test is entirely useless, as it is
    > not assigned to anything.


    It's a mystical incantation. See the related comment.

    And yes, jQuery's attr doesn't know what it wants to be. Some of it
    deals with attributes (substituting undefined for null when they are
    missing), other bits will cheerfully return DOM defaults/
    interpretations and even user input. (!)

    I tried to replicate both the realAttr and prop patterns from my
    attribute test page and neither was do-able with the jQuery methods.
    As it sits, I have almost 100 picky unit tests for each method and
    nothing outside of the presented wrappers can come close to passing
    them. jQuery can't even pass the gauntlet without blowing up (several
    times). (!) I will post the results shortly (new chapter: J is for
    Junk).

    For something that is focused on querying the document, jQuery is
    startlingly illiterate. As for writing (e.g. removing attributes), it
    is prone to throwing exceptions, failing silently, stepping on user
    input, etc. It's a stretch to think the authors are going to suddenly
    "get it" after all of these years of futility. Same goes for the rest
    of the open source Frankenscript projects. Those who can rarely
    bother constructing ill-advised monoliths as context is what keys
    competent browser scripting designs.

    You had asked before about why such methods would ever be necessary
    and as I'm working on that chapter, I have given it some more
    thought. For one, a CSS selector query should ignore DOM defaults,
    user input, etc. For two, a more practical concern is form
    serialization. We know that determining the value of a SELECT
    requires at least a hasAttribute wrapper (in case the selected option
    has a value of ''). ISTM that WYSIWYG editors would need a clear and
    consistent view of the underlying markup as well.
    David Mark, Dec 11, 2009
    #20
    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. Richard B. Katz
    Replies:
    0
    Views:
    403
    Richard B. Katz
    Jun 3, 2004
  2. Richard B. Katz
    Replies:
    0
    Views:
    421
    Richard B. Katz
    Jul 12, 2005
  3. Servertec
    Replies:
    0
    Views:
    367
    Servertec
    Sep 5, 2005
  4. Aaron Gray
    Replies:
    20
    Views:
    400
    Lasse Reichstein Nielsen
    Jul 27, 2008
  5. lorlarz
    Replies:
    6
    Views:
    213
    David Mark
    Mar 25, 2010
Loading...

Share This Page