Help Jquery: unable to register a ready function

**David Mark** · Oct 28 '08, 06:45 PM

Re: Help Jquery: unable to register a ready function

On Oct 28, 7:50 am, "souporpo...@gm ail.com" <soup_or_po...@ yahoo.com>
wrote:

Hello All
>
I am trying to activate a link using Jquery. Here is my code;

Trying to do what? And you can't do anything useful with jQuery.

You forgot the doctype.

>
<html>
<head>
<script type="text/javascript" src="../../resources/js/
jquery-1.2.6.js"</script>

Remove this.

>
<script language="javas cript" type="text/javascript">
>
$(document).rea dy(function(){ $('.mylink').cl ick(function()
{ $.jPrintArea('# tabularData') }); });

This is the sort of mangled syntax that the jQuery crowd thinks "makes
JavaScript bearable?" This is complete nonsense and about as
inefficient as it gets. And BTW, their "ready" method is known to be
unreliable.

>
jQuery.jPrintAr ea=function(el)
{
alert("hello");
>
var iframe=document .createElement( 'IFRAME');
>
var doc=null;
>
$(iframe).attr( 'style','positi on:absolute;wid th:0px;height:
0px;left:-500px;top:-500px;');
>
document.body.a ppendChild(ifra me);
>
doc=iframe.cont entWindow.docum ent;
>
var links=window.do cument.getEleme ntsByTagName('l ink');
>
for(var i=0;i<links.len gth;i++)
if(links[i].rel.toLowerCas e()=='styleshee t')
>
doc.write('<lin k type="text/css" rel="stylesheet " href="'+links[i].href
+'"></link>');
>
doc.write('<div class="'+$(el). attr("class")+' ">'+$(el).html( )+'</
div>');
>
doc.close();
>
iframe.contentW indow.focus();
>
iframe.contentW indow.print();
>
alert('Printing ...');
>
//wait(1);
>
document.body.r emoveChild(ifra me);
>
}
>
</script>
</head>
<body>
<div id="tabularData ">
<a href="#" class="mylink" name="mylink">P rint this Table</a>
</div>
</body>
</html>
>
When I click on the link I see nothing. I am expecting to see an
alert. Could someone please tell me where
I am going wrong?

Yes. You clearly want to add scripting to your site, but do not know
how. You heard that jQuery would make it really easy and you won't
have to learn anything about ECMAScript, cross-browser issues, etc.
Just wind it up and watch it go, right? It won't work. Yes, lots of
pundits on blogs say it works, but they don't know what they are
talking about.

See the FAQ for some basic examples. That is the best place to start.

**souporpower@gmail.com** · Oct 29 '08, 12:35 PM

Re: Help Jquery: unable to register a ready function

On Oct 28, 2:35 pm, David Mark <dmark.cins...@ gmail.comwrote:

On Oct 28, 7:50 am, "souporpo...@gm ail.com" <soup_or_po...@ yahoo.com>
wrote:
>

Hello All

>

I am trying to activate a link using Jquery. Here is my code;

>
Trying to do what? And you can't do anything useful with jQuery.
>
You forgot the doctype.
>
>
>

>
Remove this.
>
>
>

>

$(document).rea dy(function(){ $('.mylink').cl ick(function()
{ $.jPrintArea('# tabularData') }); });

>
This is the sort of mangled syntax that the jQuery crowd thinks "makes
JavaScript bearable?" This is complete nonsense and about as
inefficient as it gets. And BTW, their "ready" method is known to be
unreliable.
>
>
>
>
>

jQuery.jPrintAr ea=function(el)
{
alert("hello");

>

var iframe=document .createElement( 'IFRAME');

>

var doc=null;

>

$(iframe).attr( 'style','positi on:absolute;wid th:0px;height:
0px;left:-500px;top:-500px;');

>

document.body.a ppendChild(ifra me);

>

doc=iframe.cont entWindow.docum ent;

>

var links=window.do cument.getEleme ntsByTagName('l ink');

>

for(var i=0;i<links.len gth;i++)
if(links[i].rel.toLowerCas e()=='styleshee t')

>

doc.write('<lin k type="text/css" rel="stylesheet " href="'+links[i].href
+'"></link>');

>

doc.write('<div class="'+$(el). attr("class")+' ">'+$(el).html( )+'</
div>');

>

doc.close();

>

iframe.contentW indow.focus();

>

iframe.contentW indow.print();

>

alert('Printing ...');

>

//wait(1);

>

document.body.r emoveChild(ifra me);

>

}

>

</script>
</head>
<body>
<div id="tabularData ">
<a href="#" class="mylink" name="mylink">P rint this Table</a>
</div>
</body>
</html>

>

When I click on the link I see nothing. I am expecting to see an
alert. Could someone please tell me where
I am going wrong?

>
Yes. You clearly want to add scripting to your site, but do not know
how. You heard that jQuery would make it really easy and you won't
have to learn anything about ECMAScript, cross-browser issues, etc.
Just wind it up and watch it go, right? It won't work. Yes, lots of
pundits on blogs say it works, but they don't know what they are
talking about.
>
See the FAQ for some basic examples. That is the best place to start.

You are right. I can't agree with you more. I found the following
vanilla javascript to be working
perfectly. For the benefit of some, I am posting it here. I am
convinced Jquery is not for me. Thanks

var iframe; //global
function printArea (el) {
iframe=document .createElement( 'IFRAME');
var doc=null;
iframe.style.he ight='0px';
iframe.style.wi dth='0px';
document.body.a ppendChild(ifra me);
doc=iframe.cont entWindow.docum ent;
var innerhtml = document.getEle mentById(el).in nerHTML;
doc.write('<htm l><body><div>'+ innerhtml +'</div></body></html>');
doc.close();
iframe.contentW indow.focus();
iframe.contentW indow.print();

setTimeout("doc ument.body.remo veChild(iframe) ",5000);

}
And it is called as printArea('mydi v') where mydiv is the div tag
wrapping around some html.

**RobG** · Oct 29 '08, 01:15 PM

Re: Help Jquery: unable to register a ready function

souporpower@gma il.com wrote:

On Oct 28, 2:35 pm, David Mark <dmark.cins...@ gmail.comwrote:

[...]

>See the FAQ for some basic examples. That is the best place to start.

>
You are right. I can't agree with you more. I found the following
vanilla javascript to be working
perfectly. For the benefit of some, I am posting it here. I am
convinced Jquery is not for me. Thanks
>
var iframe; //global

You seem to be making iframe global so you can call it from setTimeout.
You don't have to do that, you can use a closure instead.

function printArea (el) {
iframe=document .createElement( 'IFRAME');
var doc=null;

There is rarely any need to initialise a variable with null if you are
going to set its value later. Just declare it, its value will be
undefined, which is more-or-less equivalent to null.

iframe.style.he ight='0px';
iframe.style.wi dth='0px';
document.body.a ppendChild(ifra me);
doc=iframe.cont entWindow.docum ent;

Now you've assigned a value to doc, the previous assignment did nothing
useful. It's not really an issue, just that you didn't need to assign
it a value of null.

var innerhtml = document.getEle mentById(el).in nerHTML;
doc.write('<htm l><body><div>'+ innerhtml +'</div></body></html>');
doc.close();
iframe.contentW indow.focus();
iframe.contentW indow.print();
>
setTimeout("doc ument.body.remo veChild(iframe) ",5000);

To use a closure so you don't need the global variable, try:

setTimeout(func tion(){document .body.removeChi ld(iframe)}, 5000);

Untested, but should be OK.

>
}
And it is called as printArea('mydi v') where mydiv is the div tag

div element. :-)

--
Rob

**Matt Kruse** · Oct 29 '08, 06:45 PM

Re: Help Jquery: unable to register a ready function

On Oct 28, 1:35 pm, David Mark <dmark.cins...@ gmail.comwrote:

And you can't do anything useful with jQuery.

You forgot the wink: ;)

You forgot the doctype.

Perhaps intentionally. (For example, when inserting code into an
existing product or service with no doctype, it's best to test without
a doctype).

$(document).rea dy(function(){ $('.mylink').cl ick(function()
{ $.jPrintArea('# tabularData') }); });

This is the sort of mangled syntax that the jQuery crowd thinks "makes
JavaScript bearable?"

No. His formatting was terrible. I would write it like:

$(function(){
$('.mylink').cl ick(function(){
$.jPrintArea('# tabularData');
});
});

ah, yes. Much better.

And BTW, their "ready" method is known to be unreliable.

Really? Under what conditions? Where would someone locate a more
reliable method of determining when the DOM is ready?

Hope that helps!

Matt Kruse

**David Mark** · Oct 29 '08, 07:45 PM

Re: Help Jquery: unable to register a ready function

On Oct 29, 2:39 pm, Matt Kruse <m...@thekrusef amily.comwrote:

On Oct 28, 1:35 pm, David Mark <dmark.cins...@ gmail.comwrote:
>

And you can't do anything useful with jQuery.

>
You forgot the wink: ;)

Why would I wink about that? It is a proven fact. You just have a
(very) short memory.

>

You forgot the doctype.

>
Perhaps intentionally. (For example, when inserting code into an
existing product or service with no doctype, it's best to test without
a doctype).

Oh, I am sure that was the intention.

>

$(document).rea dy(function(){ $('.mylink').cl ick(function()
{ $.jPrintArea('# tabularData') }); });

This is the sort of mangled syntax that the jQuery crowd thinks "makes
JavaScript bearable?"

>
No. His formatting was terrible. I would write it like:

Formatting?! What does that have to do with anything?

>
$(function(){
$('.mylink').cl ick(function(){
$.jPrintArea('# tabularData');
});
>
});
>
ah, yes. Much better.

Much better than what? Look at that BS. Create a big jQuery object,
which is known to have problems with its own arguments (typeof a ==
'array', isFunction, etc.) due to an incredibly ignorant design, then
discard a big jQuery object. Create a big jQuery object, discard a
big jQuery object, create a big jQuery object, discard a big jQuery
object, etc., etc. That's how all of the pathetic examples for this
library read. It encourages people to be as inefficient as possible.
And how many functions are called by the above "better" example?
3000?

And you already know about the browser sniffing and the all-around
incompetence of the author.

http://ejohn.org/blog/future-proofin...ipt-libraries/

That one is my personal favorite, next to the time he asked me for a
"magic flag" to feature test get/setAttribute. Yes, I gave it to him,
but I think he had fled back to gumdrop-land by then.

Though for comic relief, you can't beat this one:

http://ejohn.org/blog/most-bizarre-ie-quirk/

What kind of idiot would delegate the most critical browser scripting
tasks to people like that? In 2008 no less?! And we just had this
discussion a year ago. Did you fall on your head since?

I take it you like to write "plug-ins" for jQuery. How
irresponsible. Are we to congratulate you for volunteering to help
the helpless? Of course not. You are serving up poison in a soup
kitchen.

I gather you like being a Big Fish in a very shallow pond.

>

And BTW, their "ready" method is known to be unreliable.

>
Really? Under what conditions? Where would someone locate a more
reliable method of determining when the DOM is ready?

Google? This group? I have personally published such methods. Peter
has a Blog entry on the subject. Perhaps you were too busy with the
special needs class to notice.

>
Hope that helps!

In a way, I think it did. Care to help dispel any more myths about
jQuery? You do that inadvertently every time you open your mouth in
here.

**Matt Kruse** · Oct 29 '08, 08:35 PM

Re: Help Jquery: unable to register a ready function

On Oct 29, 2:43 pm, David Mark <dmark.cins...@ gmail.comwrote:

And you can't do anything useful with jQuery.

You forgot the wink: ;)

Why would I wink about that? It is a proven fact. You just have a
(very) short memory.

I do useful things with it all the time. That seems to falsify your
theory. *WINK*

$(function(){
$('.mylink').cl ick(function(){
$.jPrintArea('# tabularData');
});

>

});
ah, yes. Much better.

Much better than what? Look at that BS. Create a big jQuery object,
which is known to have problems with its own arguments (typeof a ==
'array', isFunction, etc.) due to an incredibly ignorant design

Ignorant design = true
Problems = Only if you hit the cases where problems might exist, and I
never have except in theory.

>, then
discard a big jQuery object. Create a big jQuery object, discard a
big jQuery object, create a big jQuery object, discard a big jQuery
object, etc., etc.

Computers are fast. Don't optimize just because you feel bad for them
having to work so hard.
There are certainly cases where using jQuery hinders performance.
Don't use jQuery in those cases.
For many problems, jQuery is an inadequate solution.
Don't use jQuery to solve those problems.
That's some revolutionary thinking right there.

And how many functions are called by the above "better" example?
3000?

Yes. Exactly 3000.

Though for comic relief, you can't beat this one:
http://ejohn.org/blog/most-bizarre-ie-quirk/
What kind of idiot would delegate the most critical browser scripting
tasks to people like that?

Delegating the most critical scripting tasks to jQuery may be a
mistake. I use it mainly in controlled environments. Mostly to add
some UI enhancements and to show pictures of bunnies.

I take it you like to write "plug-ins" for jQuery.

I have. My motivation for doing so is probably quite different than
what you imagine.

> How irresponsible.

It's surely right up there with smoking while pregnant and eating live
puppies, both of which I have also done. I like to live on the edge.

Are we to congratulate you for volunteering to help the helpless?

Yes?

> Of course not.

Damn.

> You are serving up poison in a soup kitchen.

[Insert one-up kitchen analogy here]

I gather you like being a Big Fish in a very shallow pond.

[Insert one-up pond analogy here]

And BTW, their "ready" method is known to be unreliable.

Really? Under what conditions? Where would someone locate a more
reliable method of determining when the DOM is ready?

Google? This group? I have personally published such methods. Peter
has a Blog entry on the subject. Perhaps you were too busy with the
special needs class to notice.

I haven't read this group regularly for a while.

In a way, I think it did. Care to help dispel any more myths about
jQuery? You do that inadvertently every time you open your mouth in
here.

Consider using more descriptive words, like "open your big fat mouth".
It will help you to connect with your audience. HTH!

Matt Kruse

**David Mark** · Oct 29 '08, 09:05 PM

Re: Help Jquery: unable to register a ready function

On Oct 29, 4:26 pm, Matt Kruse <m...@thekrusef amily.comwrote:

On Oct 29, 2:43 pm, David Mark <dmark.cins...@ gmail.comwrote:
>

And you can't do anything useful with jQuery.
You forgot the wink: ;)

Why would I wink about that? It is a proven fact. You just have a
(very) short memory.

>
I do useful things with it all the time. That seems to falsify your
theory. *WINK*

Useful according to whom?

>

$(function(){
$('.mylink').cl ick(function(){
$.jPrintArea('# tabularData');
});

>

});
ah, yes. Much better.

Much better than what? Look at that BS. Create a big jQuery object,
which is known to have problems with its own arguments (typeof a ==
'array', isFunction, etc.) due to an incredibly ignorant design

>
Ignorant design = true
Problems = Only if you hit the cases where problems might exist, and I
never have except in theory.

Christ on a crutch. You don't have to have empirical evidence. Look
at the code. You know it won't work on anything but a handful of
modern browsers in their default configurations. You know this, yet
you persist with these sorts of "arguments. " You want to be
different.

>

, then
discard a big jQuery object. Create a big jQuery object, discard a
big jQuery object, create a big jQuery object, discard a big jQuery
object, etc., etc.

>
Computers are fast. Don't optimize just because you feel bad for them
having to work so hard.

Computers are fast?! That is your argument for using such inane and
inefficient patterns? EVERYTHING IS RELATIVE. Tattoo that on your
forehead.

There are certainly cases where using jQuery hinders performance.

And there are certainly cases where incompetence hinders productivity.

Don't use jQuery in those cases.

You had something there, but you stopped three words too late.

For many problems, jQuery is an inadequate solution.

^^^^

You misspelled "any and all."

Don't use jQuery to solve those problems.

Right.

That's some revolutionary thinking right there.

It is yours after all. Your assumption that people who use jQuery to
shield themselves from the intricacies of cross-browser scripting
would be in a position to judge what would be a problem for jQuery is
patently absurd. These people don't know what they are doing. That
is why they chose jQuery in the first place.

>

And how many functions are called by the above "better" example?
3000?

>
Yes. Exactly 3000.

At least 2998 too many.

>

Though for comic relief, you can't beat this one:
http://ejohn.org/blog/most-bizarre-ie-quirk/
What kind of idiot would delegate the most critical browser scripting
tasks to people like that?

>
Delegating the most critical scripting tasks to jQuery may be a
mistake. I use it mainly in controlled environments. Mostly to add
some UI enhancements and to show pictures of bunnies.
>

I take it you like to write "plug-ins" for jQuery.

>
I have. My motivation for doing so is probably quite different than
what you imagine.

Oh, I see you wrote a "context menu" plug-in for jQuery. A popup menu
hard-wired to work only with the alternate mouse button? And it
requires jQuery to work? Whatever your motivation, you are not
helping.

>

How irresponsible.

>
It's surely right up there with smoking while pregnant and eating live
puppies, both of which I have also done. I like to live on the edge.

Advocating a blob of incompetently written, poorly designed, *browser
sniffing* script in 2008 is completely off-base. Your reputation can
join Resig's in the toilet. No amount of stupid asides can change
that.

>

Are we to congratulate you for volunteering to help the helpless?

>
Yes?

See next line.

>

Of course not.

[snip]

>
I haven't read this group regularly for a while.
>

And you apparently forgot everything you learned previously. We just
had this exact discussion a year ago. What are you in self-imposed
exile ever since?

In a way, I think it did. Care to help dispel any more myths about
jQuery? You do that inadvertently every time you open your mouth in
here.

>
Consider using more descriptive words, like "open your big fat mouth".
It will help you to connect with your audience. HTH!
>

Consider what a foolish post this was.

**Matt Kruse** · Oct 29 '08, 09:35 PM

Re: Help Jquery: unable to register a ready function

On Oct 29, 3:58 pm, David Mark <dmark.cins...@ gmail.comwrote:

I do useful things with it all the time. That seems to falsify your
theory. *WINK*

Useful according to whom?

Me. Why would I care if it's useful to you or anyone else?

Problems = Only if you hit the cases where problems might exist, and I
never have except in theory.

Christ on a crutch. You don't have to have empirical evidence. Look
at the code.

Your argument is that it will fail under some cases. My argument is
that those cases don't matter to me. Your argument is theory, mine is
practical.

I'm doing X, and you're arguing that it can't do Y. Odd.

You know it won't work on anything but a handful of
modern browsers in their default configurations.

And I'm okay with that. You seem to think that if a person finds
jQuery useful, then they must advocate its use on all web sites for
all needs. That's not the case. jQuery is a tool. I use it for what it
is useful for. I do not use or advocate it for situations where it is
not useful.

Computers are fast. Don't optimize just because you feel bad for them
having to work so hard.

Computers are fast?! That is your argument for using such inane and
inefficient patterns?

It is actually not as ridiculous of a strategy as you make it sound.
A data warehouse, for example, is a very inefficient pattern as far as
data storage is concerned. Keys duplicated, many rows, etc. If all you
care about is data integrity and storage, you might say it is a
terrible implementation. But if you use different criteria, it may
become the best solution.

A pattern that is less efficient to run, but more efficient to write
and maintain, yet runs with an imperceptible loss in performance, can
be considered a success.

EVERYTHING IS RELATIVE. Tattoo that on your forehead.

I'm quite familiar with Einstein. We can discuss that if you'd like.
One of my favorite topics. Tattoos, not so much.

Don't use jQuery in those cases.

You had something there, but you stopped three words too late.

For many problems, jQuery is an inadequate solution.

^^^^
You misspelled "any and all."

Your extreme bias against jQuery makes your argument less compelling.
I find that most intelligent people are less extreme and more
reasoned.

It is yours after all. Your assumption that people who use jQuery to
shield themselves from the intricacies of cross-browser scripting
would be in a position to judge what would be a problem for jQuery is
patently absurd. These people don't know what they are doing. That
is why they chose jQuery in the first place.

That is your absurd assumption.

I take it you like to write "plug-ins" for jQuery.

I have. My motivation for doing so is probably quite different than
what you imagine.

Oh, I see you wrote a "context menu" plug-in for jQuery. A popup menu
hard-wired to work only with the alternate mouse button? And it
requires jQuery to work? Whatever your motivation, you are not
helping.

Your inability to think outside your box is amusing.

Your reputation can join Resig's in the toilet.

If you haven't noticed by now, I couldn't possibly care less what you
or anyone else thinks of my opinions on jQuery.

> No amount of stupid asides can change that.

I'll keep trying.

And you apparently forgot everything you learned previously. We just
had this exact discussion a year ago. What are you in self-imposed
exile ever since?

Ummmmm, not really.

Consider what a foolish post this was.

Indeed it was, but I forgive you. You can try again.

Matt Kruse

**Conrad Lender** · Oct 29 '08, 10:15 PM

Re: Help Jquery: unable to register a ready function

On 2008-10-29 20:43, David Mark wrote:

http://ejohn.org/blog/future-proofin...ipt-libraries/
>
That one is my personal favorite [..]

Actually, I thought it was quite interesting. He wrote that scripting
libraries like JQuery or Dojo are used, among other things, to "pave
over" browser bugs and incompatibiliti es, so that the users can
concentrate on the real task at hand instead of hand-rolling yet another
cross-browser event abstraction layer, for example. He also demonstrated
that sometimes object detection is not possible, or not enough to
provide a solid abstraction. In those cases, feature tests can help; for
the remaining cases they have no option but to go by browser version.
This is obviously not ideal, hence the idea of taking the test suites of
popular scripting libraries and adding them to the existing Mozilla test
suite. This would have two major benefits: it would provide the QA at
Mozilla with better tests based on real-life applications, and it would
provide an early warning system to detect incompatibiliti es between the
libraries and the JS engine updates. Win-win. What didn't you like about
that article?

Though for comic relief, you can't beat this one:
>
http://ejohn.org/blog/most-bizarre-ie-quirk/
>
What kind of idiot would delegate the most critical 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?

- Conrad

**David Mark** · Oct 29 '08, 10:25 PM

Re: Help Jquery: unable to register a ready function

On Oct 29, 5:26 pm, Matt Kruse <m...@thekrusef amily.comwrote:

On Oct 29, 3:58 pm, David Mark <dmark.cins...@ gmail.comwrote:
>

I do useful things with it all the time. That seems to falsify your
theory. *WINK*

Useful according to whom?

>
Me. Why would I care if it's useful to you or anyone else?
>

Problems = Only if you hit the cases where problems might exist, and I
never have except in theory.

Christ on a crutch. You don't have to have empirical evidence. Look
at the code.

>
Your argument is that it will fail under some cases. My argument is
that those cases don't matter to me. Your argument is theory, mine is
practical.

No. You advocate the use of jQuery on the Web. That is pure folly.

>
I'm doing X, and you're arguing that it can't do Y. Odd.

Who knows what you are doing? Doesn't really matter. If it is
browser scripting and involves jQuery, then you are doing something
foolish. Intranet or not.

>

You know it won't work on anything but a handful of
modern browsers in their default configurations.

>
And I'm okay with that. You seem to think that if a person finds
jQuery useful, then they must advocate its use on all web sites for

But that is where you see jQuery (all over the public Internet.) This
is largely because jackasses like you are handing out bad advice (like
these last few posts.)

all needs. That's not the case. jQuery is a tool. I use it for what it
is useful for. I do not use or advocate it for situations where it is
not useful.

It is not useful for anything but deluding yourself (and your clients)
into thinking you are competent to do cross-browser scripting.

>

Computers are fast. Don't optimize just because you feel bad for them
having to work so hard.

Computers are fast?! That is your argument for using such inane and
inefficient patterns?

>
It is actually not as ridiculous of a strategy as you make it sound.

Completely ridiculous. "Computers are fast" so it is okay to waste
all of their resources. Who are you now, Bill Gates? Try using any
of your jQuery apps on an older PC. You can literally hear the
incompetence in the whirring fans.

A data warehouse, for example, is a very inefficient pattern as far as
data storage is concerned. Keys duplicated, many rows, etc. If all you

Data normalization and de-normalization is OT (and irrelevant) here.

care about is data integrity and storage, you might say it is a
terrible implementation. But if you use different criteria, it may
become the best solution.

You are off in the weeds.

>
A pattern that is less efficient to run, but more efficient to write
and maintain, yet runs with an imperceptible loss in performance, can

Imperceptible?!

be considered a success.

You have completely lost it. There is nothing about using another
person's browser sniffing monstrosity of a script that will make for
easy maintenance. And who cares if it is easier to write if the end
result is a maintenance nightmare?

>

EVERYTHING IS RELATIVE. Tattoo that on your forehead.

>
I'm quite familiar with Einstein. We can discuss that if you'd like.
One of my favorite topics. Tattoos, not so much.

Okay, write it in black magic marker on your hand, then smack yourself
in the forehead.

>

Don't use jQuery in those cases.

You had something there, but you stopped three words too late.

For many problems, jQuery is an inadequate solution.

^^^^
You misspelled "any and all."

>
Your extreme bias against jQuery makes your argument less compelling.

Prototype, jQuery, MooTools, etc. are all fruits of the same poison
tree. I am hardly alone in this determination.

I find that most intelligent people are less extreme and more
reasoned.

Most intelligent people would find your "arguments" to be non-
arguments. It is like talking to a wall.

>

It is yours after all. Your assumption that people who use jQuery to
shield themselves from the intricacies of cross-browser scripting
would be in a position to judge what would be a problem for jQuery is
patently absurd. These people don't know what they are doing. That
is why they chose jQuery in the first place.

>
That is your absurd assumption.

Of course not. It's the library that "makes JavaScript (sic)
bearable." Articles about it always start out: "I used to *hate*
JavaScript, then I discovered..." To finish their thought, they
discovered that they could create really lousy, inefficient scripts if
they let somebody else's large, lousy and inefficient script do all of
the work. Nobody with experience would consider this a worthwhile
discovery.

>

I take it you like to write "plug-ins" for jQuery.
I have. My motivation for doing so is probably quite different than
what you imagine.

Oh, I see you wrote a "context menu" plug-in for jQuery. A popup menu
hard-wired to work only with the alternate mouse button? And it
requires jQuery to work? Whatever your motivation, you are not
helping.

>
Your inability to think outside your box is amusing.

Outside my box? What you were after was a popup menu. I published
one here a full year ago. And yes, it had an optional context "plug-
in" (optional script) and "themes" (alternate style sheets.) It even
works with XHTML (try *that* with jQuery.) And last, but not least,
it does not require 50K of jQuery code to work. Certainly it couldn't
be easier to implement and maintenance will likely be non-existent for
a long time (unlike your browser sniffing "plug-in.")

>

Your reputation can join Resig's in the toilet.

>
If you haven't noticed by now, I couldn't possibly care less what you
or anyone else thinks of my opinions on jQuery.

And I don't care what you think about my opinions, but I will not let
you spread half-truths and outright falsehoods here. There is enough
blithering on the blogs.

>

No amount of stupid asides can change that.

>
I'll keep trying.

And you will keep failing. The pattern is not hard to spot.

**dhtml** · Nov 4 '08, 07:55 AM

Re: Help Jquery: unable to register a ready function

Conrad Lender wrote:

On 2008-10-29 20:43, David Mark wrote:

>http://ejohn.org/blog/future-proofin...ipt-libraries/
>>
>That one is my personal favorite [..]

>
Actually, I thought it was quite interesting. He wrote that scripting
libraries like JQuery or Dojo are used, among other things, to "pave
over" browser bugs and incompatibiliti es,

That is what those libraries are advertised as being. That, and being a
way to solve many problems. I view the libraries as Matt does: a tool.
That tool might be useful for many common, simple tasks. It won't be the
most suitable tool for specific tasks, and in some cases, might have
more than needed for a given application.

so that the users can
concentrate on the real task at hand instead of hand-rolling yet another
cross-browser event abstraction layer, for example.

It depends what the abstraction layer does. Have you looked at jQuery's
bind?

A simple "addEvent" function can work for most situations.

function addCallback(o, type, cb) {
if(o.addEventLi stener)
o.addEventListe ner(type, cb, false);
else if(o.attachEven t)
o.attachEvent(" on"+type, function(ev){ cb.call(o, ev); });
return o;
}

A separate registry can be used for custom events or legacy DOM events
e.g. "onclick". The average web developers I've worked with don't use
custom events

He also demonstrated
that sometimes object detection is not possible, or not enough to
provide a solid abstraction.

He stated two cases where object detection fails and even provided a
workaround for one. That doesn't make a case that object detection is
sometimes not possible.

In those cases, feature tests can help; for
the remaining cases they have no option but to go by browser version.

You mean:-

| Unfortunately, in real-world JavaScript development, object detection
| can only get you so far. For example, there's no object that you can
|'detect' to determine if browsers return inaccurate attribute values
| from getAttribute

?

Concluding that there is no remaining option but to check the browser
version is a hasty conclusion. The topic of browser detection/capability
detection has debated a lot[1]. Would mean that all other viable
possibilities have been explored. Take a look at the mouseenter function
jquery recently added.

Feature detection doesn't get interesting until a browser supports a
feature but does so in a different way. Detecting how the feature is
implemented (or ruling out how it is not implemented) can often be done
by creating a situation where an expected result of using that feature
can be tested against how the feature actually behaves.

http://jibbering.com/faq/#getWindowSize

(for example)

>

>Though for comic relief, you can't beat this one:
>>
>http://ejohn.org/blog/most-bizarre-ie-quirk/
>>
>What kind of idiot would delegate the most critical 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?
>

Yeah, that's weird. The comments by Lasse were interesting.

[1]http://dev.opera.com/articles/view/using-capability-detection/

--
comp.lang.javas cript FAQ <URL: http://jibbering.com/faq/ >

**Conrad Lender** · Nov 4 '08, 01:25 PM

Re: Help Jquery: unable to register a ready function

On 2008-11-04 08:53, dhtml wrote:
[Snipping my quotes about how object detection and feature tests
sometimes can't be used to detect browser behavior]

Concluding that there is no remaining option but to check the browser
version is a hasty conclusion. The topic of browser detection/capability
detection has debated a lot[1]. Would mean that all other viable
possibilities have been explored.

I know it's been discussed at length, and there are many good reasons to
avoid browser sniffing wherever possible. I still believe there are
situations where it can't be easily avoided (see below).

Here's an example of where object detection fails and feature testing
can help: dynamic creation of radio buttons.

var radio = document.create Element("input" );
radio.type = "radio";
radio.name = "xy";
out(radio.name) ; // a debugging function
target.appendCh ild(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.outerHTM L && radio.outerHTML .indexOf("name= ") < 0) {
// use IE's proprietary createElement() version
}

There's no need for browser sniffing in this example. If/when Microsoft
decide to fix that bug, the check won't misbehave in future IE versions.

Examples where feature tests aren't enough usually include browser
capabilities that aren't directly related to javascript:

- can the browser can correctly render alpha transparency for PNGs?
- will calling window.print() pause execution of the script?
- will an element's opacity have a big visual jump between 99% and 100%?

I know, it's frowned upon here, but in cases like these I personally
have no problem with sacrificing purity for functionality. I *know* that
IE6 doesn't support PNG transparency, and I *know* that IE7 does. If for
some reason there is a requirement to make that distinction, I will do
the practical thing and check the browser version.

- Conrad

**David Mark** · Nov 4 '08, 06:05 PM

Re: Help Jquery: unable to register a ready function

On Nov 4, 2:53 am, dhtml <dhtmlkitc...@g mail.comwrote:

Conrad Lender wrote:

On 2008-10-29 20:43, David Mark wrote:

>http://ejohn.org/blog/future-proofin...ipt-libraries/

>

That one is my personal favorite [..]

>

Actually, I thought it was quite interesting. He wrote that scripting
libraries like JQuery or Dojo are used, among other things, to "pave
over" browser bugs and incompatibiliti es,

>
That is what those libraries are advertised as being. That, and being a
way to solve many problems. I view the libraries as Matt does: a tool.

A tool for what?

That tool might be useful for many common, simple tasks. It won't be the

Like what? A mockup? I wouldn't even recommend them for that.

most suitable tool for specific tasks, and in some cases, might have
more than needed for a given application.

Or in the case of many, the code may be incompetently written and
therefore a waste of time.

And yes, the designs are absurd for browser scripting.

>
so that the users can
>

concentrate on the real task at hand instead of hand-rolling yet another
cross-browser event abstraction layer, for example.

>
It depends what the abstraction layer does. Have you looked at jQuery's
bind?

Yes, it is a crock.

>
A simple "addEvent" function can work for most situations.
>
function addCallback(o, type, cb) {
if(o.addEventLi stener)
o.addEventListe ner(type, cb, false);
else if(o.attachEven t)
o.attachEvent(" on"+type, function(ev){ cb.call(o, ev);});
return o;
>
}
>
A separate registry can be used for custom events or legacy DOM events
e.g. "onclick". The average web developers I've worked with don't use
custom events
>
He also demonstrated
>

that sometimes object detection is not possible, or not enough to
provide a solid abstraction.

>
He stated two cases where object detection fails and even provided a

And at least one of the two is demonstrably false. The other looks
like nonsense too.

workaround for one. That doesn't make a case that object detection is
sometimes not possible.

It isn't a case for anything.

>
In those cases, feature tests can help; for
>

the remaining cases they have no option but to go by browser version.

>
You mean:-
>
| Unfortunately, in real-world JavaScript development, object detection
| can only get you so far. For example, there's no object that you can
|'detect' to determine if browsers return inaccurate attribute values
| from getAttribute

LOL. And there you have it.

>
?
>
Concluding that there is no remaining option but to check the browser
version is a hasty conclusion. The topic of browser detection/capability

It is far worse than a hasty conclusion. The idea that you cannot
feature test IE's broken getAttribute has been proven false by me in
this newsgroup a long time ago. And that pinhead was a participant in
the thread. (!) So why hasn't he retracted this rubbish?

detection has debated a lot[1]. Would mean that all other viable
possibilities have been explored. Take a look at the mouseenter function
jquery recently added.

Why?

[snip]

>

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?

>
Yeah, that's weird. The comments by Lasse were interesting.
>
[1]http://dev.opera.com/articles/view/using-capability-detection/

Neither of you got it. Re-read that "quirk report" again.

The moral of the story is that even if people like John Resig had the
slightest idea what they were talking about, browser detection would
still be useless. If you read between the lines, you will see why
they think they need it. Needless to say, their fundamental mistake
has been discussed to death here.

**David Mark** · Nov 4 '08, 06:05 PM

Re: Help Jquery: unable to register a ready function

On Nov 4, 8:24 am, Conrad Lender <crlen...@yahoo .comwrote:

On 2008-11-04 08:53, dhtml wrote:
[Snipping my quotes about how object detection and feature tests
sometimes can't be used to detect browser behavior]
>

Concluding that there is no remaining option but to check the browser
version is a hasty conclusion. The topic of browser detection/capability
detection has debated a lot[1]. Would mean that all other viable
possibilities have been explored.

>
I know it's been discussed at length, and there are many good reasons to
avoid browser sniffing wherever possible. I still believe there are
situations where it can't be easily avoided (see below).

That is inexperience talking.

>
Here's an example of where object detection fails and feature testing
can help: dynamic creation of radio buttons.
>
var radio = document.create Element("input" );
radio.type = "radio";
radio.name = "xy";
out(radio.name) ; // a debugging function
target.appendCh ild(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

Yes, you can feature test that.

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

Not like that!

>
There's no need for browser sniffing in this example. If/when Microsoft
decide to fix that bug, the check won't misbehave in future IE versions.

You have the basic idea.

>
Examples where feature tests aren't enough usually include browser
capabilities that aren't directly related to javascript:
>
- can the browser can correctly render alpha transparency for PNGs?

LOL. No need for browser sniffing there.

- will calling window.print() pause execution of the script?

That can (and should) be designed out of any system.

- will an element's opacity have a big visual jump between 99% and 100%?

Same.

>
I know, it's frowned upon here, but in cases like these I personally
have no problem with sacrificing purity for functionality. I *know* that
IE6 doesn't support PNG transparency, and I *know* that IE7 does. If for
some reason there is a requirement to make that distinction, I will do
the practical thing and check the browser version.

Nope. Not the user agent string. Try thinking about these issues a
little harder.

Help Jquery: unable to register a ready function

Help Jquery: unable to register a ready function

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment