Why won't my (j)query work?

Diego Perini · Jan 1, 2010

In IE? Absolutely.

In IE the "onreadystatechange" event, notifying "complete" state, is
reached before "onload" even if the page has already being cached,
sometime just few milliseconds but enough for the objective of
IEContentLoaded. There are tests showing that bit. Read the
accompanying instructions and vendor reference before using it
http://javascript.nwbox.com/IEContentLoaded .

David Mark · Jan 1, 2010

In IE the "onreadystatechange" event, notifying "complete" state, is
reached before "onload" even if the page has already being cached,
sometime just few milliseconds but enough for the objective of
IEContentLoaded.

No, a few milliseconds is worthless for the purpose of simulating
DOMContentLoaded (obviously). That's why you have the doScroll hack
in there. BTW, I hope you read my review of _that_ "logic".

Diego Perini · Jan 1, 2010

No, a few milliseconds is worthless for the purpose of simulating
DOMContentLoaded (obviously). That's why you have the doScroll hack
in there. BTW, I hope you read my review of _that_ "logic".

It is not worthless, it accomplish the required task: fire before
"onload". Nobody needs timing there, just need to ensure they can get
ALL the nodes they need at that point without risking (query the
document) !

Yes, that's why I use the "doScroll" which is needed to fire much
early if possible. If not then the "complete" state is used as a fall
back notification. And contrary to what you said it is documented in
the Microsoft references I link to (true or not).

David Mark · Jan 1, 2010

It is not worthless, it accomplish the required task: fire before
"onload".

That's not what people are looking for in a script like this. They
want something to fire when the DOM is ready, which could be seconds
(or even minutes) before the load event fires.

Nobody needs timing there, just need to ensure they can get
ALL the nodes they need at that point without risking (query the
document) !

You might as well use the load event then.

<body onload="...">

Or, if you must look foolish and behind the times, you can go the
"Unobtrusive" (bunk) route:-

window.onload = function() { ... };

Yes, that's why I use the "doScroll" which is needed to fire much
early if possible.

And you can't see the problem with that? Please read my review and
recall that ill-conceived code immediately. You are giving the
library lemmings more bad ideas (and they weren't exactly in short
supply).

If not then the "complete" state is used as a fall
back notification.

Which is tantamount to using onload in IE. Sorry, but there's nothing
new here.

And contrary to what you said it is documented in
the Microsoft references I link to (true or not).

What is documented where?

Diego Perini · Jan 1, 2010

That's not what people are looking for in a script like this. They
want something to fire when the DOM is ready, which could be seconds
(or even minutes) before the load event fires.

Right, "doScroll" can fire seconds or even minutes before "onload".

I was looking exactly for what I wrote, I can't really say what other
needs really, but I assumed they probably needed the same thing. If
they don't get any help from it they can avoid using it.

No because then I cannot the snippet will notify BEFORE "onload", I
would need to change the wording and say "you will be notified at
onload" which as you said already exists, I am currently saying that I
give them a chance to do something before that precise moment...

Maybe hard to understand but that is what I have seen people use it
for, and I have not being given proof of it failing by users up to
now. If you have a test showing it fails I would surely agree with
you.

You might as well use the load event then.

<body onload="...">

Already said that, I want to precede the above handler, and in a cross-
browser moment !

Or, if you must look foolish and behind the times, you can go the
"Unobtrusive" (bunk) route:-

window.onload = function() { ... };

Really, if you know this stuff you perfectly understand there is no
need of waiting an "onload" event either for most things. You can
append elements to body much before the "onload" event. In every
browser that I tested.

IEContentLoaded/DOMContentLoaded serves for a different purpose, they
are needed just to ensure your queries will be executed when all
elements are available. If you used NWEvents delegation you will have
no need for that either. ;-) It doesn't matter how it is used in other
libraries, my scope was clear before the many attempt and test I did
and is clearly written in the few notes.

And you can't see the problem with that? Please read my review and
recall that ill-conceived code immediately. You are giving the
library lemmings more bad ideas (and they weren't exactly in short
supply).

Which is tantamount to using onload in IE. Sorry, but there's nothing
new here.

I repeat, if you want to ensure users to have a chance to precede

What is documented where?

That "doScroll" behavior is documented here:

http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx

these info were already in the link I sent you above. Please read !

I am sure you can easily run the static/dynamic test found in the
original project site.

jdalton · Jan 1, 2010

David,

Please read ( http://groups.google.com/group/comp.lang.javascript/msg/db3f64d3edb78a2d
)
for some issues I had with your "IEContentLoaded" review.
It got lost in between some other rather long replies.
http://groups.google.com/group/comp.lang.javascript/msg/db3f64d3edb78a2d

Thanks,
-JDD

David Mark · Jan 1, 2010

That still leaves a niche for jQuery---it allows to write quite
a few operations in short, nice-to-look-at, easy-to-understand,
functional code.

It is neither nice-to-look-at, nor easy-to-understand. Look at any
non-trivial app and it reads like alphabet soup.

That code may not be very efficient, but in many cases it is
still nicer than raw JavaScript.

Nicer? And it is still _calling_ tons of complex "raw JavaScript".
What does the neophyte do when something goes wrong? The usual
strategy is to "upgrade" the whole interdependent mess, effectively
setting testing back to ground zero. It's a mad strategy (and doomed
to fail).

As long as this is so, many newcomers and even intermediate
coders will flock to jQuery, no matter how many problems they
may (or in many simple cases may not) incur.

Even the simplest jQuery scripts are susceptible to problems.
Virtually every "simple" example out there uses the attr method, which
even the jQuery authors don't understand. The problem is that
newcomers typically test in a few browsers and declare their scripts
working in "all browsers". Also madness.

I think you should write a plug-compatible replacement for
jQuery.

A what?

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

For reference, that is modular where jQuery is monolithic. It makes
it trivial to do progressive enhancement where jQuery makes it
impossible (unless you consider PE to be script or no script).

Also, the OO interface is _optional_ allowing for any "face" to be
painted on top of the functional API. And, last but not least, and
most important for business applications, the cost of ownership is
virtually nil (i.e. it doesn't require wholesale changes every few
months to "keep up" with the latest major browsers). It works with
ten-year-old browsers, just as it works with today's. How many jQuery
authors does it take to support IE8? Read their forum(s) and you will
see that it has been a long, slow, agonizing process to get anywhere
near competent results in just that one browser. In contrast, I
didn't do _anything_ to mine, which was written over a year before the
first IE8 Betas showed up. And most ironic of all, I told Resig
himself what the biggest problem would be with IE8 and how he could
avoid it. Here it is in 2010 and that problem is still biting jQuery
users (hard) while the developers struggle to grasp basic DOM
scripting issues (like _reading_ documents).

http://groups.google.com/group/jquery-dev/browse_thread/thread/e020458f8983fb9a#

http://groups.google.com/group/jquery-dev/browse_thread/thread/fe658871a8bff208#

http://groups.google.com/group/jquery-dev/browse_thread/thread/db8554d10e2c1899#

http://groups.google.com/group/jquery-dev/browse_thread/thread/24c57d4a3a862239#

The $ object should make this very easy.

Mine has that (if you really want it).

http://www.cinsoft.net/mylib-builder.asp

It's an alias for API.getEBCS (get element by CSS selector).
Furthermore, it has the requisite wrapper objects, which are actually
(drum roll please) object-oriented (e.g. you can create new objects
that inherit from them). In contrast, jQuery's single object is just
that. And what an awkward interface it is. Everything is a
collection of nodes, even a single node?

Use those parts
of the API that make sense in jQuery, keep the rest for
compatibility, and add your own parts, like .att(), .prop(),
whatever you think is better.

Way ahead of you.

My Library, Too is a new project that is much
like My Library, but smaller, faster, friendlier, more efficient and
incorporating browser advances made in the last couple of years (e.g.
CSS transitions, QSA, etc.) The first two methods I added to the
element wrapper objects were attr and prop, from:-

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

That's the lowest level. There are higher level methods on top of
those, of course. As for the window wrapper, dimensions (and scroll
position) top the list:-

http://www.cinsoft.net/viewport.asp

And there's the new keyboard monitor, built-in event and proprietary
style detection, etc. None of it should come as much of a surprise.
It's pretty much the last word on all of the basic problems that have
been incompetently re-invented over and over by the various "major"
libraries.

This would make for interesting times, because then people could
instantly test jQuery against the new competition.

jQuery is not a benchmark. And you can already test at least one
aspect of mine (queries) against jQuery and the rest:-

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

Those are all of the pre-QSA versions. Add QSA (about a dozen lines
of code) to My Library and it will trounce all of the latest ones too
(and will actually be _compatible_ for browsers _without_ QSA, which
still must be supported). And watch for a TaskSpeed test page. The
results are quite predictable (mine topsy, jQuery turvy).

Or just go to the builder and click "Test HTML". You can't do (most
of) that with jQuery at all. jQuery doesn't even support multiple box
models, for God's sake (so IE quirks mode is out).

I don't think the API can be protected with copyright, but if
there are any problems here, you could use a fundamentally
different one to start with and leave the $ replacement to the
user.

I wouldn't ape their API. It's a waste of time.

Good new project for 2010?

Sort of.

David Mark · Jan 1, 2010

Do you mean documentation like the one linked to in the nwbox page
abovehttp://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#Comp...

LOL. That's the reference for C++ developers. You are reaching so
far that you've toppled over. It doesn't mean that the IE developers
_must_ throw an exception.

"Returns S_OK if successful, or an error value otherwise"

That's meaningless in this context. Show me where in the IE
documentation it says that the method will _throw_ that exception to
the calling script (and under what circumstances).

"When the content of an element changes and causes scroll bars to
display, the IHTMLElement2::doScroll method might not work correctly
immediately following the content update."

Does that translate to the IE developers throwing exceptions before
the DOM is safe to manipulate (and never throwing them after). Of
course not.

Or this which suggest errors are thrown on properties/methods that
require the document to be completely parsedhttp://msdn.microsoft.com/en-us/library/ms531426%28VS.85%29.aspx#ctl0...

And just where in that massive (and largely irrelevant) document does
it say that? How about a quote?

Or this implementation which states it may return an errorhttp://msdn.microsoft.com/en-us/library/aa703983(VS.85).aspx

Again. A salient quote?

Or that in reality it's been proven that it throws errors ?

Proven to throw errors _when_ and who says IE9 will do the same
thing? All of you guys seem to have the same narrow mindset. How
many versions/configurations of IE have you tested this on? What does
"proof" mean to you? Nobody ever complained to you personally, so it
must work?

This snippet was intended for use on IE only.

Doesn't really matter what it was intended for. As presented, it will
run in everything. And again, what versions of IE and how do you plan
to target them?

Implementers mostly likely use browser sniffs,

In 2010? Those were bad enough in 2001.

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

feature inference,

Object inferences are another form of browser sniffing. What objects
would indicate that doScroll does what you assert it to do?

or
feature detection
to determine if the "doScroll" code should be executed.

Do tell. What feature would you detect?

...

Actually there are instances where onreadystatechange will fire with
readyState "complete" before the load event fires.

Perhaps a millisecond. So what does that help?

I believe it fires early on cached loads but I don't have the
specifics at hand.

As if that matters.

The script has its limitations, for example doScroll() won't throw
errors on secondary documents such as pages loaded in iframes.

Thanks for wasting my time.

However there are workarounds for that.

Do tell. Workarounds for a workaround. Browser scripting doesn't
need this sort of shit. Thanks anyway.

jdalton · Jan 1, 2010

David,

In the post I originally replied to
http://groups.google.com/group/comp.lang.javascript/msg/c8a115d7d7cf87b4?pli=1

You said there wasn't a "shred of documentation anywhere that
indicates
this method will throw an exception".

I believe I have shown at least a shred that implies erroring.
You can read through them on your own time.

As to your "C++ developers" comment:
I mentioned in my post that the link was for a different
implementation.

As to sniffs / object inference / feature detection:
I wasn't judging their usage rather stating how the code is used by
implementers.

As to the "onreadystate" comment.
You originally wrote "readyState indicates completion at the same time
the load event fires"
I was just letting you know it didn't always fire at the same time (in
fact is fires before).

As to your "As presented, it will run in everything" comment:
If you looked at Diego's code and usage examples you would see that is
not the case.

You also wrote "Why not design with reality in mind?".
In reality this is a working solution for at least IE 6-8.

- JDD

David Mark · Jan 2, 2010

David,

In the post I originally replied tohttp://groups.google.com/group/comp.lang.javascript/msg/c8a115d7d7cf8...

You said there wasn't a "shred of documentation anywhere that
indicates
this method will throw an exception".

And, unsurprisingly, there isn't.

I believe I have shown at least a shred that implies erroring.
You can read through them on your own time.

Implies? For whom. What you cited was for C++ programmers (e.g. the
IE browser developers). They can do whatever they want with the
result (including nothing).

As to your "C++ developers" comment:
I mentioned in my post that the link was for a different
implementation.

So you posted something irrelevant and mentioned that it was
irrelevant at the same time. Why?

As to sniffs / object inference / feature detection:
I wasn't judging their usage rather stating how the code is used by
implementers.

And, doesn't it follow that if you can't implement it without browser
sniffing, it's a dead issue (and has been for ten years?)

As to the "onreadystate" comment.
You originally wrote "readyState indicates completion at the same time
the load event fires"

That's true, except for nit-picking over a millisecond or two. You
(and everyone else I hope) know what the implications of that
statement are. This is how time gets wasted (going back and forth
over nonsense). Gee, if you count a millisecond then you might have a
technical point, but nobody is keeping score on that front (and you
are just confusing the central issue of DOM readiness).

I was just letting you know it didn't always fire at the same time (in
fact is fires before).

Thanks for that.

Seems more like you want points for something.

As to your "As presented, it will run in everything" comment:
If you looked at Diego's code and usage examples you would see that is
not the case.

That's not true. I posted the code I reviewed in its _entirety_.

The IEContentLoaded source code

/*
*
* IEContentLoaded.js
*
* Author: Diego Perini (diego.perini at gmail.com) NWBOX S.r.l.
* Summary: DOMContentLoaded emulation for IE browsers
* Updated: 05/10/2007
* License: GPL/CC
* Version: TBD
*
*/

// @w window reference
// @fn function reference
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');
} catch (e) {
setTimeout(arguments.callee, 50);
return;
}
// no errors, fire
init();
})();
// trying to always fire before onload
d.onreadystatechange = function() {
if (d.readyState == 'complete') {
d.onreadystatechange = null;
init();
}
};
}

Nope. Nothing there at all. Hitting View Source (!) reveals a (very)
ugly object inference:-

// only start this for Internet Explorer

if (typeof document.fileSize != 'undefined') {

Is that the "example" you mean? In the source?

You also wrote "Why not design with reality in mind?".

Just quote and cite. Thanks.

In reality this is a working solution for at least IE 6-8.

Even if that were the case (it's certainly not proven), the reality is
that you can't implement it without sniffing and have no way to know
what it will break in the future. A script that seems to work today
per observation only is hardly guaranteed to work tomorrow. You have
to have some shred of a (real) hypothesis or documentation as to why
it should work and why it should continue to work in the future. Your
observations of it working in _your_ IE desktop browsers are worthless
(think how many different configurations each of them has).

And how do you define "working" as well? The same way you define
"proof?" This industry does not need more mindless blithering. Is
this your idea of job security (i.e. doing stupid things for no real
reason to ensure a call back?) Why not investigate the myriad other
options that _are_ grounded in reality?

I've got two words for all of the seemingly endless stream of cocksure
neophytes that want to "argue" endlessly about nothing. Why bother?

Scott Sauyet · Jan 2, 2010

You didn't understand that?

I understand that you somehow think for jQuery, the number of posts is
O(n^2) in respect to the number of active posters. I have no idea how
you got that idea, but I rather doubt it and would love to see your
evidence.

What doesn't make sense is your taking Matt Kruse to task for being
inconsistent on whether the number of posts says anything positive
about jQuery while your yourself are being inconsistent about the very
same thing. You earlier said that the large number of posts
demonstrated problems with jQuery. Why are you now not willing to say
that falling numbers demonstrate increasing competence?

There is a real question of what the number of posts mean. It's clear
that a little-used technology will not likely generate large numbers
of posts, so large numbers do say something about how widespread the
interest in the technology is. But on the other hand, a well-
documented technology with few bugs will generate fewer posts than one
that is buggy or poorly understood, so large numbers also say
something about the lack of quality of a technology. How these two
factors balance against each other, though, that's anyone's guess.

-- Scott

Diego Perini · Jan 2, 2010

And, unsurprisingly, there isn't.

Implies? For whom. What you cited was for C++ programmers (e.g. the
IE browser developers). They can do whatever they want with the
result (including nothing).

So you posted something irrelevant and mentioned that it was
irrelevant at the same time. Why?

And, doesn't it follow that if you can't implement it without browser
sniffing, it's a dead issue (and has been for ten years?)

That's true, except for nit-picking over a millisecond or two. You
(and everyone else I hope) know what the implications of that
statement are. This is how time gets wasted (going back and forth
over nonsense). Gee, if you count a millisecond then you might have a
technical point, but nobody is keeping score on that front (and you
are just confusing the central issue of DOM readiness).

Thanks for that. Seems more like you want points for something.

That's not true. I posted the code I reviewed in its _entirety_.

The IEContentLoaded source code

/*
*
* IEContentLoaded.js
*
* Author: Diego Perini (diego.perini at gmail.com) NWBOX S.r.l.
* Summary: DOMContentLoaded emulation for IE browsers
* Updated: 05/10/2007
* License: GPL/CC
* Version: TBD
*
*/

// @w window reference
// @fn function reference
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');
} catch (e) {
setTimeout(arguments.callee, 50);
return;
}
// no errors, fire
init();
})();
// trying to always fire before onload
d.onreadystatechange = function() {
if (d.readyState == 'complete') {
d.onreadystatechange = null;
init();
}
};

}

Nope. Nothing there at all. Hitting View Source (!) reveals a (very)
ugly object inference:-

// only start this for Internet Explorer

if (typeof document.fileSize != 'undefined') {

Is that the "example" you mean? In the source?

Just quote and cite. Thanks.

Even if that were the case (it's certainly not proven), the reality is
that you can't implement it without sniffing and have no way to know
what it will break in the future. A script that seems to work today
per observation only is hardly guaranteed to work tomorrow. You have
to have some shred of a (real) hypothesis or documentation as to why
it should work and why it should continue to work in the future. Your
observations of it working in _your_ IE desktop browsers are worthless
(think how many different configurations each of them has).

And how do you define "working" as well? The same way you define
"proof?" This industry does not need more mindless blithering. Is
this your idea of job security (i.e. doing stupid things for no real
reason to ensure a call back?) Why not investigate the myriad other
options that _are_ grounded in reality?

I've got two words for all of the seemingly endless stream of cocksure
neophytes that want to "argue" endlessly about nothing. Why bother?

You are just refuting any evidence that has been showed and you still
do not give any failing test case nor a better solution:

* Summary: DOMContentLoaded emulation for IE browsers

Does it mean something to you ? If not read or re-read the complete
accompanying page, I wrote it clearly in the first sentence:

This is an Internet Explorer only method. It does not produce the
expected results on other browsers.
It is meant to be used as an IE alternative in other fine scripts
trying to fix the window onload problem.
It is based on a hack (no doubt about that), but I hope it is an
improvement over previous IE hacks.

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

if you were searching for my old cross-browser solution (knowing you,
I fear in showing so much sniffing, but anyway just to clear up the
confusion I may have created in you and your expectations):

http://javascript.nwbox.com/ContentLoaded/

but if you like to do free reviews and help a bit you should really
look at the implementation I moved to latest NWEvents where I finally
removed all that unwanted browser sniffing of UA:

http://github.com/dperini/nwevents/

the additions/commits of my DOMContentLoaded/IEContentLoaded solution
to nwevents-1.2.3.js were included just a few days ago (on users
request) !

This is the Microsoft citation again, I mean the one the pushed me to
test things instead of just assuming:

http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx

A few methods, such as doScroll, require the primary document to be
completely loaded. If these methods are part of an initialization
function, they should be handled when the ondocumentready event fires.

And yes I (and others) have tested the that method throws errors up
until the page source is completely loaded, even if trickled by server
code, I mean inserting delays in server-side output both through
server scripting flushes and using proxy software like Charles for
analyzing the process.

Then it was tried comparing Microsoft original/suggested HTC solution
and it was found to give the same results/timings.

It is still an "hack" as I wrote in the docs. Have no ways to disagree
on that.

David Mark · Jan 2, 2010

I understand that you somehow think for jQuery, the number of posts is
O(n^2) in respect to the number of active posters.

Dear God. That's what you took from that? It was an _example_.
Threads are trees and trees grow exponentially. As I said: "call it n
squared" (for the sake of argument).

I have no idea how
you got that idea, but I rather doubt it and would love to see your
evidence.

No, you just want to blather about nothing (or there is some sort of
language barrier in play).

What doesn't make sense is your taking Matt Kruse to task for being
inconsistent on whether the number of posts says anything positive
about jQuery while your yourself are being inconsistent about the very
same thing.

I certainly am not.

You earlier said that the large number of posts
demonstrated problems with jQuery.

No, I didn't (and I thought I explained that well enough, even for a
child to understand). The "large number of posts" quote from a year
ago was in response to Matt's assertion that they got more posts than
CLJ because their group was more active. Get it?

Why are you now not willing to say
that falling numbers demonstrate increasing competence?

You've got two different trains of thought crossed up in your brain.
They still get more posts _per active user_ because they can never
seem to answer anything with finality (it's all guesswork). It
doesn't matter if there is one or a million users.

There is a real question of what the number of posts mean.
Obviously.

It's clear
that a little-used technology will not likely generate large numbers
of posts, so large numbers do say something about how widespread the
interest in the technology is.

Yes, somewhat.

But on the other hand, a well-
documented technology with few bugs will generate fewer posts than one
that is buggy or poorly understood, so large numbers also say
something about the lack of quality of a technology.

Bingo! There is clearly nothing well-documented about jQuery and no
real progress on bugs in the last few years (certainly can't
characterize their infestation as a "few bugs"), so I think the cause
of the decline is clear (it has nothing to do with quality).

How these two
factors balance against each other, though, that's anyone's guess.

If you rule out your "quality" argument, what's left?

Dr J R Stockton · Jan 2, 2010

In comp.lang.javascript message <4602e3a1-b2dc-41d1-a32f-d77941291e5d@z4
1g2000yqz.googlegroups.com>, Thu, 31 Dec 2009 18:21:13, David Mark

I have Thunderbird. My stupid provider canceled NNTP years ago
(idiots). Duh, they can you just use Google Groups.

Then use one or more of the inexpensive non-American NNTP providers.

Or even of the free ones.

David Mark · Jan 3, 2010

In comp.lang.javascript message <4602e3a1-b2dc-41d1-a32f-d77941291e5d@z4
1g2000yqz.googlegroups.com>, Thu, 31 Dec 2009 18:21:13, David Mark
<[email protected]> posted:

Then use one or more of the inexpensive non-American NNTP providers.

Or even of the free ones.

I have signed up for eternal-september.org. Will configure TB when I
have a chance. Will be great to get away from this abominable
interface. Whatever could Google be thinking presenting news articles
like this? It's so completely beyond awful that you have to wonder if
anybody there has even tried it. If they did, why in God's name did
they sign-off on it?

Same goes for Adsense. After I complained repeatedly about the "auto-
sign-in" breaking the back button, they tried to fix it. Of course,
now it never signs in, landing inevitably on the sign-in form, with
this blurb above it in yellow:-

"Already signed in? Take me to my account."

....why are they _asking_ me?! Don't they know?

And there is also this link, captioned "What's this?":-

https://www.google.com/adsense/static/en_US/AutoSignIn.html

I knew exactly what it was before I clicked it. They are so utterly
predictable.

Oh well, glad I could help.

Garrett Smith · Jan 3, 2010

Dr said:
In comp.lang.javascript message <4602e3a1-b2dc-41d1-a32f-d77941291e5d@z4
1g2000yqz.googlegroups.com>, Thu, 31 Dec 2009 18:21:13, David Mark

Then use one or more of the inexpensive non-American NNTP providers.

Or even of the free ones.

I have comcast for ISP, but use eternal-september.org for news.

David Mark · Jan 3, 2010

I see your point, but the fact remains that jQuery is incredibly
popular, rightfully or not.

So was Disco.

Trust me when I tell you that it is on its way
(rightfully) down the toilet. Have I been wrong yet?

"Aping" their API is the only chance
to let users easily and directly compare and find what works.

Not really. TaskSpeed is a good example. Of course, when jQuery came
in dead last (by fifty lengths at least) and the rest of the pack
finished a mile behind the "pure" baseline, I heard ugly "Real World"
murmurs creeping in (e.g. the "pure" solutions were somehow
cheating). Some people will see what they want to see, regardless of
reality (see Matt Kruse)

While I assume you are right about all the technical basics, you
may still be overlooking how attractive the jQuery API is for
beginners, probably also for intermediate programmers, and those
are the ones that matter a lot for the market situation.

There's exactly two attractions for the dull and duller set:-

1. Querying by CSS selector
2. "Chaining"

#1 is arguably not a good interface for DOM scripting, but that's as
maybe. Virtually every browser that jQuery "supports" has it built-in
now (QSA, and it simply isn't compatible with jQuery).

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

#2 was always built into the language. Put this at the end of your
method calls:-

return this;

So, it's pretty much over for them for all but the hopelessly deluded
who will eventually self-destruct (like all die-hard cult members).
The same goes for any "cross-browser" script or framework stupid
enough to "support" one wave of browsers at a time (e.g. the latest
major desktop browsers). They are now hopelessly swamped,
particularly those still stuck in the decade before last (sniffing the
UA string).

Forget about the inefficiency. For most typical jQuery
applications it just does not matter, and for the fewer web
sites where jQuery's inefficiency does matter, one can still
offer alternatives.

You are completely wrong. jQuery can be hundreds and even thousands
of times slower than a competently written, context-specific script.
It's outrageous what these "code monkified" sites do to my PC's. And
for what? Most of them don't do anything special at all.

And when responding to user input, scripts need to be as fast as
possible. This is particularly true on mobile devices (which jQuery-
fied sites needn't worry about as they will typically just blow up at
the outset).

Yet another reason is the huge amount of existing jQuery code.

It's all shit. By definition, it would have to be. Don't listen to
idiots who use those "nothing is perfect" or "just being pragmatic"
argument to try to explain away core issues. When the foundation
(reading element attributes and dimensions, viewport measurement,
input monitoring, etc.) shifts _constantly_ (usually because of
incompetence on the part of the authors), it topples the efforts of
the neophytes building on top of it. Then what do _they_ do? See the
various support forums to find out. The end result is typically to
try to replace it with a newer (or older) version, which is a non-
trivial proposition, even for experienced developers with support from
solid QA testers (hardly the norm). Phew! And what if it still
doesn't "work?" Do you see how you could never rely on plug-ins or
anything else written by a third-party jQuery "programmer?" And
there's no system to keep track of compatibility for any of it.
Software just doesn't work like that, even on the desktop where it is
a _far_ easier proposition to wing it.

Only a compatible API can lever that.

You need a shovel for that pile, not a lever.

By the way, I would redefine jQuery's .attr(…) method to work
only with properties.

Yes, explaining that (or anything for that matter) to the deluded
authors (again, see Matt Kruse).

http://groups.google.com/group/jquery-dev/browse_thread/thread/baef5e91bd714033#

It's a cargo cult. Resig's idea of "test-driven development" is to
use tests not to confirm his designs are implemented correctly, but to
shape his designs. It's mixed up and nobody can seem to convince him
otherwise (after three years). He's just a rotten programmer with
abysmal problem-solving skills (and virtually no real experience with
cross-browser scripting) who (unfortunately) stumbled upon success and
adulation from people who don't know any better (e.g. Web
developers). It's retarded whatever development he might have been
capable of. Bit of a loud-mouth too. As for his die-hard followers,
some of them seem genuinely retarded to me.

Wouldn't you have to
be at this point, at least mildly?

For the most part they have done that
themselves already, so the misnomer will have to stay.

Um, it's still a bizarre hybrid last I checked. It throws exceptions
for some attributes, reads attributes for others, steps on still
others and reads straight properties for the majority. It varies from
one version of jQuery to the next and the behavior changes _radically_
in IE8 on clicking the compatibility mode button (which sort of
simulates IE7), which is a large button right next to Refresh. Do you
see the problem with this?

jdalton · Jan 4, 2010

David,

Here are links with quotes this time

http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx#Component_Initialization

A few methods, such as <a>doScroll</a>, require the primary document
to be completely loaded.
If these methods are part of an initialization function, they should
be handled when the ondocumentready event fires.

My earlier comment about doScroll() failing to behave properly on
secondary documents, because it's based on the primary, reinforces the
documentation above.

http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx#ctl00_MTCS_main_ctl53
(suggest errors are thrown on things that require the document to be
completely parsed)

The innerHTML property of the custom element is available once the
oncontentready event has fired.
Therefore, an event handler should be attached to this event in a
Literal Content component that retrieves the innerHTML property of the
custom element. Otherwise, an error occurs, which indicates that the
innerHTML property is not yet available.

So you posted something irrelevant and mentioned that it was
irrelevant at the same time. Why?

The C++ link was to show possible intent carried over from the related
API.

And, doesn't it follow that if you can't implement it without browser
sniffing, it's a dead issue (and has been for ten years?)

I wasn't suggesting/endorsing that implementers use browser sniffing.
I was merely stating that it is one of the techniques used to
determine if they should call their IEContentLoaded() equivalent.
None of the implementers should call the function without attempting
to ensure IE-only use first.

About the "onreadystate" comment:
The "onreadystatechange" is intended as a fallback (worse case).
It will at least be executed before the onload event observers.

About the code usage:
At the top of the page it states "This is an Internet Explorer only
method".

The source code includes nothing to make it self-executing so it's up
to the implementer to determine when the function should be called.

Nope. Nothing there at all. Hitting View Source (!) reveals a (very)
ugly object inference:-

if (typeof document.fileSize != 'undefined') {

Is that the "example" you mean? In the source?

Yes that's one way.

About the technique working:

Even if that were the case (it's certainly not proven),

It has been proven.
http://dl.dropbox.com/u/513327/doscroll.png

Just fire up your VM and try the demos or
http://dl.dropbox.com/u/513327/doscroll.html

A script that seems to work today
per observation only is hardly guaranteed to work tomorrow.

It’s worked for 11 years now.
With Microsoft investing in JavaScript frameworks and nearly all of
them using this technique I think it’s pretty likely to stick around
for another 11 or more.

You have
to have some shred of a (real) hypothesis or documentation as to why
it should work and why it should continue to work in the future.

See above.

I've got two words for all of the seemingly endless stream of cocksure
neophytes that want to "argue" endlessly about nothing. Why bother?

I really dig informed and constructive reviews.
Seeing as you missed docs, notes, and usage context from the post I
don’t think your review would qualify as informed or constructive.

-JDD

David Mark · Jan 4, 2010

David,

Here are links with quotes this time

http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx#Comp...

A few methods, such as <a>doScroll</a>, require the primary document
to be completely loaded.
If these methods are part of an initialization function, they should
be handled when the ondocumentready event fires.

Click to expand...

I've seen that one. IIRC, it is quoted on one of the pages espousing
your advocated strategy. As I said, it does not say that the browser
will throw exceptions before the DOM is ready.

My earlier comment about doScroll() failing to behave properly on
secondary documents, because it's based on the primary, reinforces the
documentation above.

I recognize those words, but...

http://msdn.microsoft.com/en-us/library/ms531426(VS.85).aspx#ctl0...
(suggest errors are thrown on things that require the document to be
completely parsed)

The innerHTML property of the custom element is available once the
oncontentready event has fired.

Click to expand...

Oh, the "oncontentready" event. Get the feeling you are reading the
wrong docs?

Therefore, an event handler should be attached to this event in a
Literal Content component that retrieves the innerHTML property of the
custom element. Otherwise, an error occurs, which indicates that the
innerHTML property is not yet available.

Click to expand...

Yep. Definitely the wrong docs. Literal Content component?!

The C++ link was to show possible intent carried over from the related
API.

It's not entirely out of touch, but close doesn't count with this sort
of stuff. The reality is that (as we've seen) you can't predict what
MS will do in the next version of IE, even when they _do_ document
things (and you apparently don't have any way to target IE anyway).
Seeing as a failure here will be fatal, it is imprudent to bet the
farm on such conjecture.

I wasn't suggesting/endorsing that implementers use browser sniffing.

I didn't say you were. But just what are you suggesting? The example
you cited used an object inference that was completely unrelated to
the doScroll method. It didn't even check if that method existed.
(!) This is the mindset that has resulted in a new jQuery version
every year and the severing of support for anything but the latest
versions of major browsers (in their default configurations). Stop
and think. It's like the last time around for these things, so why
not shock the world and come up with a competent solution? It's been
three years (and ten since IE6 came out) and you still can't even
_read_ documents straight.

I was merely stating that it is one of the techniques used to
determine if they should call their IEContentLoaded() equivalent.

And what method would you recommend? My point has been that there is
no feature test that will indicate anything about this behavior, so
you might as well write it off and investigate the myriad other (sane)
possibilities.

None of the implementers should call the function without attempting
to ensure IE-only use first.

See above. You aren't really adding anything at this point.

About the "onreadystate" comment:
The "onreadystatechange" is intended as a fallback (worse case).
It will at least be executed before the onload event observers.

And that stupid try-catch may still be going around in circles at 50ms
a revolution.

About the code usage:
At the top of the page it states "This is an Internet Explorer only
method".

That's meaningless and irrelevant. The fact is it is a doScroll-
exists-and-throws-exceptions-before-dom-ready method. I told you
there's no feature test for that. End of story, unless you are keen
on banging your head against a wall for no reason.

The source code includes nothing to make it self-executing so it's up
to the implementer to determine when the function should be called.

You are a broken record. Why are you wasting time like this?

Yes that's one way.

....to shoot yourself in the foot.

1. Other browsers have been known to copy IE
2. IE9 may drop that property
3. That property has nothing to do with the task at hand
4. Where is the detection of the doScroll method?

It's the same song and dance; the same miserable tune I've been
hearing from self-proclaimed browser scripting gurus for the last few
years. Look where it's got you.

About the technique working:

It has been proven.http://dl.dropbox.com/u/513327/doscroll.png

That proves nothing. Where is the data that indicates the DOM was
ready when that thing snapped out of its exception cycle? Are you
aware that Operation Aborted (and related maladies) are notoriously
sporadic? I would think that would be obvious by now.

Just fire up your VM and try the demos orhttp://dl.dropbox.com/u/513327/doscroll.html

Fire up my VM?! Do I take that to mean that you haven't even tested
this in Windows?

It’s worked for 11 years now.

It is the height of absurdity for you to cite the age of IE6 in
defense of such hacks. You realize that jQuery is nowhere near
compatible with that browser, right?

And what about year 12?

With Microsoft investing in JavaScript frameworks and nearly all of
them using this technique I think it’s pretty likely to stick around
for another 11 or more.

Microsoft investing in JavaScript (sic) frameworks? Do tell! You do
realize that IE8 broke the jQuery in so many ways that it is now
virtually unusable? They are really looking out for Resig's
interests, huh?

And for the umpteenth time, browser developers do not bend to the will
of code monkeys. We've seen it over and over. Why do you think they
have to keep rewriting large tracts of jQuery (and dismissing last
year's browsers?).

See above.

See above.

I really dig informed and constructive reviews.

You really dig? Are you saying you haven't been informed by my
various reviews? I suggest you read them again. And if you find them
destructive, that's your problem (in every conceivable sense).

Seeing as you missed docs, notes, and usage context from the post I
don’t think your review would qualify as informed or constructive.

I missed nothing.

jdalton · Jan 4, 2010

David,

Oh, the "oncontentready" event. Get the feeling you are reading the
wrong docs?

Therefore, an event handler should be attached to this event in a
Literal Content component that retrieves the innerHTML property of the
custom element. Otherwise, an error occurs, which indicates that the
innerHTML property is not yet available.

Click to expand...

Yep. Definitely the wrong docs. Literal Content component?![/QUOTE]

The documentation is targeted toward behaviors/htc files but reference
the doScroll method of the element API.
Testing confirms that the documentation, related to doScroll, holds
for regular use in browsers and has remained consistent for 11 years.

And what method would you recommend? My point has been that there is
no feature test that will indicate anything about this behavior, so
you might as well write it off and investigate the myriad other (sane)
possibilities.

I disagree. A specific object inference on the method should be
enough.
You have similar in your own code.

About the "onreadystate" comment:

And that stupid try-catch may still be going around in circles at 50ms
a revolution.

The dropbox example I posted is a basic example designed to provide
confirmation that technique works.
A more robust solution could stop repeated calls to the function in an
onload event handler (worse case).

That's meaningless and irrelevant. The fact is it is a doScroll-
exists-and-throws-exceptions-before-dom-ready method. I told you
there's no feature test for that. End of story, unless you are keen
on banging your head against a wall for no reason.

It shows your initial lack of context as you failed to properly read
the post and jumped to unrealistic conclusions.
Again object inference with the "shreds" of documentation and tests
are enough here.

Fire up my VM?! Do I take that to mean that you haven't even tested
this in Windows?

No I did.
I was stating you can fire up a virtual machine/pc and test it on an
image if you had one handy.

It is the height of absurdity for you to cite the age of IE6 in
defense of such hacks. You realize that jQuery is nowhere near
compatible with that browser, right?

It was the age of IE 5.0.
The code reviewed was not jQuery code.

And for the umpteenth time, browser developers do not bend to the will
of code monkeys. We've seen it over and over. Why do you think they
have to keep rewriting large tracts of jQuery (and dismissing last
year's browsers?).

I am not defending jQuery's coding practices.

Developers influence browser development all the time.
The popularity of selecting elements by css selectors helped pave the
way for querySelectorAll().

Some browsers even allow per site compatibility patching.
http://blogs.msdn.com/ie/archive/2008/12/03/compatibility-view-improvements-to-come-in-ie8.aspx

You really dig? Are you saying you haven't been informed by my
various reviews? I suggest you read them again. And if you find them
destructive, that's your problem (in every conceivable sense).

I am referring to your review over IEContentLoaded not the various
others.
http://groups.google.com/group/comp.lang.javascript/msg/c8a115d7d7cf87b4

I missed nothing.

Look again

-JDD

Blue J Ciphertext Program	2	Nov 22, 2023
Survey details won't go through using php, ajax, Mysql	0	Oct 26, 2023
My subroutine won't call within a for and if...is this normal?	1	Jan 25, 2022
Variable won't evaluate correctly in Javascript	4	Jan 29, 2023
JQuery add shadow error	4	Sep 1, 2023
Why does my php code work on some websites but not others.	1	Jan 6, 2023
Hey can anyone tell me why input data wont save in my database?	0	Jun 16, 2024
Seeking co-founders for my company.	3	Sep 8, 2024

Why won't my (j)query work?

Diego Perini

David Mark

Diego Perini

David Mark

Diego Perini

jdalton

David Mark

David Mark

jdalton

David Mark

Scott Sauyet

Diego Perini

David Mark

Dr J R Stockton

David Mark

Garrett Smith

David Mark

jdalton

David Mark

jdalton

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads