Help Jquery: unable to register a ready function

[David Mark]

Re: Help Jquery: unable to register a ready function

On Nov 4, 7:58 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>
wrote:

David Mark <dmark.cins...@ gmail.comwrites :

[…] If you mean conditional
compilation, wrong again.  I would never put that into the library as
(for one) it screws up the YUI minifier.

>
Only clueless idiots use minifiers (what else is new :-).

Oh brother. Who told you that?

[David Mark]

Re: Help Jquery: unable to register a ready function

On Nov 4, 6:51 pm, Matt Kruse <m...@thekrusef amily.comwrote:

On Nov 4, 4:09 pm, David Mark <dmark.cins...@ gmail.comwrote:
>

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'sa

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

>
What about the need to fix for control z-index bleed-thru (ie, select
box showing above popup divs, etc).

There are numerous ways to design that out of the system. If you
refuse to do that, then you will have to either deal with it the same
way in all browsers (e.g. hide the selects when popping up a div)
or...

I use CC to apply the fix for that. I've not come across a good test
for it.

There is nothing inherently wrong with CC. If you find yourself using
it for more than this and perhaps two other things I can think of, you
are probably using it as a crutch. In any event, CC is not the same
thing as "detecting" the user agent.

>
Matt Kruse

[RobG]

Re: Help Jquery: unable to register a ready function

On Nov 5, 7:43 am, Matt Kruse <m...@thekrusef amily.comwrote:
[...]

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?

I think there are two bigger issues.

1. When a new version of a browser fixes[1] whatever quirk the sniff
was directed at, either the browser continues to get the "assume it's
broken" fork when it should not or the code authors have to add a
version-specific sniff.

2. Developers become lazy and start the old "this site must be viewed
in browser X" crap when the browser X is actually pefectly capable of
viewing the site.

My ISP continues to deliver different content to Safari users based on
a UA sniff, despite the fact that they could very easily have used a
feature test and it was fixed about version 1.2 or so. I change my UA
string to mimic Firefox and everything is fine.


1. Where "fixes" can mean conforms to whatever norm is expected, it
need not actually be a bug or missing feature.



--
Rob

[Eric B. Bednarz]

Re: Help Jquery: unable to register a ready function

David Mark <dmark.cinsoft@ gmail.comwrites :

On Nov 4, 7:58 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>:

>David Mark <dmark.cins...@ gmail.comwrites :

[…] If you mean conditional
compilation, wrong again.  I would never put that into the library as
(for one) it screws up the YUI minifier.

>>
>Only clueless idiots use minifiers (what else is new :-).

>
Oh brother. Who told you that?

The same back-end guy who told me that creative mangling^Woptim izing
of source code will introduce new bugs, and that if your toolbox is
broken you fix your toolbox without making too much noise. Not that it’s
really relevant, I rather enjoy shooting without aiming, just like you.


--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

[David Mark]

Re: Help Jquery: unable to register a ready function

On Nov 4, 6:49 pm, Matt Kruse <m...@thekrusef amily.comwrote:

On Nov 4, 4:20 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:
>

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.

>
I know how CC's work, I'm not stupid.

That is a debate for another time.

>
My point is simple - a browser other than IE could implement CC's,

A browser could be made out of cake too. Highly unlikely, but
theoretically possible. IE could stop implementing them in a future
version as well (also highly unlikely.)

process them correctly, and behave as if it is IE6/7/8. If you are
using CC to determine the capabilities of the browser and inferring
it's CSS quirks, then you would apply incorrect logic to "fix" such a
browser that isn't broken.

The browser you described is broken as designed. But regardless,
consider the case at hand, which comes up over and over. How to deal
with the fact that IE6 cannot render transparent PNG's properly.

Solution #1

Use CC's to include an additional style sheet for IE6. As discussed,
other browsers ignore comments (as they must!) The images will look
slightly less impressive (if they have any translucent pixels that is)
in IE6 (or any hypothetical browser that chooses to interpet comments
as directives.) No script required. No chance of degrading the user
experience in any way (other than maybe a slightly less impressive
graphic.)

Sounds hard to beat doesn't it? Inexplicably, many script developers
endeavor to create scripted solutions for problems that will never be
perfectly solved by script.

Solution #2

Sniff the user agent string. Set a global variable to true to
indicate when the string "MSIE" is contained therein. If this
variable is set, call a proprietary DirectX hack that is sure to throw
an exception in any agent other than IE. For those who don't know,
lots of agents have "MSIE" in their user agent strings (e.g. mobile
devices, old versions of Opera, FF with the UA string changed to
thwart browser sniffing scripts, etc.)

The inevitable, ridiculous argument that comes back from these library
developers and their proponents is that they "did what they had to do"
to make it "work." If, for example, a PNG correction routine is
present in Prototype or jQuery, it almost certainly uses browser
sniffing to "work", so clearly the feature should have been left out
altogether (it is better solved in other ways.) Ask why they didn't
opt for the obvious and the answer will be that it wouldn't have been
"cool."

And for those that don't know, in jQuery and Prototype, you can find
the sloppy fingerprints from this sort of handiwork throughout.
Really. Tangled all throughout, this sort of "logic" waits to
explode on anyone foolish enough to browse your site with something
other than the latest versions of FF, IE, Safari or Opera. I guess a
disclaimer wouldn't have been "cool" either.

>
In the same way, the user-agent string of IE6/7/8 is predictable. If a
browser fakes it and appears to be IE6/7/8, then your browser-sniffing
code may "fix" quirks that aren't really broken.

Whose browser sniffing code? This is an "apples vs. oranges" argument
anyway.

>
Both approaches are making an assumption about X based on some other
unrelated Y.

The assumption that browsers will treat comments as comments is far
better than any inference you can make from the user agent string.

>
Granted, user-agent sniffing is more error-prone than CC. But I would

Apples and oranges.

hope you would realize that both strategies have some room for
failure.

One has virtually zero chance of failure and for the other, failure is
a virtual certainty. Take your pick.

>
In my experience, both approaches should be used as a last-resort. And

One should be used as a last resort to serve proprietary rules to
IE6. The other should never be used for anything. There just aren't
any parallels here.

I would use CC before browser sniffing. But also in my experience,

I would Notepad before Outlook Express.

I've never come across a problem (in many years) caused by incorrect
browser-sniffing when used as a last resort. So it's not something I'm
afraid of, either.

Your clients should be scared to death though, particularly if you
built public sites for them.

>

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 as explained, using CC is vulnerable to the same thing.

Notepad and OE both crash.

>
And further on this point, I personally don't care about browsers that
are trying to spoof me and pretend to be IE or whatever. If they want

Oh, Christ on a crutch, here we go with the "I don't care" argument.
You are not your users.

to proclaim to the world that they are IE, then they get treated as IE

Are you really this clueless or just trying to make conversation here?

in cases when it's necessary to differentiate. If users don't like it,
they should use a browser that doesn't pretend to be something it's
not.

There is the classic and idiotic assumption that the user knows what
browser and configuration they are using and/or has any means to
change these circumstances. Blame the user for "pretending " to cover
up for your own shortcomings as a Web developer.

>

 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 thoseissues
and continue sniffing anyway (unless it is *absolutely required*) is just
plain stupid.

>
It is stupid to sniff when it is not the most efficient way to
accomplish a task. And in most cases, it is the wrong strategy.

I am still waiting (after ten odd years) to hear of a single case
where it is the right strategy.

[David Mark]

Re: Help Jquery: unable to register a ready function

On Nov 4, 8:35 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>
wrote:

David Mark <dmark.cins...@ gmail.comwrites :

On Nov 4, 7:58 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>:

David Mark <dmark.cins...@ gmail.comwrites :
[…] If you mean conditional
compilation, wrong again.  I would never put that into the libraryas
(for one) it screws up the YUI minifier.

>

Only clueless idiots use minifiers (what else is new :-).

>

Oh brother.  Who told you that?

>
The same back-end guy who told me that creative mangling^Woptim izing
of source code will introduce new bugs, and that if your toolbox is
broken you fix your toolbox without making too much noise. Not that it’s
really relevant, I rather enjoy shooting without aiming, just like you.

Never me.

[Eric B. Bednarz]

Re: Help Jquery: unable to register a ready function

David Mark <dmark.cinsoft@ gmail.comwrites :

On Nov 4, 8:35 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>

^^^
I *do* have one good thing to say about jQuery: I hate G2 much more.

>[…] I rather enjoy shooting without aiming, just like you.

>
Never me.

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


--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011

[David Mark]

Re: Help Jquery: unable to register a ready function

On Nov 4, 9:06 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>
wrote:

David Mark <dmark.cins...@ gmail.comwrites :

On Nov 4, 8:35 pm, Eric B. Bednarz <bedn...@fahr-zur-hoelle.org>

>
                                          ^^^
I *do* have one good thing to say about jQuery: I hate G2 much more.

You hate something I have never heard of more than jQuery. How does
that promote jQuery?

>

[…] I rather enjoy shooting without aiming, just like you.

>

Never me.

>
Not? The only thing that keeps me from considering you and Thomas Lahn

What does he have to do with it? Do you think he is the only other
member of the group to question the competence of the jQuery project?

to be jQuery’s most effective – albeit somewhat unintentional –
ambassadors in this NG is having read its source code myself;

Perhaps you are reading a different newsgroup?

accidental readers are unlikely to share this advantage.

I don't follow the logic. You don't have to read all of the code.
Just read a few choice excerpts that have been posted here repeatedly.

[dhtml]

Re: Help Jquery: unable to register a ready function

Conrad Lender wrote:

On 2008-11-04 19:35, David Mark wrote:

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

No you are not. You are checking to see if creating a named control does
not result in a lower-case "name=" in an outerHTML property. Does your
application really care what the outerHTML string looks like?

The easiest way to avoid the problem of not being able to find an
element by name is simply not give the element a - name - and use ID
instead.

createElement(i nvalid_string) is supposed to raise a DOMException

If you used that, and you got a domexception, it would be entirely your
fault; that is exactly what should happen in that case. A browser that
had the same problem of creating named form controls would get the
createElement(i nvalid_string) would trigger that situation.

If creating an element and setting a name creates a problem, the problem
should be identified clearly in a feature test.

The pseudo code might be:-

create a named anchor
check to see if the element is found in the way you are looking for it
(getElementsByN ame).

>>Again, what's _your_ solution?

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

>
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
workaround, and an ugly one at that, given that GIFs don't support alpha
transparency.
>

A device may support PNG without supporting the alpha channel. It's
optional.

http://www.w3.org/TR/PNG/

When a PNG is desired, but cannot be displayed, the grey fuzzy junk is
not acceptable. There should be a way to have a fallback.

The scope of the problem is larger than IE. I don't have the answer.

>>Where did I say anything about the user agent string?

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

>
There are better and more reliable ways to test for IE versions. And you
know it - you're using conditional evaluation in your own library...
>

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

>

I've seen much worse. Probably anyone whose had a job has. Search random
websites and view the source.

Garrett

>
- Conrad

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

[Matt Kruse]

Re: Help Jquery: unable to register a ready function

On Nov 4, 7:06 pm, David Mark <dmark.cins...@ gmail.comwrote:

What about the need to fix for control z-index bleed-thru (ie, select
box showing above popup divs, etc).

There are numerous ways to design that out of the system.  

Are you aware of every system?
Sounds like "I can't solve this problem, so I'll just avoid it
instead."
That works well in some cases, and not so well in others.

If you
refuse to do that, then you will have to either deal with it the same
way in all browsers (e.g. hide the selects when popping up a div)

Terrible approach. Especially for browsers that don't exhibit the
problem.

I use CC to apply the fix for that. I've not come across a good test
for it.

There is nothing inherently wrong with CC.  If you find yourself using
it for more than this and perhaps two other things I can think of, you
are probably using it as a crutch.  In any event, CC is not the same
thing as "detecting" the user agent.

But it kind of is "detecting" the user agent. You can use tags to
check against the OS, browser version, etc.

To use CC's, you are:
1. Trusting that the browser is what it says it is
2. Assuming that behavior X exists because of what your experience
tells you about that browser

When you use sniffing, you are:
1. Trusting that the browser is what it says it is
2. Assuming that behavior X exists because of what your experience
tells you about that browser

The point is valid that #1 is more reliable for CC than it is for
sniffing. True in practice. But not necessarily so. CC's could be
spoofed, just as user agent strings can be spoofed.

Point #2 is a necessary evil for both, because there are some things
you simply can't reliably test for. The GOAL is to handle as many
cases as possible and offer users the best possible experience.

A point that seems to get lost is that I'm not justifying the browser
sniffing in jQuery at all. It's unnecessary and amateur-ish. But just
because it exists doesn't invalidate the rest of the code for me. And
because it works consistently, reliably, and conveniently for me in
every situation I choose to use it in, I find value in it. It's far
from perfect and it has flaws, but I can accept that.

Matt Kruse

[Richard Cornford]

Re: Help Jquery: unable to register a ready function

On Oct 29, 10:14 pm, 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.

I found it quite informative, but on its author rather than its subject.

He wrote that scripting libraries like JQuery or Dojo are
used, among other things, to "pave over" browser bugs and
incompatibiliti es,

'Plaster over' rather than "pave over". In solving a small subset of the
cross-browsers scripting problem these libraries are in a potion to make
out that the people using them no longer have to consider the issues at
all. Their users find this appealing, and prefer not to perceive the
degree to which these things fall short genuinely addressing the issues.
As do their authors; John Resig is very keen to speak of the 3 or 4
recent desktop web browsers that JQuery actually does support as "all
browsers", and when you are fully supporting "all browsers" the result
must then be cross-browser.

so that the users can concentrate on the real task at hand

There is a general failure to appreciate that the "real task at hand" is
much more than just churning out web pages/applications. All projects to
which web development 'skills' are applied have a pre-determined purpose
and a context. One of the bigger tasks at hand is the application of
knowledge and experience to the design such that the outcome best
satisfies that purpose in context.

To illustrate; the primary purpose of an e-commerce site is to take
money off people in exchange for goods and/or services (that did not
take much working out). The state of web technologies is such that it is
possible to take money of everyone with an HTTP(S), HTML web browsers
that understands forms. 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. The design decisions have a direct impact on the
potential of the outcome to satisfy its purpose. There will be aspects
of the design that may have a positive impact on the outcome, such as a
more 'professional' look giving the potential customers greater
confidence and increasing their willingness to part with their money. 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?

Libraries such a JQuery allow people with little or no experience in web
development to crate sites that, on a limited number of web browsers, it
there default configurations, appear to 'work' and present a (more or
less) impressive presentation. But these people have no understanding of
the consequences of their actions (indeed mostly seem unaware that there
are any issues arising from their decisions at all). And the customers
of such sites are likely using one of the popular browsers in its
default configuration, and relying on the 'professionalis m' of their web
developers to have had any design issues addressed in there best
interests. That is an understandable expectation from the site
customers, but not realistic in the light of general level of web
development skills exhibited in the real world.

instead of hand-rolling yet another
cross-browser event abstraction layer, for example.

This, oft repeated, assertion that the only alternative to using a third
party general purpose library is write everything from scratch for
yourself is a total nonsense. In-between those two alternatives lay a
whole spectrum of code re-use opportunities, and only the very
masochistic are not re-using pre-written code for the bulk of their
projects even if they are not using the 'popular' general purpose
libraries.

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

"Demonstrat ed", did he? While there inevitably will be features that
cannot be detected (though far fewer than may people would like to make
out) I have to question whether John Resig demonstrated any of them in
that article.

The first example he mentions as "fail to return correct results from a
getElementsByTa gName query" refers to an article that asserts that it is
sometimes impossible to retrieve collections of PARAM elements from
inside OBJECT elements. OBJECT elements tend to be inconsistent, odd and
divergent little sods so this is an entirely plausible assertion. It is
not a demonstration of the ineffectiveness of feature detection as if
you have an OBJECT elements and know it to contain PARAM elements it is
trivial to apply the element retrieval method and deduce the
applicability of the issue from the success of that attempt. That is, if
you fail to retrieve elements that you know are there you then know that
you are in an environment where such retrievals are ineffective (so can
attempt alternative retrieval techniques or follow your graceful
degradation path).

From John Resig's perspective this may not sound like a useful approach
because general purpose library code has no way of knowing whether any
OBJECT elements on a page have PARAM children, so not finding any cannot
be used to deduce anything. However, this is not an issue of future
detecting, it is an issue introduced by the attempt to be 'general
purpose'. And if you are going to address issues in browser scripting it
is quite important to be clear about where those issues are coming from.

Remember that only a small proportion of web sites/applications have
OBJECT elements, only a proportion of those have PARAM elements inside
those OBJECT elements, and only a small proportion of those
sites/applications have an interest in retracing those PARAM elements
with scirpts. So in the real world this is a non-issue for the huge
majority.

All of that assumes the issue reported on the limked page is accuratly
reported, which may still not be the case as the quality of issue
analysis among the 'bloogging' javascript comunity tends to be extramly
poor. Often they are just re-itterating the misconceved impressions of
others in the same 'comunity' without even testing them.

And on the subject of testing, lets get pack to John Resig's page, where
we read another "demonstration" :-

| Additionally, object detection has the ability to completely fail.
| Safari currently has a super-nasty bugs related to object
| detection. For example, assuming that you have a variable and you
| need to determine if it contains a single DOM Element, or a DOM
| NodeList. One one would think that it would be as simple as:
|
| if ( elem.nodeName ) {
| // it's an element
| } else {
| // it's a nodelist
| }
| However, in the current version of Safari, this causes the browser
| to completely crash, for reasons unknown. (However, I'm fairly
| certain that this has already been fixed in the nightlies.)

That would not be a very good test to discriminate an Element from a
Node list as some IceBrowser NodeLists have non-empty nodeName -
properties, but we wouldn't expect John Resig to be aware of the
characteristics of any browsers that are not in his "all browsers" list.

Anyway, if true, that sounds like it could be a serious problem. So is
it true? When something is true it can be demonstrated in a way that is
reproducible by others (an attitude popular in science but not at all
out of place in software development). Of course if someone asserts
that a particular browser/version exhibits particular behaviour it
becomes very helpful if they also state precisely which browser/version
they have seen the issue on. Doing that makes verifying the observation
much easier because not seeing the issue on any different version does
not necessarily prove it does not exist.

John Resig does not provide that information, only the assertion that
the version is 'current' and that the issue is absent from 'nightlies,
and that the article was posted March 1st 2007. I have a Mac mini that
was purchased in late January 2007 and has never had any software
updates. That makes it seem likely that its Safari version is the one
that was 'current' in the run-up to March 1st 2007. It is version is
2.0.4 (419.3) and when exposed to this simple test page:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">
window.onload = function(){
var ndList = document.getEle mentsByTagName( 'BODY');
var emptyList = document.getEle mentsByTagName( 'DIV');
var node = document.body;
if(node.nodeNam e){
alert(
'[expected: BODY] node.nodeName = '+
node.nodeName
);
}
if(ndList.nodeN ame){
alert(
'[unexpect] ndList.nodeName = '+
ndList.nodeName
);
}else{
alert(
'[expect: undefined] ndList.nodeName = '+
ndList.nodeName
);
}
if(emptyList.no deName){
alert(
'[unexpect] emptyList.nodeN ame = '+
emptyList.nodeN ame
);
}else{
alert(
'[expect: undefined] emptyList.nodeN ame = '+
emptyList.nodeN ame
);
}
};
</script>
</head>
<body>
</body>
</html>

- it happily completed the execution of the script and showed all of the
expected alerts.

So was that issue real, or just a bogus report made, untested, based on
rumour from a third party? As an isolated report of an issue you might
conclude that there was a Safari release that came after the versions
that I have and before the 'fix' in the 'nightlies' made it into a
post-march 2007 release that did indeed exhibit this uses (introduced in
one version and them fixed). On the other hand you might take this
apparently bogus report in contest, and specific in the context of an
article that goes on to assert:-

| Additionally, in Internet Explorer, doing object detection checks
| can, sometimes, cause actual function executions to occur. For
| example:
|
| if ( elem.getAttribu te ) {
| // will die in Internet Explorer
| }
| That line will cause problems as Internet Explorer attempts to
| execute the getAttribute function with no arguments (which is
| invalid). (The obvious solution is to use
| "typeof elem.getAttribu te == 'undefined'" instead.)

Now I know that that is pure BS because I have been using tests along
the lines of - if(elem.getAttr ibute){ .... } - on Element nodes for
years (at least 5) and have never seen them fail, and I do test/use that
code in (lots of versions of) IE. But still, lets make it easy for
everyone to test the proposition for themselves and so verify its
veracity. A simple test page might be:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<script type="text/javascript">
window.onload = function(){
if(document.bod y.getAttribute) {
alert(
'document.body. getAttribute = '+
document.body.g etAttribute
);
}
};
</script>
</head>
<body>
</body>
</html>

Now to start with we need to know what IE's - getAttribute - would do if
it were executed with no arguments. The DOM spec is not that clear,
execute that it says no exceptions will be thrown. It is easy enough to
test, and it turns out that:-

alert(''+docume nt.body.getAttr ibute());

- alert "null", so the method call returns null. So, if -
elem.getAttribu te - calls the method with no arguments the result is
likely be null. If the result is null then in the above test page the -
if(document.bod y.getAttribute) { - test will be false, the - if - branch
will not be entered and the alert will not be shown. But on every IE
version where I have tried the above test the alert is shown, plus the
alert shows "document.body. getAttribute = function
getAttribute(){[native code]}", not the "null" that would be result of
calling the method with no arguments.

Can you find an IE version that does exhibit this 'issue'? I am pretty
certain that I have tested code that used this test on IE versions from
4 to 8 without issue, so I doubt it.

Given that this assertion is demonstrably BS may attitude toward the
previous "demonstrat ed" issue on Safari, in light of my test, leans
heavily toward dismissing that as also being BS.

So what is this article? If it is a reasoned analysis of future
detecting as a technique why are its examples bogus? An explanation
might be that this is not an examination of feature detection at all,
but rather an attempt to justify not trying feature detection written by
someone who has realised that they have no talent for it. And if you
have no concern for the veracity of the arguments you use it is possible
to find justification for anything.

One more quote from Resig's article:-

| The point of these examples isn't to rag on Safari or Internet
Explorer
| in particular, but to point out that rendering-engine checks can end
up
| becoming very convoluted - and thusly, more vulnerable to future
| changes within a browser.

- which can be summarised as 'complexity equals vulnerability'.
Certainly complexity will relate to vulnerability, in a very general
sense, but in the context of feature detection if a test is the correct
test, no matter how complex it may be, it will not be vulnerable to
updates in the browsers because significant changes the browsers will
directly impact on the outcomes of those tests, which is the point of
feature detection.

From my own experience; when IE 7 was released I was working on a web
application with (at the time) 100,000 lines of client-side code (code
employing nothing but feature detection where it is necessary to react
to divergent environments). The total number of changes in the scripts
needed to accommodate IE 7 was zero. When Chrome was released the total
number of changes necessary to accommodate that was also zero. And last
week QA started testing that application on IE 8. They may take another
week to run through all there tests but so far they have found no
issues, and I have a realistic expectation that they will not (as pretty
much everything that would be likely to be problematic would inevitably
get used in the first day or so).

Now that is "Future Proof" javascript, and low maintenance javascript.

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

<snip>

Chrome and JQuery made interesting point about User Agent string based
browser detection; Chrome works (more or less) with JQuery because its
authors pragmatically gave it a UA string that would result in most
current browser sniffing scripts identifying it as Safari, and treating
Chrome as Safari is probably the best thing to do if you are going to
script in that style at all. But this means that UA sting based browser
sniffing was effective in this case not because it enabled the accurate
determination of the browser and its version, but instead was effective
precisely because it misidentified the browser and its version.

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

I think you have missed the point. He observed a weird behaviour in IE,
applied an obviously fatly process to the analysis of that behaviour and
that then resulted in his coming to a series of utterly false
conclusions about what the observed behaviour was. Joking about
applications for that behaviour became irrelevant as having
misidentified the behaviour in the first place any proposed applications
of that misidentified behaviour would be worthless even if taken
seriously.

And you are likely to ask; his mistake was using an - alert - in the
test. Generally, alerts aren't much use in examining pointing device
interactions in web browsers because they tend to block script execution
(and so real-time event handling) and they can shift focus (keyboard
'enter' goes to the button on the box. Most people learn this lesson
quite early on as they learn browser scripting, as a consequence of
trying things out for themselves and trying to examine how they work.
The BS examples on the 'future proof javascript' page might suggest that
John Resig is not someone who goes in for trying things out for himself
that often.

Here is an alternative test page for the IE setTimeout quirk:-

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01
Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title></title>
<style type="text/css">
BODY {
width:100%;
height:100%;
}
</style>
<script type="text/javascript">
var count = 0;
setInterval(
function(){
window.status = ++count;
},
-1
);
</script>
</head>
<body>
<div style="width100 %;height:100%;" ></div>
</body>
</html>

- so give it a go. Make use your IE status bar is visible and watch the
displayed number as you click, mouse-down, move the mouse, release the
mouse button. And when you have done that see what you think of Resig's
conclusion that "What happened is positively bizarre: The callback
function will be executed every time the user left clicks the mouse,
anywhere in the document." In reality ckicking, and click events have
nothing to with IE's behaviour, beyond their representing a mousedown
followed by a mouseup.

While you may conclude that the reaction to the self proclaimed
"JavaScript Ninja" on this group is biased and personal, in reality it
is mostly a direct reaction to what he writes/does, and a reaction
informed by pertinent knowledge and experience in the field of browser
scripting.

Richard.

[Matt Kruse]

Re: Help Jquery: unable to register a ready function

On Nov 5, 11:07 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

[snip detailed analysis]

Richard, as always your analysis is detailed, analytical, accurate,
and insightful (and long).
I wish I had someone at my disposal to review my work in such detail.
Surely you recognize that there are few people who would be capable of
such an analysis.

John Resig is very keen to speak of the 3 or 4
recent desktop web browsers that JQuery actually does support as "all
browsers", and when you are fully supporting "all browsers" the result
must then be cross-browser.

I think the most valid non-technical criticism of jQuery is that it is
promoted as being a generalized solution that is applicable to most
(or all) public web sites. It is not. But must we continually repeat
that fact as if it completely invalidates it as a tool for other
purposes?

Libraries such a JQuery allow people with little or no experience in web
development to crate sites that, on a limited number of web browsers, it
there default configurations, appear to 'work' and present a (more or
less) impressive presentation. But these people have no understanding of
the consequences of their actions (indeed mostly seem unaware that there
are any issues arising from their decisions at all).

This is true of many things in life, not just jQuery. You just happen
to be an expert in the area that jQuery addresses and can see its
faults. Technical perfection is NOT the only measure of success or
evaluation criteria.

Take a retail situation as an example. A store may not be able to
accept all forms of payment, thereby limiting their potential
customers. They may not be open at convenient hours, further limiting
potential customers. They may not have adequate parking. Maybe some of
their products are out of reach of some customers. Maybe they have
shopping carts that fit most people, but some find inadequate so they
leave. Maybe their store layout is too confusing so some people leave
because they can't find what they want. Maybe their sales tactics are
obnoxious and they annoy customers so much that they walk out.

BUT WAIT! Don't they know that each of these things is a design
decision that could prevent a small percentage of potential customers
from giving them money?! Why don't they fix them all and optimize it
so every single person can use their store and buy as much as
possible?

Why? Because it's made by humans, and humans aren't perfect. Sometimes
you have to say "close enough" and get on with it. If a site "appears
to work" for most people, and the customer finds it acceptable, and
even if they lose out on a small percentage of potential sales, maybe
that is truly "good enough". Maybe they can't afford to do it exactly
right. Maybe the analysis and perfection of the system just isn't
warranted, because with just a little effort they can get a lot of
business, and that more than makes up for the potential losses of
customers. That's the real world.

instead of hand-rolling yet another
cross-browser event abstraction layer, for example.

This, oft repeated, assertion that the only alternative to using a third
party general purpose library is write everything from scratch for
yourself is a total nonsense.

It's not black-and-white to you, but to others in different situations
it just might be, because they don't have the same options as you do.

In-between those two alternatives lay a
whole spectrum of code re-use opportunities

You are in a position to determine that because you have a good
understanding of the technology. You criticize jQuery because it
doesn't handle all cases and has design flaws that may impact a public
site that is using it, because its developers are too naive to know
the pitfalls of the library. But then you expect these same naive
developers to understand how to develop, test, modularize, and re-use
their own code as a better option?

From my own experience; when IE 7 was released I was working on a web
application with (at the time) 100,000 lines of client-side code (code
employing nothing but feature detection where it is necessary to react
to divergent environments).

You realize that this kind of example shows that you are at the very
extreme edge of js development? You are very clearly not the audience
for jQuery or any other popular library approach. I suspect you have a
hard time relating to the average developer who is struggling just to
do simple animations or toggle divs.

And last week QA started testing that application on IE 8.

And do you know how many projects even _have_ QA departments? Consider
yourself lucky to work in such an environment! You are the exception,
not the norm.

Now that is "Future Proof" javascript, and low maintenance javascript.

Planned, designed, and written by an expert in the field. We just need
everyone to be experts and all this discussion would go away! :)

While you may conclude that the reaction to the self proclaimed
"JavaScript Ninja" on this group is biased and personal, in reality it
is mostly a direct reaction to what he writes/does, and a reaction
informed by pertinent knowledge and experience in the field of browser
scripting.

From my perspective, John Resig is clearly not as knowledgeable and
experienced as you are with regards to Javascript. But, whether you
like it or not, he has much more knowledge than the vast majority of
people attempting to write Javascript. He's not perfect (who is?) but
he's out there, sticking his neck out, showing his cards, sharing what
he knows (or thinks he knows). That takes a lot of guts, and I'm sure
he's learning along the way. If everyone needs to be an expert at your
level before they can share anything they know, no one would be
learning!

The developer world needs people like him, and libraries like jQuery,
to bridge the gap between the average user who is lost and confused,
and the expert developer such as yourself. You may not think that
jQuery is a positive thing in the scripting world, but countless other
people disagree with you, and things are moving in that direction
whether you like it or not. Even Microsoft (not your biggest measure
of success, I'm sure) has adopted jQuery into its development
platform. Surely this doesn't affect how you do your work. But you
need to recognize how it changes the game for the rest of the
developer world.

It seems that your perspective prevents you from understanding the
needs of people who are in a very different situation from yourself.
And if you want to have a more positive impact on the scripting world,
you need to learn from people like John Resig just as much as he needs
to learn from you.

All IMO, of course.

Matt Kruse

[Thomas 'PointedEars' Lahn]

Re: Help Jquery: unable to register a ready function

Eric B. Bednarz wrote:

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


PointedEars
--
var bugRiddenCrashP ronePieceOfJunk = (
navigator.userA gent.indexOf('M SIE 5') != -1
&& navigator.userA gent.indexOf('M ac') != -1
) // Plone, register_functi on.js:16

[David Mark]

Re: Help Jquery: unable to register a ready function

On Nov 5, 11:16 am, Matt Kruse <m...@thekrusef amily.comwrote:

On Nov 4, 7:06 pm, David Mark <dmark.cins...@ gmail.comwrote:
>

What about the need to fix for control z-index bleed-thru (ie, select
box showing above popup divs, etc).

There are numerous ways to design that out of the system.  

>
Are you aware of every system?
Sounds like "I can't solve this problem, so I'll just avoid it
instead."
That works well in some cases, and not so well in others.
>

If you
refuse to do that, then you will have to either deal with it the same
way in all browsers (e.g. hide the selects when popping up a div)

>
Terrible approach. Especially for browsers that don't exhibit the
problem.
>

I use CC to apply the fix for that. I've not come across a good test
for it.

There is nothing inherently wrong with CC.  If you find yourself using
it for more than this and perhaps two other things I can think of, you
are probably using it as a crutch.  In any event, CC is not the same
thing as "detecting" the user agent.

>
But it kind of is "detecting" the user agent. You can use tags to
check against the OS, browser version, etc.
>
To use CC's, you are:
1. Trusting that the browser is what it says it is
2. Assuming that behavior X exists because of what your experience
tells you about that browser
>
When you use sniffing, you are:
1. Trusting that the browser is what it says it is
2. Assuming that behavior X exists because of what your experience
tells you about that browser
>
The point is valid that #1 is more reliable for CC than it is for
sniffing. True in practice. But not necessarily so. CC's could be
spoofed, just as user agent strings can be spoofed.

We've been over that.

>
Point #2 is a necessary evil for both, because there are some things

It isn't necessary. That is my whole point. When somebody asks the
jQuery or Prototype "teams" to implement (for example) a PNG fix
script, they should simply refuse as it is impossible to detect the
condition. Perhaps they could even recommend the obvious non-script
solutions. But no, they are in a perceived arms race to create the
biggest general-purpose script ever. It is just ridiculous.

you simply can't reliably test for. The GOAL is to handle as many
cases as possible and offer users the best possible experience.
>
A point that seems to get lost is that I'm not justifying the browser
sniffing in jQuery at all. It's unnecessary and amateur-ish. But just

I know you aren't and I know you tried to convince the jQuery support
group to see the light on this. I also know they didn't see the light
and therefore their uses are still in the dark.

because it exists doesn't invalidate the rest of the code for me. And
because it works consistently, reliably, and conveniently for me in
every situation I choose to use it in, I find value in it. It's far
from perfect and it has flaws, but I can accept that.

I think you know that I don't really care if you use it for your
private application. It is just that the library is "marketed" (often
with religious zeal) to Web developers, most of whom work on the
public Internet. That is upsetting for a number of reasons, not the
least of which is that I can't browse the Web without tripping over
incompetent scripts (can't turn script off either of course.) Not all
of them use jQuery of course (lots do), but the whole culture of Web
development seems to have taken a major step backwards in the last few
years.

So I would just like to see some disclaimers when people talk about
it. For example:

jQuery Rules!!!!!!!!!*

* Provided you are using the default configuration of a handful of
modern browsers, then, well, it still doesn't rule per se, but it is
there. Warning: may explode in the middle of "chained" calls, leaving
the document in an unexpected (and possibly non-working) state.

[Matt Kruse]

Re: Help Jquery: unable to register a ready function

On Nov 5, 1:16 pm, David Mark <dmark.cins...@ gmail.comwrote:

So I would just like to see some disclaimers when people talk about
it.  For example:
>
jQuery Rules!!!!!!!!!*
>
* Provided you are using the default configuration of a handful of
modern browsers, then, well, it still doesn't rule per se, but it is
there.  Warning: may explode in the middle of "chained" calls, leaving
the document in an unexpected (and possibly non-working) state.

Heh. Now that I agree with.

Matt Kruse