Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Recommendations for JavaScript drop-down menu code

Reply
Thread Tools

Recommendations for JavaScript drop-down menu code

 
 
Richard Cornford
Guest
Posts: n/a
 
      10-30-2007
Brian Adkins wrote:
> On Oct 28, 1:40 pm, Richard Cornford wrote:
>> Brian Adkins wrote:
>>> 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 you're saying this cross-browser JavaScript knowledge
> is distributed among the minds of various individuals,


Didn't I write "captured and consolidated _in_ the minds of the
individuals", not distributed among ... ?

> then I'd say it's neither captured nor consolidated.


If your 'if' were true then you would be correct.

> I feel you're being purposely obtuse here.


Maybe, you are not being very forthcoming with answers to the questions
you are being asked here so you should not expect too much else from
others.

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


Use for what exactly? Javascript design decisions should be context
driven.

For example, if you context were needing an application framework for
the types of activates that are of interest to a large-ish search engine
provider then YUI could easily be pretty much spot-on for the task. On
the other hand, if you goal was to provide supplementary room heating
for a "target audience" living in a cold climate then making extensive
use of anything built on top of Prototype.js should pump the maximum
amount of extra heat into the user's domestic environment.

Work out what it is you are trying to achieve before you set about
working out how best to achieve it.

Richard.

 
Reply With Quote
 
 
 
 
Brian Adkins
Guest
Posts: n/a
 
      10-30-2007
On Oct 30, 4:55 am, "Richard Cornford" <(E-Mail Removed)>
wrote:
> Brian Adkins wrote:
> > On Oct 28, 1:40 pm, Richard Cornford wrote:
> >> Brian Adkins wrote:
> >>> 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 you're saying this cross-browser JavaScript knowledge
> > is distributed among the minds of various individuals,

>
> Didn't I write "captured and consolidated _in_ the minds of the
> individuals", not distributed among ... ?
>
> > then I'd say it's neither captured nor consolidated.

>
> If your 'if' were true then you would be correct.
>
> > I feel you're being purposely obtuse here.

>
> Maybe, you are not being very forthcoming with answers to the questions
> you are being asked here so you should not expect too much else from
> others.


I haven't been forthcoming? Do you seriously think that having cross
browser knowledge "captured and consolidated in the *minds* of
individuals" is useful to anyone other than those individuals? I think
many people would correctly infer my intent was to determine if the
knowledge had been consolidated into a form that would be of use to
others - a web site, book, library, etc. Are you suggesting people
interview these individuals?

I don't know why you feel I haven't been forthcoming. After getting
the impression that many people on this newsgroup felt that no
existing JavaScript library was worthwhile to use, I thought I'd start
with a base case and see if there was any library (in active use was
implied) that was worthwhile to use in any context. Getting an answer
to that question has been like pulling teeth!

Maybe you got the impression I was playing games here, but I honestly
wanted to see if any of the regulars here felt any library was
worthwhile.

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


Yes, you and David keep reiterating that "no one says you have to
write it all yourself", and yet you also won't mention any worthwhile
libraries to use. So, let me ask you, if one doesn't need to "write it
all themselves" - where do you suggest people obtain the code that
they haven't written?

There are certainly people who have stated they felt the only
reasonable course of action was to write all JavaScript code
themselves, so maybe by "nobody" you meant you and a few others.

> Use for what exactly? Javascript design decisions should be context
> driven.


Naturally. But since my impression was that this group felt all
existing JavaScript libraries were not good enough to use (that
statement has been made multiple times), I simply wanted to know if
you felt any libraries were good enough in any context. And by
library, I think a reasonable person would discount a few lines of
code whipped up for the purpose of this discussion - I was referring
to something on a public web site currently in existence.

> For example, if you context were needing an application framework for
> the types of activates that are of interest to a large-ish search engine
> provider then YUI could easily be pretty much spot-on for the task.


Wow, finally! So, for some contexts, you feel YUI is a worthwhile
library to use. Are there any others? I take it that you feel both
Prototype and JQuery are not worthwhile. Is YUI the only one that is
in your opinion?

> On
> the other hand, if you goal was to provide supplementary room heating
> for a "target audience" living in a cold climate then making extensive
> use of anything built on top of Prototype.js should pump the maximum
> amount of extra heat into the user's domestic environment.
>
> Work out what it is you are trying to achieve before you set about
> working out how best to achieve it.


What I was trying to achieve was to determine a set of JavaScript
libraries that might be worth investing time in researching. The
purpose was clear, but my choice of information source was seriously
misguided.

 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      10-30-2007
On Oct 29, 3:22 pm, Matt Kruse <(E-Mail Removed)> wrote:

[snip]

>
> > Just what do you need to do that requires jQuery?

>
> Nothing _requires_ jQuery, obviously.
> I have found it useful for:
> 1) Animation effects


Of course. jQuery's is completely inappopriate for anthing that
requires DOM positioning, CSS manipulation, etc. Everything it does
in those areas relies on the userAgent string.

> 2) Simplified AJAX interaction


Don't you have your own "AJAX toolkit?"

> 3) Easily adding :hover effects which IE will understand


If you need a library for hover effects, then perhaps you should skip
the hover effects.

> 4) Adding some UI improvements to existing pages
> 5) etc, etc


Those are too non-specific.

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


If the plug-ins are of similar quality, then you are dumping more bad
code on top of an already shaky foundation.

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

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


Your "argument" in the other thread was an oversimplification.

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

>
> Like?


Like attaching event handlers to every anchor element in a document.
jQuery's design encourages such things and DOM-challenged developers
take full "advantage." Never mind that it creates an inefficient mess
behind the scenes.

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

> > That you know of.

>
> In many cases, I know all my users personally.


How many of them would notice subtle problems like memory leaks. How
many are psychic? One of my main points is that you are buying future
trouble.

>
> > Why not utilize JavaScript programmers to write JavaScript?

>
> What if an organization does not have dedicated Javascript
> programmers?


If an organization does not employ JavaScript developers, then it
shouldn't be developing Web applications. Certainly it shouldn't
bother with hover effects and animations. When these frill features
go awry, there will be nobody there to deal with the issues.

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


I am talking about the code design. As for the API, all you have
found is a false sense of security.

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


Again with the 26K figure. It is almost 50K minified. It doesn't
make sense to compare file weights after compression as compression is
not always available. All things equal, it is five times as large as
a 10K library or two 5K style sheets, etc. Adding compression to the
comparison is just a way for library developers to confuse and mislead
those who don't know any better.

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


Hardly. Here is jQuery's hover function:

hover: function(f,g) {

// A private function for handling mouse 'hovering'
function handleHover(e) {
// Check if mouse(over|out) are still within the same parent element
var p = e.relatedTarget;

// Traverse up the tree
while ( p && p != this ) try { p = p.parentNode; } catch(e) { p =
this; };

// If we actually just moused on to a sub-element, ignore it
if ( p == this ) return false;

// Execute the right function
return (e.type == "mouseover" ? f : g).apply(this, [e]);
}

First, it relies on jQuery's inefficient event normalization to
provide the related target. Then it walks all the way to the document
node in most cases. The try/catch is a bit of a mystery too. As is
the use of apply, when call would do.

Complicated? No. Inefficient and inappropriate for most hover
effects? Yes.

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

>
> I'm quite familiar with browser sniffing arguments.


Your "arguments" indicate that you don't understand the implications
of browser sniffing.

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


There is a big difference between supporting "every browser on the
planet" and supporting just the newer versions of IE, Safari, Opera
and Firefox. Clearly jQuery is inappropriate for use on the public
Internet. And what you fail to realize is that jQuery can easily
break as the versions are updated (a constant happening for the latter
three.) The reliance on browser sniffing marries you to whatever
versions were tested during development, so your Intranet is far from
future-proof.

> I'm not concerned with any browsers not on their supported list, so it
> doesn't bother me.


And what will you tell your IT department when they want to
standardize on a newer browser? It might bother them if the rollout
is held up because the new version breaks jQuery.

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

>
> 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 just repeat the same nonsense over and over. You apparently
haven't heard a word I have said.

> > You are simply delusional.

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


Success is relative.

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


That would be nice. I am getting tired of reading and responding to
the same worthless opinions and non-arguments over and over again.

 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      10-30-2007
On Oct 30, 9:40 am, David Mark <(E-Mail Removed)> wrote:
> Of course. jQuery's is completely inappopriate for anthing that
> requires DOM positioning, CSS manipulation, etc. Everything it does
> in those areas relies on the userAgent string.


I agree with your criticisms, but I again must point out that it has
never been a problem for me. I suspect that the quality of the code
and logic in the library will improve before I find a case where it
would be a problem.

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

> > Like?

> Like attaching event handlers to every anchor element in a document.


One thing I don't like about jQuery is the push to add all kinds of
handlers and stuff on the page load. I've found problems with that
approach, especially for internal webapps where "unobtrusive"
javascript is not a concern. But I do like the ability to use CSS
selectors to apply handlers to specific things after the page loads.
I've used this often to improve existing pages where altering the HTML
source is not simple or in some cases possible.

> > What if an organization does not have dedicated Javascript
> > programmers?

> If an organization does not employ JavaScript developers, then it
> shouldn't be developing Web applications.


That's quite an over-statement. Most web-development organizations I
know of don't have dedicated js programmers.

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

> Again with the 26K figure. It is almost 50K minified.


Packed it is 26k. If you're concerned about file size.

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

> Hardly.


Not the hover function itself, but attaching it to certain elements
via CSS selectors.

Matt Kruse

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      10-30-2007
On Oct 30, 12:34 pm, Matt Kruse <(E-Mail Removed)> wrote:
> On Oct 30, 9:40 am, David Mark <(E-Mail Removed)> wrote:
>
> > Of course. jQuery's is completely inappopriate for anthing that
> > requires DOM positioning, CSS manipulation, etc. Everything it does
> > in those areas relies on the userAgent string.

>
> I agree with your criticisms, but I again must point out that it has
> never been a problem for me. I suspect that the quality of the code
> and logic in the library will improve before I find a case where it
> would be a problem.
>


You already have problems if you use jQuery on the public Internet.
And what makes you think it will improve? How long has it been out?
Look at the issues I cited in the other thread and realize that most
are trivial to fix. Of couse, the problem of patching bugs is
augmented by the sloppy coding style.

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

> > Like attaching event handlers to every anchor element in a document.

>
> One thing I don't like about jQuery is the push to add all kinds of
> handlers and stuff on the page load. I've found problems with that
> approach, especially for internal webapps where "unobtrusive"
> javascript is not a concern. But I do like the ability to use CSS


There is nothing wrong with seperating behavior from markup. It is a
good strategy for internal or external applications.

> selectors to apply handlers to specific things after the page loads.


If your app needs to attach multiple handlers, there are standard ways
of doing that. Using CSS selectors is counter-intuitive. Use jQuery
long enough and you become conditioned to design for what you perceive
as its strengths (e.g. saving you a few lines of code.) Furthermore,
putting jQuery's event handling logic between your elements and their
handlers is inefficient. This is especially true of the often-cited
hover handler.

> I've used this often to improve existing pages where altering the HTML
> source is not simple or in some cases possible.


There ia nothing wrong with that. But you don't need jQuery to do
it. In fact, jQuery will typically lead you to a solution that is
less than optimal.

>
> > > What if an organization does not have dedicated Javascript
> > > programmers?

> > If an organization does not employ JavaScript developers, then it
> > shouldn't be developing Web applications.

>
> That's quite an over-statement. Most web-development organizations I
> know of don't have dedicated js programmers.


They don't have to be dedicated (just competent.)

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

> > Again with the 26K figure. It is almost 50K minified.

>
> Packed it is 26k. If you're concerned about file size.


You are deliberately side-stepping the issue. The compressed size is
not relevant. You can't compare it to other assets unless you
compress them as well, so it is more useful to compare uncompressed
sizes. It is more accurate as well as compression is not universally
available. Furthermore, it is a bad idea to manually compress
scripts. That is handled by the Web server, only after a negotiation
with each client.

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

> > Hardly.

>
> Not the hover function itself, but attaching it to certain elements
> via CSS selectors.


Doesn't it give you pause when you refer to CSS selectors with regard
to DOM queries?

 
Reply With Quote
 
Matt Kruse
Guest
Posts: n/a
 
      10-30-2007
On Oct 30, 12:45 pm, David Mark <(E-Mail Removed)> wrote:
> > That's quite an over-statement. Most web-development organizations I
> > know of don't have dedicated js programmers.

> They don't have to be dedicated (just competent.)


Even that is quite rare.

> > Packed it is 26k. If you're concerned about file size.

> You are deliberately side-stepping the issue. The compressed size is
> not relevant.


I didn't say compressed, I said packed. Using http://dean.edwards.name/packer/

> Doesn't it give you pause when you refer to CSS selectors with regard
> to DOM queries?


Not at all. It's a logical way to select elements in the DOM for
manipulation. It's fantastic.

Of course, you don't need jQuery to use CSS selectors. There are other
libs and even stand-alone functions that use the same approach. Why do
you not like the approach?

Matt Kruse

 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      10-30-2007
On Oct 30, 2:38 pm, Matt Kruse <(E-Mail Removed)> wrote:
> On Oct 30, 12:45 pm, David Mark <(E-Mail Removed)> wrote:
>
> > > That's quite an over-statement. Most web-development organizations I
> > > know of don't have dedicated js programmers.

> > They don't have to be dedicated (just competent.)

>
> Even that is quite rare.
>


And jQuery isn't helping the situation. Instead of trying to become
competent, developers learn how to use somebody else's incompetent
code.

> > > Packed it is 26k. If you're concerned about file size.

> > You are deliberately side-stepping the issue. The compressed size is
> > not relevant.

>
> I didn't say compressed, I said packed. Usinghttp://dean.edwards.name/packer/
>


I thought you might be referring to that. But who in their right mind
would use that thing? HTTP compression is widely supported. Even
without that, dial-up users don't need extra help compressing text
files (the modems take care of it.)

> > Doesn't it give you pause when you refer to CSS selectors with regard
> > to DOM queries?

>
> Not at all. It's a logical way to select elements in the DOM for
> manipulation. It's fantastic.
>


It makes little sense to me. Even less sense after looking at the
jQuery code that implements it. I thought jQuery converted its CSS
selector queries into XPath queries when possible. After glancing at
that code again, it doesn't appear to be the case.

> Of course, you don't need jQuery to use CSS selectors. There are other
> libs and even stand-alone functions that use the same approach. Why do
> you not like the approach?


It makes no sense to me to pass CSS selector syntax to a function that
queries the DOM. And much of what jQuery (and Prototype) do in this
regard is of little practical use.

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      10-31-2007
On Oct 30, 1:03 pm, Brian Adkins wrote:
> On Oct 30, 4:55 am, Richard Cornford wrote:
>> Brian Adkins wrote:
>>> On Oct 28, 1:40 pm, Richard Cornford wrote:
>>>> Brian Adkins wrote:
>>>>> 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 you're saying this cross-browser JavaScript knowledge
>>> is distributed among the minds of various individuals,

>
>> Didn't I write "captured and consolidated _in_ the minds
>> of the individuals", not distributed among ... ?

>
>>> then I'd say it's neither captured nor consolidated.

>
>> If your 'if' were true then you would be correct.

>
>>> I feel you're being purposely obtuse here.

>
>> Maybe, you are not being very forthcoming with answers to
>> the questions you are being asked here so you should not
>> expect too much else from others.

>
> I haven't been forthcoming?


Corrrect.

> Do you seriously think that having cross browser knowledge
> "captured and consolidated in the *minds* of individuals"
> is useful to anyone other than those individuals?


It is of more use to others than not having it.

> I think many people would correctly infer my intent was
> to determine if the knowledge had been consolidated into a
> form that would be of use to others - a web site, book,
> library, etc.


And it hasn't. All the information is availed but not consolidated.

> Are you suggesting people interview these individuals?


Why not? What do you think you are doing at the moment?

> I don't know why you feel I haven't been forthcoming.


The ratio of questions asked to answers given.

> After getting the impression that many people on this
> newsgroup felt that no existing JavaScript library was
> worthwhile to use,


Try to remember what it is you have been shown here. It is almost
trivial to pick a library and find plenty of examples of code that has
been written where if the individual who wrote that code had understood
what they were doing they never would have written it (assuming that
they are sane). We are not talking subjective judgments or questions of
design or style here but instead specific things that technical
knowledge alone would have prevented. For example, in an earlier post I
showed an example from dojo where the HTML mark-up for a SCRIPT element
had been split up using a number of concatenation operations. As soon as
someone understands why they might be doing this (and I mean really
understands, not jut believes some old wife's tale, or slavishly
reproduces someone else's mystical incantation) they will do it
differently.

Thus when you see these things being done in the way it is done in dojo
(and many other places) it is reasonable to infer that the individual
responsible did not understand what they were doing, and so did not have
the relevant knowledge. And in the case of a community effort, like
dojo, the existence of such code implies that the most knowledgeable
person involved does not have this knowledge.

Should it be surprising that when observing that the people writing
theses libraries lack basic browser scripting knowledge that there
should then be extreme reticence is recommending that anyone use the
products of such self-evidently ignorant authors?

There is also the matter of considering what it may have been that these
authors would have produced if they had taken the time to learn browser
scripting before prematurely assuming themselves qualified to write
there libraries. The question of what changes to the designs of these
libraries would have followed from gaining the additional experience of
scripting web browsers. This is particularly pertinent when you observe
that the people who do have this experience are not creating large scale
general purpose and instead have totally different notions of what is
appropriate in browser script design.

> I thought I'd start with a base case and see if there was
> any library (in active use was implied) that was worthwhile
> to use in any context.


To which the answer was always going to be 'none', because javascript
design decisions should be context driven, which would not be the case
if they could be context independent.

> Getting an answer
> to that question has been like pulling teeth!


Only because you insist that that question should have an answer when
the rational response is to ask you to qualify the context (which is
what has happened).

> Maybe you got the impression I was playing games here,
> but I honestly wanted to see if any of the regulars here
> felt any library was worthwhile.


But you did not explain what there libraries were supposed to be
worthwhile for, even though you were asked.

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

>
> Yes, you and David keep reiterating that "no one says you
> have to write it all yourself", and yet you also won't
> mention any worthwhile libraries to use.


Didn't I put quite a lot of effort into explaining that those are not
the only two alternatives?

> So, let me ask you, if one doesn't need to "write it
> all themselves" - where do you suggest people obtain the
> code that they haven't written?


If you spend your time looking for libraries the results will either be
your finding libraries or your not finding them. My design strategy
would have me looking for independent task-specific modules and finding
those in many places, including the archives for this group.

> There are certainly people who have stated they felt the
> only reasonable course of action was to write all
> JavaScript code themselves,


No there are not.

> so maybe by "nobody" you meant you and a few others.


No, it means nobody sane.

>> Use for what exactly? Javascript design decisions should
>> be context driven.

>
> Naturally.


So isn't it understandable that you would not get recommendations
without first stating the context.

> But since my impression was that this group felt all
> existing JavaScript libraries were not good enough
> to use (that statement has been made multiple times),


There are certainly very good reasons for question the fitness of many
available libraries for any task. You will recall that I have
demonstrated in this thread that dojo includes code that falls into the
mystical incantation style of programming, and clear evidence of its
authors either not understanding the basics of javascript or not being
rational.

> I simply wanted to know if you felt any libraries were
> good enough in any context.


And I have proposed two contexts for which particular libraries would be
well suited. And indeed it is the very design flaws in Prototype.js that
make it well suited in the context of wanting to have the user's
computer run hot.

> And by library, I think a reasonable person would discount
> a few lines of code whipped up for the purpose of this
> discussion - I was referring to something on a public web
> site currently in existence.
>
>> For example, if you context were needing an application
>> framework for the types of activates that are of interest
>> to a large-ish search engine provider then YUI could easily
>> be pretty much spot-on for the task.

>
> Wow, finally! So, for some contexts, you feel YUI is a
> worthwhile library to use.


Well yes. YUI was designed as an application framework for a search
engine provider, so if you are a search engine provider looking for an
application framework it could be 100% suited to your context.

> Are there any others?


Yes, there are many competently written single task/context libraries
that are entirely fit for the single task/context for which they were
written.

> I take it that you feel both
> Prototype and JQuery are not worthwhile.


I think Prototype.js has an inherently stupid design. JQuery is not code
that I have really looked at, though the snippets of it posted here do
not suggest competence on the part of its author.

> Is YUI the only one that is
> in your opinion?


That is not what I said, or even implied.

>> On the other hand, if your goal was to provide supplementary
>> room heating for a "target audience" living in a cold climate
>> then making extensive use of anything built on top of
>> Prototype.js should pump the maximum amount of extra heat into
>> the user's domestic environment.

>
>> Work out what it is you are trying to achieve before you set
>> about working out how best to achieve it.

>
> What I was trying to achieve was to determine a set of JavaScript
> libraries that might be worth investing time in researching.


Of the libraries discussed here the only one that is worth researching
is YUI, unless you want examples of code written by people who don't
really understand what they are doing. But YUI is not a panacea. The
further you move away from the context for which it was designed the
less suited it will be to that context.

> The purpose was clear,


Not really, that last sentence was the first time you asked for
"libraries that might be worth investing time in researching", which is
a very different criteria from any previously mentioned.

> but my choice of information source was
> seriously misguided.


This certainly is not the place to ask questions if you insist on
getting only pre-defined answers.

Richard.

 
Reply With Quote
 
Brian Adkins
Guest
Posts: n/a
 
      10-31-2007
On Oct 30, 10:11 pm, "Richard Cornford" <(E-Mail Removed)>
wrote:
> On Oct 30, 1:03 pm, Brian Adkins wrote:
> > The purpose was clear,

>
> Not really, that last sentence was the first time you asked for
> "libraries that might be worth investing time in researching", which is
> a very different criteria from any previously mentioned.


Ok, if you feel that "worthwhile" and "worth investing time in
researching" are "very different" concepts, I think I can see why
we're having difficulty communicating, and we're likely to have
continued communication difficulties. I'll assume responsibility for
the miscommunication, and move on to new and wonderful JavaScript
threads of discussion free of the term "library".

Brian

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Javascript Drop Down Menu Issue. Replacing Text of the Menu Ivann Javascript 1 07-22-2008 08:34 PM
any recommendations for drop-down menu code? laredotornado@zipmail.com Javascript 2 08-16-2006 04:40 PM
RE: Menu recommendations Yan-Hong Huang[MSFT] ASP .Net 0 07-29-2003 08:30 AM
Re: Menu recommendations Steve C. Orr, MCSD ASP .Net 1 07-29-2003 02:43 AM
Re: Menu recommendations Kevin Spencer ASP .Net 2 07-28-2003 09:29 PM



Advertisments