YUI--doomed?

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

  1. David Mark

    David Mark Guest

    http://github.com/yui/yui3/commit/a3b173f97e351148a2741470a46c87e93424c16d#diff-0

    1076 1076
    1077 1077 hasMethod: function(method) {
    1078 1078 var node = this._node;
    1079 - return !!(node && method in node && node[method].apply);
    1079 + return !!(node && method in node &&
    1080 + (typeof node[method] === 'function' ||
    1081 + String(node[method]).indexOf('function') ===
    1)); // IE reports as object, prepends space

    Passing a host object method to the String constructor. Are they
    completely insane? One thing is for sure, they don't read this group
    (or peruse my site).

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

    " kangax added a note to a3b173f build/node/node-base-debug.js:L1081

    May 14, 2010

    String-converting host objects is known to blow up in IE, so this is not
    a very good idea. Function decompilation is another thing that's best
    avoided."

    Good man.

    " msweeney added a note to a3b173f build/node/node-base-debug.js:L1081

    May 15, 2010

    Its not pretty, but it works in IE6 and isn't blowing up any test cases."

    It most assuredly does _not_ work in IE6 (or any version of IE for that
    matter). This is what happens when you program by observation. He's
    looking for a failure case, instead of understanding the abstraction
    which says: host objects can do whatever the hell they want. It's been
    well-established (for about ten years) that typeof is the only safe way
    to detect their methods. It's been written up here a thousand times.
    Who on the planet that writes JS for a living hasn't heard of isHostMethod?

    "Let me know if you have a failure case."

    There it is. Show me where it fails. That's what the Dojo people say
    over and over. If a lack of a failure case is your only justification
    for your logic, then you don't understand cross-browser scripting at
    all. Do these people ever think about what will happen tomorrow? The
    whole point of things like YUI and Dojo is that they are supposedly
    needed due to the ever-changing browsers, yet their authors will commit
    anything that appears to work in _today's_ browsers (well, the four or
    five they profess to "care" about). They don't seem to understand that
    tomorrow's browsers may change. What sort of logic is that? And it's
    not like they don't have an avalanche of broken browsers behind them to
    serve as reminders. All I can figure is that they are all suffering
    from mass hysteria and the developers who lean on them have just gotten
    used to the endless failures. You sure don't have to show them where it
    fails. :)

    "Better yet, suggest a cleaner hasMethod test."

    Why bother? I know what will come of it. I suggested a cleaner Dojo.
    Lots of similar blithering ensued and it never got used.

    "This undocumented method will likely be marked deprecated in a future
    release."

    Great.

    " GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

    5 days ago

    Based on the change, you seem to have realized that host objects aren't
    functions and don't have an apply method. Most realized that 5 years ago
    or more. Where have you been?"

    They've been working on YUI of course. Just gettin' stuff done in the
    Real World (where host methods work like native functions and IE never
    throws exception on type conversions). :)

    "Converting host property object to string and parsing the string to see
    what it looks like doesn't really provide indication for the capability
    of that property.

    when node is a form:
    hasMethod("item")

    And yes, string conversion of host object is known to blow up in IE,
    even [[Get]] can cause unknown error. The in operator may provide
    misleading results with catchall. For most consistent results, use typeof."

    As hopefully any novice knows by now.

    " msweeney added a note to a3b173f build/node/node-base-debug.js:L1081

    5 days ago

    Thanks for the feedback."

    I find that open source contributors usually go out of their way to be
    polite. It's often all they've got. And it gives them an excuse to
    dismiss criticism as rude by comparison (they want to get back to having
    fun again). :(

    "If you're assertion is true ("For most consistent results, use typeof")
    then you have nothing to worry about as IE should never reach the OR
    condition that converts to string."

    Oh brother. If? And, once again, today's observations alone are enough
    to go by (until tomorrow of course). Don't attempt to understand
    anything, just watch the browsers and adjust to suit. Of course, in
    this case, the observations are demonstrably faulty _today_ (as well as
    ten years ago). And this is a "major" library with tons of widgets
    stacked on top of it, published by a behemoth enterprise (Yahoo!)

    "Unfortunately, that is consistently wrong, as typeof on a host object
    in IE is "object"."

    That's not "wrong". What is wrong is the design of the "soon to be
    deprecated" function. Welcome to 2001, er 2010. :)

    "As mentioned, this undocumented method will be likely be deprecated."

    So no need to fix it or learn anything from its failings.

    "However, I would love to be enlightened by those in the "know", so
    please submit a use-case that makes YUI::Node:hasMethod blow up."

    Show me where it fails. Show me where it fails. Show me where it
    fails. Ugh. Even if it doesn't fail today, it may well fail tomorrow.
    See all of those broken "degraded" browsers behind you? Best to
    finally learn what you are doing.

    And note the snide attempt at irony. That's typical. The more ignorant
    they are, the quicker they resort to baiting. IIRC, Resig launched into
    similar snipes almost instantly when I first reviewed his garbage (and
    slowly but surely implemented most of the ideas I fed him).

    " GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

    5 days ago

    The typeof operator takes an operand and results in string; it is not
    consistently wrong. typeof on a host object in IE is not consistently
    "object". Try the example I provided in my last message. Again:
    when node is a form:
    hasMethod("item")

    A program expecting MSIE to consistently result "object" for methods
    will fail if the type is something other than object. The typeof
    operator returns implementation dependent string for host object in ES3.

    But carry on as you like."

    And you know they will.

    " msweeney added a note to a3b173f build/node/node-base-debug.js:L1081

    5 days ago

    Thanks Garrett."

    :)

    "The example you provide is exactly why this method is currently
    undocumented, and why it will likely be deprecated."

    That's three times now.

    "Short of try/catching a call to the method, I haven't found a reliable
    way to determine whether the object is a function or not in all cases."

    OMG. I can repeat myself too.

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

    i - s - H - o - s - t - M - e - t - h - o - d. There you go. :)

    "Unfortunately, in my testing, no native dom node reports anything as
    typeof "function", so all checks fall to the String coercion."

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

    i - s - H - o - s - t - M - e - t - h - o - d. There you go. :)

    "The only assumptions made here are that calling the String constructor
    on native dom properties/methods is safe."

    Native dom properties/methods? Regardless, that's not a safe assumption.

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

    i - s - H - o - s - t - M - e - t - h - o - d. There you go. :)

    "I've heard anecdotally that this may "blow up" in some cases, however
    none of these case have surfaced with this implementation. A testcase to
    the contrary would be helpful."

    Show me where it fails. Show me where it fails...

    "Rather than commenting on checkins, a better way to contribute would be
    to help solve this problem."

    And commenting on check-ins is not a way to help solve the problem?

    "While I'm not convinced Node::hasMethod belongs in the library,
    Y.Lang.isFunction could benefit with some help here."

    Well, make up your mind. Do you want more comments or not?

    " GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

    5 days ago

    Anything where typeof results in "unknown".
    Here:
    typeof document.createElement("xml").onreadystatechange; // "unknown"
    document.createElement("xml").onreadystatechange; // boom!"

    Yes, that's a classic.

    "The ES3 specification states that for host object, the result of typeof
    is implementation-dependent. Notable changes are seen between Opera
    versions and IE. Moreover, string conversion of host objects, as stated,
    is not required by ES3 and that can blow up, too."

    That's an abstraction put forth by the specification. Understand that
    and you will understand why "isFunction" has no place in a JS program
    and "hasMethod" won't work for any arbitrary property you throw at it.
    There has to be a contract between the caller and the function, which
    should be documented. Here it is:-

    http://www.cinsoft.net/mylib-doc.asp#ishostmethod

    "Using the value of string converting a host object to determine program
    decisions is ridiculous. No standard requires string conversion of host
    object. The result is nonstandard, proprietary, undocumented. You should
    not be doing that."

    Exactly. Understand that and you never have to test this in another
    browser again. I haven't since around 2001. And not one explosion since.

    "For example, in IE, I can see the string value of alert, which is a
    host method, has "function" in it.
    javascript: alert( String( alert ) )

    My suggestion for helping out with isFunction is to refactor anything
    that uses it to not do that, to deprecate isFunction, and to remove it.
    It is broken by design."

    I suspect you are spitting in the wind. That's almost exactly what I
    told the Dojo people about isFunction and isArray. They still exist to
    this day and are called by about a thousand different functions. New
    functions are constantly added that must discriminate between host
    objects, arrays and Object objects (a trifecta!) It's almost as if they
    go out of their way to run straight into the walls imposed by the
    language. I wonder if anyone working on these "standard" libraries that
    support so many shiny widgets (which unsurprisingly break down, even in
    the handful of "current" browsers they ostensibly support) knows the
    first thing about any of this. I couldn't vouch for them. Not a one.

    "/**
    * Determines whether or not the provided object is a function.
    * Note: Internet Explorer thinks certain functions are objects:
    */

    The comment further indicates that the author believes that getAttribute
    is a function in IE. There is no reason for believing that to be true
    and in fact it is false."

    I remember Resig blogged about it being called without a call operator
    at one point. Of course, he was wrong and blaming his failure to
    understand on voodoo.

    "Y.Lang.isFunction does not and can not, in the general sense, fulfill
    what is promised in its preceding code comment."

    Of course not. It should not be allowed to accept host objects of any
    sort (not even methods). And if it can't accept host objects, what do
    you need it for? Okay, the odd native object that is callable in some
    browsers but not others (e.g. RegExp). So disallow passing those
    objects as well. Once you understand that, you don't design
    "overloaded" functions that must discriminate between regular
    expressions and functions. End of story.

    typeof xyz == 'function'; // What else do you need?

    "It fails due to the reasons that been discussed over the years on
    c.l.js and touched upon here. It boils down to typeof having different
    results with host object and the [[Class]] property being
    implementation-dependent for host object. It fails for other reasons
    where a built-in may have also a [[Call]] property, or be somehow
    callable without having a [[Call]] property (as spidermonkey RegExp)."

    Right. Though I don't know about any Spidermonkey object that is
    callable but does not implement [[Call]] internally. How do you figure
    that? Regardless, this is all well beyond what the YUI authors can (or
    need to) digest.

    "The function is a failed attempt because the author demonstrates
    misleading information about the a callable object being a function. An
    object that is callable is not necessarily a function. Failing to make
    that distinction in a code comment, and, moreover, providing a false
    statement with getAttribute, shows that the author does not know that
    the function is not clear on what can be expected of it.

    As such, use of that function should be avoided."

    As should the author. ;)

    "More details of "isFunction" functions, typeof, and host methods have
    been discussed over the years on c.l.js."

    " msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "

    I can't say as I'm optimistic. I really don't want to read it, but...

    "4 days ago

    The "boom" in your test is a "not supported" JS error due to
    node[method] access on a field of type "unknown", not String conversion."

    Here we go. Any type conversion will do it. Try it!

    "Treating "unknown" as "undefined" resolves this issue and puts the
    hasMethod result inline with other vendor implementations for the
    xmlNode.hasMethod('onreadystatechange') test case."

    Not even close.

    "As I mentioned, while not sold on the Node::hasMethod, we are
    interested in beefing up support for Lang::isFunction."

    Did you not read the previous comments? It doesn't need "beefing up"
    but slaughtering.

    "This discussion would be more appropriate on YUI Forums or within our
    ticket system."

    I suspect it would be just as productive in those venues. :)

    " GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

    4 days ago

    You wrote: "Treating "unknown" as "undefined" resolves this issue and
    puts the hasMethod result inline with other vendor implementations "

    That is completely wrong and false. The unknown type represents ActiveX
    object.

    Didn't you just publish a chapter in book? And you're on the YUI team....

    Unbelievable."

    Indeed. What book would that be? And being on the YUI team is not
    exactly a badge of honor. More of a scarlet letter (Y).

    " msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "

    I know I don't want to continue, but it's like watching a train wreck...

    "4 days ago

    Thanks Garrett."

    :)

    "Calling Node::hasMethod against your xml test case is now "false", as
    expected."

    Oh God. Expected by whom?

    "Please file a bug for any failing case you have with this
    implementation. Calling it "wrong" doesn't get any closer to a resolution."

    Show me where it fails; show me where if fails; show me, show me, show
    me... Arrgh!! Not even an attempt at understanding. None of the
    previous registered at all? It's like what one of the Dojo team members
    told me: I'm not too good with abstractions. How can you write software
    if you aren't "too good" with abstractions? Well, badly of course (and
    Dojo is certainly bad).

    " GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081

    4 days ago

    Quote: "Calling Node::hasMethod against your xml test case is now
    "false", as expected."

    No, and for example, a true result for:-
    typeof hostObject.property === "unknown"

    - is not an indication that the property is undefined; quite the
    contrary. In IE, some host objects are implemented as ActiveX objects.
    When an ActiveX object is supplied to typeof operator, the result is
    "unknown"."

    When a _property_ of an ActiveX object... We went over this.

    "And so the example typeof hostObject.property === "unknown" would be
    indicative that the property is an ActiveX object."

    Yes, it is a specific type of ActiveX object that is only found in
    JScript implementations as a _property_ of other types of ActiveX
    objects (which do not have "unknown" types themselves).

    "This matches behavior documented in MS-ES3, for SafeArray."

    That's the one.

    "MSDN links are broken, but a copy of MS-ES3 may be found on the FAQ:
    http://jibbering.com/faq/#resources"

    That was four days ago. The line seems to have gone dead. Hopefully
    YUI will follow suit. As it is full of UA sniffing, I'm sure it will.
    It's not like it is setting the world at present.

    If that all sounds harsh, realize that I have to deal with these things
    constantly. I don't mind as I get paid dearly for it. But I feel for
    the clients. YUI, Dojo, etc. projects shouldn't require a high-end JS
    consultant on permanent standby. Aren't they supposed to make things
    _easier_, saving tine and money? I know for sure it doesn't pan out
    (except for me). These things are gold. If I were selfish, I wouldn't
    say a word, would I? Think about that before whining about my criticism(s).
     
    David Mark, May 22, 2010
    #1
    1. Advertising

  2. On May 22, 5:11 pm, David Mark <> wrote:
    > [...]


    I'm curious to why you bother. The subjects of your criticism don't
    understand the language in theory yet are trying to put it into
    practice and also show no willingness to improve on that situation.
    Why not just let them collapse in upon themselves if that is what they
    are destined to do anyway as you've claimed?
     
    Michael Haufe (\TNO\), May 23, 2010
    #2
    1. Advertising

  3. David Mark

    David Mark Guest

    Michael Haufe ("TNO") wrote:
    > On May 22, 5:11 pm, David Mark <> wrote:
    >> [...]

    >
    > I'm curious to why you bother.


    Why does anyone bother to do anything? At least I am trying to bring
    about positive change. And it has worked well (if sporadically) over
    the years. Somebody from YUI will see this and you can bet they will
    get the message eventually. In the interim, I predict there will be a
    lot of hissing and moaning on IRC, the term "troll" will be bandied
    about (ironic for IRC dwellers who live below the newsgroups) and
    perhaps a new article will be posted to StackOverflow (or the like); not
    to address the issues, but to question my motivations.

    But notice how jQuery finally removed the UA sniffing, despite Resig's
    obvious misunderstandings about it. Remember his reaction when I first
    told him he was screwing up (and about ten years behind the times).
    This was in 2007. It finally sunk in (about a year later). The
    attribute issues were discussed in that same thread, but they are still
    chewing on those. In 2010. Just for the record, the issues in
    question date back to 1999 (and were never a secret). Granted, I didn't
    publish a GP solution (with appropriate feature testing) until 2007.
    Same for other feature testing tidbits that eventually showed up in
    jQuery, Prototype and countless other small projects. The larger
    dinosaurs (e.g. Dojo, YUI) are slower to move. Their brains are too far
    removed from their tails. ;)

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

    Like tossing a boulder into the ocean, eventually the waves break on
    every shore.

    > The subjects of your criticism don't
    > understand the language in theory yet are trying to put it into
    > practice and also show no willingness to improve on that situation.


    Yes, so one of my motivations is to *warn* developers to steer clear of
    projects like that. You don't think there is a *huge* problem with
    naive developers being taken in by projects like this? I do as I see it
    every day. They end up buying books, T-shirts, attending fanboy
    conferences and never seem to realize that they've been had. It sucks a
    fortune out of the economy (a portion of which ends up in my pocket
    eventually, so I can hardly be criticized for speaking up about the
    problem). In short, if you are developing with YUI, Dojo, etc. and
    don't have a clue what goes on in inside it, you best have someone like
    me on site (or on a short leash). Because when things break, the only
    recourse is to upgrade/downgrade pieces (or all) of the canned software
    and/or ask the authors of the software (as seen in the OP) what they
    think. And as we've seen endlessly, the developers don't know anything.
    ;) On the contrary, reading their source is like reading a coloring
    book for me. A very bad, ugly coloring book with gaudy color, drawing
    outside the lines, etc.

    > Why not just let them collapse in upon themselves if that is what they
    > are destined to do anyway as you've claimed?


    So I should just clam up and let them take everyone else with them.
    Apathy is just not my thing. And the "collapse" won't be complete as
    there will always be dead-enders slaving away at these things. Dojo
    never even bubbled, so there's nothing to collapse, yet that doesn't
    deter its authors (who are hopelessly deluded and blind to their own
    failings).

    Whet is happening should be obvious. iPhones/iPads are a prime example
    of how Joe Consumer is starting to rely less and less on Joe Web
    Developer. Who wants to deal with flaky scripts in a browser when you
    can buy shiny applications from Apple's store? The Web will not be the
    application platform of the future; that much is clear at this point.
    Such proprietary platforms are to the Web as the Web was to the old
    bulletin board systems.

    The incompetents have thrown the game away by concentrating on follies
    like CSS selector queries (five years down the drain), bloated OO
    architecture that bastardizes the language, crappy grid widgets, etc.
    It's all been a huge waste. The Web will never be Windows. And Dojo,
    YUI, etc. will never be Visual Basic.
     
    David Mark, May 23, 2010
    #3
  4. David Mark

    David Mark Guest

    David Mark wrote:
    [...]

    >
    > That was four days ago. The line seems to have gone dead. Hopefully
    > YUI will follow suit. As it is full of UA sniffing, I'm sure it will.
    > It's not like it is setting the world at present.
    >


    That was supposed to read "setting the world ablaze". They do make lots
    of videos of themselves talking about it though. What a colossal waste. :(
     
    David Mark, May 23, 2010
    #4
  5. David Mark wrote:

    > But notice how jQuery finally removed the UA sniffing, despite Resig's
    > obvious misunderstandings about it. Remember his reaction when I first
    > told him he was screwing up (and about ten years behind the times).
    > This was in 2007. It finally sunk in (about a year later).


    This is not the first time you claim your ideas influenced design changes in
    other libraries, particularly jQuery, directly, so I should point this
    fallacy out to you: Post hoc non est propter hoc.¹

    While it is true that you have told him, there is no obvious cause-and-
    effect relationship between your postings and the later change. In fact,
    since Resig is known to despise you, it is more likely that the message sunk
    in through other channels, if at all.

    You should keep that in mind when you observe further such changes.


    PointedEars
    ___________
    ¹ <http://en.wikipedia.org/wiki/Post_hoc_ergo_propter_hoc>
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, May 23, 2010
    #5
  6. David Mark

    David Mark Guest

    Thomas 'PointedEars' Lahn wrote:
    > David Mark wrote:
    >
    >> But notice how jQuery finally removed the UA sniffing, despite Resig's
    >> obvious misunderstandings about it. Remember his reaction when I first
    >> told him he was screwing up (and about ten years behind the times).
    >> This was in 2007. It finally sunk in (about a year later).

    >
    > This is not the first time you claim your ideas influenced design changes in
    > other libraries, particularly jQuery, directly, so I should point this
    > fallacy out to you: Post hoc non est propter hoc.¹


    My Latin is rusty, but you should know that most libraries are using
    isEventSupported these days (as well as other constructs of mine). In
    the case of isEventSupported, the cite is typically to Kangax' blog,
    which links back to me. Same for CSS detection, which usually cites
    Peter's blog, which links back to me. Fair enough?

    Then there the umpteen different bug fixes that were spelled out here,
    then carried over there by Matt Kruse (who also seems to "despise" me).
    Those are well-documented. In fact, several required more than one
    round trip, leading to long threads going on simultaneously (here and in
    the jQuery developer forum). The selected option bug is the most recent
    example. The ActiveX XHR exceptions are another.

    >
    > While it is true that you have told him, there is no obvious cause-and-
    > effect relationship between your postings and the later change.


    Which change are you talking about? Regardless, telling him means he
    heard it from me (first). Can't change that. Do you think he erased
    his memory? Whether others chimed in later is irrelevant. The UA
    sniffing would seem to top the list. What a revelation he had a full
    year later. And what a bizarre coincidence that he used a virtually
    identical script injection test (as seen in My Library). Same for the
    bit that injects a DIV, checks its padding, etc. Almost verbatim, even
    the set to null at the end (which I had long since deemed unnecessary)
    was carried over. And recall that he and Matt Kruse were falling all
    over themselves to get me to post my code (fall of 2007). I did and
    then a year later (jQuery 1.3 IIRC), pieces of it started showing up in
    jQuery. Call me paranoid. :)

    > In fact,
    > since Resig is known to despise you, it is more likely that the message sunk
    > in through other channels, if at all.


    Resig would do well not to despise me as I'm personally responsible for
    cleaning up a number of his messes. And he should really listen more as
    he keeps putting his foot in his mouth in public. I just read where he
    is claiming that you can be "standards-based" in "all browsers" if you
    use the HTML5 doctype. And apparently, he's been slinging that nonsense
    since 2008. Can I help it if he routinely makes a buffoon out of
    himself? All I can do is try to mitigate the damage he does.

    >
    > You should keep that in mind when you observe further such changes.


    No I shouldn't. Who cares?
     
    David Mark, May 23, 2010
    #6
  7. David Mark

    David Mark Guest

    Thomas 'PointedEars' Lahn wrote:
    > In fact,
    > since Resig is known to despise you, it is more likely that the message sunk
    > in through other channels, if at all.
    >


    And, of course, he very recently copped my attributes code and put it in
    his repository. So the idea that his "despising" me would prevent him
    from lifting my stuff is a laughable fallacy in its own right. Think
    about that.

    Furthermore, the whines that erupted when I forced him to remove it all
    painted *me* as the bad guy. Go figure. :)
     
    David Mark, May 24, 2010
    #7
  8. David Mark

    David Mark Guest

    David Mark wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> In fact,
    >> since Resig is known to despise you, it is more likely that the message sunk
    >> in through other channels, if at all.
    >>

    >
    > And, of course, he very recently copped my attributes code and put it in
    > his repository. So the idea that his "despising" me would prevent him
    > from lifting my stuff is a laughable fallacy in its own right. Think
    > about that.
    >
    > Furthermore, the whines that erupted when I forced him to remove it all
    > painted *me* as the bad guy. Go figure. :)


    And to alleviate any doubt about my "claims".

    From jQuery 1.4:-

    // Technique from Juriy Zaytsev
    //
    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);
    if ( !isSupported ) {
    el.setAttribute(eventName, "return;");
    isSupported = typeof el[eventName] === "function";
    }
    el = null;

    return isSupported;
    };

    And when and where was this technique invented? Hopefully you already
    know as it was done here. :)

    As for when, not sure why (in my Host primer) I linked to this
    particular message in the fairly lengthy thread where this was first
    proposed, but here it is:-

    http://groups.google.com/group/comp...0878c7c67c/6641a9bce1e18d7d?#6641a9bce1e18d7d

    Later discussed here:-

    http://groups.google.com/group/comp.lang.javascript/msg/d216c4b1c2b3c7ec

    And then blogged about by Kangax. Think Resig even knew where the idea
    originally came from? Well, he did if he read the blog post carefully
    as I'm rightly credited. It's incontrovertibly my invention.

    Googling "isEventSupported" today comes up with roughly 2000 hits. I'm
    pretty sure Prototype is one of them. YUI too, IIRC. I've seen it in
    other "major" (as well as minor) libraries as well. And here is a
    regurgitation of Kangax' post on the subject:-

    http://blog.strictly-software.com/2009/11/testing-for-browser-event-support.html

    And resting exactly above that code in jQuery 1.4 is this "inject and
    detect" device that I first published in 2007 (and it sure as hell
    wasn't being used by anybody at that time, at least not in public).
    Sort of a double feature. :)

    jQuery(function(){
    var div = document.createElement("div");
    div.style.width = div.style.paddingLeft = "1px";

    document.body.appendChild( div );
    jQuery.boxModel = jQuery.support.boxModel = div.offsetWidth === 2;
    document.body.removeChild( div ).style.display = 'none';
    div = null;
    });

    Note the superfluous set to null at the end.

    And here's one of many similar examples from My Library:-

    var divOuter = createElement('div');
    var divInner = createElement('div');

    offsetIncludesBorder = (function() {
    setStyles(divOuter, {position:'absolute', visibility:'hidden',
    left:'0', top:'0', padding:'0', border:'solid 1px'});
    setStyles(divInner, {position:'absolute', left:'0', top:'0', margin:'0'});
    divOuter.appendChild(divInner);
    body.appendChild(divOuter);
    b = divInner.offsetLeft == 1;
    body.removeChild(divOuter);
    divOuter.removeChild(divInner);
    return b;
    })();

    divInner = divOuter = null;

    Of course, in this case, the set to null is not superfluous. But other
    examples in My Library featured such unneeded code at one time. And
    I've published numerous other examples of similar patterns that featured
    the fairly well-known superfluous null set (since deemed unnecessary).

    Then there's this obvious (and uncredited) imitation:-

    script.type = "text/javascript";
    try {
    script.appendChild( document.createTextNode( "window." + id + "=1;" ) );
    } catch(e){}

    root.insertBefore( script, root.firstChild );

    // Make sure that the execution of code works by injecting a script
    // tag with appendChild/createTextNode
    // (IE doesn't support this, fails, and uses .text instead)
    if ( window[ id ] ) {
    jQuery.support.scriptEval = true;
    delete window[ id ];
    }

    He actually tries to delete a property of a host object (window). As
    noted, IE never gets to that line (at least not to this date), so it
    "works" by coincidence. Can't show him where that fails today, can you?
    Maybe tomorrow... :)

    My slightly longer (and more competent) version can be seen in My
    Library or side by side with this one at:-

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

    And I should give credit to Randy Webb for inspiring mine. As a matter
    of fact, he and Richard are largely responsible for schooling me on the
    basics of feature testing. Without their input, My Library would not
    have been possible. Just as without my input (and influence), jQuery
    would not be able to "work" without UA sniffing or when ActiveX is
    disabled (an fairly notorious example not recounted in this post) and
    neither would "Live" have been "fixed":-

    http://www.neeraj.name/2010/01/14/how-jquery-1-4-fixed-rest-of-live-methods.html

    So, unless you are blind, stupid (or Matt Kruse), I suspect this will
    put the matter to rest once and for all. I didn't even go into all of
    the bug fixes. Kruse likes to take sole credit for those; but of
    course, as seen with the selected option bug, left to his own devices,
    he's hardly capable of fixing (or even diagnosing) anything. I think it
    took about six months or repetition before he realized what I meant by
    "jQuery will blow up in IE with ActiveX disabled". ;)
     
    David Mark, May 24, 2010
    #8
    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. Mike Hnatt
    Replies:
    2
    Views:
    4,556
    Mike Hnatt
    Nov 3, 2003
  2. gavino
    Replies:
    1
    Views:
    369
    Philipp Leitner
    Jul 19, 2006
  3. Sumit
    Replies:
    2
    Views:
    445
    Dhaivat Pandya
    Feb 22, 2011
  4. YUI Custom Events Problem

    , Jul 13, 2006, in forum: Javascript
    Replies:
    5
    Views:
    134
    Richard Cornford
    Jul 14, 2006
  5. Replies:
    3
    Views:
    129
    Richard Cornford
    Aug 11, 2006
Loading...

Share This Page