Help Jquery: unable to register a ready function

souporpower · Oct 28, 2008

Hello All

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

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

<script language="javascript" type="text/javascript">

$(document).ready(function(){ $('.mylink').click(function()
{ $.jPrintArea('#tabularData') }); });

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

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

var doc=null;

$(iframe).attr('style','position:absolute;width:0px;height:
0px;left:-500px;top:-500px;');

document.body.appendChild(iframe);

doc=iframe.contentWindow.document;

var links=window.document.getElementsByTagName('link');

for(var i=0;i<links.length;i++)
if(links.rel.toLowerCase()=='stylesheet')

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

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

doc.close();

iframe.contentWindow.focus();

iframe.contentWindow.print();

alert('Printing...');

//wait(1);

document.body.removeChild(iframe);

}
</script>
</head>
<body>
<div id="tabularData">
<a href="#" class="mylink" name="mylink">Print 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?

Thanks for your help. Sorry I am unable to post the code on a web
site.

David Mark · Oct 28, 2008

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="javascript" type="text/javascript">

$(document).ready(function(){ $('.mylink').click(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.jPrintArea=function(el)
{
alert("hello");

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

var doc=null;

$(iframe).attr('style','position:absolute;width:0px;height:
0px;left:-500px;top:-500px;');

document.body.appendChild(iframe);

doc=iframe.contentWindow.document;

var links=window.document.getElementsByTagName('link');

for(var i=0;i<links.length;i++)
if(links.rel.toLowerCase()=='stylesheet')

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

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

doc.close();

iframe.contentWindow.focus();

iframe.contentWindow.print();

alert('Printing...');

//wait(1);

document.body.removeChild(iframe);

}

</script>
</head>
<body>
<div id="tabularData">
<a href="#" class="mylink" name="mylink">Print 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 · Oct 29, 2008

Hello All

Click to expand...

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

Click to expand...

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>

Click to expand...

Remove this.

<script language="javascript" type="text/javascript">

Click to expand...

$(document).ready(function(){ $('.mylink').click(function()
{ $.jPrintArea('#tabularData') }); });

Click to expand...

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.jPrintArea=function(el)
{
alert("hello");

Click to expand...

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

Click to expand...

var doc=null;

var links=window.document.getElementsByTagName('link');

Click to expand...

for(var i=0;i<links.length;i++)
if(links.rel.toLowerCase()=='stylesheet')

Click to expand...

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

Click to expand...

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

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

Click to expand...

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?

Click to expand...

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.height='0px';
iframe.style.width='0px';
document.body.appendChild(iframe);
doc=iframe.contentWindow.document;
var innerhtml = document.getElementById(el).innerHTML;
doc.write('<html><body><div>'+innerhtml +'</div></body></html>');
doc.close();
iframe.contentWindow.focus();
iframe.contentWindow.print();

setTimeout("document.body.removeChild(iframe)",5000);

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

RobG · Oct 29, 2008

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.height='0px';
iframe.style.width='0px';
document.body.appendChild(iframe);
doc=iframe.contentWindow.document;

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.getElementById(el).innerHTML;
doc.write('<html><body><div>'+innerhtml +'</div></body></html>');
doc.close();
iframe.contentWindow.focus();
iframe.contentWindow.print();

setTimeout("document.body.removeChild(iframe)",5000);

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

setTimeout(function(){document.body.removeChild(iframe)}, 5000);

Untested, but should be OK.

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

div element.

Matt Kruse · Oct 29, 2008

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).

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').click(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, 2008

You forgot the wink:

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

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.

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

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

$(function(){
$('.mylink').click(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-proofing-javascript-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.

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, 2008

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*

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]

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, 2008

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

Useful according to whom?

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.

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.

Yes. Exactly 3000.

At least 2998 too many.

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 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.

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.

Yes?

See next line.

Of course not.

Click to expand...

[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?

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, 2008

Useful according to whom?

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

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?! 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.

You had something there, but you stopped three words too late.
^^^^
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.

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

David Mark · Oct 29, 2008

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

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.

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.

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?

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.

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.

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.

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.")

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.

I'll keep trying.

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

David Mark · Nov 4, 2008

Conrad said:
Conrad said:

http://ejohn.org/blog/future-proofing-javascript-libraries/
That one is my personal favorite [..]

Click to expand...

Click to expand...

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 incompatibilities,

Click to expand...

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

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.addEventListener)
o.addEventListener(type, cb, false);
else if(o.attachEvent)
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

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

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?

Click to expand...

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, 2008

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.

Click to expand...

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.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

Yes, you can feature test that.

if (radio.outerHTML && 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.

David Mark · Nov 4, 2008

If you've got a better solution, how about telling us?

A better solution to using outerHTML? How about anything?

Again, what's _your_ solution?

Depends on the context. As I have worked on numerous projects that
use transparent PNG's as widget decorations, I have had to work around
the same IE6 nonsense that you have. Never once have I had to stoop
to browser sniffing. The simplest solution is to provide GIF
equivalents and override the the PNG's in the inevitable IE6-specific
style sheets. And those are typically hidden with IE conditional
comments.

I disagree. Anyway, the point is that it can't be feature tested.

It can't be inferred from the user agent string either. Best to
design it out of the system (whether you agree or not is another
story.)

Where did I say anything about the user agent string?

That's what browser sniffing uses to "check the browser version."

Try providing solutions (if you've got them) instead of lording it over

Thin ice, Conrad. Very thin ice. You are clearly new and very
impetuous. Try reading more and writing less.

people who don't share your fierce hatred of anything connected to John
Resig. At least he put his code out there where other people can use it

Fierce of hatred of who?! I don't know him at all. His code is awful
though.

and improve it. You're sitting on a huge (and possibly superior)
library, but it's not open source, and thus unavailable to most of us.

The ice just broke. Try a little research before opening your mouth.
It will save a lot time and embarrassment. You are currently
following in the footsteps of Matt Kruse, circa a year or so back.

Matt Kruse · Nov 4, 2008

That's what browser sniffing uses to "check the browser version."

Not necessarily. Depends on your definition of "sniffing".
Using IE conditional comments is one alternate approach.

Matt Kruse

David Mark · Nov 4, 2008

Not necessarily. Depends on your definition of "sniffing".
Using IE conditional comments is one alternate approach.

IE conditional comments are not sniffing per se. And they are
absolutely the best way to include the handful of CSS corrections that
are virtually always required for older versions of IE (e.g.
proprietary rules like "zoom:1".)

They can be abused though. Do not use conditional comments to load
script that makes assumptions about IE's host objects based on the
browser version.

Matt Kruse · Nov 4, 2008

IE conditional comments are not sniffing per se.

Semantics. You can define it however you wish.

And they are
absolutely the best way to include the handful of CSS corrections that
are virtually always required for older versions of IE (e.g.
proprietary rules like "zoom:1".)

In theory, it is no more reliable than a user-agent string. Any
browser could choose to process code within IE's conditional comments.
Just as any browser can choose to fake a user-agent string.

Can you really assume CSS behavior based on a browser's evaluation of
conditional comments? Isn't that quite a leap?

You rely on one potentially-broken approach, but not the other. Why?

They can be abused though. Do not use conditional comments to load
script that makes assumptions about IE's host objects based on the
browser version.

But you can make assumptions on PNG support from conditional comments?
What if a user has a custom extension in their version of IE6 that
allows PNG files to work correctly? Oh, SNAP!

Matt Kruse

David Mark · Nov 4, 2008

Semantics. You can define it however you wish.

Nonsense. It is clearly not browser sniffing.

In theory, it is no more reliable than a user-agent string. Any

That is where you are wrong.

browser could choose to process code within IE's conditional comments.

But since there is no benefit for them to do so (unlike spoofing UA
strings), they don't.

Just as any browser can choose to fake a user-agent string.

Can you really assume CSS behavior based on a browser's evaluation of
conditional comments? Isn't that quite a leap?

Certainly not. It is the best practice for fixing IE6's silly quirks
(primarily by using rules that are proprietary to IE.)

You rely on one potentially-broken approach, but not the other. Why?

One is easily demonstrated as baseless, the other is not.

But you can make assumptions on PNG support from conditional comments?
What if a user has a custom extension in their version of IE6 that
allows PNG files to work correctly? Oh, SNAP!

Oh what? They would still get the GIF's. Wouldn't hurt a thing. See
how that works?

Matt Kruse · Nov 4, 2008

Nonsense. It is clearly not browser sniffing.

If you restrict sniffing to only looking at the user-agent, then I
suppose you are right.

That is where you are wrong.

I agree that it is more reliable in practice, but not in theory.

But since there is no benefit for them to do so (unlike spoofing UA
strings), they don't.

So you're going to assume it's a safe tactic because, according to
your knowledge, no browser is currently doing it?
What if I wrote a browser that used IE's parsing/js engine but my own
CSS logic? It might evaluate conditional comments, but not follow the
CSS quirks that you are inferring. The point is, you are making an
assumption about some behavior (css quirks) based on something
entirely different (support for conditional comments evaluation).

In my experience, I've never come across a browser that faked it's UA
string and caused a problem for the user. So by your logic, can't I
assume it is a safe practice?

[snip the rest due to boredom]

Matt Kruse

David Mark · Nov 4, 2008

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.

Why do you feel the need to tell me that? Assume whatever you want.

In the example I've posted, I'm checking whether I should use the
IE-proprietary way of calling createElement, so it's perfectly
acceptable to use a proprietary property in the check.

I didn't care for any of it. Thank you.

[...] The simplest solution is to provide GIF
equivalents and override the the PNG's in the inevitable IE6-specific
style sheets. And those are typically hidden with IE conditional
comments.

Click to expand...

That's not an answer either. My point was that it couldn't be feature
tested, and you say use GIFs and stylesheets. That's not a test, it's a

You have no point at all. You can't feature test the color shirt the
user is wearing either. Sheesh.

workaround, and an ugly one at that, given that GIFs don't support alpha
transparency.

Nothing ugly about it. Supporting alpha transparency (or not) does
not affect a single design of mine. Yours?

There are better and more reliable ways to test for IE versions. And you

You don't have to "test for IE versions" in your script at all.
That's the point.

know it - you're using conditional evaluation in your own library...

Conditional evaluation? I think not. If you mean conditional
compilation, wrong again. I would never put that into the library as
(for one) it screws up the YUI minifier. Perhaps you are thinking of
an add-in? Sure as hell doesn't "check the IE version" either. Could
you get any more off-base than to lecture me on my own code?

Then you've just called a person you don't know at all "all-around
incompetent". You also said "as for him *as a person*, he is an idiot".

His incompetence is easily discerned from his numerous books, blog
posts, scripts, etc. Opinion seems to be divided here. Everybody
else says it is so, you and Matt Kruse say it isn't (though Matt seems
to have finally realized that Resig is not worth listening to.)

And yeah, I have talked to him. It is a matter of public record. He
is an idiot. Read more, write less.

I'm glad we were able to break the ice between us, maybe we can have a
more constructive discussion next time. I'm done with this.

The ice under your feet, genius. As in, you had no argument at all.
All of the blithering that followed was the usual waste of time, which
was clearly followed by the inevitable epiphany.

If I really cared to help you, perhaps I would have suggested some
search terms (e.g. "browser scripting" library.) Looks like #1, #2
and #4 respectively on Yahoo, Google and Answers. Looks like you
figured it out on your own. There's a good fellow.

Thomas 'PointedEars' Lahn · Nov 4, 2008

Matt said:
If you restrict sniffing to only looking at the user-agent, then I
suppose you are right.

I agree that it is more reliable in practice, but not in theory.

The point that you are still missing after all these months I already tried
to explain it to you is that your theory is flawed.

Using Conditional Comments does not break anything because when it is not
regarded as a special processing instruction (as by MSHTML, or a
deliberately borken UA if it can't handle it properly) it is regarded an
SGML/HTML/XML comment and goes *ignored*, plain and simple. IOW, when a CC
fails you do *not* do anything.

Much in contrast, using browser sniffing and sniffing to the wrong effect is
inevitably harmful because you end up *doing* things that you did not
intended to do in the UA that you did not know to spoof you successfully
yet. And you will have to adapt your code each time it happens to handle
that case, *after* some kind soul *might* have told you that your code
messed with their UA. I hope you can agree that being aware of those issues
and continue sniffing anyway (unless it is *absolutely required*) is just
plain stupid.

PointedEars

Jquery not registering the ready func	2	Oct 27, 2008
JQuery add shadow error	4	Sep 1, 2023
Jquery not triggering / acting as expected.	0	Mar 6, 2022
DJForm Login Help!	1	Sep 28, 2024
I need help making a zooming function	11	Dec 14, 2021
JQuery Ajax	3	Jul 24, 2010
Help with code	0	Jun 12, 2022
Help with my responsive home page	2	Dec 14, 2022

Help Jquery: unable to register a ready function

souporpower

David Mark

souporpower

RobG

Matt Kruse

David Mark

Matt Kruse

David Mark

Matt Kruse

David Mark

David Mark

David Mark

David Mark

Matt Kruse

David Mark

Matt Kruse

David Mark

Matt Kruse

David Mark

Thomas 'PointedEars' Lahn

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads