473,408 Members | 1,728 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,408 software developers and data experts.

third-party libraries

Hi,
any idea about what third-party library can I use to improve my
Javascript UI

YUI ?
Google ?
script.aculo.us ?

or others?

My goal is to use one that is power and widely used...

Thanks

Aug 25 '07 #1
37 1968
On Aug 25, 12:48 pm, josh <xdevel1...@gmail.comwrote:
any idea about what third-party library can I use to improve my
Javascript UI
jQuery + Interface + (other plugins)

Matt Kruse

Aug 25 '07 #2
Matt Kruse wrote:
On Aug 25, 12:48 pm, josh <xdevel1...@gmail.comwrote:
>any idea about what third-party library can I use to improve my
Javascript UI

jQuery + Interface + (other plugins)
jQuery is junk. It uses needless (and failing) browser detection, and it is
based on Prototype.
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Aug 25 '07 #3
On Aug 25, 1:24 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
jQuery is junk.
Your "opinion" is without merit and in the minority.
It uses needless (and failing) browser detection
Incorrect.
and it is based on Prototype.
Incorrect.

I've never in the history of this group seen code written by you that
was superior to any part of jQuery. Your opinion is worthless.

Matt Kruse

Aug 25 '07 #4
Matt Kruse wrote:
On Aug 25, 1:24 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>jQuery is junk.

Your "opinion" is without merit and in the minority.
See below.
>It uses needless (and failing) browser detection

Incorrect.
It used browser detection when I checked the code at 2007-08-12.
I've never in the history of this group seen code written by you that
was superior to any part of jQuery. Your opinion is worthless.
Argumentum ad hominem. I think you can do better than that.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Aug 25 '07 #5
Matt Kruse wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
>[jQuery] is based on Prototype.

Incorrect.
You're right, my bad. What is "Interface"?
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Aug 25 '07 #6
Matt Kruse meinte:
>jQuery is junk.

Your "opinion" is without merit and in the minority.
So... Given its market penetration: Internet Explorer is the best
browser? Right?
I've never in the history of this group seen code written by you that
was superior to any part of jQuery. Your opinion is worthless.
Hmmm... Makes opinions of all kind of critics useless. The film critic
who is no director, the book critic who is no author (or maybe only an
"average" one), restaurants, fashion, art, etc.

Bashing Thomas might be fun, but your "arguments" stink (particularly in
this context).

Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 25 '07 #7
On Aug 25, 3:31 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
It used browser detection when I checked the code at 2007-08-12.
And it still does:
Your statement was:
: jQuery is junk. [...] It uses needless (and failing) browser
detection

I wasn't disputing that it uses browser detection. I was disputing
that it is needless and failing.

Browser detection is not ideal, but the reality is that in some cases
it works and is the most prudent way to accomplish a task in a
generalized, cross-browser way. Only in fringe cases (often where the
user is deliberately trying to create a problem) does it usually fail.
If you still need a reason why not to use jQuery in its present state:
"compressed": 22679 bytes
22k is trivial. Smaller than many images, yet it packs considerable
power. Simply stating the size of a library without presenting any
arguments is meaningless.
>>[jQuery] is based on Prototype.
Incorrect.
You're right, my bad.
No need to state the obvious.
What is "Interface"?
It's a jQuery plugin that creates many animation and UI effects.

Matt Kruse

Aug 25 '07 #8
On Aug 25, 3:38 pm, Gregor Kofler <use...@gregorkofler.atwrote:
Your "opinion" is without merit and in the minority.
So... Given its market penetration: Internet Explorer is the best
browser? Right?
I said nothing about market penetration. The fact is that there are
many expert javascript developers in the world who have much more
experience and knowledge than Mr. P. Ears, and I don't know of any
that would classify jQuery as "junk". Even among his peers (average
javascript hackers) his opinion would be in the minority.

I won't even touch the IE "argument". I've been developing for the web
for 15 years - long enough to have heard every debate under the sun a
thousand times. Nothing is as simple as it seems.
Hmmm... Makes opinions of all kind of critics useless. The film critic
who is no director, the book critic who is no author (or maybe only an
"average" one), restaurants, fashion, art, etc.
Mr. Ears has no credibility in this forum or on any topic in
javascript. He is not a film critic who is not a director - he has
published code and samples in the past, none of which I have found to
be impressive in the least. He does claim to be a javascript expert,
yet fails to demonstrate it. He's a film critic who _has_ tried to
make films and failed miserably, yet continues to tell others how to
do it "right". One should not critique something that one obviously
does not understand.
Bashing Thomas might be fun, but your "arguments" stink (particularly in
this context).
Bashing P.E. isn't fun. I only followup on this topic for fear that
someone else would find his arguments and stay away from jQuery
because of his baseless remarks.

Matt Kruse

Aug 25 '07 #9
Matt Kruse meinte:
>Hmmm... Makes opinions of all kind of critics useless. The film critic
who is no director, the book critic who is no author (or maybe only an
"average" one), restaurants, fashion, art, etc.

Mr. Ears has no credibility in this forum or on any topic in
javascript. He is not a film critic who is not a director - he has
published code and samples in the past, none of which I have found to
be impressive in the least. He does claim to be a javascript expert,
yet fails to demonstrate it. He's a film critic who _has_ tried to
make films and failed miserably, yet continues to tell others how to
do it "right". One should not critique something that one obviously
does not understand.
"...has no credibility on this forum (sic!)..."
"...published nothing I found impressive in the least..."
"...failed miserably..."
"...does not understand (Javascript)..."

Maybe you should put it "I think TL is an obnoxious dork, who I
thoroughly despise." Sounds equally substantial. Put him in your
killfile (Randy Webb should do the same) and everything will be good again.

Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 26 '07 #10
Matt Kruse wrote:
On Aug 25, 3:31 pm, Thomas 'PointedEars' Lahn wrote:
>>It used browser detection when I checked the code at
2007-08-12.
And it still does:

Your statement was:
: jQuery is junk. [...] It uses needless (and failing)
browser detection

I wasn't disputing that it uses browser detection.
But using browser detection is the most telling indicator of bad code
that exists.
I was disputing
that it is needless and failing.
The examples cited by Thomas show lots of evidence that the browser
detection used is needless, for example:-

| --jquery-1.1.4.js:1604---------------------------------------------
| // check if target is a textnode (safari)
| if (jQuery.browser.safari && event.target.nodeType == 3)
| event.target = originalEvent.target.parentNode;

- where the logic implemented is that is the browser appears to be
safari and the event.target is a text node then it should be replaced
with the parent of the original target, suggesting that the subject node
should be an element node not a text node. But why only when the browser
is safari? If event.target's being a text node is a problem on safari
shouldn't it also be a problem on any browser where it is a text node?

The logic here betrays a mindset that is thinking in terms of supporting
a limited set of browsers and then adding branches with the idea of
adding single browsers to that set, but in taking that approach has
become fixated on the browsers being added to the extent of being
blinded to the general problem.

And when I see:-

| --jquery-1.1.4.js:1402----------------------------------------------
| // For whatever reason, IE has trouble passing the window object
| // around, causing it to be cloned in the process
| if ( jQuery.browser.msie && element.setInterval != undefined )
| element = window;

- I am reading a comment that shouts of programming by mystical
incantation.
Browser detection is not ideal,
It is unreliable and technically bass-less.
but the reality is that in some cases
it works
Things that are unreliable tend to work in some cases, it is the cases
where they don't work that makes them unreliable.
and is the most prudent way to accomplish a task in a
generalized,
Wanting to do things in a generalised way is itself a decision that
introduces available problems, and there are very few real-world
situations (beyond the questionable wisdom of attempting to create
general libraries) that are general.
cross-browser way.
That is precisely what using browser detection renders impossible. The
best that could be achieved is multi-browser, as we see here in this
JQuery code.
Only in fringe cases (often where the
user is deliberately trying to create a problem) does it
usually fail.
<snip>

You are trying to blame the user for the unreliability that results form
a script author using a technique that is technically baseless and
self-evidently flawed? It may be a convenient excuse for incompetence,
but it does not really excuse it at all.

Richard.

Aug 26 '07 #11
Gregor Kofler wrote:
<snip>
Put him in your killfile (Randy Webb should do the same)
and everything will be good again.
No, that is not a good idea at all. Any significant use of killfiles
will eventually result in there being multiple independent cultures
within the group, with each unaware of what the other(s) are saying or
doing. That will be extremely confusing to newcomers, and would result
in a great deal of nonsense going uncorrected/challenged, to the overall
determent of credibility of the group as a whole.

Richard.

Aug 26 '07 #12
Richard Cornford meinte:
Gregor Kofler wrote:
>Put him in your killfile (Randy Webb should do the same)
and everything will be good again.

No, that is not a good idea at all.
[snip]

Generally agreed. However, I suppose Thomas being in Matt Kruse's or
Randy Webb's killfile won't do any harm to the discussions, since they
just deliver insults as responses to Thomas' postings.

That's IMO simply childish and cut off otherwise interesting threads.
How about Matt Kruse having his "jQuery + Interface + (other plugins)"
explained in detail?

Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 26 '07 #13
On Aug 26, 11:10 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
But using browser detection is the most telling indicator of bad code
that exists.
Well, I wouldn't go _that_ far, but I do agree that in most cases it
is a sign of a programmer who hasn't thought through the problem
enough.
| --jquery-1.1.4.js:1604---------------------------------------------
| // check if target is a textnode (safari)
| if (jQuery.browser.safari && event.target.nodeType == 3)
| event.target = originalEvent.target.parentNode;
But why only when the browser
is safari? If event.target's being a text node is a problem on safari
shouldn't it also be a problem on any browser where it is a text node?
Good question. I will raise some of these questions to the developers,
because I am curious to know the reasoning as well. Surely they are
not perfect and would be open to code improvements. I've never dug
deep into the browser-sniffing portions of the library to try to
justify their existence, but rather trusted that the developers had
done so already and had technical reasons for coding how they did. But
I may be able to contribute to improving the code, perhaps. I know
you're probably not interested in improving the code, but if you have
any other specific criticisms I would like to hear them.
Browser detection is not ideal,
It is unreliable and technically bass-less.
Are you saying it lacks low-frequency tones or a certain type of fish?
;)
cross-browser way.
That is precisely what using browser detection renders impossible. The
best that could be achieved is multi-browser, as we see here in this
JQuery code.
Perhaps it could be improved. Also consider that jQuery's intent is
always to add unobtrusive scripting to an otherwise plain-html page,
so if there are problems in some browsers that end up not being
supported, the existing non-scripted page should still work.
You are trying to blame the user for the unreliability that results form
a script author using a technique that is technically baseless and
self-evidently flawed?
No - if a user configures their browser to lie about what it is, then
they should expect unpredictable results. In the absence of users
trying to purposely confuse the code, I've been extremely happy with
the cross-browser capabilities of jQuery and I've yet to come across a
real-world situation where it failed to work as expected.

Matt Kruse

Aug 26 '07 #14
On Aug 26, 1:47 pm, Gregor Kofler <use...@gregorkofler.atwrote:
Generally agreed. However, I suppose Thomas being in Matt Kruse's or
Randy Webb's killfile won't do any harm to the discussions, since they
just deliver insults as responses to Thomas' postings.
I rarely post to this group anymore, but it is true that I
occasionally get drawn into a battle with Thomas that I should just
let go. Reading his history of posts in this group easily shows why he
has earned the reputation he has here, however. And it's not just with
Randy and myself. It's difficult to let someone with such a lack of
perspective and technical experience "get the last word" on topics
where people are looking for advice that they can take with them and
actually use in something productive. I would hate for people doing
google searches and finding his replies to think they has is some de-
facto expert in this field and take his opinions more seriously than
they warrant.
How about Matt Kruse having his "jQuery + Interface + (other plugins)"
explained in detail?
What more do you want to know? Going to jquery.com and also finding
the Interface plugin/examples should be all anyone needs to get going
if they are interested.

Matt Kruse

Aug 26 '07 #15
Matt Kruse meinte:
>How about Matt Kruse having his "jQuery + Interface + (other plugins)"
explained in detail?
What more do you want to know? Going to jquery.com and also finding
the Interface plugin/examples should be all anyone needs to get going
if they are interested.
The OP wanted to know which 3rd party library to use (though he didn't
state any requirements). IMO you should at least elaborate somewhat on
the whys of your ..er... recommendation.

Threads in other groups sound similar:

"best camera?"
"canon!"
>"canon 's crap"
>>"idiot. haven't seen any good pix from you. you don't have a clue"
....

Gregor

--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 26 '07 #16
Matt Kruse wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
>If you still need a reason why not to use jQuery in its present state:
"compressed": 22679 bytes

22k is trivial. Smaller than many images, yet it packs considerable
power. Simply stating the size of a library without presenting any
arguments is meaningless.
The library could be much smaller if it did not so much needless browser
detection. That said, jQuery is mostly an implementation if XPath; as
several DOMs have built-in XPath support, it is unreasonable not to make use
of that. See the XPath one-liner I posted recently; with jQuery that would
have included the download of at least 22k to work in the supported
environments.
>>>[jQuery] is based on Prototype.
Incorrect.
You're right, my bad.

No need to state the obvious.
In contrast to several other people who post here, I have a sense of decency
left, and feel compelled to apologize when I went awfully wrong. Call me
old-fashioned.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Aug 26 '07 #17
On Aug 26, 3:24 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
jQuery is mostly an implementation if XPath;
"Mostly"? It does considerably more than XPath.
several DOMs have built-in XPath support, it is unreasonable not to make use
of that.
http://docs.jquery.com/DOM/Traversin...Path_Selectors
with jQuery that would
have included the download of at least 22k to work in the supported
environments.
If you're only going to use a selector to grab elements, using jQuery
may very well be over-kill. But that's not really a criticism of the
library.

Matt Kruse

Aug 26 '07 #18
Wanting to do things in a generalised way is itself a decision that
introduces available problems, and there are very few real-world
situations (beyond the questionable wisdom of attempting to create
general libraries) that are general.
A very generalized statement, ironically.

Conceptual reuse is what language itself is based upon.

Creating a sentence, or a program statement is general knowledge.

Building a kitchen. Imagine, what if the builder had a mistake and put
the toilet next to the refrigerator!

In the code world, we have great things like frameworks. Now in Java,
there is Spring. Spring is great.

In JavaScript, we have a lot of libraries. They're all buggy.

My only problem with them is that they are all proprietary.

Can you use Yahoo event system with jQuery Ajax transport with a Dojo
widget?
>
That is precisely what using browser detection renders impossible. The
best that could be achieved is multi-browser, as we see here in this
JQuery code.
Only in fringe cases (often where the
user is deliberately trying to create a problem) does it
usually fail.

<snip>

You are trying to blame the user for the unreliability that results form
a script author using a technique that is technically baseless and
self-evidently flawed? It may be a convenient excuse for incompetence,
but it does not really excuse it at all.
Typical.
Richard.

Aug 27 '07 #19
On Aug 27, 5:00 am, Matt Kruse <m...@mattkruse.comwrote:
On Aug 26, 11:10 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
[...]
| --jquery-1.1.4.js:1604---------------------------------------------
| // check if target is a textnode (safari)
| if (jQuery.browser.safari && event.target.nodeType == 3)
| event.target = originalEvent.target.parentNode;
But why only when the browser
is safari? If event.target's being a text node is a problem on safari
shouldn't it also be a problem on any browser where it is a text node?

Good question. I will raise some of these questions to the developers,
because I am curious to know the reasoning as well. Surely they are
not perfect and would be open to code improvements.
Early versions of Safari returned a text node if that was the node
that started the event, other browsers don't.
[...]
No - if a user configures their browser to lie about what it is, then
they should expect unpredictable results. In the absence of users
trying to purposely confuse the code, I've been extremely happy with
the cross-browser capabilities of jQuery and I've yet to come across a
real-world situation where it failed to work as expected.
I find programmers who can't keep their browser sniffing up-to-date to
be a much bigger problem. eBay keeps telling me to update my browser
when I visit using Safari 3 (but not with version 2). I've repeatedly
asked them to what verison, they don't respond.

The use of browser sniffing is becoming more prevelent, its inclusion
in popular libraries only encourages bad programming.

My ISP uses browser sniffing to deliver totally different pages to
different browsers, significant portions of the site are degraded if
you use a browser they've decided not to support. Banks are starting
to do the same again too after many years of reducing its incidence,
I've even seen sites attempting to detect "mobile Safari", and
detection scripts up to 500 lines (there are probably much longer
ones) that fail to recognise many reasonably popular browsers.

It is a return to the bad old days, we really shouldn't need to go
back there.
--
Rob

Aug 27 '07 #20
On Mon, 27 Aug 2007 06:26:51 -0000, in comp.lang.javascript
"dh**********@gmail.com" <dh**********@gmail.com>
<11**********************@i13g2000prf.googlegroups .comwrote:
>|
| Wanting to do things in a generalised way is itself a decision that
| introduces available problems, and there are very few real-world
| situations (beyond the questionable wisdom of attempting to create
| general libraries) that are general.
| >
|
| A very generalized statement, ironically.
|
| Conceptual reuse is what language itself is based upon.
|
| Creating a sentence, or a program statement is general knowledge.
|
| Building a kitchen. Imagine, what if the builder had a mistake and put
| the toilet next to the refrigerator!
|
| In the code world, we have great things like frameworks. Now in Java,
| there is Spring. Spring is great.
|
| In JavaScript, we have a lot of libraries. They're all buggy.
|
| My only problem with them is that they are all proprietary.
|
| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| widget?
http://docs.jquery.com/Using_jQuery_...ther_Libraries
The jQuery library, and virtually all of its plugins are constrained
within the jQuery namespace. As a general rule, "global" objects are
stored inside the jQuery namespace as well, so you shouldn't get a
clash between jQuery and any other library (like Prototype, MooTools,
or YUI).

>| That is precisely what using browser detection renders impossible. The
| best that could be achieved is multi-browser, as we see here in this
| JQuery code.
| >
| Only in fringe cases (often where the
| user is deliberately trying to create a problem) does it
| usually fail.
| >
| <snip>
| >
| You are trying to blame the user for the unreliability that results form
| a script author using a technique that is technically baseless and
| self-evidently flawed? It may be a convenient excuse for incompetence,
| but it does not really excuse it at all.
| >
| Typical.
|
| Richard.
|
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------
Aug 27 '07 #21
Jeff North wrote:
[...] "dh**********@gmail.com" [...] wrote:
>| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| widget?

http://docs.jquery.com/Using_jQuery_...ther_Libraries
The jQuery library, and virtually all of its plugins are constrained
within the jQuery namespace. As a general rule, "global" objects are
stored inside the jQuery namespace as well, so you shouldn't get a
clash between jQuery and any other library (like Prototype, MooTools,
or YUI).
However, that is completely ignoring the fact that ECMAScript 3
implementations have no concept of a namespace, and that any
user-defined object or property may be overwritten at any time.

Please trim your quotes.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Aug 27 '07 #22
On Aug 27, 1:26 am, "dhtmlkitc...@gmail.com" <dhtmlkitc...@gmail.com>
wrote:
In JavaScript, we have a lot of libraries. They're all buggy.
My only problem with them is that they are all proprietary.
I don't know what exactly you mean by "proprietary", but check out
base2:
http://code.google.com/p/base2/

Dean's goal is to merely correct for browsers bugs/quirks and to
implement missing functionality so that you can code javascript to the
standards and have it work even in browsers that don't support the
standards. It's an interesting approach, but it doesn't offer the
convenience or simplicity of higher-level libs like jQuery.

Matt Kruse

Aug 27 '07 #23
On Aug 27, 8:35 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
All-purpose libraries are a Bad Thing.
That's a fundamental difference of opinion and has been argued to
death. Needless to say, your opinion is in the minority, even among
experts.
Not following the standard recommendation by using `$' as an identifier for
code that is not machine-generated is another reason why not to use it.
That's a ridiculous criticism, especially considering that '$' is just
an alias of the jQuery object put there for convenience. You never
have to use '$' in your jQuery code anywhere if you don't want to. In
fact, one of the rules of writing plugins is to never use $ because
the user may also be using another library like Prototype.

Matt Kruse

Aug 27 '07 #24
What more do you want to know? Going to jquery.com and also finding
the Interface plugin/examples should be all anyone needs to get going
if they are interested.

Matt Kruse
.... when I posted this topic I done it because I'm in a difficult
moment. My boss told me:
>ok you know Javascript/Css/Jsp ecc. but now I want a more productivity! Does exist a Javascript toolkit that speed-up your job and make your code more reusable? Ok prepare me a comparative draft....... >>>
Sincerely I'd choose YUI because it seems very good and because it
seems can give more guarantees
that in a future it will be largely used... but why W3C does not make
an API set????????
it seems like programming in C++. What GUI, REGEX, ecc. library must I
use?????

Help me!!!!!

Aug 27 '07 #25
Matt Kruse wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
>All-purpose libraries are a Bad Thing.

That's a fundamental difference of opinion and has been argued to
death.
Fair enough.
Needless to say, your opinion is in the minority, even among experts.
Are we back to ad hominem again? You cannot even prove that, no matter your
definition of "experts".
>Not following the standard recommendation by using `$' as an identifier for
code that is not machine-generated is another reason why not to use it.

That's a ridiculous criticism,
It isn't. It shows a pattern.
especially considering that '$' is just an alias of the jQuery object put
there for convenience.
I know. And that convenience is disregarding the standard.
You never have to use '$' in your jQuery code anywhere if you don't want to.
But the library itself defines it, and it defines and uses more properties
that begin with `$'.
In fact, one of the rules of writing plugins is to never use $ because
the user may also be using another library like Prototype.
JFTR: You are defending one piece of junk code with the possibility of using
another one.
PointedEars
Aug 27 '07 #26
Richard Cornford wrote:
RobG wrote:
>Early versions of Safari returned a text node if that was
the node that started the event, other browsers don't.

As safari's code is based upon Konquerors' code, and Safari development
is feeding back into Konqueror development, that is unlikely to be true.
Not as unlikely as you may think. According to the KHTML people (I don't
have the reference anymore), Safari WebCore is actually based on a very
small subset of KHTML code, and has been extended much by Apply since. And
the feed that gets back from Apple WebKit developers to KHTML developers was
described, and maybe still is, sparse at best.

See for example http://www.eweek.com/article2/0,1895,1826096,00.asp
PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Aug 27 '07 #27
RobG wrote:
Early versions of Safari returned a text node if that was the node
that started the event, other browsers don't.
Old versions of Mozilla also do.

--

Martin Honnen
http://JavaScript.FAQTs.com/
Aug 27 '07 #28
josh wrote:
>What more do you want to know? Going to jquery.com and
also finding the Interface plugin/examples should be
all anyone needs to get going if they are interested.

Matt Kruse

... when I posted this topic I done it because I'm in
a difficult moment. My boss told me:
>>ok you know Javascript/Css/Jsp ecc. but now I want a
more productivity! Does exist a Javascript toolkit
that speed-up your job and make your code more
reusable? Ok prepare me a comparative draft....... >>>

Well there is the thing; if you cannot judge the answer for yourself
then your boss' "you know javascript" was a false assumption on his part
(or a false claim on yours).
Sincerely I'd choose YUI because it seems very good and
because it seems can give more guarantees
that in a future it will be largely used...
What would YUI being more "largely used" have do with your productivity
or your ability to make reusable code? Are you in the same business as
Yahoo?
but why W3C does not make
an API set????????
They are working on a standardised API for web applications. Are you in
the business of writing web applications?
it seems like programming in C++. What GUI, REGEX, ecc.
library must I use?????
Comparing apples and oranges will not help. The best approach to writing
computer application code (the existence of numerous and comprehensive
pre-written and standardised libraries) is not automatically the best
approach to writing web browser scripts.

Richard.

Aug 27 '07 #29
Well there is the thing; if you cannot judge the answer for yourself
then your boss' "you know javascript" was a false assumption on his part
(or a false claim on yours).
well I explain me better! I use Javascript and related web
technologies by a lot time
but because of the objects cross-browser incompatibility (thanks to
Microsoft for which the W3c standards are nothing....) every
program take long time to end (also if it ends well and also if I
write some generics functions). Now my boss have seen that the web is
evolved and he wants that we write applications like if we was writing
in Java or C++ (that is my first background). Than
I must explain him that it is not so simple because Javascript is not
proper an OOP language and
so on...but at least if I can use some high-level library...
Obviously I can study each API and make me a personal opinion but my
SIMPLE question was
to know if someone had already used some APIs...on the road...and can
give me some ideas of his experience!
Are you in the same business as
Yahoo?
No!
They are working on a standardised API for web applications. Are you in
the business of writing web applications?
Sorry, here, I don't understand what you want to say
Comparing apples and oranges will not help.
the concept I express does not concerns apples or oranges but to make
some standard API to help
programmer and this is the same when I want to program a GUI with the C
++

josh

Aug 27 '07 #30
On Mon, 27 Aug 2007 15:06:28 +0200, in comp.lang.javascript Thomas
'PointedEars' Lahn <Po*********@web.de>
<46**************@PointedEars.dewrote:
>| Jeff North wrote:
| [...] "dh**********@gmail.com" [...] wrote:
| >| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| >| widget?
| >
| http://docs.jquery.com/Using_jQuery_...ther_Libraries
| The jQuery library, and virtually all of its plugins are constrained
| within the jQuery namespace. As a general rule, "global" objects are
| stored inside the jQuery namespace as well, so you shouldn't get a
| clash between jQuery and any other library (like Prototype, MooTools,
| or YUI).
|
| However, that is completely ignoring the fact that ECMAScript 3
| implementations have no concept of a namespace, and that any
| user-defined object or property may be overwritten at any time.
I think that you are completely ignoring the fact that the people at
jQuery weren't using namespace in the context of the ECMAScript (non)
definition.
>| Please trim your quotes.
....and get abused for misquoting or trimming too much?
>| PointedEars
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------
Aug 27 '07 #31
On Aug 27, 9:35 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
It is neither generalised not ironic. It is a general statement that is
trivially true. It is also an important statement because there are
browser scripting problems that are insoluble (or can never be complexly
solved, or for which the solution is non-viable (mostly fare too big and
slow to use) generally, but can be solved in the majority of known
contexts because in those contexts sufficient aspects of the general
problem can be observed to be absent that what remains can be handled.
One common argument in favor of some browser sniffing is that a
generalized test to check for a browser quirk or misbehavior may be
quite long and complex, even though the problem is known to only exist
in a single browser or a single environment. Why write extensive extra
code to solve the general case when it's never been shown that there
is a problem outside of the very specific case?

Relying on browser sniffing and some object detection would surely be
shorter, faster, and just as compatible. Although it wouldn't cover
the case where some other browser develops the same problem, why worry
about a situation that can be demonstrated as not existing? If it pops
up in the future, why not generalize it at that point if necessary?

Matt Kruse
Aug 27 '07 #32
"Matt Kruse" <ma**@mattkruse.comwrote:
On Aug 27, 9:35 am, Richard Cornford wrote:
>It is neither generalised not ironic. It is a general statement
that is trivially true. It is also an important statement because
there are browser scripting problems that are insoluble (or can
never be complexly solved, or for which the solution is non-viable
^^^^^^^^^
Should have been "completely".
>(mostly fare too big and slow to use) generally, but can
^^^
"far"
>be solved in the majority of known contexts because in
those contexts sufficient aspects of the general problem
can be observed to be absent that what remains can be handled.

One common argument in favor of some browser sniffing is that a
generalized test to check for a browser quirk or misbehavior
may be quite long and complex,
Aren't we a few posts down stream of code showing a browser sniffing
based test that is more complex than it could have been precisely
because of the browser sniffing (that is, a test where the subject
should have been the type of the Node, not the type of the Node plus
whether the browser was Safari)?

It also would not be much of an argument in the face of examples of
browser sniffing code that includes and executes 500+ lines just for the
browser sniffing, and regardless of whether or not the results are ever
used.

Still, to date you are the only person who has mentions this "common
argument" to me. Obviously I must be not taking part in enough browser
sniffing and feature testing related debates.
even though the problem is known to only exist
in a single browser or a single environment.
How would it be "known" that the problem only existed on a single
browser? Logically haven't you got to positively verify that the problem
does not exist on _every_ other browser in existence before you can know
that? Given that the people who put most effort into collection web
browsers are the least convinced that it is possible to possess all web
browsers isn't that supposed 'knowledge' practically unachievable?

Without that knowledge you are in the area of surmise and assumptions.
Why write extensive extra code to solve the general
case when it's never been shown that there
is a problem outside of the very specific case?
You don't write browser sniffing code because it is imposable to write
such code so that it will accurately identify browsers or their
versions. Thus you could not know that there was a certain relationship
between the results of such tests and the condition that was the
purported reason for the test. While the principle of feature detection
that a good feature detection test tests a condition that has a
one-to-one relationship with whatever it is that the test is supposed to
determine, if achievable, guarantees the relationship of the test with
the need for a test.
Relying on browser sniffing and some object detection would
surely be shorter, faster, and just as compatible.
In some cases shorter and faster (but not in all cases by a very long
way), but just not (and never) reliable. Remember that browser sniffing
is predicated on treating something that is not supposed to be treated
as a source of information is if it was a source of information.
Reliable outcomes cannot be achieved in that way.
Although it wouldn't cover the case where some other browser
develops the same problem,
Or already had the same problem but had gone unnoticed by whoever
designed the browser sniffing code.
why worry about a situation that
can be demonstrated as not existing?
How were you planning on "demonstrating" that no unknown or unrecognised
browser has the issue in question? Trying a test-case on all browsers
may represent such a demonstration, if achievable at all, but it is
hardly realistic to propose such an extreme action as a prerequisite of
something that is purported to be "shorter and faster".
If it pops up in the future, why not generalize it
at that point if necessary?
Isn't the cost of ongoing maintenance to be considered? Haven't there
been enough examples of browser sniffing needing to be modified at each
release of a new browser, and of positively silly outcomes following
from author's falling to keep up with developments in browsers? How can
it ever make sense to be telling someone using the last version of a web
browser that they need to be upgrading to a newer version?

One of the greatest practical advantages of feature detection tests is
that if you get the test right it keeps on being the right test
regardless if whether the issue being tested for is fixed, crops up
somewhere else, or is accidentally re-introduced.

Richard.

Aug 27 '07 #33
Jeff North wrote:
On Mon, 27 Aug 2007 15:06:28 +0200, in comp.lang.javascript Thomas
'PointedEars' Lahn <Po*********@web.de>
<46**************@PointedEars.dewrote:
There is no need to replicate this much header information in the message
body. The attribution should be short so that it fulfills its purpose as
to indicate merely who wrote what of the quoted text.
>| Jeff North wrote:
| [...] "dh**********@gmail.com" [...] wrote:
| >| Can you use Yahoo event system with jQuery Ajax transport with a Dojo
| >| widget?
| >
| http://docs.jquery.com/Using_jQuery_...ther_Libraries
| The jQuery library, and virtually all of its plugins are constrained
| within the jQuery namespace. As a general rule, "global" objects are
| stored inside the jQuery namespace as well, so you shouldn't get a
| clash between jQuery and any other library (like Prototype, MooTools,
| or YUI).
|
| However, that is completely ignoring the fact that ECMAScript 3
| implementations have no concept of a namespace, and that any
| user-defined object or property may be overwritten at any time.

I think that you are completely ignoring the fact that the people at
jQuery weren't using namespace in the context of the ECMAScript (non)
definition.
You are missing the point. The concept of a namespace implies that
something defined in that namespace cannot be overwritten by other
pieces of code because of that namespace. Using an object as a
pseudo-namespace certainly can help to avoid conflicts when using
different libraries, but anything more is just a wild guess that
can not be backed up by features of the used programming language.
>| Please trim your quotes.

...and get abused for misquoting or trimming too much?
Abused? Not by me, or only by trolls, if you use common sense.

http://www.jibbering.com/faq/faq_notes/clj_posts.html
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>
Aug 27 '07 #34
On Aug 27, 1:44 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
Aren't we a few posts down stream of code showing a browser sniffing
based test that is more complex than it could have been precisely
because of the browser sniffing
It appears so, but I think we're now discussing the broader issue, not
that specific case.
It also would not be much of an argument in the face of examples of
browser sniffing code that includes and executes 500+ lines just for the
browser sniffing, and regardless of whether or not the results are ever
used.
True, such code exists, but it's also not relevant to jQuery.
Still, to date you are the only person who has mentions this "common
argument" to me. Obviously I must be not taking part in enough browser
sniffing and feature testing related debates.
A few url's:
http://ejohn.org/blog/future-proofin...ipt-libraries/
http://andrewdupont.net/2007/04/04/browser-sniffing/
http://dev.opera.com/articles/view/u...ity-detection/
even though the problem is known to only exist
in a single browser or a single environment.
How would it be "known" that the problem only existed on a single
browser? Logically haven't you got to positively verify that the problem
does not exist on _every_ other browser in existence before you can know
that?
Perhaps if you are seeking logical perfection, yes. Practically,
perfection isn't required. Of all the browsers you claim exist, I'll
bet that I haven't seen hardly any of them visit the sites I care
about. Devoting effort and thought to a fringe user who might someday
visit my site with a browser I don't know about is not something I
really care that much about.
Without that knowledge you are in the area of surmise and assumptions.
Which may be a fine area to be in.
You don't write browser sniffing code because it is imposable to write
such code so that it will accurately identify browsers or their
versions.
And yet the code that exists seems to work just fine for every single
user I've ever cared about, without exception. Believe me, I
understand your theoretical/logical argument. If you're seeking
perfect logical consistency similar to a mathematical proof, you are
absolutely correct in your arguments. But sometimes "good enough"
really _is_ "good enough". Why kill yourself trying to create an
exhaustive and bullet-proof detection algorithm that may not even be
possible? You could instead solve the case for every known user and
every probable future user of your site with some simple code, and
leave open the possibility that a rare case may exist in the future
that may make you want to reconsider your code. Or download the latest
version of your library and find that 20 others have already
investigated the problem and fixed it for you.
Remember that browser sniffing
is predicated on treating something that is not supposed to be treated
as a source of information is if it was a source of information.
Again, perhaps technically true. But in reality, it is a source of
information. And it's correct for almost every single user with the
exception of some people who purposely try to provide inaccurate
information. Personally, I don't care about those people. That's not
perfect, but it sure is practical.
why worry about a situation that
can be demonstrated as not existing?
How were you planning on "demonstrating" that no unknown or unrecognised
browser has the issue in question?
You can't prove it conclusively. But, for example, I often code for
apps that support only IE or maybe IE/FF. I can demonstrate well that
there are no known issues outside of my supported browser environment.
And for my case, browser detection (when required) works flawlessly,
without exception.
One of the greatest practical advantages of feature detection tests is
that if you get the test right it keeps on being the right test
regardless if whether the issue being tested for is fixed, crops up
somewhere else, or is accidentally re-introduced.
I agree. And where practical, that approach is always preferred.

Matt Kruse

Aug 27 '07 #35
Matt Kruse wrote:
On Aug 27, 9:38 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>>Needless to say, your opinion is in the minority, even among experts.
Are we back to ad hominem again? You cannot even prove that, no matter your
definition of "experts".

It's an obvious conclusion, IMO, if you just spend time reading the
web and following the advances in the javascript world.
You have allowed your reasoning to be influenced, if not controlled, by
emotion, so statements like the above have to appear to you as an obvious
conclusion. As long as you continue like this, you do not deserve to be
taken seriously anymore.
>But the library itself defines it, and it defines and uses more properties
that begin with `$'.

Only as an alias for jQuery. [...]
No, there is a $this variable, and an $events and a $handle property. It
turns out that I have reviewed the source; obviously you have not. (What
would your "experts" say about people who state facts about something
and are defending it even if they do not even know about it to make such
statements? Don't answer.)
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Aug 27 '07 #36
On Aug 27, 3:36 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
You have allowed your reasoning to be influenced, if not controlled, by
emotion, so statements like the above have to appear to you as an obvious
conclusion. As long as you continue like this, you do not deserve to be
taken seriously anymore.
Did you take me seriously to begin with? Do I care? :)
But the library itself defines it, and it defines and uses more properties
that begin with `$'.
Only as an alias for jQuery. [...]
No, there is a $this variable, and an $events and a $handle property. It
turns out that I have reviewed the source; obviously you have not.
Actually, I just misunderstood what you meant.

Matt Kruse

Aug 27 '07 #37
Well you might also let the people at Yahoo, Google et al know this
because they use the same terminology.
>| >| Please trim your quotes.
Post trimmed - happy now?
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------
Aug 28 '07 #38

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: TG | last post by:
I have a problem trying to get a value from textbox 1 and textbox 2. If those two values match the data in the database then it has to return a third corresponding value to a third textbox (or...
3
by: johkar | last post by:
I need to document.write out a select list populated with the dates for the first and third Wednesday of each month. How do I get to the actual days? <select name="mySelect"> <option value="Oct...
4
by: Michael Hill | last post by:
I am having a problem formatting the third column. It should be 70px wide, but it is extending well beyond 70. The 2nd and 3rd column should be the same width. The content of the 3rd column...
12
by: Jan Roland Eriksson | last post by:
I have worked some more on this suggested new mFAQ version trying to get all user input to blend into the text. Another review by the NG would be welcome. ===== Archive-name:...
6
by: thesushant | last post by:
hi, whats the use of third argument to main( ), i.e. environmental parameters.... if i am not wrong ? 1st 1 is argc 2nd is argv and what bout the 3rd 1??????????? sushant
4
by: dmeiser | last post by:
Hello all: I need to query a table for events that happen on third shift ( 11 PM to 7 AM ) in a date range. In the past, I've only needed to query for one night, but I now need to query for 14...
0
by: Jason | last post by:
I've got a PC that is on the same intranet as I am, and I'm local admin on both machines. The second machine has a second nic in it and it is attached to a third pc that is not on the intranet,...
4
by: not_a_commie | last post by:
I have a tight time constraint on a small chunk of processing. It takes about a third of a second to run. Occasionally, this function will get stalled for (what I can only guess) is a garbage...
2
by: manishamca | last post by:
can anyone say me how to find the difference of values present in two textbox and display the result in the third textbox. for eg: <input type=text name=t1 value=123> <input...
1
maxx233
by: maxx233 | last post by:
I need to look at/average some data from every third tuesday of each month during a specific time of day, over the course of the last 2 years. Can anyone think of ways, or recommend something to...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.