Re: Help Jquery: unable to register a ready function
On Nov 5, 12:07 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:
Exactly. Their unit tests throw an exception and somebody comes up
with a half-baked plan to patch it with yet another browser sniff.
Prototype looks like a structure ready to collapse as so many hacks
have been piled on top of other hacks. They are reduced to testing
minor version numbers at one point. Of course, nobody seems to use
Prototype anymore (other than with those Rails "helper" things.)
jQuery has been widely mistaken as a viable alternative.
[snip]
You are correct. Pure and unadulterated BS and demonstrably so.
IIRC, it happens only with XML elements (appears they are ActiveX
objects under the hood.) No surprise that jQuery attempts to deal
with such objects. Clearly Resig bumped into my "unknown" bug and
typical jumped to the wrong conclusion, based on guesswork,
meditation, etc.
Here is a slightly modified demonstration that shows how another
property can explode in similar fashion (and how simple it is to test
this case.) This property isn't even a method, so it proves that
Resig's theory about accidentally calling methods by type conversion
is nonsense.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">
window.onload = function(){
var el = document.create Element('div');
document.body.a ppendChild(el);
document.body.i nnerHTML = '';
if(typeof el.offsetParent == 'unknown'){
alert('Warning. About to explode...');
}
alert('offsetPa rent = '+ el.offsetParent );
};
</script>
</head>
<body>
</body>
</html>
Clearly a competently designed and written Web application will never
run into this. However, since MS can change the rules at any time, I
advocate using the typeof operator to test all host object methods.
Clearly Resig prefers voodoo to scientific methods (like testing) or
he would never have published his article.
Not the issue as such (clearly it is being mistaken for another
issue.)
My feeling exactly. I have never finished that article. It is
sickening to think how many people have visited this Fantasyland over
the years and gone on to spread such "wisdom" in the real world. If
there is one guy in the world who should not be talking about feature
testing, it is this guy. Ironic that he is near constantly blithering
about the subject.
A delusion masquerading as a reasoned argument. As you mentioned, the
argument serves only to justify his own incompetence vis-a-vis feature
detection. One of the Prototype twits authored a similar call to
browser sniffing back when that library was the flavor of the day.
People have a right to their own ignorant opinions, but what compels
these people to spread them like they are gospel?
[snip]
And thus, John Resig is both incompetent and incoherent.
Interesting take.
Yes. My experiences with Chrome, Windows Safari, FF3, Opera, etc.
have been similar. Do things right the first time and you don't have
to re-do them.
The title of that article is ironic indeed. Even worse, jQuery's two
main selling points are reduced maintenance and that it is "fast." We
know browser sniffing only creates future maintenance headaches and,
of course, there is no slower way to do anything in browser scripting
than to use jQuery (the design ensures that.) He can rewrite his
silly CSS selector queries until the end of the earth but it won't put
a dent in the overall inefficiency (he is looking at a total rewrite
from scratch to accomplish that.)
Of course. And the purveyors of jQuery, Prototype, etc. ran their
unit tests through it and rejoiced that their code still "worked."
Somehow they see the coincidental circumstances that led to this
latest "success" as validation of their baseless methods. People like
that should not be writing software. Period. They certainly should
not be degrading Web documents with their collective delusions.
He did.
Or paying the slightest attention to anything critical of his work.
His mantra seems to be "stop hating me!" Last time I pointed out an
obvious mistake to him, he responded with the age-old "argument" of
library authors: "where is your way-cool cross-browser library?" Now
that that "platform" has collapsed, he is predictably absent from all
such discussions.
[snip]
And who on earth would take technical advice from a self-described
"JavaScript Ninja?" I wonder if he has a JScript belt too?
I've had the displeasure of talking to him briefly (here) and came to
the conclusion that he is a few sandwiches short of a picnic. But it
is his code, books, blogs, etc. that irk me as he is spreading
outrageous misconceptions.
On Nov 5, 12:07 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:
On Oct 29, 10:14 pm, Conrad Lender wrote:
>
>>
>
>
I found it quite informative, but on its author rather than its subject.
>
>
'Plaster over' rather than "pave over". In solving a small subset of the
>
On 2008-10-29 20:43, David Mark wrote:
That one is my personal favorite [..]
Actually, I thought it was quite interesting.
I found it quite informative, but on its author rather than its subject.
>
He wrote that scripting libraries like JQuery or Dojo are
used, among other things, to "pave over" browser bugs and
incompatibiliti es,
used, among other things, to "pave over" browser bugs and
incompatibiliti es,
'Plaster over' rather than "pave over". In solving a small subset of the
with a half-baked plan to patch it with yet another browser sniff.
Prototype looks like a structure ready to collapse as so many hacks
have been piled on top of other hacks. They are reduced to testing
minor version numbers at one point. Of course, nobody seems to use
Prototype anymore (other than with those Rails "helper" things.)
jQuery has been widely mistaken as a viable alternative.
[snip]
| example:
|
| if ( elem.getAttribu te ) {
| // will die in Internet Explorer
| }
| That line will cause problems as Internet Explorer attempts to
| execute the getAttribute function with no arguments (which is
| invalid). (The obvious solution is to use
| "typeof elem.getAttribu te == 'undefined'" instead.)
>
Now I know that that is pure BS because I have been using tests along
|
| if ( elem.getAttribu te ) {
| // will die in Internet Explorer
| }
| That line will cause problems as Internet Explorer attempts to
| execute the getAttribute function with no arguments (which is
| invalid). (The obvious solution is to use
| "typeof elem.getAttribu te == 'undefined'" instead.)
>
Now I know that that is pure BS because I have been using tests along
the lines of - if(elem.getAttr ibute){ .... } - on Element nodes for
years (at least 5) and have never seen them fail, and I do test/use that
years (at least 5) and have never seen them fail, and I do test/use that
objects under the hood.) No surprise that jQuery attempts to deal
with such objects. Clearly Resig bumped into my "unknown" bug and
typical jumped to the wrong conclusion, based on guesswork,
meditation, etc.
code in (lots of versions of) IE. But still, lets make it easy for
everyone to test the proposition for themselves and so verify its
veracity. A simple test page might be:-
>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">
window.onload = function(){
if(document.bod y.getAttribute) {
alert(
'document.body. getAttribute = '+
document.body.g etAttribute
);
}};
>
</script>
</head>
<body>
</body>
</html>
>
everyone to test the proposition for themselves and so verify its
veracity. A simple test page might be:-
>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">
window.onload = function(){
if(document.bod y.getAttribute) {
alert(
'document.body. getAttribute = '+
document.body.g etAttribute
);
}};
>
</script>
</head>
<body>
</body>
</html>
>
property can explode in similar fashion (and how simple it is to test
this case.) This property isn't even a method, so it proves that
Resig's theory about accidentally calling methods by type conversion
is nonsense.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">
window.onload = function(){
var el = document.create Element('div');
document.body.a ppendChild(el);
document.body.i nnerHTML = '';
if(typeof el.offsetParent == 'unknown'){
alert('Warning. About to explode...');
}
alert('offsetPa rent = '+ el.offsetParent );
};
</script>
</head>
<body>
</body>
</html>
Clearly a competently designed and written Web application will never
run into this. However, since MS can change the rules at any time, I
advocate using the typeof operator to test all host object methods.
Now to start with we need to know what IE's - getAttribute - would do if
it were executed with no arguments. The DOM spec is not that clear,
execute that it says no exceptions will be thrown. It is easy enough to
test, and it turns out that:-
>
alert(''+docume nt.body.getAttr ibute());
>
- alert "null", so the method call returns null. So, if -
elem.getAttribu te - calls the method with no arguments the result is
likely be null. If the result is null then in the above test page the -
if(document.bod y.getAttribute) { - test will be false, the - if - branch
will not be entered and the alert will not be shown. But on every IE
version where I have tried the above test the alert is shown, plus the
alert shows "document.body. getAttribute = function
getAttribute(){[native code]}", not the "null" that would be result of
calling the method with no arguments.
it were executed with no arguments. The DOM spec is not that clear,
execute that it says no exceptions will be thrown. It is easy enough to
test, and it turns out that:-
>
alert(''+docume nt.body.getAttr ibute());
>
- alert "null", so the method call returns null. So, if -
elem.getAttribu te - calls the method with no arguments the result is
likely be null. If the result is null then in the above test page the -
if(document.bod y.getAttribute) { - test will be false, the - if - branch
will not be entered and the alert will not be shown. But on every IE
version where I have tried the above test the alert is shown, plus the
alert shows "document.body. getAttribute = function
getAttribute(){[native code]}", not the "null" that would be result of
calling the method with no arguments.
he would never have published his article.
>
Can you find an IE version that does exhibit this 'issue'? I am pretty
certain that I have tested code that used this test on IE versions from
4 to 8 without issue, so I doubt it.
Can you find an IE version that does exhibit this 'issue'? I am pretty
certain that I have tested code that used this test on IE versions from
4 to 8 without issue, so I doubt it.
issue.)
>
Given that this assertion is demonstrably BS may attitude toward the
previous "demonstrat ed" issue on Safari, in light of my test, leans
heavily toward dismissing that as also being BS.
Given that this assertion is demonstrably BS may attitude toward the
previous "demonstrat ed" issue on Safari, in light of my test, leans
heavily toward dismissing that as also being BS.
sickening to think how many people have visited this Fantasyland over
the years and gone on to spread such "wisdom" in the real world. If
there is one guy in the world who should not be talking about feature
testing, it is this guy. Ironic that he is near constantly blithering
about the subject.
>
So what is this article? If it is a reasoned analysis of future
So what is this article? If it is a reasoned analysis of future
argument serves only to justify his own incompetence vis-a-vis feature
detection. One of the Prototype twits authored a similar call to
browser sniffing back when that library was the flavor of the day.
People have a right to their own ignorant opinions, but what compels
these people to spread them like they are gospel?
[snip]
>
One more quote from Resig's article:-
>
| The point of these examples isn't to rag on Safari or Internet
Explorer
| in particular, but to point out that rendering-engine checks can end
up
| becoming very convoluted - and thusly, more vulnerable to future
| changes within a browser.
One more quote from Resig's article:-
>
| The point of these examples isn't to rag on Safari or Internet
Explorer
| in particular, but to point out that rendering-engine checks can end
up
| becoming very convoluted - and thusly, more vulnerable to future
| changes within a browser.
>
- which can be summarised as 'complexity equals vulnerability'.
- which can be summarised as 'complexity equals vulnerability'.
Certainly complexity will relate to vulnerability, in a very general
sense, but in the context of feature detection if a test is the correct
test, no matter how complex it may be, it will not be vulnerable to
updates in the browsers because significant changes the browsers will
directly impact on the outcomes of those tests, which is the point of
feature detection.
>
From my own experience; when IE 7 was released I was working on a web
application with (at the time) 100,000 lines of client-side code (code
employing nothing but feature detection where it is necessary to react
to divergent environments). The total number of changes in the scripts
needed to accommodate IE 7 was zero. When Chrome was released the total
number of changes necessary to accommodate that was also zero. And last
week QA started testing that application on IE 8. They may take another
week to run through all there tests but so far they have found no
issues, and I have a realistic expectation that they will not (as pretty
much everything that would be likely to be problematic would inevitably
get used in the first day or so).
sense, but in the context of feature detection if a test is the correct
test, no matter how complex it may be, it will not be vulnerable to
updates in the browsers because significant changes the browsers will
directly impact on the outcomes of those tests, which is the point of
feature detection.
>
From my own experience; when IE 7 was released I was working on a web
application with (at the time) 100,000 lines of client-side code (code
employing nothing but feature detection where it is necessary to react
to divergent environments). The total number of changes in the scripts
needed to accommodate IE 7 was zero. When Chrome was released the total
number of changes necessary to accommodate that was also zero. And last
week QA started testing that application on IE 8. They may take another
week to run through all there tests but so far they have found no
issues, and I have a realistic expectation that they will not (as pretty
much everything that would be likely to be problematic would inevitably
get used in the first day or so).
have been similar. Do things right the first time and you don't have
to re-do them.
>
Now that is "Future Proof" javascript, and low maintenance javascript.
Now that is "Future Proof" javascript, and low maintenance javascript.
main selling points are reduced maintenance and that it is "fast." We
know browser sniffing only creates future maintenance headaches and,
of course, there is no slower way to do anything in browser scripting
than to use jQuery (the design ensures that.) He can rewrite his
silly CSS selector queries until the end of the earth but it won't put
a dent in the overall inefficiency (he is looking at a total rewrite
from scratch to accomplish that.)
>
>
<snip>
>
Chrome and JQuery made interesting point about User Agent string based
browser detection; Chrome works (more or less) with JQuery because its
authors pragmatically gave it a UA string that would result in most
current browser sniffing scripts identifying it as Safari, and treating
Chrome as Safari is probably the best thing to do if you are going to
script in that style at all. But this means that UA sting based browser
sniffing was effective in this case not because it enabled the accurate
determination of the browser and its version, but instead was effective
precisely because it misidentified the browser and its version.
In those cases, feature tests can help; for the remaining
cases they have no option but to go by browser version.
cases they have no option but to go by browser version.
<snip>
>
Chrome and JQuery made interesting point about User Agent string based
browser detection; Chrome works (more or less) with JQuery because its
authors pragmatically gave it a UA string that would result in most
current browser sniffing scripts identifying it as Safari, and treating
Chrome as Safari is probably the best thing to do if you are going to
script in that style at all. But this means that UA sting based browser
sniffing was effective in this case not because it enabled the accurate
determination of the browser and its version, but instead was effective
precisely because it misidentified the browser and its version.
unit tests through it and rejoiced that their code still "worked."
Somehow they see the coincidental circumstances that led to this
latest "success" as validation of their baseless methods. People like
that should not be writing software. Period. They certainly should
not be degrading Web documents with their collective delusions.
>
>>
>
>
I think you have missed the point. He observed a weird behaviour in IE,
Though for comic relief, you can't beat this one:
What kind of idiot would delegate the most critical
browser scripting tasks to people like that?
browser scripting tasks to people like that?
I thought it was funny. He found a weird behavior in IE,
and joked about finding a use for it. You didn't take
that seriously, did you?
and joked about finding a use for it. You didn't take
that seriously, did you?
I think you have missed the point. He observed a weird behaviour in IE,
applied an obviously fatly process to the analysis of that behaviour and
that then resulted in his coming to a series of utterly false
conclusions about what the observed behaviour was. Joking about
applications for that behaviour became irrelevant as having
misidentified the behaviour in the first place any proposed applications
of that misidentified behaviour would be worthless even if taken
seriously.
>
And you are likely to ask; his mistake was using an - alert - in the
test. Generally, alerts aren't much use in examining pointing device
interactions in web browsers because they tend to block script execution
(and so real-time event handling) and they can shift focus (keyboard
'enter' goes to the button on the box. Most people learn this lesson
quite early on as they learn browser scripting, as a consequence of
trying things out for themselves and trying to examine how they work.
The BS examples on the 'future proof javascript' page might suggest that
John Resig is not someone who goes in for trying things out for himself
that often.
that then resulted in his coming to a series of utterly false
conclusions about what the observed behaviour was. Joking about
applications for that behaviour became irrelevant as having
misidentified the behaviour in the first place any proposed applications
of that misidentified behaviour would be worthless even if taken
seriously.
>
And you are likely to ask; his mistake was using an - alert - in the
test. Generally, alerts aren't much use in examining pointing device
interactions in web browsers because they tend to block script execution
(and so real-time event handling) and they can shift focus (keyboard
'enter' goes to the button on the box. Most people learn this lesson
quite early on as they learn browser scripting, as a consequence of
trying things out for themselves and trying to examine how they work.
The BS examples on the 'future proof javascript' page might suggest that
John Resig is not someone who goes in for trying things out for himself
that often.
His mantra seems to be "stop hating me!" Last time I pointed out an
obvious mistake to him, he responded with the age-old "argument" of
library authors: "where is your way-cool cross-browser library?" Now
that that "platform" has collapsed, he is predictably absent from all
such discussions.
>
Here is an alternative test page for the IE setTimeout quirk:-
>
Here is an alternative test page for the IE setTimeout quirk:-
>
>
While you may conclude that the reaction to the self proclaimed
"JavaScript Ninja" on this group is biased and personal, in reality it
While you may conclude that the reaction to the self proclaimed
"JavaScript Ninja" on this group is biased and personal, in reality it
"JavaScript Ninja?" I wonder if he has a JScript belt too?
is mostly a direct reaction to what he writes/does, and a reaction
informed by pertinent knowledge and experience in the field of browser
scripting.
informed by pertinent knowledge and experience in the field of browser
scripting.
the conclusion that he is a few sandwiches short of a picnic. But it
is his code, books, blogs, etc. that irk me as he is spreading
outrageous misconceptions.
Comment