Recommendations for JavaScript drop-down menu code

[Richard Cornford]

That's good news. Are you aware if this cross-browser
JavaScript knowledge been consolidated and captured somewhere?

Well, obviously the necessary knowledge must be captured and
consolidated in the minds of the individuals who demonstrate the
possibilities.

If the time to learn how to use a library exceeded the time
saved by using the library, then I wouldn't consider the
library "good enough".

Doesn't that assessment lead to a 'Catch 22' situation where you cannot
assess the time needed to learn (and so trade that off against time
saved) until you have learnt to use the library? If the results fail
your "good enough" here the time that has been spent learning the
library in order to assess how long that would take is pure wasted time.

But then there is the question of how you would know that you were done
learning any library. Obviously that is quite important to any
assessment of how log the process takes.

I like to write my own code as much as anyone, but it's not
always the best investment in time. Over the years, I've
benefited by being able to reuse libraries in various
languages, so I was a bit surprised at what seems like a
prevalent attitude of "write it all yourself" on
this newsgroup.

Didn't I write you a very long post explaining code re-use strategies
that are suited to browser scripting tasks? Nobody is saying 'write it
all yourself', though it is obviously a good idea to know how to write
it all yourself because without that it is impossible to judge the stuff
that comes off other people's shelves, and eventually there will be
something needed that does not currently exist at all. And the act of
learning to write it all yourself, if reasonably handled, will go a long
way to providing anyone who does so with a large collection of their own
re-useable and well-tested code.

Do you think that comes from the constraints of using
libraries in JavaScript, or is there another factor
I'm missing?

You seem to be miss-characterising what you read so there probably is
something you are missing.

Richard.

 

[Brian Adkins]

Well, obviously the necessary knowledge must be captured and
consolidated in the minds of the individuals who demonstrate the
possibilities.

If you're saying this cross-browser JavaScript knowledge is
distributed among the minds of various individuals, then I'd say it's
neither captured nor consolidated. I feel you're being purposely
obtuse here.

... Nobody is saying 'write it
all yourself' ...

Ok, now I feel like we're just going in circles. Let me just be
crystal clear by asking one simple question:

Which publicly available JavaScript libraries do you feel are
worthwhile to use?

 

[David Mark]

If you're saying this cross-browser JavaScript knowledge is
distributed among the minds of various individuals, then I'd say it's
neither captured nor consolidated. I feel you're being purposely
obtuse here.

Possession does not imply distribution.

Ok, now I feel like we're just going in circles. Let me just be
crystal clear by asking one simple question:

You are definitely going in circles.

Which publicly available JavaScript libraries do you feel are
worthwhile to use?

You are fishing for something that does not exist. There is no magic
do-everything library out there that will safely shield you from
learning JavaScript.

 

[Peter Michaux]

You are fishing for something that does not exist. There is no magic
do-everything library out there that will safely shield you from
learning JavaScript.

If "publicly available JavaScript library" means something big like
Dojo, YUI, Prototype, jQuery then it does seem difficult to find a
library that will have the features appropriate to a particular task
without being bloated and be of sufficiently high quality to be
acceptable for use. It seems almost insane to write my previous
sentence because it seems such a library should exist for any
particular task. I suppose if your task is to write a modern Ajax-y
website that does normal "Web 2.0" things like everyone else and
"works" on only the newest set of browsers with images, CSS, and
JavaScript enabled for clients with fast Internet connections then you
have plenty of libraries from which to choose. You can even choose a
library API that makes you feel all warm and fuzzy inside as that is
the primary difference amongst them. If your requirements deviate even
slightly from this situation then the library pickings get slimmer.

Another option would be a JavaScript recipes book that describes many
common situations with competent solutions for at least a few
permutations of each situation so the reader would know how to make
changes for other situations without too much time investment as the
reader has learned the situation-related problems by reading the book.

In general, you would expect there were better JavaScript resources
available from which to learn or to use. The information is available
but it has not been completely aggregated in a book or code library.

The code library format Richard Cornford described where modules have
defined interfaces and several implementations for various situations
seems the most appealing. This is no surprise as this is normally the
case with Richard's suggestions. This type of library in combination
with some sort of automated build tool could be easy to use. A
publicly available library like this would be possible but it would
take detailed documentation for each implementation and would have a
steeper learning curve than the mainstream libraries available today.

Peter

 

[RobG]

Whether or not it [MSIE] still has a 90% market share or not (142%
of all Web statistics are flawed) is irrelevant

As with all statistics, they are not irrelevant on condition that the
measuring methods are acceptable.

Statistically every person has one breast.

No statistics required, that is a matter of biology. All humans (and
a very large number of other animals) have two breast unless they
either have some genetic idiosyncracy or have had one or both
removed.

 

[Brian Adkins]

If "publicly available JavaScript library" means something big like
Dojo, YUI, Prototype, jQuery ...

I'm not sure why you would think that. I simply asked about JavaScript
libraries that were both "publicly available" and "worthwhile to use".
There was nothing about size/scope in that question. It was a
straightforward question, but I still figured the likelihood of
getting a recommendation was low.

It was the guy who replied to me that invented the idea that I was
looking for a "magic do everything library" that would "shield me from
learning JavaScript" - in other words, a straw man fallacy:

http://en.wikipedia.org/wiki/Straw_man

 

[Peter Michaux]

I'm not sure why you would think that. I simply asked about JavaScript
libraries that were both "publicly available" and "worthwhile to use".
There was nothing about size/scope in that question. It was a
straightforward question, but I still figured the likelihood of
getting a recommendation was low.

You are a hard man to please, Brad. If size or scope don't matter then
it is difficult to know your motivation for asking and to give you an
answer that would be useful to you. Here is a small library you could
use that is handy for debugging

function log(msg) {
if (console && console.log) {
console.log(msg);
}
else {
alert(msg);
}
}

Watch others pick that library to shreds as I didn't test the type of
console.log to determine if it is callable. I also didn't use try-
catch for errors but that wouldn't work in NN4...etc.

It was the guy who replied to me that invented the idea that I was
looking for a "magic do everything library" that would "shield me from
learning JavaScript" - in other words, a straw man fallacy:

http://en.wikipedia.org/wiki/Straw_man

This thread has become confusing but as a result all sorts of bonus
information has been presented.

Peter

 

[David Mark]

I'm not sure why you would think that. I simply asked about JavaScript

The same reason that anybody would think that. You cited those four
earlier in the thread as "good enough" for your purposes (whatever
those may be.)

libraries that were both "publicly available" and "worthwhile to use".
There was nothing about size/scope in that question. It was a
straightforward question, but I still figured the likelihood of
getting a recommendation was low.

Your question is much too vague. "Worthwhile to use" for what? Just
what sort of "cross-browser knowledge" are you fishing for?

It was the guy who replied to me that invented the idea that I was
looking for a "magic do everything library" that would "shield me from

That sentence makes no sense, nor does the link that followed. If you
really want help, you will have to express your ideas more clearly.

 

[David Mark]

You are a hard man to please, Brad. If size or scope don't matter then
it is difficult to know your motivation for asking and to give you an
answer that would be useful to you. Here is a small library you could
use that is handy for debugging

function log(msg) {
if (console && console.log) {
console.log(msg);
}
else {
alert(msg);
}

}

Watch others pick that library to shreds as I didn't test the type of
console.log to determine if it is callable. I also didn't use try-

There is no way to know for sure if the property of a host object is
callable. The best you could do is:

if (console && (typeof(console.log) == 'function' ||
typeof(console.log) == 'object')

I think your original test is adequate.

catch for errors but that wouldn't work in NN4...etc.

Which is why you shouldn't have used try/catch, unless this function
is segregated in its own file.

It does have a few other issues though.

var global = this;
var log = (function() {
if (global.console && global.console.log) {
return function(msg) { global.console.log(msg); };
}
if (global.alert) {
return function(msg) { global.alert(msg); };
}
})();

This way you can feature test log before presenting a logging
interface.

 

[Brian Adkins]

You are a hard man to please, Brad. If size or scope don't matter then
it is difficult to know your motivation for asking and to give you an
answer that would be useful to you.

Peter, why are you making this difficult. It was an extremely simple
question. I only presented two requirements, but you seem to struggle
with that. For example, is your "small library" below publicly
available? I expect not - so why did you present it as an example of a
worthwhile, publicly available library? The fact that I didn't specify
a scope/size doesn't mean a reasonable one isn't implied. Would you
really bother to present the code below as a "library" for others to
use? I think not, so you are just playing games here.

For example, if the same question was asked in the context of the Ruby
language instead of JavaScript, I would reply that the 'net/http'
library is both publicly available and worthwhile to use. See that
wasn't so difficult. Do you think it's an unreasonable question to ask
in the context of JavaScript?

 

[Brian Adkins]

The same reason that anybody would think that. You cited those four
earlier in the thread as "good enough" for your purposes (whatever
those may be.)

I don't think you're representative of the general population. The
question stands on its own, there was no reference to the prior
information. In fact, I purposely set the bar as low as possible
because I've yet to get a single recommendation, so I thought I'd see
if there was even a *single* library that someone would recommend.

Your question is much too vague. "Worthwhile to use" for what? Just
what sort of "cross-browser knowledge" are you fishing for?

Worthwhile for *anything*. David, I truly think you're in this thread
just to argue. Let's find out right here. You complain that my
question is too vague, and yet you can't even recommend a *single*
publicly available library that is worthwhile in any context.

That sentence makes no sense, nor does the link that followed. If you
really want help, you will have to express your ideas more clearly.

Have you ever considered that the difficulty in communication lies
partly with you? My question didn't state I wanted a "magic" or
"large" library. Nor did it state I wanted to "shield myself from
learning JavaScript". When you refute arguments that you make up
yourself, you commit a "Straw Man" fallacy. You've been committing
this fallacy a lot.

If you've noticed, I haven't been replying to your posts directly,
because I truly think you're here just to argue, and I simply want
recommendations for reusable JavaScript code. If you reply with more
arguments and no recommendations, that will confirm my suspicions.

 

[David Mark]

I don't think you're representative of the general population. The

I hope not.

question stands on its own, there was no reference to the prior
information. In fact, I purposely set the bar as low as possible

But it is in the context of a discussion thread. If you want to start
a new topic, start a new thread.

because I've yet to get a single recommendation, so I thought I'd see

Peter's recommendation is valid in the clarified context of your
question.

if there was even a *single* library that someone would recommend.

What sort of library? Your original question concerned a menu
library. I recommended one.

Use for what?

You seem to be programmed for failure.

Worthwhile for *anything*. David, I truly think you're in this thread

For anything? Doesn't console logging count as something? The
absurdity of that answer was likely meant to enlighten you on the
absurdity of your question.

just to argue. Let's find out right here. You complain that my
question is too vague, and yet you can't even recommend a *single*
publicly available library that is worthwhile in any context.

I second the recommendation for Peter's console logging library, with
the additional changes I recommended. There you go.

Have you ever considered that the difficulty in communication lies
partly with you? My question didn't state I wanted a "magic" or

No. The sentence was referenced was incoherent. Read it aloud.

"large" library. Nor did it state I wanted to "shield myself from
learning JavaScript". When you refute arguments that you make up
yourself, you commit a "Straw Man" fallacy. You've been committing
this fallacy a lot.

This isn't a proper argument.

If you've noticed, I haven't been replying to your posts directly,

I didn't notice. Feel free to not reply to them in any way you like.

because I truly think you're here just to argue, and I simply want

Again, this thread hardly qualifies as an argument.

recommendations for reusable JavaScript code. If you reply with more
arguments and no recommendations, that will confirm my suspicions.

I think we're done here.

 

[Peter Michaux]

Peter, why are you making this difficult. It was an extremely simple
question. I only presented two requirements, but you seem to struggle
with that. For example, is your "small library" below publicly
available? I expect not - so why did you present it as an example of a
worthwhile, publicly available library?

I posted it to Usenet's comp.lang.javascript newsgroup so yes it is
publicly available.

The fact that I didn't specify
a scope/size doesn't mean a reasonable one isn't implied.

You stressed that you didn't specify size/scope. There is no way for
me to guess what "reasonable" size/scope is for your programming
tasks.

Would you
really bother to present the code below as a "library" for others to
use? I think not, so you are just playing games here.

If they were looking for a logging library I might. If they were
looking for an Ajax library I wouldn't.

For example, if the same question was asked in the context of the Ruby
language instead of JavaScript, I would reply that the 'net/http'
library is both publicly available and worthwhile to use. See that
wasn't so difficult. Do you think it's an unreasonable question to ask
in the context of JavaScript?

It is a question. It may be reasonable. It is probably not an optimal
question if you have a particular programing task in mind regardless
of language.

Brad, the regulars (and all respondents) at comp.lang.javascript are
volunteering their time to help others and aren't here just to argue
or be obtuse. If you recognize that you will probably get more value
out of the newsgroup. Look in the archives and you will see all the
people in this thread helping many people with well defined problems
and questions.

Peter

 

[Brian Adkins]

I hope not.


But it is in the context of a discussion thread. If you want to start
a new topic, start a new thread.

With that logic it would appear that you feel that Dojo, YUI,
Prototype, jQuery, etc. were being proposed as solutions to the
original drop-down menu code subject. You should probably get used to
the idea that usenet discussion threads often change dramatically from
the original subject. It's important to keep up.

Peter's recommendation is valid in the clarified context of your
question.

No it was not. I don't think any reasonable person would assert that
throwing out a few lines of code in a usenet post qualifies as a
"publicly available library". I could've added "in active use" or
other such verbiage, but the response would be the same, I'm sure,
because the intent here doesn't seem to be to provide an answer, but
to see how many different ways a question can be nitpicked.

What sort of library? Your original question concerned a menu
library. I recommended one.

You did? I must have missed that. Can you provide a link to the
website here? I hope you're not referring to your own code that you
posted here - are you?

For anything? Doesn't console logging count as something? The
absurdity of that answer was likely meant to enlighten you on the
absurdity of your question.

The question was not absurd, only the responses. The question would
have been absurd on another language newsgroup because there are so
many libraries to recommend. On this newsgroup, however, I've yet to
receive one serious recommendation. You can't seem to be able to see
the difference between a "publicly available library" and people
whipping up a few lines of code as an example.

I second the recommendation for Peter's console logging library, with
the additional changes I recommended. There you go.

Ok, the JavaScript community has spoken. Peter's console logging
library (as modified by you) is the shining example of JavaScript
reuse.

I think we're done here.

Agreed.

 

[Matt Kruse]

Worthwhile for *anything*. David, I truly think you're in this thread
just to argue. Let's find out right here. You complain that my
question is too vague, and yet you can't even recommend a *single*
publicly available library that is worthwhile in any context.

Brian,

I've read this group for years (much less so now) and this same
discussion has come up many times. Rather than participating, you can
just go back and read the previous discussions where I was saying
similar things to what you are now. You could save some time!

There are some very knowledgeable people in this group. But many of
the most knowledgeable people are also extremely anal, argumentative,
hostile, unrealistic, and disconnected from the real world most people
work in.

The reality of the situation is that libraries like jQuery (my
personal preference) and others don't get everything perfect. If you
wait for a perfect library you'll never find one. Similarly, if you
start from scratch to build your own and learn everything, you'll
never accomplish the things you need to.

So, you choose a library that is not "perfect" but does everything you
expect of it, and you benefit from it. And you ignore the jerks here
who can't seem to grasp the advantage that you have given yourself by
doing so.

I've experienced a fantastic improvement in productivity in some
developers I work with since adopting jQuery as a standard. Instead of
trying to learn and write javascript on the fly, they are using a
library that already gets things way more right than they would have
on their own. They are building components and creating UI's that have
never yet caused problems with any of our users, yet they certainly
wouldn't have been able to build on their own. The value it has added
is real and extremely beneficial.

Now, the zealots here may say "yeah but in line 1643 of jQuery it uses
a command that is known to fail under XYZ browser on platform ABC!" I
say, so what? Maybe it does. Maybe they'll fix it. But it doesn't
affect me, and it will never affect me. Why would I throw out a
library for a fault that I don't care about, and lose the incredible
benefits that it has provided me? I'm mostly building internal webapps
with strict browser limitations, and the library works great for me.
Even on public sites, if someone is using an obscure browser and they
don't see my fancy hover effect, so what? It's close enough.
(Enter from stage left: Richard... "yeah, but if it's a commercial
site, you can't afford to lose paying customers!"... to which I
respond, "wrong")

These are simply arguments that some of the people here just can't
seem to understand. Personally, I think they must live miserable lives
if this truly how they view the world!

I think it is a very intelligent and well-informed decision to
investigate javascript libraries and select one (or more) that will
help you reach your ultimate goal. Consider some of the things said in
this thread, but also realize that the most vocal library-opponents
here are also in the extreme minority, and their idealistic view of
javascript development surely has no relevance in the real world that
most people find themselves in. Find yourself a solution and go with
it!

Matt Kruse

 

[Brian Adkins]

Brian,

I've read this group for years (much less so now) and this same
discussion has come up many times. Rather than participating, you can
just go back and read the previous discussions where I was saying
similar things to what you are now. You could save some time!

[ more useful advice skipped for brevity ]

Matt Kruse

Thanks for the post. I think your assessment is an accurate one. I
came to a similar conclusion a while back, but I was intrigued by the
difficulty of getting any library recommendations.

Actually, any type of communication on this newsgroup seems to take
more effort than it should. I'm sure if I said, "It's a nice sunny day
today", that someone would reply, "What makes you think it will never
rain again? Do you even know how clouds form? ... " One of my
mistakes was thinking it was rational to reply to such a post; it was
not.

Brian Adkins

 

[Peter Michaux]

I've read this group for years (much less so now) and this same
discussion has come up many times. Rather than participating, you can
just go back and read the previous discussions where I was saying
similar things to what you are now. You could save some time!

[ more useful advice skipped for brevity ]

Matt Kruse

Thanks for the post. I think your assessment is an accurate one. I
came to a similar conclusion a while back, but I was intrigued by the
difficulty of getting any library recommendations.

Actually, any type of communication on this newsgroup seems to take
more effort than it should. I'm sure if I said, "It's a nice sunny day
today", that someone would reply, "What makes you think it will never
rain again? Do you even know how clouds form? ... " One of my
mistakes was thinking it was rational to reply to such a post; it was
not.

There is no question that comp.lang.javascript is a rough environment
if you want friendly, congratulatory discussion. I'm glad that people
here are forthright and do nitpick. If they didn't many small detailed
warnings and useful asides would be omitted. This is a discussion
group so this is healthy for the group. If a programmer wants a
friendly, you're-doing-a-great-job, you're-always-right online
JavaScript community there are many available. I think the usefulness
of comp.lang.javascript is far greater than those communities and it
is largely due to the ideals, experience, confidence and stubbornness
of the the curmudgeons and their abrasive tone.

Balancing the advice given in the group with your business
requirements is an important step also.

Peter

 

[David Mark]

Brian,

I've read this group for years (much less so now) and this same
discussion has come up many times. Rather than participating, you can
just go back and read the previous discussions where I was saying
similar things to what you are now. You could save some time!

There are some very knowledgeable people in this group. But many of
the most knowledgeable people are also extremely anal, argumentative,
hostile, unrealistic, and disconnected from the real world most people
work in.

What world do you work in?

The reality of the situation is that libraries like jQuery (my
personal preference) and others don't get everything perfect. If you

That's quite an understatement.

wait for a perfect library you'll never find one. Similarly, if you

Why wait for a library at all?

start from scratch to build your own and learn everything, you'll

Why start from scratch to build a library? You write an application
one function at a time. The next application may have use for some of
the previous functions or may not. The more applications you write,
the more functions you have. Eventually you will have enough to
organize them into modules suitable for the sorts of projects you work
on. Nobody is saying that you have to write them all from scratch.
But you need to know them well enough to organize them appropriately.

never accomplish the things you need to.

Just what do you need to do that requires jQuery?

So, you choose a library that is not "perfect" but does everything you
expect of it, and you benefit from it. And you ignore the jerks here
who can't seem to grasp the advantage that you have given yourself by
doing so.

You have gained an advantage by using jQuery? What sort of
advantage? And over whom?

I've experienced a fantastic improvement in productivity in some
developers I work with since adopting jQuery as a standard. Instead of
trying to learn and write javascript on the fly, they are using a

So these developers never learned JavaScript, but are now cranking out
JavaScript applications by relying on code written by somebody else
who never learned JavaScript. That is the blind leading the blind.

library that already gets things way more right than they would have
on their own. They are building components and creating UI's that have

jQuery makes it easy to do things that you shouldn't want to do in the
first place. Developers who are shielded from browser scripting and
the JavaScript language are all too happy to take advantage. They
don't know that what they are writing will cause problems until it is
too late. Then what do they do? Try to debug jQuery? That would be
difficult considering they never learned JavaScript.

never yet caused problems with any of our users, yet they certainly

That you know of.

wouldn't have been able to build on their own. The value it has added

Certainly if they don't know JavaScript, they couldn't be expected to
build anything with it. Handing them jQuery and unleashing them on
the Web (or Intranet) would seem an odd choice. Why not utilize
JavaScript programmers to write JavaScript?

is real and extremely beneficial.

Now, the zealots here may say "yeah but in line 1643 of jQuery it uses
a command that is known to fail under XYZ browser on platform ABC!" I
say, so what? Maybe it does. Maybe they'll fix it. But it doesn't

You could spend all day picking apart jQuery, but who would want to
bother? It is simply an ill-conceived design with an incompetent
execution. The only quick fix is to drag it to the recycle bin.

affect me, and it will never affect me. Why would I throw out a
library for a fault that I don't care about, and lose the incredible

If it doesn't affect you, then clearly you are not using some or all
of the code, which illustrates exactly why a "one size fits all"
JavaScript library is a bad idea in the first place.

benefits that it has provided me? I'm mostly building internal webapps
with strict browser limitations, and the library works great for me.

Works great in what sense? To accomplish what?

Even on public sites, if someone is using an obscure browser and they
don't see my fancy hover effect, so what? It's close enough.

You really need jQuery to do a "fancy hover effect?" And what you
fail to realize is that browser sniffing does not normally degrade
gracefully. Furthermore, jQuery claims to support only a small subset
of modern browsers. Is everything else "obscure?"

(Enter from stage left: Richard... "yeah, but if it's a commercial
site, you can't afford to lose paying customers!"... to which I
respond, "wrong")

Exit any semblance of credibility you had left.

These are simply arguments that some of the people here just can't
seem to understand. Personally, I think they must live miserable lives
if this truly how they view the world!

You are simply delusional.

I think it is a very intelligent and well-informed decision to
investigate javascript libraries and select one (or more) that will
help you reach your ultimate goal. Consider some of the things said in
this thread, but also realize that the most vocal library-opponents
here are also in the extreme minority, and their idealistic view of
javascript development surely has no relevance in the real world that

That is utter nonsense. You have been told repeatedly why your
"arguments" in favor of jQuery, browser sniffing and the like are pure
fantasy.

most people find themselves in. Find yourself a solution and go with
it!

If jQuery is your solution, then what was your problem?

 

[Matt Kruse]

Why start from scratch to build a library? You write an application
one function at a time. The next application may have use for some of
the previous functions or may not. The more applications you write,
the more functions you have. Eventually you will have enough to
organize them into modules suitable for the sorts of projects you work
on. Nobody is saying that you have to write them all from scratch.

How long after your first project do you eventually get efficient
enough to be productive? A few months after you go bankrupt?

Just what do you need to do that requires jQuery?

Nothing _requires_ jQuery, obviously.
I have found it useful for:
1) Animation effects
2) Simplified AJAX interaction
3) Easily adding :hover effects which IE will understand
4) Adding some UI improvements to existing pages
5) etc, etc

I have also found some of the plugins to be extremely useful in
speeding up development of complex UI's.

You have gained an advantage by using jQuery? What sort of
advantage? And over whom?

I covered this in another thread. Real cost ($$$) savings.

jQuery makes it easy to do things that you shouldn't want to do in the
first place.
Like?

That you know of.

In many cases, I know all my users personally.

Why not utilize JavaScript programmers to write JavaScript?

What if an organization does not have dedicated Javascript
programmers?

You could spend all day picking apart jQuery, but who would want to
bother? It is simply an ill-conceived design with an incompetent
execution.

On the contrary, I think the design is quite intuitive and exactly
what I am often looking for.

If it doesn't affect you, then clearly you are not using some or all
of the code, which illustrates exactly why a "one size fits all"
JavaScript library is a bad idea in the first place.

I disagree. Not using some of a 26kb library is unimportant to me.

You really need jQuery to do a "fancy hover effect?"

No, but it sure makes it easier. To do it from scratch would be
complex.

And what you
fail to realize is that browser sniffing does not normally degrade
gracefully.

I'm quite familiar with browser sniffing arguments.

Furthermore, jQuery claims to support only a small subset
of modern browsers. Is everything else "obscure?"

If you want to support every browser on the planet, then perhaps you
shouldn't use jQuery. They make their browser support claims quite
clear.
I'm not concerned with any browsers not on their supported list, so it
doesn't bother me.

Exit any semblance of credibility you had left.

Sacrificing a (very) small (perhaps non-existent) set of potential
customers in order to reduce development time, decrease bugs, increase
usability, and reduce overall cost is a good business decision.

You are simply delusional.

Thank you. Delusion has apparently been working quite successfully for
me for many years!

That is utter nonsense. You have been told repeatedly why your
"arguments" in favor of jQuery, browser sniffing and the like are pure
fantasy.

You are wrong, sir. I'll avoid telling you repeatedly.

Matt Kruse

 

[Brian Adkins]

[ more useful advice skipped for brevity ]

Matt Kruse

Thanks for the post. I think your assessment is an accurate one. I
came to a similar conclusion a while back, but I was intrigued by the
difficulty of getting any library recommendations.

Actually, any type of communication on this newsgroup seems to take
more effort than it should. I'm sure if I said, "It's a nice sunny day
today", that someone would reply, "What makes you think it will never
rain again? Do you even know how clouds form? ... " One of my
mistakes was thinking it was rational to reply to such a post; it was
not.

There is no question that comp.lang.javascript is a rough environment
if you want friendly, congratulatory discussion. I'm glad that people
here are forthright and do nitpick. If they didn't many small detailed
warnings and useful asides would be omitted. This is a discussion
group so this is healthy for the group. If a programmer wants a
friendly, you're-doing-a-great-job, you're-always-right online
JavaScript community there are many available. I think the usefulness
of comp.lang.javascript is far greater than those communities and it
is largely due to the ideals, experience, confidence and stubbornness
of the the curmudgeons and their abrasive tone.

You hit your cue perfectly