Why won't my (j)query work?

[David Mark]

For the typical neophyte, CSS selectors are magic. Put in a selector,
get out a collection of matching elements. What could be easier?
Turns out, almost anything would be easier.

For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution. They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s). Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.

Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations. It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).

These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.

http://groups.google.com/group/jquery-dev/browse_thread/thread/31f1592d11c3bbe6

http://groups.google.com/group/jquery-en/browse_thread/thread/23d0f3c908410e3f#

This bit says it all:-

$(':checkbox[name=number]').click(function() {
if ($(this).is(':checked')) alert($(this).val());
});

This is the sort of thing that is sold as "simpler" than basic DOM
scripting. Sure looks like the function body - for example - could be
reduced to something like:-

if (this.checked) alert(this.value);

Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).

A demonstration:-

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

The example uses jQuery, but the rest will fail in similar fashion.
And these issues are just the tip of the iceberg for most of them.
They could even be considered "edge cases" (a recurring theme for
these things), except that there are tons of other mistakes in-
between. These are simply the easiest to demonstrate.

The worst implementation has got to be YUI as its hasAttribute wrapper
treats empty attribute values the same as missing attributes. (!)

<input type="checkbox" checked>

elCheckbox.getAttribute('checked') // '' in most browsers

<input type="checkbox">

elCheckbox.getAttribute('checked') // null in most browsers

YUI3, the latest and "greatest" time-saver from Yahoo will report an
empty string for both. How is that helping? All it does is reinforce
the myth that cross-browser scripting is impossible. I guess for
Yahoo (and the rest of these bums), it _is_ impossible.

No, the query engine in My Library is not perfect either (though it is
much closer than the rest of these things), but then I never advocated
using CSS selectors to query the DOM in the first place. I spent a
weekend putting the thing together just to see what was involved. My
advice is to avoid it (there are plenty of simpler alternatives for
finding elements).

Furthermore, I didn't bother trying to support _all_ of the selector
types as that's just silly. The "majors" love to tick off the
selectors they "support", but it doesn't really count if they don't
work _reliably_ cross-browser (like gEBI and gEBTN). For those
wondering, if a selector type is on the speed test page, it's
supported.

For aspiring library luminaries, start with a foundation like this:-

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

....and you can write a serviceable query engine (and have some hope of
success in "old" browsers like IE7 and Opera 9). I will transplant
these functions back into My Library when I have a chance (or if there
is a specific request.).

But I still say it is a waste of time (three years and counting for
the "majors" and a couple of weekends for me).

 

[Thomas 'PointedEars' Lahn]

For the typical neophyte, CSS selectors are magic. Put in a selector,
get out a collection of matching elements. What could be easier?
Turns out, almost anything would be easier.

For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution. They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s). Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.

Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations. It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).

These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.

<http://groups.google.com/group/jquery
dev/browse_thread/thread/31f1592d11c3bbe6>

<http://groups.google.com/group/jquery
en/browse_thread/thread/23d0f3c908410e3f#>

This bit says it all:-

$(':checkbox[name=number]').click(function() {
if ($(this).is(':checked')) alert($(this).val());
});

This is the sort of thing that is sold as "simpler" than basic DOM
scripting. Sure looks like the function body - for example - could be
reduced to something like:-

if (this.checked) alert(this.value);

Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).

JFTR: For those who still buy into the potentially error-prone "Unobtrusive
JavaScript" pattern, since the `click' event bubbles, the rest of it can be
replaced by more efficient code, too (only minimal feature tests included,
not yet optimized):

document.body.onclick = function(e) {
if (!e) e = window.event;
if (e)
{
var t = e.target || e.srcElement;
if (t && t.tagName.toUpperCase() == "INPUT"
&& t.type.toLowerCase() == "checkbox"
&& t.name == "number")
{
if (t.checked) alert(t.value);
}
}
};

Of course, a more reasonable approach would be to handle the `click' event
at the form or fieldset level, preferably through the standards-compliant
backwards-compatible event-handler attribute:

<fieldset onclick="if (typeof event != 'undefined') fsClick(event)">
<input type="checkbox" name="number" value="...">
<input type="checkbox" name="number" value="...">
<input type="checkbox" name="number" value="...">
</fieldset>


PointedEars

 

[David Mark]

For the typical neophyte, CSS selectors are magic.  Put in a selector,
get out a collection of matching elements.  What could be easier?
Turns out, almost anything would be easier.

For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution.  They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s).  Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.

Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations.  It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).

These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.


This bit says it all:-

$(':checkbox[name=number]').click(function() {
     if ($(this).is(':checked')) alert($(this).val());
});

This is the sort of thing that is sold as "simpler" than basic DOM
scripting.  Sure looks like the function body - for example - could be
reduced to something like:-

if (this.checked) alert(this.value);

Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).

JFTR: For those who still buy into the potentially error-prone "Unobtrusive
JavaScript" pattern, since the `click' event bubbles, the rest of it can be
replaced by more efficient code, too (only minimal feature tests included,
not yet optimized):

  document.body.onclick = function(e) {
    if (!e) e = window.event;
    if (e)
    {

No harm done, but I consider it safe to skip this check.

      var t = e.target || e.srcElement;
      if (t && t.tagName.toUpperCase() == "INPUT"
            && t.type.toLowerCase() == "checkbox"
            && t.name == "number")
      {
        if (t.checked) alert(t.value);
      }
    }
  };

But where programmers are architects, Web developers are paper hangers
(they only deal in patterns). This example will make them shriek
about writing assembly language and such.

Of course, a more reasonable approach would be to handle the `click' event
at the form or fieldset level, preferably through the standards-compliant
backwards-compatible event-handler attribute:

  <fieldset onclick="if (typeof event != 'undefined') fsClick(event)">
    <input type="checkbox" name="number" value="...">
    <input type="checkbox" name="number" value="...">
    <input type="checkbox" name="number" value="...">
  </fieldset>

Absolutely. But to the indoctrinated Web developer/code monkey, this
is "old-fashioned" and "obtrusive". They want to play Chess, but
haven't yet mastered Checkers.

The biggest problem I see here is that many of these aspiring
developers refuse to test anything but the latest browsers (it is
considered a waste of time as they just want to Get Things Done). And
since most of the latest now have QSA, it is very easy to write a
script that works perfectly in - for example - IE8, but fails when you
click the Compatibility Mode button (or in IE < 8). Somehow they
think if they blow up enough documents in "broken" browsers/modes,
everyone will upgrade and catch up to their "progressive" designs.

 

[Garrett Smith]

For the typical neophyte, CSS selectors are magic. Put in a selector,
get out a collection of matching elements. What could be easier?
Turns out, almost anything would be easier.

For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution. They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s). Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.

Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations. It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).

These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.

<http://groups.google.com/group/jquery
dev/browse_thread/thread/31f1592d11c3bbe6>

<http://groups.google.com/group/jquery
en/browse_thread/thread/23d0f3c908410e3f#>

This bit says it all:-

$(':checkbox[name=number]').click(function() {
if ($(this).is(':checked')) alert($(this).val());
});

This is the sort of thing that is sold as "simpler" than basic DOM
scripting. Sure looks like the function body - for example - could be
reduced to something like:-

if (this.checked) alert(this.value);

Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).

JFTR: For those who still buy into the potentially error-prone "Unobtrusive
JavaScript" pattern, since the `click' event bubbles, the rest of it can be
replaced by more efficient code, too (only minimal feature tests included,
not yet optimized):

document.body.onclick = function(e) {
if (!e) e = window.event;
if (e)
{
var t = e.target || e.srcElement;
if (t && t.tagName.toUpperCase() == "INPUT"
&& t.type.toLowerCase() == "checkbox"
&& t.name == "number")
{
if (t.checked) alert(t.value);
}
}
};

I buy into that pattern. Works great.

It would be pretty odd to have two elements with different type, yet
same name. Instead, why not have the "number" named elements be the
checkboxes?

Using the getTarget function from APE:-

function bodyClickHandler(ev) {
var target = APE.dom.Event.getTarget(ev);
if(target && target.checked && target.name === "number") {
alert(target.value);
}
}

 

[S.T.]

For the typical neophyte, CSS selectors are magic. Put in a selector,
get out a collection of matching elements...

Your crusade against libraries is well past the boring stage. Ramble
about something else that might actually be interesting to read.

Here ya go:
http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/

Makes sense to me. Well articulated. Points out flaws of some libraries
(JACKPOT!!!!) but manages to be informative at the same time. Seems
like a good role model for you.

 

[David Mark]

David Mark wrote:

For the typical neophyte, CSS selectors are magic.  Put in a selector,
get out a collection of matching elements.  What could be easier?
Turns out, almost anything would be easier.
For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution.  They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s).  Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.
Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations.  It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).
These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.
<http://groups.google.com/group/jquery
dev/browse_thread/thread/31f1592d11c3bbe6>
<http://groups.google.com/group/jquery
en/browse_thread/thread/23d0f3c908410e3f#>
This bit says it all:-
$(':checkbox[name=number]').click(function() {
     if ($(this).is(':checked')) alert($(this).val());
});
This is the sort of thing that is sold as "simpler" than basic DOM
scripting.  Sure looks like the function body - for example - could be
reduced to something like:-
if (this.checked) alert(this.value);
Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).

JFTR: For those who still buy into the potentially error-prone "Unobtrusive
JavaScript" pattern, since the `click' event bubbles, the rest of it can be
replaced by more efficient code, too (only minimal feature tests included,
not yet optimized):

  document.body.onclick = function(e) {
    if (!e) e = window.event;
    if (e)
    {
      var t = e.target || e.srcElement;
      if (t && t.tagName.toUpperCase() == "INPUT"
            && t.type.toLowerCase() == "checkbox"
            && t.name == "number")
      {
        if (t.checked) alert(t.value);
      }
    }
  };

I buy into that pattern.  Works great.

The problem is that document.body is unavailable while the HEAD is
parsing. As most developers insist on putting SCRIPT elements in the
HEAD, this cannot run until the DOM is ready. As IE (among others)
has no DOMContentLoaded event, you must use the load event, which can
delay execution for documents bloated with too many images, IFrames,
flash, etc., so bizarre hacks have come into vogue. Like this "fine
script for the window.onload problem":-

http://javascript.nwbox.com/IEContentLoaded/

function IEContentLoaded (w, fn) {
var d = w.document, done = false,
// only fire once
init = function () {
if (!done) {
done = true;
fn();
}
};
// polling for no errors
(function () {
try {
// throws errors until after ondocumentready
d.documentElement.doScroll('left');

For one, there's not a shred of documentation anywhere that indicates
this method will throw an exception if the DOM is not ready. For two,
this _will_ throw an exception if the method is unavailable.

} catch (e) {
setTimeout(arguments.callee, 50);

So, this will never call back in DOM's without a doScroll method.
Hard to imagine a worse result.

return;
}
// no errors, fire

Fire when ready? Cancel that order.

init();
})();
// trying to always fire before onload

This part is useless in IE (readyState indicates completion at the
same time the load event fires).

d.onreadystatechange = function() {
if (d.readyState == 'complete') {
d.onreadystatechange = null;
init();
}
};
}

This junk has already been copied into jQuery and YUI (and I imagine
others will follow suit). Ostensibly, it is less likely to cause the
dreaded "Operation Aborted" error in IE. Such "logic" has no place in
programming (especially not in browser scripting). Why not design
with reality in mind?

 

[Asen Bozhilov]

Here ya go:http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-bro...

<URL: http://jibbering.com/faq/faq_notes/not_browser_detect.html>

Posted url from you, doesn't says anything new. Looks like a bad
reverse engineering of article in FAQ. Moreover article in FAQ doesn't
make PR of MooTools or anything other libs.

 

[David Mark]

Your crusade against libraries is well past the boring stage. Ramble
about something else that might actually be interesting to read.

As usual, you want to change the subject.

Here ya go:http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-bro...

(Very) old news.

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

Makes sense to me. Well articulated. Points out flaws of some libraries
(JACKPOT!!!!) but manages to be informative at the same time.

You find my postings uninformative compared to that basic
regurgitation?

From one of the comments:-

"For instance, there’s no way to feature-detect if a particular flavor
of CSS opacity is supported or not, since there’s no way in JavaScript
to tell if the opacity was rendered or not."

It seems something was lost in translation. And that guy is
promoting his own browser sniffing code (of course).

Then there's this comment:-

"I’d also caution that user-agent sniffing isn’t as fragile as you
make it out to be. Any program, when written poorly and without the
proper amount of insight, is bound to fail. Many user-agent sniffs do
fall into that category but that doesn’t mean it can’t be done
properly (for instance, I show a safe way to do so in my book)."

LOL. Don't buy _that_ book. And BTW, these comments are from
_today_.

 Seems
like a good role model for you.

More like another wannabe.

 

[JR]

For the typical neophyte, CSS selectors are magic.  Put in a selector,
get out a collection of matching elements.  What could be easier?
Turns out, almost anything would be easier.

For the typical library author, attribute handling is also magic, so
they never got close to creating a reliable query solution.  They all
fail in similar ways, varying slightly with the specific
misconceptions of their respective author(s).  Not unexpectedly, years
of slap-dash debugging by hapless users and contributors has failed to
fix the problems (none has a clue what is going on under the hood).
If they can't fix attr, they sure as hell can't fix the queries.

Now they want to deprecate (on paper) every browser that fails to meet
their warped expectations.  It's ironic that such a move makes them
virtually superfluous (take away "Sizzle" and all that is left of
jQuery is an ill-advised, "overloaded" clunker of an OO DOM
interface).

These issues come up over and over in the various mailing lists for
the "major" libraries. They are usually answered with guesswork (e.g.
try this instead) or ignored.

http://groups.google.com/group/jquery-dev/browse_thread/thread/31f159...

http://groups.google.com/group/jquery-en/browse_thread/thread/23d0f3c...

This bit says it all:-

$(':checkbox[name=number]').click(function() {
     if ($(this).is(':checked')) alert($(this).val());

});

This is the sort of thing that is sold as "simpler" than basic DOM
scripting.  Sure looks like the function body - for example - could be
reduced to something like:-

if (this.checked) alert(this.value);

Smaller, more readable, no function calls, no guesswork about what
goes on in those functions and it's impervious to jQuery "upgrades".
It's even less typing (as if that was ever a rational concern).

A demonstration:-

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

The example uses jQuery, but the rest will fail in similar fashion.
And these issues are just the tip of the iceberg for most of them.
They could even be considered "edge cases" (a recurring theme for
these things), except that there are tons of other mistakes in-
between.  These are simply the easiest to demonstrate.

The worst implementation has got to be YUI as its hasAttribute wrapper
treats empty attribute values the same as missing attributes. (!)

<input type="checkbox" checked>

elCheckbox.getAttribute('checked') // '' in most browsers

<input type="checkbox">

elCheckbox.getAttribute('checked') // null in most browsers

YUI3, the latest and "greatest" time-saver from Yahoo will report an
empty string for both.  How is that helping?  All it does is reinforce
the myth that cross-browser scripting is impossible.  I guess for
Yahoo (and the rest of these bums), it _is_ impossible.

No, the query engine in My Library is not perfect either (though it is
much closer than the rest of these things), but then I never advocated
using CSS selectors to query the DOM in the first place.  I spent a
weekend putting the thing together just to see what was involved. My
advice is to avoid it (there are plenty of simpler alternatives for
finding elements).

Furthermore, I didn't bother trying to support _all_ of the selector
types as that's just silly.  The "majors" love to tick off the
selectors they "support", but it doesn't really count if they don't
work _reliably_ cross-browser (like gEBI and gEBTN).  For those
wondering, if a selector type is on the speed test page, it's
supported.

For aspiring library luminaries, start with a foundation like this:-

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

...and you can write a serviceable query engine (and have some hope of
success in "old" browsers like IE7 and Opera 9).  I will transplant
these functions back into My Library when I have a chance (or if there
is a specific request.).

But I still say it is a waste of time (three years and counting for
the "majors" and a couple of weekends for me).  

I had a very sad realization after reading that Microsoft and Nokia
have adopted jQuery (I didn't know that):
http://www.eweek.com/c/a/Applicatio...-Adopts-OpenSource-jQuery-JavaScript-Library/

The worse part is that the jQuery team will keep control.

On top of that, the jQuery's creator, John Resig, works side by side
with Brendan Eich, the creator of Javascript and CTO at the Mozilla
Corporation. Geez, I had goose bumps just for thinking about what all
these facts could interfere with the development of the next versions
of IE and Firefox. If these two companies adapt their browsers to work
smoothly with jQuery, or at least to not fail with jQuery, then I
suppose the rest of the browser vendors would blindly follow the
giants.

It's not a promising start for 2010...

 

[David Mark]

<URL:http://jibbering.com/faq/faq_notes/not_browser_detect.html>

Posted url from you, doesn't says anything new. Looks like a bad
reverse engineering of article in FAQ. Moreover article in FAQ doesn't
make PR of MooTools or anything other libs.

Speaking of MooTools. Remember they used getBoxObjectFor to
"identify" FF? Then they found out that particular method was
deprecated. They actually issued a _recall_ with this statement:-

"We have overhauled our browser detection to be based on the user
agent string. This has become the standard practice among JavaScript
libraries because of potential issues as Firefox 3.6 demonstrates."

Browser detection has _become_ the standard practice? Who knew? I
thought it went out with the last century.

"As browsers grow closer together, looking at “features” to separate
them will become more difficult and risky. From this point forward,
browser detection will only be used where it would be impossible not
to, in order to give the consistent experience across browsers that
one would expect from a world-class JavaScript framework."

Unbelievable. But then, I suppose such confused waffling is
predictable as the authors of MooTools have no idea what they are
doing.

http://www.flickr.com/photos/7825776@N04/2347642183/sizes/o/

 

[David Mark]

[...]

I had a very sad realization after reading that Microsoft and Nokia
have adopted jQuery (I didn't know that):http://www.eweek.com/c/a/Application-Development/Microsoft-Adopts-Ope...

AFAIK, they just include the script (whatever version is handy) in
their Visual Studio distribution. But there was much rejoicing in
jQuery-land when this was announced. They seemed sure they "won"
something.

The worse part is that the jQuery team will keep control.

Yeah, that's some team they've got there. I'm reminded of the
football coach who, when asked about his team's execution, responded:
"I'm all for it."

On top of that, the jQuery's creator, John Resig, works side by side
with Brendan Eich, the creator of Javascript and CTO at the Mozilla
Corporation.

Then how is it he is so clueless about the language? And, as for side
by side, I imagine Resig's office is nowhere near the executive floor
(probably in the evangelical complex).

Geez, I had goose bumps just for thinking about what all
these facts could interfere with the development of the next versions
of IE and Firefox.

Don't worry, browser developers don't bend for code monkeys.

If these two companies adapt their browsers to work
smoothly with jQuery, or at least to not fail with jQuery, then I
suppose the rest of the browser vendors would blindly follow the
giants.

There's no way to pin down what jQuery does. It changes constantly as
they "discover" new issues (e.g. the decade-old MSHTML attribute
problem was recently a hot topic).

It's not a promising start for 2010...

No, I think interest in jQuery (and things like it) is waning.
Ironically IE8, which came out just after the MS announcement, is a
big reason.

 

[Garrett Smith]

Your crusade against libraries is well past the boring stage. Ramble
about something else that might actually be interesting to read.

Here ya go:
http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/


Makes sense to me. Well articulated. Points out flaws of some libraries
(JACKPOT!!!!) but manages to be informative at the same time. Seems
like a good role model for you.

Pointing out the logical fallacy of affirming the consequent.

The "I didn't mean to pick on moo" is limp.

 

[Garrett Smith]

[...]

I buy into that pattern. Works great.

The problem is that document.body is unavailable while the HEAD is
parsing. As most developers insist on putting SCRIPT elements in the
HEAD, this cannot run until the DOM is ready. As IE (among others)
has no DOMContentLoaded event, you must use the load event, which can
delay execution for documents bloated with too many images, IFrames,
flash, etc., so bizarre hacks have come into vogue. Like this "fine
script for the window.onload problem":-

That is not a problem.

Either add the callback to `document` or put the script at the bottom.

No problem.

 

[David Mark]

Pointing out the logical fallacy of affirming the consequent.

The "I didn't mean to pick on moo" is limp.

No question, especially given what follows:-

"I really didn’t mean to pick on MooTools when I first started writing
this post. It just happens to present a really good learning
opportunity for other developers. The MooTools developers are smart
folks who I’m sure are continuing to work to improve their library and
actively support their large user base. We all go through a similar
learning curve, and we can all learn from one another."

Why are these guys so obsequious? The MooTools developers are
incompetent and never mind their "large user base". And the "learning
curve" comment is priceless. It's almost 2010. Perhaps it is the
year they make contact (with reality).

I posted a comment, but according to the author (who is trying to sell
a book), comments are "heavily moderated". I bet.

"You are both (very) late to the ball. This (very similar) article is
from the turn of the century.

http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

And yes, you can detect which opacity style to use:-

http://perfectionkills.com/feature-testing-css-properties/

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

....and the idea of a script loader (another one?!) using browser
sniffing is crazy. Change the design to suit reality; don’t impose
your delusions on the general public. Or just forget it."

 

[David Mark]

[...]>> I buy into that pattern.  Works great.

The problem is that document.body is unavailable while the HEAD is
parsing.  As most developers insist on putting SCRIPT elements in the
HEAD, this cannot run until the DOM is ready.  As IE (among others)
has no DOMContentLoaded event, you must use the load event, which can
delay execution for documents bloated with too many images, IFrames,
flash, etc., so bizarre hacks have come into vogue.  Like this "fine
script for the window.onload problem":-

That is not a problem.

Either add the callback to `document` or put the script at the bottom.

You mean window.onload? Sure. But you still end up with two
different behaviors (one before and one after load), which often
mandates hiding parts of the document during load.

But I was presenting the "problem" as the typical framework developer
sees it. I suggested the bottom dwelling script recently and was told
that the "progressive enhancement folks" would have a fit over it (and
requiring two pastes is such an ugly imposition).

No problem.

They'll carp about DOMContentLoaded too.

 

[Garrett Smith]

Thomas 'PointedEars' Lahn wrote:
David Mark wrote:

[...]>> I buy into that pattern. Works great.

The problem is that document.body is unavailable while the HEAD is
parsing. As most developers insist on putting SCRIPT elements in the
HEAD, this cannot run until the DOM is ready. As IE (among others)
has no DOMContentLoaded event, you must use the load event, which can
delay execution for documents bloated with too many images, IFrames,
flash, etc., so bizarre hacks have come into vogue. Like this "fine
script for the window.onload problem":-

That is not a problem.

Either add the callback to `document` or put the script at the bottom.

You mean window.onload?

No, I meant document. As in document.onclick, not document.body.onclick.

The function can be placed anywhere, but must come after whereever
APE.dom is defined (dom.js).

<script type="text/javascript" src="dom.js"></script>
<script type="text/javascript">
document.onclick = documentClickHandler;

function documentClickHandler() {
var target = APE.dom.Event.getTarget(ev);
if(target && target.checked && target.name === "number") {
alert(target.value);
}
}
</script>

I would not add a global "documentClickHandler" function. I would also
not add the callback that way. Instead, I would use an event registry.
For example:-

EventPublisher.add(document, "onclick", documentClickHandler);

The reason for using EventPublisher for that is to avoid potential
conflict with other script that uses document.onclick. EventPublisher
replaces document's onclick callback. If an event handler property by
that name already exists, then it is added first to the callbacks array.

 

[David Mark]

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern.  Works great.
The problem is that document.body is unavailable while the HEAD is
parsing.  As most developers insist on putting SCRIPT elements in the
HEAD, this cannot run until the DOM is ready.  As IE (among others)
has no DOMContentLoaded event, you must use the load event, which can
delay execution for documents bloated with too many images, IFrames,
flash, etc., so bizarre hacks have come into vogue.  Like this "fine
script for the window.onload problem":-
That is not a problem.
Either add the callback to `document` or put the script at the bottom.

You mean window.onload?

No, I meant document. As in document.onclick, not document.body.onclick.

Oh. That will work for this example, but it's not a typical
delegation strategy. I don't care for using body either (in most
cases). A fieldset (or other container) would be the best bet.

The function can be placed anywhere, but must come after whereever
APE.dom is defined (dom.js).

Yes, if you are using that script.

<script type="text/javascript" src="dom.js"></script>
<script type="text/javascript">
   document.onclick = documentClickHandler;

   function documentClickHandler() {

Typo (missing ev).

       var target = APE.dom.Event.getTarget(ev);

I can't see using a library for this. And what's with the long-winded
"namespace?" I don't care for that either.

       if(target && target.checked && target.name === "number") {
         alert(target.value);
       }
   }
</script>

I would not add a global "documentClickHandler" function. I would also
not add the callback that way. Instead, I would use an event registry.
For example:-

  EventPublisher.add(document, "onclick", documentClickHandler);

Or just use addEventListener/attachEvent. And why do you have to
pass "onclick"? ISTM that "click" would suffice (as in My Library):-

API.attachDocumentListener('click', documentClickHandler);

And if you act now, I'll throw in:-

D(document).on('click', documentClickHandler);

....you just pay the extra shipping and handling.

The reason for using EventPublisher for that is to avoid potential
conflict with other script that uses document.onclick.

I think this example is getting a little too APE-centric.

 

[Garrett Smith]

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]>> I buy into that pattern. Works great.

[...]
Typo (missing ev).

var target = APE.dom.Event.getTarget(ev);

I can't see using a library for this. And what's with the long-winded
"namespace?" I don't care for that either.

An abstraction is appropriate here.

Regarding the namespace:-

APE - the library namespace.

dom - the dom module. This module may be used with only dependency of
APE.js. APE.js, fully commented and uncompressed, is about two
screenfulls of code (something like 6k, uncompressed, with comments).

dom.Event - for dealing with dom events. If these methods were placed
directly on dom, they would need renaming. Consider:-

APE.dom.getTarget; // what sort of target?
APE.dom.Event.getTarget; // gets an event target.

Does APE.dom.getEventTarget look better? I would have to consider other
methods in the dom.Event package (how they woul be renamed, if they
would make sense, etc).

Local aliases are often useful things:-

(function(){

var dom = APE.dom;
// ...
})();

Or just use addEventListener/attachEvent. And why do you have to
pass "onclick"? ISTM that "click" would suffice (as in My Library):-

EventPublisher is designed as a pure AOP event notification system. That
is why "onclick" must be used. EventPublisher provides functionality for
event notification and has nothing to do with the DOM.

In a way, EventPublisher is like dojo.connect, but without the
complexity buried in the argument typechecking. EventPublisher also
catches and rethrows errors instead of breaking on the first error, as
many libraries do (or did).

So where with dojo, you would have:-
dojo.connect(exampleObj, "onfoo", exampleObj, "bar");

- in APE, that is:-
APE.EventPublisher.addCallback(exampleObj, "onfoo", exampleObj.bar);

It is odd to design a public interface with the callback as a property,
as exampleObj.bar. Instead, the callback can be hidden, and the result
of adding it would look like:-

APE.EventPublisher.addCallback(exampleObj, "onfoo", bar);

As with dojo.connect, any object that has a method can use
EventPublisher. For example, an Animation has an onend.

var a = new Animation(1);
a.run = runA;
a.onend = aEndHandler;
function runA(){
console.log(this.rationalValue); // 0-1.
}

function aEndHandler(){
alert("all done!");
}

And so you can take that, now, and use EventPublisher there instead:-

APE.EventPublisher.add(a, "onend", runA);

Any Animation's `onend` can be listened to by anyone interested in
listening for that.

It should also be possible to extend EventPublisher, so that the code
could be used as:-

a.add("onplay", runA);

Thought that is not necessary. Besides being unnecessary, the name of
the instance method, `add`, should be renamed to `addCallback`.

APE.dom.Event is a different matter. That is specifically for DOM event
handling.

API.attachDocumentListener('click', documentClickHandler);

And if you act now, I'll throw in:-

D(document).on('click', documentClickHandler);

That method seems intended for DOM event handlers.

The D method should probably be renamed to something sensible.

...you just pay the extra shipping and handling.


I think this example is getting a little too APE-centric.

Ideally, I woul just use:-

ev.target

- but that won't work in IE, and may have problems in Safari 2.

It would not be sensible to write every line of code from scratch. An
abstraction is appropriate here.

Instead of repeating:
ev = ev || window.event;
target = ev && ev.target || ev.srcElement;

- I prefer an abstraction like:-


// using a local `Event` alias.
var target = Event.getTarget(ev);

That is much more concise, less cluttered. The method does what it says
and nothing more. I don't have to worry about a browser including text
nodes in the result (Safari 2); the abstraction handles that.

 

[Matt Kruse]

How about, instead of making emotional comments about the person, trying
to refute some of the many factual points that are raised.

David has latched on to one very specific issue that he has researched
and apparently understands well, whereas many other javascript authors
do not. He repeatedly argues this same point ad nauseum, twisting it
slightly to make new arguments and making long, repetitive posts here
which could best be summed up in one sentence - "Correctly handling
attributes requires considering some special cases and browser quirks,
which most libraries and js authors do not do correctly."

Okay, we get it. Can we move on? Clearly, David has identified some
problems in major libraries. Clearly, these problems are not as show-
stopping as he makes them out to be, otherwise the bug trackers for
each project would be filled with complaints from users. If the error
results in a css selector engine returning an incorrect result in a
specific case using an attribute selector for a specific tag and
specific attribute, then that's a problem. But clearly not one that
most users will ever encounter, nor justification for throwing out
libraries entirely or declaring their authors inept. Again, "don't
throw the baby out with the bathwater."

He reminds me a bit of Gomer Pyle issuing a citizen's arrest:

What David is doing is publicity, nothing more. He's said he's writing
a book about this stuff, and he is an independent js author trying to
seek attention. He believes that destroying the reputation of the js
libraries will boost his credibility and put him in the position of
respected authority on the matter, which will help him push whatever
it is that he has to sell. It's so transparent that it's just worthy
of an eye-roll at this point.

Matt Kruse

An ignorant person is one who doesn't know what you have just found
out.
-- Will Rogers

Nothing can be so amusingly arrogant as a young man who has just
discovered an old idea and thinks it is his own.
-- Sidney J. Harris

 

[S.T.]

<URL: http://jibbering.com/faq/faq_notes/not_browser_detect.html>

Posted url from you, doesn't says anything new. Looks like a bad
reverse engineering of article in FAQ.

I found it to be a quality article, though I didn't necessarily expect
posters in this particular thread to think so. The 'quickly dismiss'
type reaction from said posters was expected as well.

Moreover article in FAQ doesn't
make PR of MooTools or anything other libs.

That highly technical ~16 page FAQ article on a topic of such narrow
scope *is* the PR for MooTools, jQuery, YUI, etc.

If a thorough understanding of CLJ FAQ represents the alternative to
libraries -- particularly what's related to DOM and AJAX -- the
libraries have an exceptionally bright future.