Help Jquery: unable to register a ready function

[David Mark]

Thanks for your thorough and interesting reply. I agree with much of
what you wrote, so I'll focus on the direct questions.

[e-commerce sites] Every time someone in that set is excluded from
the group from whom money can be taken that is a direct result of a
design decision. [..]
So we come to trade-offs; is the increased turnover that will result from
a more professional presentation greater than the loss in turnover that
may result form designing out the possibility of the user of some
browsers from accessing the site at all? How do you make those
judgments, and who should be making those decisions, and based on what
information, knowledge and experience?

This boils down to the question which user agents an application is
designed to support, and who makes that decision. Only the client is in
a position to decide who to shut out, and he will (or should) base this
decision on his customer base, collected browser statistics, and the

Browser statistics?! Are you kidding?

advice of his technical staff and developers. Amazon will reach a
different conclusion here than, say, YouTube, or a gaming site, or a

They are both public Web sites. The idea that they should make a
conscious decision to "shut out" users is absurd.

portal for Ajax fans. Dropping support for ancient user agents can help

As long as the documents are still usable in those ancient user
agents, then that is fine. But you *cannot* degrade gracefully
through browser sniffing. End of story.

keep the code base managable and reduce the maintainance effort. I would

The last thing that adding a browser sniffing script like jQuery to
your app is going to do is save on maintenance. Scripts like that are
patched to death, so trying to keep up with the ever-changing browser
landscape is an exercise in futility. The more workarounds added to
"fix" unit tests, the worse it gets. Try to remove any of these
patches and the whole thing unravels. And you are going to delegate
these tasks to people who do not understand the first thing about
browser scripting? That is not a sound strategy.

never say that JQuery is suitable for any site; but for some sites the
target audience will be overwhelmingly likely to use one of the browser
versions that JQuery supports.

Absolute rubbish. And even on an Intranet where one configuration of
IE is used, it is still a poorly designed, inefficient and ugly piece
of code. Does that sound like something you want?

For personal sites, the owner gets to decide. A private blog, for
example, would be much less affected by the reactions of the <1% of
visitors whose user agent isn't in JQuery's list.

But there are so many other options out there. What is the
fascination with this crappy little script from three years ago?

Anyway, I wasn't trying to recommend or defend JQuery, I was only
talking about the linked articles.

Instead, you should have been reading the linked articles. If you
didn't follow, then you should have searched the group for the links.
All of this is re-hash.

Perhaps so, but where *is* all that pre-written and tested code? Every

These discussions always devolve into a demand for "pre-written and
tested" code. To have pre-written code, you have to have written some
code at some time that is re-usable. If you don't have that, it is
likely because you have been cobbling together bits of other people's
code.

time somebody asks for a good library (as in collection of code that
helps to deal with browser quirks and incompatibilities), they're told
that there is no such thing. If they dare to mention one of the popular

You know that is not true. In general, general-purpose browser
scripting libraries are a bad idea. Collections of code (good code)
are not a bad idea and have been published (here and other places) by
numerous contributors.

libraries, they get flamed to cinders. If such a collection exists, I

Public contradiction of dubious advice is invariably referred to as
"flaming" by those whose "sensibilities" it offends. If you had spent
months or years in the comfort of your own little vacuum, writing
browser scripts to great accolades from your peers, and then find
yourself summarily contradicted in the real world, it is likely to be
an unwelcome shock. You can react one of two ways (think again or
complain about some perceived hatred and flaming.)

would very much like to know where to find it.

Didn't we just have this discussion?

(snipping your test cases) You're right. I had already tried to
duplicate the problems mentioned by Resig and couldn't reproduce them
either. Maybe the errors only happened with very obscure configurations,

See my post on the subject. It is a behavior that I stumbled upon
years ago. I never wrote a blog entry about it, but I have posted
about it numerous times in this group. John Resig stumbled on the
same thing, failed to understand it at all, and posted his comedy bit
about phantom calls to getAttribute.

or maybe he's just wrong. Who knows. It doesn't really matter though,

He's just wrong. With him, that is virtually always a good
assumption. Never mind how many idiots in the publishing industry
think otherwise.

because the point was that object detection isn't a cure-all for
cross-browser scripting, and I agree with that.

He had no point and therefore proved nothing.

Probably. Still, using bad (or let's be nice and say unreproducible)

No, bad.

examples doesn't necessarily invalidate the main focus of the article,

Certainly it does. The whole thing is an attempt to justify his own
incompetence. The Prototype people have published similarly ill-
conceived rants (my favorite involved the display style.) You have to
wonder why anybody would trust code from any of these "programmers."
I wouldn't take a batch file from any of them, let alone a script that
might turn users away from my site. (!)

or at least the point that I found interesting - which is adding the
JQuery test suite to the Mozilla test suite. It's *possible* that a new

Worthless as jQuery is almost entirely hinged on user agent
detection. Think about that.

browser version could introduce bugs like the ones Resig used in his
examples (even if they didn't exist now), or uncover bugs in the JQuery
library. Testing a browser with a widely used library is a good thing.

See my numerous posts on feature detection and testing. Peter
published a nice blog entry on the subject as well:

http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting

(though the CSS seems to be malfunctioning!)

That's very impressive. In an application of that size, I'd expect to
find issues even without accounting for new browsers. I assume that your

Your expectations are set realistically low. I would expect much the
same from your code at this point (you have a lot to learn.)

requirements are vastly different from those who want to build a flashy
site with moving objects and whistles and bells.

Irrelevant. You don't get more "whistles and bells" than the project
I have spent the last half year on. Yes, moving things, special
effects, etc. can be future-proof (sure as hell not with jQuery
though!)

Looks like he was on the wrong track with his test, and you're the first

He was in the wrong rail yard.

person who's figured it out... (and the quirk looks even weirder now).
I'm not about to defend his misjudgement, I just don't think he took it

That would be difficult. He doesn't do it, so why should you try?

very seriously. He probably considers himself part of the "Web 2.0
wave", whatever that is, so he tossed out a blog entry about a curious

Ah yes, "New Wave JavaScript." He is part of a new wave of
incompetent programmers who insist on "teaching" others how to do
everything in the worst possible way.

quirk without much research, to let the community figure it out and play
with it. I really don't think this could or should be used to discredit
him. What he does in his library is a different matter.

He writes code as he writes blogs (incompetently.) What should he get
credit for? Exhorting and enabling hordes of incompetent Web
developers to add browser scripting to their acts?

As I said, I'm still convinced that checking browser types/versions
can't always be avoided. But since both you and David say that it not

Give me one example where it absolutely *cannot* be avoided.

only CAN be done, but HAS to be done, I'll try a little experiment and
ask the group whenever I'm tempted to write [if browser is MSIE6]. If I
can find solid cross-browser solutions for these problems, I'll gladly
retract my statement.

Then you are a better man than John Resig.

 

[David Mark]

David, I'm not going to continue this discussion with you, until you
decide to skip the insults and at least pretend to be civil. The
constant digs at the "incompetence" of JQuery and its author are also
getting old, and don't need any further comments. But this does:




So, to build a nice, dynamic site one has to build up a collection of
tried-and-tested cross-browser functions first. Of course, getting to
know all the little gotchas will take years, but that's okay, as long as
you don't use a library.
Every other language has its libraries and module archives; but we're
different. We're building it all ourselves. Because the library writers
are all "incompetent".



If you're hinting at your own library (again), I'll have to reply
(again) that without a Free Software license it's not much use for most
people. If we're following the previous pattern, this is the point where
you get angry with me.



It's not:http://peter.michaux.ca/articles/omg-that-blog-is-old-school

Great idea, btw.

  - Conrad

 

[David Mark]

David, I'm not going to continue this discussion with you, until you
decide to skip the insults and at least pretend to be civil. The

I don't care what you do. Do you really think I am interested in your
views about feature detection?

constant digs at the "incompetence" of JQuery and its author are also
getting old, and don't need any further comments. But this does:

Old to you perhaps. Maybe because you are constantly bringing up that
miserable script.

So, to build a nice, dynamic site one has to build up a collection of
tried-and-tested cross-browser functions first. Of course, getting to

Certainly helps.

know all the little gotchas will take years, but that's okay, as long as
you don't use a library.

Same old bullshit. All or nothing. Black or white. Pardon my
French, but what the **** is wrong with you?

Every other language has its libraries and module archives; but we're

What do archives have to do with anything?

different. We're building it all ourselves. Because the library writers
are all "incompetent".

You just don't get it. General-purpose browser scripting libraries
are largely a stupid idea. The more general they are, the more
problems they try to solve, the worse they get. Several have engaged
in an "arms race" over the last few years to be the ultimate, way-cool
Ajax library. They all use browser sniffing to include features that
can never work on the Web and then add the caveat that it only "works"
with four browsers (they conveniently forget to mention that it will
likely blow up in everything else.) Poor Web Trash.

If you're hinting at your own library (again), I'll have to reply

I am "hinting" at the fact that we just discussed this topic. I have
never, nor will I ever, pushed my library in here. That would be
pretty silly as, for one, the online builder is still a Beta. For
two, ever since I put that thing up, I am way to busy for such charity
work. Such is the way of the world.

(again) that without a Free Software license it's not much use for most

LOL. I knew it. Tell me, why should I give any part of it to you for
free? Not just you in particular, but any average rude and
aggravating free-loader.

people. If we're following the previous pattern, this is the point where
you get angry with me.

You couldn't be more mistaken. Hey, I'm thinking friends for life.
What do you say?

It's not:http://peter.michaux.ca/articles/omg-that-blog-is-old-school

Ah, I see.

Great idea, btw.

For what?

 

[Eric B. Bednarz]

[...] The only thing that keeps me from considering you and Thomas Lahn
to be jQuery’s most effective – albeit somewhat unintentional –
ambassadors in this NG is having read its source code myself;
accidental readers are unlikely to share this advantage.

That argument is fallacious as it is based on the false assumption that
discussing the shortcomings of a piece of software attracts a majority of
relevant users to exactly that software.

No it isn’t. It is based on the true assumption that name-calling for its
own sake serves no particular purpose other then egotainment (there’s
nothing wrong with that in the context of Usenet, as far as I am
concerned, but it is only amusing for people who are sufficiently
interested in the topic at hand already). It’s not only about what you
say, but how. And if you do not know that how you say something can have
the opposite effect on your environment, well, than I’d think that’s
lack of experience (David Mark has pointed out repeatedly that it is
lack of interest in his environment in his case, so I willingly take his
word on that).

If you like to know, last year I have been looking for convincing
(external) arguments against (the popular) general purpose libraries in
this NG and I couldn’t find any for the target audience. At least, not
in the broad sense, by – more or less – complete thread (‘the community
has spoken, professionally’). Just like in this thread, there’s usually
just Richard, very verbose, very accurate, very professional (which is
to say, sharp, but not ridiculous, and also very lonely at all of that),
and, implicitly, very expensive, or there would be more of the same
quality. And a lot of noise.

 

[Eric B. Bednarz]

You hate something I have never heard of more than jQuery.

You could just stop posting until you know better, how about that?

What does he have to do with it?

Sorry to throw you in the same basket. Apparently he isn’t too cheap to
consult a proper nntp server, my mistake, probably.

Do you think he is the only other
member of the group to question the competence of the jQuery project?

Oh no. The valuable information just didn’t originate from either of you.

Perhaps you are reading a different newsgroup?

Now *that* is more interesting in more senses than you could ever
understand. And the answer is certainly yes.

 

[Thomas 'PointedEars' Lahn]

On 2008-11-04 19:35, David Mark wrote:
Conrad Lender wrote:
Here's an example of where object detection fails and feature testing
can help: dynamic creation of radio buttons.

var radio = document.createElement("input");
radio.type = "radio";
radio.name = "xy";
out(radio.name); // a debugging function
target.appendChild(radio);

IE will follow all the steps, and the debug content will correctly read
"xy". As soon as we add the new element to the page, however, the "name"
attribute will be missing. As it turns out, IE can't set the "name"
attribute of radio buttons at runtime. To work around that, we could do
a feature test along the lines of

if (radio.outerHTML && radio.outerHTML.indexOf("name=") < 0) {
// use IE's proprietary createElement() version

}
[...] Not like that! [...]
If you've got a better solution, how about telling us?

A better solution to using outerHTML? How about anything?

That's not an answer. Until you actually show me a better solution, I'm
just going to assume that you don't have one.

That would be a mistake, and a logical fallacy, on your part. I think it
was Douglas Cornford who already provided and explained the better solution,
which is, to use the standard createElement() method always but also
explicitly to assign the `name' property to items of the corresponding
collection after the element has been added (CMIIW). IIRC he was pointing
out that the initial step necessary to get to this solution was properly
analyzing the problem in the first place.


PointedEars

 

[Thomas 'PointedEars' Lahn]

On 2008-11-04 19:35, David Mark wrote:
Conrad Lender wrote:
On 2008-11-04 19:35, David Mark wrote:
if (radio.outerHTML && radio.outerHTML.indexOf("name=") <
0) { // use IE's proprietary createElement() version

}
[...] Not like that! [...]
If you've got a better solution, how about telling us?
A better solution to using outerHTML? How about anything?
That's not an answer. Until you actually show me a better solution,
I'm just going to assume that you don't have one.

That would be a mistake, and a logical fallacy, on your part.

Nothing to do with logic; I was just expressing my annoyance at David's
tendency to criticize without helping. "How about anything," indeed.

I think it was Douglas Cornford who already provided and explained
the better solution, which is, to use the standard createElement()
method always but also explicitly to assign the `name' property to
items of the corresponding collection after the element has been
added (CMIIW).

Douglas Crockford or Richard Cornford?

Err, sorry. Richard, of course.

Assuming the latter, I wasn't able to find the post (or page) you're
referring to.

Sorry, I can't tell you how to find it then.

The "corresponding collection", would that be
targetElement.getElementsByTagName("input")?

IIRC, he showed how to create a name iframe and assigned to
window.frames[...]. I presumed it would work for `input'
elements as well (document.forms[...].elements[...]).

I just tried the following,
and collB.length was 0 in IE (vs 1 in standards compliant browsers):

function appendRadioBtn (target, name, value, checked) {
var radio = document.createElement("input");
radio.type = "radio";
//radio.name = "xy";
radio.value = "123";
radio.defaultChecked = checked;
target.appendChild(radio);
var collA = target.getElementsByTagName("input");
collA[collA.length - 1].name = "xy";
}

var trg = document.getElementById("target");
appendRadioBtn(trg, "xy", "123", true);
var collB = document.getElementsByName("xy");
print(collB.length);

Was that what you meant?

Almost.


PointedEars