Recommendations for JavaScript drop-down menu code
Brian Adkins
drop-down, hierarchical menus. Are there high quality libraries for
this, or is it more typical for people to roll their own?
My preference is for open source code, but royalty-free commercial
code would be acceptable as well.
Ideally, the code would:
* Allow configuring horizontal or vertical menus
* Allow configuring the delay for closing the menu after mousing out
of the menu
* Provide a mechanism for playing well with existing code and other
libraries
* Be well designed & documented
* Be highly portable among browsers in common use
* Allow styling via css
Thanks,
Brian Adkins
David Mark
> I would appreciate recommendations for JavaScript code that implements
> drop-down, hierarchical menus. Are there high quality libraries for
> this, or is it more typical for people to roll their own?
I don't know if there are any good ones out there, but there are lots
of bad ones.
>
> My preference is for open source code, but royalty-free commercial
> code would be acceptable as well.
>
> Ideally, the code would:
> * Allow configuring horizontal or vertical menus
That is a function of CSS, not script.
> * Allow configuring the delay for closing the menu after mousing out
> of the menu
That doesn't make sense to me for a hierarchical menu.
> * Provide a mechanism for playing well with existing code and other
> libraries
> * Be well designed & documented
> * Be highly portable among browsers in common use
Your expectations of freebie menu scripts are likely too high.
> * Allow styling via css
You'd be hard-pressed to disallow CSS with script.
Anyway, craate your hierarchy with nested lists, style it with CSS and
then look for a script that initially hides all but the parent list
and then displays child lists in response to mouse or keyboard input
(you'll find that most ignore the keyboard.)
Brian Adkins
> On Sep 27, 12:04 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > My preference is for open source code, but royalty-free commercial
> > code would be acceptable as well.
>
> > Ideally, the code would:
> > * Allow configuring horizontal or vertical menus
>
> That is a function of CSS, not script.
There are a number of ways of accomplishing this. CSS is one way, but
the JavaScript code can make CSS styling less difficult or more
difficult.
> > * Allow configuring the delay for closing the menu after mousing out
> > of the menu
>
> That doesn't make sense to me for a hierarchical menu.
It makes even more sense for a hierarchical menu. Consider navigating
through a complicated menu structure via hovering, then right before
you click the appropriate entry, you accidentally move the mouse too
far and the whole menu closes. That's the scenario (typically found on
CSS-only menus) I want to avoid, so I'd like a "grace period" if you
will.
> > * Provide a mechanism for playing well with existing code and other
> > libraries
> > * Be well designed & documented
> > * Be highly portable among browsers in common use
>
> Your expectations of freebie menu scripts are likely too high.
If so, then a commercial solution would seem to make sense. Do you
know of good commercial menus?
> > * Allow styling via css
>
> You'd be hard-pressed to disallow CSS with script.
>
> Anyway, craate your hierarchy with nested lists, style it with CSS and
> then look for a script that initially hides all but the parent list
> and then displays child lists in response to mouse or keyboard input
> (you'll find that most ignore the keyboard.)
If I was only looking for that, I'd just write it myself, but I'm not
big on reinventing wheels.
David Mark
> On Sep 27, 12:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Sep 27, 12:04 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > My preference is for open source code, but royalty-free commercial
> > > code would be acceptable as well.
>
> > > Ideally, the code would:
> > > * Allow configuring horizontal or vertical menus
>
> > That is a function of CSS, not script.
>
> There are a number of ways of accomplishing this. CSS is one way, but
> the JavaScript code can make CSS styling less difficult or more
> difficult.
How so? Your app must not break down when either or both is disabled.
>
> > > * Allow configuring the delay for closing the menu after mousing out
> > > of the menu
>
> > That doesn't make sense to me for a hierarchical menu.
>
> It makes even more sense for a hierarchical menu. Consider navigating
> through a complicated menu structure via hovering, then right before
> you click the appropriate entry, you accidentally move the mouse too
> far and the whole menu closes. That's the scenario (typically found on
> CSS-only menus) I want to avoid, so I'd like a "grace period" if you
> will.
I didn't mean the delay made no sense, but the usual rollover-only
functionality of canned menu scripts.
>
> > > * Provide a mechanism for playing well with existing code and other
> > > libraries
> > > * Be well designed & documented
> > > * Be highly portable among browsers in common use
>
> > Your expectations of freebie menu scripts are likely too high.
>
> If so, then a commercial solution would seem to make sense. Do you
> know of good commercial menus?
>
> > > * Allow styling via css
>
> > You'd be hard-pressed to disallow CSS with script.
>
> > Anyway, craate your hierarchy with nested lists, style it with CSS and
> > then look for a script that initially hides all but the parent list
> > and then displays child lists in response to mouse or keyboard input
> > (you'll find that most ignore the keyboard.)
>
> If I was only looking for that, I'd just write it myself, but I'm not
> big on reinventing wheels.
If you aren't looking for what I described, then what are you looking
for?
Brian Adkins
> On Sep 28, 1:49 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > On Sep 27, 12:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > On Sep 27, 12:04 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > Ideally, the code would:
> > > > * Allow configuring horizontal or vertical menus
>
> > > That is a function of CSS, not script.
>
> > There are a number of ways of accomplishing this. CSS is one way, but
> > the JavaScript code can make CSS styling less difficult or more
> > difficult.
>
> How so? Your app must not break down when either or both is disabled.
"Must not" ? I'm surprised you think you know enough about the
requirements for my application to be able to make this statement. The
title of this post has to do with recommending JavaScript menus. If
you're not going to make a recommendation, please don't also make such
ridiculous statements. Combining arrogance and ignorance is
inadvisable.
Before you reply with some ridiculous retort, please identify at least
3 major web applications that would practically fall apart if users
disabled both JavaScript & CSS and reconcile that with your statement
above.
>
> > > > * Allow configuring the delay for closing the menu after mousing out
> > > > of the menu
>
> > > That doesn't make sense to me for a hierarchical menu.
>
> > It makes even more sense for a hierarchical menu. Consider navigating
> > through a complicated menu structure via hovering, then right before
> > you click the appropriate entry, you accidentally move the mouse too
> > far and the whole menu closes. That's the scenario (typically found on
> > CSS-only menus) I want to avoid, so I'd like a "grace period" if you
> > will.
>
> I didn't mean the delay made no sense, but the usual rollover-only
> functionality of canned menu scripts.
I can see you have many opinions. It's a pity none of them have to do
with the original request.
David Mark
> On Sep 28, 1:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Sep 28, 1:49 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > On Sep 27, 12:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > On Sep 27, 12:04 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > > Ideally, the code would:
> > > > > * Allow configuring horizontal or vertical menus
>
> > > > That is a function of CSS, not script.
>
> > > There are a number of ways of accomplishing this. CSS is one way, but
> > > the JavaScript code can make CSS styling less difficult or more
> > > difficult.
>
> > How so? Your app must not break down when either or both is disabled.
>
> "Must not" ? I'm surprised you think you know enough about the
> requirements for my application to be able to make this statement. The
It has nothing to do with the requirements of your application.
That's a general rule for any competent Web page or application.
> title of this post has to do with recommending JavaScript menus. If
> you're not going to make a recommendation, please don't also make such
> ridiculous statements. Combining arrogance and ignorance is
> inadvisable.
The specific response was to your assertion that JS and CSS are
somehow intertwined. It should be intuitively obvious that if you
disable one but not the other, then any reliance on JS to prop up CSS
will be exposed. It is inadvisable to argue a point that you clearly
don't understand.
>
> Before you reply with some ridiculous retort, please identify at least
> 3 major web applications that would practically fall apart if users
> disabled both JavaScript & CSS and reconcile that with your statement
> above.
As I suspected, you didn't get the point at all. Regardless, most Web
applications (and many simple Web pages) fall apart when both JS and
CSS are disabled. Name three "major Web applications" that don't.
>
>
>
> > > > > * Allow configuring the delay for closing the menu after mousing out
> > > > > of the menu
>
> > > > That doesn't make sense to me for a hierarchical menu.
>
> > > It makes even more sense for a hierarchical menu. Consider navigating
> > > through a complicated menu structure via hovering, then right before
> > > you click the appropriate entry, you accidentally move the mouse too
> > > far and the whole menu closes. That's the scenario (typically found on
> > > CSS-only menus) I want to avoid, so I'd like a "grace period" if you
> > > will.
>
> > I didn't mean the delay made no sense, but the usual rollover-only
> > functionality of canned menu scripts.
>
> I can see you have many opinions. It's a pity none of them have to do
> with the original request.
The original request matters little at this point. As I mentioned a
few posts back, I have no recommendation for you, other than a few
general rules to follow when evaluating canned menu scripts.
Thomas 'PointedEars' Lahn
> I would appreciate recommendations for JavaScript code that implements
> drop-down, hierarchical menus. Are there high quality libraries for
> this, or is it more typical for people to roll their own?
Let JScript(!) code add to the functionality of CSS where required. Don't
attempt to replace HTML and the latter by a client-side script that
generates the content; the result would be inevitably inaccessible.
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>
Peter Michaux
> On Sep 28, 2:12 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
>
>
> > On Sep 28, 1:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Sep 28, 1:49 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > On Sep 27, 12:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > > On Sep 27, 12:04 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > > > Ideally, the code would:
> > > > > > * Allow configuring horizontal or vertical menus
>
> > > > > That is a function of CSS, not script.
>
> > > > There are a number of ways of accomplishing this. CSS is one way, but
> > > > the JavaScript code can make CSS styling less difficult or more
> > > > difficult.
>
> > > How so? Your app must not break down when either or both is disabled.
>
> > "Must not" ? I'm surprised you think you know enough about the
> > requirements for my application to be able to make this statement. The
>
> It has nothing to do with the requirements of your application.
> That's a general rule for any competent Web page or application.
It does have to do with the specific requirements. Not all web pages
are for general web consumption. Some are for back-end pages where the
user logs in and is known to have a certain set of prerequisite
capabilities. In these cases, spending the extra time to make the page
degrade gracefully or otherwise may not be considered a wise use of
development dollars.
Another option is a gateway page that branches to two versions of the
application. This is like GMail. One branch is for JavaScript enabled
(and sufficiently capable JavaScript) and the other branch is for
anyone not capable of the "full" version. So in this case the fancy
drop down menus would not have to degrade either.
Peter
Brian Adkins
Yahoo! UI Library: Menu
http://developer.yahoo.com/yui/menu/
Son of Suckerfish - Nice, but menu collapses unforgivingly
http://www.htmldog.com/articles/suckerfish/dropdowns/
FreeStyle Menu - Angus Turnbull
http://www.twinhelix.com/dhtml/fsmenu/demo/
jdMenu plugin for JQuery
http://jdsharp.us/jQuery/plugins/jdMenu/
I also forgot to list one requirement. I'm using XHTML 1.0 Strict, so
the menu would need to be compatible with that.
At this point, I'm leaning toward starting with Son of Suckerfish and
adding JavaScript to make the collapsing more forgiving. It seems like
the simplest and I like the idea of building something onto a simple
foundation versus trying to understand someone else's monstrosity.
I would be curious about experiences with Yahoo's menu or other
libraries with significant developer acceptance.
Randy Webb
<snip>
> I also forgot to list one requirement. I'm using XHTML 1.0 Strict, so
> the menu would need to be compatible with that.
Why are you using something that isn't understood by 90% of the web and
would end up being processed as soup tag HTML and thus a true XHTML
script wouldn't work with it?
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Brian Adkins
> Brian Adkins said the following on 9/29/2007 12:51 PM:
> > the menu would need to be compatible with that.
>
> Why are you using something that isn't understood by 90% of the web and
> would end up being processed as soup tag HTML and thus a true XHTML
> script wouldn't work with it?
I wasn't aware that "90% of the web" doesn't understand it. Can you
provide documentation for that statistic? I have to admit being
skeptical since my testing has uncovered no issues and there are a
number of major sites using the same doctype, but I'd like to keep an
open mind.
I'm not familiar with the phrase "soup tag HTML", but it doesn't sound
good. Which browsers process XHTML as "soup tag HTML" ? I also don't
know what you mean by a "true XHTML script" - is this different than a
regular old JavaScript script? Are you saying that many browsers will
populate the DOM differently from XHTML input than from HTML? If you
can provide examples of input that validates against XHTML 1.0 Strict
that turns into "soup tag HTML" and thus won't work with a valid
JavaScript program I would appreciate it.
Just out of curiosity, which doctype do you prefer?
Brian Adkins
Just in case we're talking about two different things, here's the
doctype & other stuff I'm using:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
...
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" />
...
Thomas 'PointedEars' Lahn
> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> Brian Adkins said the following on 9/29/2007 12:51 PM:
>>> I also forgot to list one requirement. I'm using XHTML 1.0 Strict, so
>>> the menu would need to be compatible with that.
>> Why are you using something that isn't understood by 90% of the web and
>> would end up being processed as soup tag HTML and thus a true XHTML
>> script wouldn't work with it?
>
> I wasn't aware that "90% of the web" doesn't understand it. Can you
> provide documentation for that statistic?
He is referring to Microsoft Internet Explorer not using a built-in XML
parser for XHTML by default, and not supporting the proper media type for
XHTML, application/xhtml+xml, to date (version 7.0). Whether or not it
still has a 90% market share or not (142% of all Web statistics are flawed)
is irrelevant; it is a sad fact that its flawed layout engine (Trident) is
still the most used one, and that the advantages XHTML undoubtedly has over
HTML must still be carefully weighted against the disadvantage of the
former's being not widely supported.
http://en.wikipedia.org/wiki/Internet_Explorer
http://en.wikipedia.org/wiki/Internet_Explorer#Standards_support
PointedEars
Thomas 'PointedEars' Lahn
> On Sep 29, 4:34 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>> Brian Adkins said the following on 9/29/2007 12:51 PM:
>> I'm not familiar with the phrase "soup tag HTML", but it doesn't sound
>> good. Which browsers process XHTML as "soup tag HTML" ?
The correct term is "tag soup HTML" which is the way most (if not all)
parsers in browsers work. If they do no support a HTML feature or encounter
not Valid code, they do error correction. That is a behavior not allowed
for XML documents such as XHTML documents; they have to be well-formed (they
need not to be Valid, although due to the definition of validating parsers
that is strongly recommended).
http://www.hixie.ch/advocacy/xhtml
http://hsivonen.iki.fi/xhtml-the-point/
>> I also don't know what you mean by a "true XHTML script" - is this
>> different than a regular old JavaScript script?
Did you even know that there is no such thing as a "regular old JavaScript
script" as every different UA uses a different script engine and DOM?
>> Are you saying that many browsers will populate the DOM differently from
>> XHTML input than from HTML?
Yes, they do. Although that is not supported by Web standards. For
example, document.write() doesn't work (i.e. throws an exception) in the
XHTML Gecko DOM with the excuse of its being capable of creating not
well-formed markup.
http://www.w3.org/TR/DOM-Level-2-HTML/
>> If you can provide examples of input that validates against XHTML 1.0 Strict
>> that turns into "soup tag HTML" and thus won't work with a valid
>> JavaScript program I would appreciate it.
YMMD.
>> Just out of curiosity, which doctype do you prefer?
HTML 4.01 Strict, unless XHTML is absolutely required. If the latter, XHTML
1.0 Strict or XHTML 1.1.
> Just in case we're talking about two different things, here's the
> doctype & other stuff I'm using:
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
> <head>
> ...
> <meta http-equiv="Content-Type" content="text/html;
> charset=utf-8" />
This is strongly recommended against if you serve it as text/html:
http://www.w3.org/TR/xhtml-media-types/#summary
And, in fact, if the XHTML was parsed by an XML parser as it should be, that
declaration would be far too late. An XML document has to be well-formed
*before* parsing starts. That is facilitated by declaring the encoding in
the HTTP header or in an XML processing instruction before the root element
of the document (PI):
<?xml version="1.0" encoding="ISO-8859-1"?>
As for scripting, there are more things to care about when using XHTML.
http://www.w3.org/TR/xhtml1/#diffs
Brian Adkins
wrote:
> Brian Adkins wrote:
> > On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> Brian Adkins said the following on 9/29/2007 12:51 PM:
> >>> I also forgot to list one requirement. I'm using XHTML 1.0 Strict, so
> >>> the menu would need to be compatible with that.
> >> Why are you using something that isn't understood by 90% of the web and
> >> would end up being processed as soup tag HTML and thus a true XHTML
> >> script wouldn't work with it?
>
> > I wasn't aware that "90% of the web" doesn't understand it. Can you
> > provide documentation for that statistic?
>
> He is referring to Microsoft Internet Explorer not using a built-in XML
> parser for XHTML by default, and not supporting the proper media type for
I see. I'm not serving it as 'application/xhtml+xml', and haven't had
any issues with IE so far. I guess the 'text/html' vs. 'application/
xhtml+xml' accounts for the discrepancy between "90% of the web
doesn't understand it" and what I'm seeing.
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Brian Adkins wrote:
>>> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>> Brian Adkins said the following on 9/29/2007 12:51 PM:
>>>>> I also forgot to list one requirement. I'm using XHTML 1.0 Strict, so
>>>>> the menu would need to be compatible with that.
>>>> Why are you using something that isn't understood by 90% of the web and
>>>> would end up being processed as soup tag HTML and thus a true XHTML
>>>> script wouldn't work with it?
>>> I wasn't aware that "90% of the web" doesn't understand it. Can you
>>> provide documentation for that statistic?
>> He is referring to Microsoft Internet Explorer not using a built-in XML
>> parser for XHTML by default, and not supporting the proper media type for
>> XHTML, application/xhtml+xml, ...
>
> I see. I'm not serving it as 'application/xhtml+xml',
But as what?
> and haven't had any issues with IE so far. I guess the 'text/html' vs.
> 'application/xhtml+xml' accounts for the discrepancy between "90% of
> the web doesn't understand it" and what I'm seeing.
It merely accounts for the possibility of your not understanding
what you are doing, see <46FEBFAE...@PointedEars.de>.
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, <f806at$ail$1$8300...@news.demon.co.uk>
Peter Michaux
See
http://www.thewebcreator.net/2007/04/16/why-you-should-be-using-html-401-instead-of-xhtml/
http://www.webdevout.net/articles/beware-of-xhtml
> Just out of curiosity, which doctype do you prefer?
HTML Transitional is the most useful to me because of iframe hacks
(hidden file upload, iframe shim for IE select element hiding).
Peter
Brian Adkins
wrote:
> Brian Adkins wrote:
> > On Sep 29, 4:34 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> >> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >>> Brian Adkins said the following on 9/29/2007 12:51 PM:
> >> [...]
> >> I'm not familiar with the phrase "soup tag HTML", but it doesn't sound
> >> good. Which browsers process XHTML as "soup tag HTML" ?
>
> The correct term is "tag soup HTML" which is the way most (if not all)
> parsers in browsers work. If they do no support a HTML feature or encounter
> not Valid code, they do error correction. That is a behavior not allowed
> for XML documents such as XHTML documents; they have to be well-formed (they
> need not to be Valid, although due to the definition of validating parsers
> that is strongly recommended).
>
> http://www.hixie.ch/advocacy/xhtml
Interesting information. I do validate my pages, and I'm not planning
on sending as 'application/xhtml+xml' anytime soon, but it certainly
may be that I assumed there were advantages to XHMTL 1.0 Strict after
reading various information sources (i.e. jumped on a bandwagon). Some
of the proposed benefits of XHTML I've heard are:
* future proofing web pages
* allowing aural screen readers to more easily consume it
* it's becoming the language of choice for mobile devices
* existing data is more easily transformed into XHTML than HTML
* there's not going to be an HTML 5, the new standard is XHTML 1.0
* <br> seems wrong compared to <br />
* etc.
For what it's worth, here are the doctypes of 49 sites that I checked
in mid July:
http://lojic.com/blog/2007/07/12/which-doctypes-are-being-used/
Summary is: none = 10, html = 20, xhtml = 19 (only 1 using XHTML 1.1)
You've given me some things to think about. If anyone is aware of
advantages of XHTML 1.1 Strict over HTML 4.01 Strict, feel free to
chime in.
Brian Adkins
wrote:
> Brian Adkins wrote:
> > [...] Thomas 'PointedEars' Lahn [...] wrote:
> >> Brian Adkins wrote:
> >>> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >>>> Brian Adkins said the following on 9/29/2007 12:51 PM:
> >>>>> I also forgot to list one requirement. I'm using XHTML 1.0 Strict, so
> >>>>> the menu would need to be compatible with that.
> >>>> Why are you using something that isn't understood by 90% of the web and
> >>>> would end up being processed as soup tag HTML and thus a true XHTML
> >>>> script wouldn't work with it?
> >>> I wasn't aware that "90% of the web" doesn't understand it. Can you
> >>> provide documentation for that statistic?
> >> He is referring to Microsoft Internet Explorer not using a built-in XML
> >> parser for XHTML by default, and not supporting the proper media type for
> >> XHTML, application/xhtml+xml, ...
>
> > I see. I'm not serving it as 'application/xhtml+xml',
>
> But as what?
>
> > and haven't had any issues with IE so far. I guess the 'text/html' vs.
> > 'application/xhtml+xml' accounts for the discrepancy between "90% of
> > the web doesn't understand it" and what I'm seeing.
>
> It merely accounts for the possibility of your not understanding
You could be right. I should probably hear your perspective on the
discrepancy between someone's statement that XHTML 1.0 Strict won't
work on "90% of the web", and the fact that I haven't uncovered any
problems (except for losing the target attribute on <a>) on 5 browsers
running on 3 operating systems covering well over 90% market share.
I've heard someone say that the difference between theory and practice
is much greater in practice than in theory ;)
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Brian Adkins wrote:
>>> On Sep 29, 4:34 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>>>> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>>>>> Brian Adkins said the following on 9/29/2007 12:51 PM:
>>>> [...]
>>>> I'm not familiar with the phrase "soup tag HTML", but it doesn't sound
>>>> good. Which browsers process XHTML as "soup tag HTML" ?
>> The correct term is "tag soup HTML" which is the way most (if not all)
>> parsers in browsers work. If they do no support a HTML feature or encounter
>> not Valid code, they do error correction. That is a behavior not allowed
>> for XML documents such as XHTML documents; they have to be well-formed (they
>> need not to be Valid, although due to the definition of validating parsers
>> that is strongly recommended).
>>
>> http://www.hixie.ch/advocacy/xhtml
>
> Interesting information. I do validate my pages, and I'm not planning
> on sending as 'application/xhtml+xml' anytime soon,
Why not if the UA supports it? Gecko-based UAs do, and they use an XML
parser then.
> but it certainly may be that I assumed there were advantages to XHMTL 1.0 Strict
> after reading various information sources (i.e. jumped on a bandwagon). Some
> of the proposed benefits of XHTML I've heard are:
>
> * future proofing web pages
HTML support is not going to disappear. Whether or not XHTML will
evolve into a viable alternative for HTML remains to be seen.
> * allowing aural screen readers to more easily consume it
NAK. Please explain why you think that would be so.
> * it's becoming the language of choice for mobile devices
Because of the short-lived WAP hype using WML?
> * existing data is more easily transformed into XHTML than HTML
Again, an explanation would be appreciated.
> * there's not going to be an HTML 5, the new standard is XHTML 1.0
The WHATWG is developing its HTML 5 now. While I debate that proprietary
approach, it remains to be seen whether or not it will be used more than
XHTML 1.0.
http://www.whatwg.org/specs/web-apps/current-work/
> * <br> seems wrong compared to <br />
On what grounds?
> * etc.
>
> For what it's worth, here are the doctypes of 49 sites that I checked
> in mid July:
>
> http://lojic.com/blog/2007/07/12/which-doctypes-are-being-used/
>
> Summary is: none = 10, html = 20, xhtml = 19 (only 1 using XHTML 1.1)
And probably most of the sites that use XHTML them serve it inefficient and
error-prone as text/html without a real need for XHTML in the first place.
Yuck.
> You've given me some things to think about. If anyone is aware of
> advantages of XHTML 1.1 Strict over HTML 4.01 Strict, feel free to
> chime in.
But please do that only where it is on-topic.
F'up2 comp.infosystems.www.authoring.html
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
David Mark
> On Sep 28, 11:40 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 28, 2:12 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > > On Sep 28, 1:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Sep 28, 1:49 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > > On Sep 27, 12:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > > > On Sep 27, 12:04 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > > > > Ideally, the code would:
> > > > > > > * Allow configuring horizontal or vertical menus
>
> > > > > > That is a function of CSS, not script.
>
> > > > > There are a number of ways of accomplishing this. CSS is one way, but
> > > > > the JavaScript code can make CSS styling less difficult or more
> > > > > difficult.
>
> > > > How so? Your app must not break down when either or both is disabled.
>
> > > "Must not" ? I'm surprised you think you know enough about the
> > > requirements for my application to be able to make this statement. The
>
> > It has nothing to do with the requirements of your application.
> > That's a general rule for any competent Web page or application.
>
> It does have to do with the specific requirements. Not all web pages
> are for general web consumption. Some are for back-end pages where the
> user logs in and is known to have a certain set of prerequisite
> capabilities. In these cases, spending the extra time to make the page
> degrade gracefully or otherwise may not be considered a wise use of
> development dollars.
Correct, but popup menus are simple enough that you would just do them
right in the first place.
>
> Another option is a gateway page that branches to two versions of the
> application. This is like GMail. One branch is for JavaScript enabled
Please don't use Google as an example. Google throws JS errors at me
constantly. But I get the idea. I don't like it, but I get it.
> (and sufficiently capable JavaScript) and the other branch is for
> anyone not capable of the "full" version. So in this case the fancy
> drop down menus would not have to degrade either.
Fancy dropdown menus? Granted they aren't really necessary for most
Web pages/applications, but they are fairly trivial widgets, which is
one reason they are so prevalent.
Hierarchies of menus would seem an unwieldy choice for site
navigation, but it is apparently the preferred UI for most Web
developers. Unfortunately, most implementations have lousy usability
and/or accessibility. It's as if the developers had never used menus
in software applications. Of course, if they were paying attention to
their desktops, they would have noticed that navigation is done with a
tree, not a series of cascading menus.
Here is an example of how I think menus should work. The code is a
little slapdash, but in my brief testing it functioned flawlessly.
The default behavior does not popup top-level menus on rollovers (I
hate that), but there is a global option to change this. And they
don't vanish just because you move the mouse away (click to hide all
active menus.) And yes, there is a configurable delay for hiding sub-
menus when it makes sense to hide them. As for accessibility,
keyboard users will have no problem and I think most screen readers/
aural browsers will work as well. I tested in IE7, the latest Mozilla
and Netscape, Opera 9 and Windows Safari beta. IE7 in quirks mode had
a weird issue with adding space between listitems when sub-menus open,
but I haven't investigated that (you shouldn't use quirks mode
anyway.) It should be okay in IE6 in standards mode.
The example has three menus with identical content: one styled as a
horizontal menubar, one vertical and the other as a popup menu. The
orientations are determined solely by CSS. The instantiation of the
popup menu and positioning of child popups are functions of the
script.
Use something like this and you won't need a branch page as the menus
degrade gracefully without script as well as without script and
style. As usual, the hardest case to get perfect is where script is
enabled but style is not. The specific examples I used are admittedly
lousy in this case as only the leaf nodes navigate, despite the fact
that all nodes have perfectly good href's. So if you must use
cascading menus for navigation (as opposed to commands), it is a good
idea to relegate links to leaf nodes.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/
TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Menus</title>
<style type="text/css" media="all">
ul.menubar { list-style-type:none;padding:0;margin:0 }
ul.menubar a, ul.menuPopup a { padding: 0 .25em 0 .25em }
ul.menubar li { margin:0;padding:0;display:inline}
ul.menubar li a:link, ul.menubar li a:visited { text-decoration:none }
ul.menubar li a:hover { background-color:#0000DD;color:white }
ul.menuPopup { list-style-type:none;padding:0;margin:0;border:outset
2px;background-color:threedface;color:windowtext;z-index:1 }
ul.menuPopup li { white-space:nowrap;display:block }
ul.menuPopup li a:link, ul.menuPopup li a:visited { text-
decoration:none;display:block }
ul.menuPopup li a:hover { background-
color:#0000DD;color:white;display:block }
ul.menuPopup li a.popup:after { content: "\0020\00BB"; }
#myMenubarVertical.menubar { width:5em;margin-bottom:1em }
#myMenubarVertical.menubar li, #myMenubarVertical.menubar li a
{ display:block }
#testPopupMenu { display:block; margin-top:1em }
body {font-family:sans-serif;background-color:threedface}
</style>
<!--[if IE]>
<style type="text/css" media="all">
ul.menubar { display:inline-block } /* Adds layout to fix IE relative
positioning bug
</style>
<![endif]-->
<style type="text/css" media="handheld">
body { margin:4px }
</style>
<style type="text/css" media="print">
body {font-family:serif}
ul.menubar, ul.menuPopup { list-style-type:disc;padding:0 0 0 1em }
ul.menuPopup { border:none;background-
color:white;color:black;position:static !important;display:block !
important }
ul.menuPopup li a {color:black;background-color:inherit}
ul.menuPopup li a.popup:after { content: ""; }
#testPopupMenu { display:none }
</style>
<script type="text/javascript">
var global = this;
if (this.document && this.document.getElementsByTagName &&
this.document.getElementById) {
(function() {
var html = global.document.getElementsByTagName('html');
if (html && html[0] && html[0].style &&
typeof(html[0].style.visibility) == 'string')
{ global.document.write('<style type="text/css"
media="all">#myMenubar, #myMenubarVertical, #myPopupMenu,
#testPopupMenu { visibility:hidden }<\/style>'); }
})();
this.onload = function() {
// Global options
var menuPause = 500; // Delay before hiding/showing sub-menu
var startWithRollover = false; // Default requires click to show
initial top-level item (second click hides)
// Set to true to allow rollover to show top-level menus (click
navigates)
var doc = global.document;
var el, elButton;
var activeMenu, timer, hrefTypeUnknown;
function nodeName(el) {
var n = (el.tagName || el.nodeName);
return n && n.toLowerCase();
}
function cancelPropagation(e) {
e = e || global.event;
if (e.stopPropagation) { e.stopPropagation(); }
e.cancelBubble = true;
}
function setStatus(s) {
// Firefox unload/mouseover bug requires typeof check here
if (typeof(global) != 'undefined') { global.setTimeout(function()
{ if (typeof(global) != 'undefined') { global.status = s; } }, 0); }
return true;
}
function menuRoot(list) {
var root;
if (!list.parentNode || nodeName(list.parentNode) != 'li') { return
null; }
while (list.parentNode) {
list = list.parentNode;
if (list && nodeName(list) == 'ul') { root = list; }
}
return (root._isRootless)?null:root;
}
function isAncestor(listChild, listParent) {
while (listChild.parentNode && listChild.parentNode != document) {
if (listChild.parentNode == listParent) { return true; }
listChild = listChild.parentNode;
}
}
function hideActiveMenu(branch, root) {
if (timer) { global.clearTimeout(timer); timer = null; }
activeMenu.style.display = 'none';
var parentMenuItem = activeMenu.parentNode;
if (parentMenuItem && nodeName(parentMenuItem) == 'li' &&
parentMenuItem.parentNode && parentMenuItem.parentNode != branch &&
parentMenuItem.parentNode != root) {
activeMenu = parentMenuItem.parentNode;
hideActiveMenu(branch, root);
}
activeMenu = branch || null;
}
function showMenu(el, branch, side, pos) {
if (timer) { global.clearTimeout(timer); timer = null; }
var elOffset, elParent, tag, a;
side = side || 'bottom';
elParent = el.parentNode;
el.style.visibility = 'hidden';
el.style.display = 'block';
if (!pos && elParent && nodeName(elParent) == 'li') {
pos = [0, 0];
if (elParent != branch) {
elOffset = elParent;
do {
pos[0] += elOffset.offsetTop || 0;
pos[1] += elOffset.offsetLeft || 0;
if (elParent != elOffset) {
pos[0] += elOffset.clientTop || 0;
pos[1] += elOffset.clientLeft || 0;
}
elOffset = elOffset.offsetParent;
if (elOffset) {
tag = nodeName(elOffset);
if (tag != 'li' && tag != 'ul') { break; }
}
}
while (elOffset && elOffset != branch);
}
if (side == 'right') { pos[1] += elParent.offsetWidth || 0; } else
{ pos[0] += elParent.offsetHeight || 0; }
}
if (pos) {
el.style.top = pos[0] + 'px';
el.style.left = pos[1] + 'px';
}
el.style.visibility = 'visible';
if (activeMenu && !isAncestor(el, activeMenu) && activeMenu != el)
{
var root = menuRoot(activeMenu);
hideActiveMenu((branch == root)?null:branch, root);
}
activeMenu = el;
a = el.getElementsByTagName('a');
if (a[0] && a[0].focus) { a[0].focus(); }
}
function showMenuPopup(el) {
showMenu(el, null);
}
function attachPopupActivator(el, list) {
el.onclick = function(e) { if (list.style.display == 'none')
{ showMenu(list, null); } else { hideActiveMenu(null, null); }
cancelPropagation(e); };
}
function initializeChildMenus(list, root, initialSide) {
initialSide = initialSide || 'bottom';
if (typeof(root) == 'undefined') { root = list; }
var lists, itemFocused;
var anchors = list.getElementsByTagName('a');
var i = 0;
var l = anchors.length;
while (i < l) {
if (anchors[i].parentNode) {
lists = anchors[i].parentNode.getElementsByTagName('ul');
if (lists && lists[0]) {
if (lists[0].style.display != 'none') { // already did this one?
hrefTypeUnknown = typeof(anchors[i].href) == 'unknown';
if (root != list || !startWithRollover || (!hrefTypeUnknown && !
anchors[i].href)) {
if (!hrefTypeUnknown) { anchors[i].href = anchors[i].href ||
'#'; }
anchors[i].onclick = (function(el) { return function(e) { if
(el.style.display == 'none') { showMenu(el, list, (root == list)?
initialSide:'right'); } else { if (root == list)
{ hideActiveMenu((root == list)?null:list, root); } }
cancelPropagation(e); return false; }; })(lists[0]);
}
anchors[i].tabIndex = 0;
initializeChildMenus(lists[0], root);
anchors[i].onmouseover = (function(el) { return function(e)
{ if (this.title) { setStatus(this.title); } if ((!activeMenu && !
startWithRollover) || (activeMenu && isAncestor(activeMenu, el)))
{ return; } if (timer) { global.clearTimeout(timer); } timer =
global.setTimeout(function() { showMenu(el, list, (root == list)?
initialSide:'right'); }, (list == root)?0:menuPause); return
true; }; })(lists[0]);
anchors[i].onmouseout = function() { if (timer)
{ clearTimeout(timer); timer = null; } if (this.title) { return
setStatus(''); } };
anchors[i].className = 'popup';
lists[0].className = 'menuPopup';
lists[0].style.position = 'absolute';
lists[0].style.display = 'none';
}
}
else {
if (anchors[i].parentNode.parentNode &&
anchors[i].parentNode.parentNode.style.display != 'none') { // already
did this one?
anchors[i].onmouseover = function() { if (this.title)
{ setStatus(this.title); } if (timer) { global.clearTimeout(timer);
timer = 0; } if (activeMenu && !isAncestor(this, activeMenu)) { timer
= global.setTimeout(function() { hideActiveMenu((list == root)?
null:list, menuRoot(activeMenu)); }, (list == root)?0:menuPause); }
return true; };
anchors[i].onmouseout = function() { if (this.title) { return
setStatus(''); } };
}
}
i++;
}
}
if (l) {
global.onunload = function() {
i = 0;
l = anchors.length;
while(i < l) {
anchors[i].onclick = anchors[i].onmouseover =
anchors[i].onmouseout = null;
i++;
}
};
}
}
function documentClickHandler(list, root) {
if (typeof(root) == 'undefined') { root = list; }
return function() {
if (activeMenu && (isAncestor(activeMenu, list) || activeMenu ==
list)) { hideActiveMenu(null, root); }
};
}
function attachDocumentClickHandler(list, root) {
var onclickOld = document.onclick;
var onclickNew = documentClickHandler(list, root);
document.onclick = (onclickOld)?function(e) { onclickOld(e);
onclickNew(e); }:onclickNew;
}
function initializeMenu(list, className, initialSide) {
list.className = className || 'menubar';
list.style.position = 'relative';
initializeChildMenus(list, list, initialSide);
attachDocumentClickHandler(list);
}
function initializeMenuPopup(list, className) {
list.className = className || 'menuPopup';
list._isRootless = true;
initializeChildMenus(list, null);
list.style.position = 'absolute';
list.style.display = 'none';
attachDocumentClickHandler(list, null);
}
el = doc.getElementById('myMenubar');
if (el && el.parentNode && el.style && typeof(el.style.display) ==
'string' && typeof(el.style.position) == 'string') {
initializeMenu(el);
el.style.visibility = 'visible';
el = doc.getElementById('myMenubarVertical');
if (el) {
initializeMenu(el, null, 'right');
el.style.visibility = 'visible';
}
el = doc.getElementById('myPopupMenu');
if (el) {
initializeMenuPopup(el);
el.style.visibility = 'visible';
elButton = document.getElementById('testPopupMenu');
if (elButton) {
elButton.disabled = false;
attachPopupActivator(elButton, el);
elButton.style.visibility = 'visible';
}
}
}
};
}
</script>
</head>
<body>
<ul id="myMenubarVertical"><li><a title="Google sites" href="http://
www.google.com">Google</a><ul><li><a href="http://
www.gmail.com">GMail</a><ul><li><a href="http://www.gmail.com">Inbox</
a></li><li><a href="http://www.gmail.com">Outbox</a></li></ul></
li><li><a href="http://www.googlecode.com">Google Code</a><ul><li><a
href="http://code.google.com/apis/ajaxsearch/">Google Ajax Search</a></
li><li><a href="http://www.google.com/apis/maps/">Google Maps</a></
li><li><a href="http://code.google.com/webtoolkit/">Google Web
Toolkit</a></li></ul></li><li><a href="http://www.google.com/
talk">GTalk</a></li></ul></li><li><a href="http://www.msn.com"
title="MSN sites">MSN</a><ul><li><a href="http://www.msnbc.com">News</
a></li><li><a href="http://msn.foxsports.com">Sports</a></li><li><a
href="http://weather.msn.com">Weather</a></li></ul></li><li><a
href="http://www.yahoo.com" title="Yahoo! site">Yahoo!</a><ul><li><a
href="http://www.yahoo.com/r/26">Sports</a></li><li><a href="http://
www.yahoo.com/r/4c">Tech</a></li></ul></li></ul>
<ul id="myMenubar"><li><a title="Google sites" href="http://
www.google.com">Google</a><ul><li><a href="http://
www.gmail.com">GMail</a><ul><li><a href="http://www.gmail.com">Inbox</
a></li><li><a href="http://www.gmail.com">Outbox</a></li></ul></
li><li><a href="http://www.googlecode.com">Google Code</a><ul><li><a
href="http://code.google.com/apis/ajaxsearch/">Google Ajax Search</a></
li><li><a href="http://www.google.com/apis/maps/">Google Maps</a></
li><li><a href="http://code.google.com/webtoolkit/">Google Web
Toolkit</a></li></ul></li><li><a href="http://www.google.com/
talk">GTalk</a></li></ul></li><li><a href="http://www.msn.com"
title="MSN sites">MSN</a><ul><li><a href="http://www.msnbc.com">News</
a></li><li><a href="http://msn.foxsports.com">Sports</a></li><li><a
href="http://weather.msn.com">Weather</a></li></ul></li><li><a
href="http://www.yahoo.com" title="Yahoo! site">Yahoo!</a><ul><li><a
href="http://www.yahoo.com/r/26">Sports</a></li><li><a href="http://
www.yahoo.com/r/4c">Tech</a></li></ul></li></ul>
<input type="button" id="testPopupMenu" value="Popup menu" disabled>
<ul id="myPopupMenu"><li><a title="Google sites" href="http://
www.google.com">Google</a><ul><li><a href="http://
www.gmail.com">GMail</a><ul><li><a href="http://www.gmail.com">Inbox</
a></li><li><a href="http://www.gmail.com">Outbox</a></li></ul></
li><li><a href="http://www.googlecode.com">Google Code</a><ul><li><a
href="http://code.google.com/apis/ajaxsearch/">Google Ajax Search</a></
li><li><a href="http://www.google.com/apis/maps/">Google Maps</a></
li><li><a href="http://code.google.com/webtoolkit/">Google Web
Toolkit</a></li></ul></li><li><a href="http://www.google.com/
talk">GTalk</a></li></ul></li><li><a href="http://www.msn.com"
title="MSN sites">MSN</a><ul><li><a href="http://www.msnbc.com">News</
a></li><li><a href="http://msn.foxsports.com">Sports</a></li><li><a
href="http://weather.msn.com">Weather</a></li></ul></li><li><a
href="http://www.yahoo.com" title="Yahoo! site">Yahoo!</a><ul><li><a
href="http://www.yahoo.com/r/26">Sports</a></li><li><a href="http://
www.yahoo.com/r/4c">Tech</a></li></ul></li></ul>
</body>
</html>
Brian Adkins
wrote:
>
> But please do that only where it is on-topic.
That is appropriate, but I find it humorous nonetheless considering
very little of this thread has been on topic. Who knows, maybe someone
will show up with some useful info regarding JavaScript menus after
all.
David Mark
> On Sep 29, 5:12 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
>
>
>
>
> > Brian Adkins wrote:
> > > On Sep 29, 4:34 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > >> On Sep 29, 4:07 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> > >>> Brian Adkins said the following on 9/29/2007 12:51 PM:
> > >> [...]
> > >> I'm not familiar with the phrase "soup tag HTML", but it doesn't sound
> > >> good. Which browsers process XHTML as "soup tag HTML" ?
>
> > The correct term is "tag soup HTML" which is the way most (if not all)
> > parsers in browsers work. If they do no support a HTML feature or encounter
> > not Valid code, they do error correction. That is a behavior not allowed
> > for XML documents such as XHTML documents; they have to be well-formed (they
> > need not to be Valid, although due to the definition of validating parsers
> > that is strongly recommended).
>
> >http://www.hixie.ch/advocacy/xhtml
>
> Interesting information. I do validate my pages, and I'm not planning
> on sending as 'application/xhtml+xml' anytime soon, but it certainly
Then why are you writing XHTML?
> may be that I assumed there were advantages to XHMTL 1.0 Strict after
> reading various information sources (i.e. jumped on a bandwagon). Some
Yep.
> of the proposed benefits of XHTML I've heard are:
>
> * future proofing web pages
Somewhat true, though many will argue that HTML5 is the real future.
But if you are going to serve your pages as HTML, you should write
them as HTML.
> * allowing aural screen readers to more easily consume it
Hardly. Most screen readers rely on browsers to parse your tag soup,
so there is no benefit there. Moreover, I know of no aural browsers
with XML parsers.
> * it's becoming the language of choice for mobile devices
Not really. I imagine you are thinking of XHTML Basic, but that has
little to do with serving XHTML 1.0 as HTML.
> * existing data is more easily transformed into XHTML than HTML
Backwards. It is easier to retrieve data from XHTML.
> * there's not going to be an HTML 5, the new standard is XHTML 1.0
XHTML 1.0 is an old standard and it doesn't look like HTML 5 is going
away. Regardless, the two are not mutually exclusive.
> * <br> seems wrong compared to <br />
It is wrong for XHTML, but correct for HTML.
> * etc.
>
> For what it's worth, here are the doctypes of 49 sites that I checked
> in mid July:
>
> http://lojic.com/blog/2007/07/12/which-doctypes-are-being-used/
>
> Summary is: none = 10, html = 20, xhtml = 19 (only 1 using XHTML 1.1)
That one person using XHTML 1.1 is nuts and I suspect the 19 using
XHTML are doing what you are doing (serving tag soup HTML.)
>
> You've given me some things to think about. If anyone is aware of
> advantages of XHTML 1.1 Strict over HTML 4.01 Strict, feel free to
> chime in.
Zero advantages and lots of pitfalls. XHTML 1.1 is not appropriate
for public Web sites.
David Mark
Oops. The instantiation should look more like this:
var displayCheck;
el = doc.getElementById('myMenubar');
if (el) {
el.style.visibility = 'visible';
displayCheck = el.style && typeof(el.style.display) == 'string' &&
typeof(el.style.position) == 'string';
if (el.parentNode && displayCheck) {
initializeMenu(el);
}
}
el = doc.getElementById('myMenubarVertical');
if (el && el.style) { el.style.visibility = 'visible'; }
if (el && el.parentNode && displayCheck) {
initializeMenu(el, null, 'right');
}
el = doc.getElementById('myPopupMenu');
elButton = doc.getElementById('testPopupMenu');
if (el && el.style) { el.style.visibility = 'visible'; }
if (elButton && elButton.style) { elButton.style.visibility =
'visible'; }
if (el && el.parentNode && displayCheck) {
initializeMenuPopup(el);
if (elButton) {
elButton.disabled = false;
attachPopupActivator(elButton, el);
}
}
I tangled up the visibility/display/positioning detection. Also, the
two references to document.onclick should technically be doc.onclick.
David Mark
> On Sep 29, 7:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
[snip]
One last thought. It would be nice to allow keyboard users to quickly
close the menus without tabbing back to the root (or the activator for
a popup.)
Add one the first function and modify the other two.
function attachDocumentKeyHandler(list, root) {
if (typeof(root) == 'undefined') { root = list; }
var onkeypressOld = doc.onkeypress;
var onkeypressNew = function(e) { e = e || global.event; var key =
e.which || e.keyCode; if (key == 27 && activeMenu &&
(isAncestor(activeMenu, list) || activeMenu == list))
{ hideActiveMenu(null, root) } };
doc.onkeypress = (onkeypressOld)?function(e) { onkeypressOld(e);
onkeypressNew(e); }:onkeypressNew;
}
function initializeMenu(list, className, initialSide) {
list.className = className || 'menubar';
list.style.position = 'relative';
initializeChildMenus(list, list, initialSide);
attachDocumentClickHandler(list);
attachDocumentKeyHandler(list);
}
function initializeMenuPopup(list, className) {
list.className = className || 'menuPopup';
list._isRootless = true;
initializeChildMenus(list, null);
list.style.position = 'absolute';
list.style.display = 'none';
attachDocumentClickHandler(list, null);
attachDocumentKeyHandler(list, null);
}
Randy Webb
If you don't serve it as XHTML then it isn't XHTML. And no DTD (or any
other element/tag/code in the page) will make the browser interpret it
as XHTML. Even your Firefox is interpreting it as HTML. Serve it with a
proper MIME type and see what IE does with it.
Peter Michaux
I'd think these quotations would be justification enough.
http://www.webdevout.net/articles/beware-of-xhtml#quotes
Peter
Randy Webb
> Brian Adkins wrote:
<snip>
>> You've given me some things to think about. If anyone is aware of
>> advantages of XHTML 1.1 Strict over HTML 4.01 Strict, feel free to
>> chime in.
>
> But please do that only where it is on-topic.
Agreed. As the advantages/disadvantages of XHTML versus HTML, and the
ability to script the two different DOM'es with one script would be
totally off-topic to clj
> F'up2 comp.infosystems.www.authoring.html
F'up set back where I want it set for my post.
Brian Adkins
Yes, I find those quotes signficant.
I see what Randy was trying to say in his initial post - the subtlety
was lost on me. I was ignorant of the fact that my carefully crafted
XHTML 1.0 Strict code was being handled as as HTML. I think I figured
the 'text/html' content type was simply to placate IE and that the
XHTML capable browsers would obey the doctype. From my research today,
it's clear that this is an all too common misconception. Bad book
authors :)
This is certainly a heavily debated topic, but I've personally been
unable to find enough evidence to justify serving XHTML up as HTML, so
unless I turn up something significant in the next few days, I think
I'll switch to HTML 4.01 Strict and continue to code in an XHTML
style. At least I feel better informed now.
There certainly seems to be a strong trend in moving to XHTML with a
'text/html' content type, so it appears that either a lot of major
site operators are misinformed, or I've yet to get all the relevant
facts about this.
Peter Michaux
> I think
> I'll switch to HTML 4.01 Strict and continue to code in an XHTML
> style.
If you use HTML doctype it would be wise to make sure your markup is
valid HTML (just forget about XHTML all together).
Peter
Randy Webb
> On Sep 29, 10:12 pm, Peter Michaux <petermich...@gmail.com> wrote:
<snip>
>> I'd think these quotations would be justification enough.
>>
>> http://www.webdevout.net/articles/beware-of-xhtml#quotes
>>
>> Peter
>
> Yes, I find those quotes signficant.
>
> I see what Randy was trying to say in his initial post - the subtlety
> was lost on me. I was ignorant of the fact that my carefully crafted
> XHTML 1.0 Strict code was being handled as as HTML. I think I figured
> the 'text/html' content type was simply to placate IE and that the
> XHTML capable browsers would obey the doctype. From my research today,
> it's clear that this is an all too common misconception. Bad book
> authors :)
Yes. Most programming books are not worth the paper they are printed on.
> This is certainly a heavily debated topic, but I've personally been
> unable to find enough evidence to justify serving XHTML up as HTML, so
> unless I turn up something significant in the next few days, I think
> I'll switch to HTML 4.01 Strict and continue to code in an XHTML
> style. At least I feel better informed now.
You can save yourself a "few days" of searching and simply forget about
XHTML for anytime in the foreseeable future. Just don't forget that HTML
doesn't have a short tag syntax.
> There certainly seems to be a strong trend in moving to XHTML with a
> 'text/html' content type, so it appears that either a lot of major
> site operators are misinformed, or I've yet to get all the relevant
> facts about this.
They are either misinformed, ignorant, or just want to be able to say
"We use XHTML on our AJAX site" or something similar. First bet is on
ignorance though.
David Mark
> On Sep 29, 7:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
Took a moment to try this in IE6 and it looked a lot like IE7 quirks
mode. That was surprising as there isn't usually a correlation
between IE6 standards and IE7 quirks. I had forgotten how
unpredictable lists were in IE.
In short, IE6 requires widths for the list items (which sucks.) I
gave them all the same widths and tweaked a few other things with
conditional comments. The result is a lot uglier, but at least there
are no parse-related hacks. The rendering is the same as before in
everything but IE6. Other than the fixed widths, IE6 looks the same
as everything else. Quirks mode is definitely out, but not
necessarily IE5.5 as there are no box model issues. I suspect Mac IE
will have some some problems, but couldn't care less at this point.
Also note that one of the menus in the original is too wide for 6em.
I didn't bother to add a specific rule to accommodate it, so that menu
will look weird in IE6 unless the captions are shortened.
<style type="text/css" media="all">
ul.menubar { list-style-type:none;padding:0;margin:0 }
ul.menubar a, ul.menuPopup a { padding: 0 .25em 0 .25em }
ul.menubar li { margin:0;padding:0;display:inline}
ul.menubar li a:link, ul.menubar li a:visited { text-decoration:none }
ul.menubar li a:hover { background-color:#0000DD;color:white }
ul.menuPopup { list-style-type:none;padding:0;margin:0;border:outset
2px;background-color:threedface;color:windowtext;z-index:1 }
ul.menuPopup li { white-space:nowrap;display:block;width:auto }
ul.menuPopup li a { width:auto }
ul.menuPopup li a:link, ul.menuPopup li a:visited { text-
decoration:none }
ul.menuPopup li a:hover { background-color:#0000DD;color:white }
ul.menuPopup li a.popup:after { content: "\0020\00BB"; }
#myMenubarVertical.menubar { width:6em;margin-bottom:1em }
#myMenubarVertical.menubar li { display:block;width:auto }
#myMenubarVertical.menubar li a { width:auto }
#testPopupMenu { display:block; margin-top:1em }
body {font-family:sans-serif;background-color:threedface}
</style>
<!--[if !IE]>-->
<style type="text/css" media="all">
#myMenubarVertical.menubar li a, ul.menuPopup li a { display:block }
</style>
<!--<![endif]-->
<!--[if IE]>
<style type="text/css" media="all">
ul.menubar { display:inline-block } /* Adds layout to fix IE relative
positioning bug */
</style>
<![endif]-->
<!--[if gt IE 6]>
<style type="text/css" media="all">
#myMenubarVertical.menubar li a, ul.menuPopup li a { display:block }
</style>
<![endif]-->
<!--[if lt IE 7]>
<style type="text/css" media="all">
ul.menubar li, ul.menubar li a, ul.menuPopup li, ul.menuPopup li a
{ height:1% }
ul.menuPopup li, ul.menuPopup li a, #myMenubarVertical.menubar li,
#myMenubarVertical.menubar li a { width:6em; zoom:1 }
</style>
<![endif]-->
Richard Cornford
> On Sep 29, 10:12 pm, Peter Michaux wrote:
>> On Sep 29, 6:35 pm, Randy Webb wrote:
<snip>
>>> If you don't serve it as XHTML then it isn't XHTML. And no
>>> DTD (or any other element/tag/code in the page) will make
>>> the browser interpret it as XHTML. Even your Firefox is
>>> interpreting it as HTML. Serve it with a proper MIME type
>>> and see what IE does with it.
>>
>> I'd think these quotations would be justification enough.
>>
>> http://www.webdevout.net/articles/beware-of-xhtml#quotes
>
>
> I see what Randy was trying to say in his initial post - the
> subtlety was lost on me. I was ignorant of the fact that my
> carefully crafted XHTML 1.0 Strict code was being handled as
> as HTML. I think I figured the 'text/html' content type was
> simply to placate IE and that the XHTML capable browsers would
> obey the doctype.
Which means that you were also not aware that there is a distinction
between HTML DOMs and XHTML DOMs. If you are scripting a DOM absolutely
the last thing you would want is to be scripting one type of DOM in one
browser and another type in the next.
> From my research today, it's clear that this is an all too
> common misconception.
All too common, and such that sufferers from the misconception are
extremely resistant to being corrected.
> Bad book authors :)
Yes, but not only. Bad web page authors (directly, and those writing
pages on writing web pages) are probably more guilty (by weight of
numbers) , along with the participants in small circulation web forums,
mailing lists and other web development 'communities'.
> This is certainly a heavily debated topic, but I've personally
> been unable to find enough evidence to justify serving XHTML
> up as HTML, so unless I turn up something significant in the
> next few days, I think I'll switch to HTML 4.01 Strict and
> continue to code in an XHTML style. At least I feel better
> informed now.
While you are judging the 'significance' of what you find consider the
consequence of scripting such a document. Since almost no non-trivial
scripts will operate successfully with both and HTML DOM and an XHTML
DOM and a document served as text/html will result in the browser
exposing an HTML DOM to be scripted, will it ever make sense to be
marking-up a document as XHTML and then scripting with the pre-requisite
that it will _never_ be interpreted as being an XHTML document by a web
browser.
> There certainly seems to be a strong trend in moving to XHTML
> with a 'text/html' content type,
There certainly is a strong trend towards seeing increasing quantities
of XHTML-style mark-up in documents (whether they be XHTML or not). It
is most obvious that fundamental miscomputations are driving this trend
when you observe the number of documents where <br> appears alongside
<br /> (or when you see things like <BR />).
> so it appears that either a lot of major site operators are
> misinformed, or I've yet to get all the relevant facts about
> this.
The general standard of technical understanding, even on 'major sites',
is so low that 'misinformed' is probably pushing things too far. To be
misinformed you need to be (in some sense) 'informed' in the first
place. Plain old endemic ignorance is a much better explanation; these
people just don't know why they are doing what they are doing.
Much of the time when we get into this XHTML/HTML discussion here it
quickly obvious that the individuals being asked why they are using
XHTML-style mark-up while scripting an HTML DOM not only don't know that
there is a distinction between the types of DOM, but don't actually know
what an HTTP content-type header is. These is no informed decision
making in what they do, just the random outcome of the aggregation of an
extended sequence of 'learnt' mystical incantations.
The depth, and pervasive nature of, that endemic ignorance is best
illustrated by the current set of 'popular' javascript libraries. Where
people who don't know any better are importing the ignorance of others
into their own projects.
On Monday morning I have been asked to analyse why an 'AJAX' web
application written by one of our subsidiary companies runs so badly on
IE6 as to be non-viable. I have not seen the code yet and the only
things I know about it are that it was written by experienced Java
programmers (so I am expecting them to have made all the mistakes I made
when moving from Java to javascript) and that they have used to
'popular' dojo library. In preparation I thought it would be a good idea
to have a look at the dojo library code, so I spent a few hours
yesterday doing that, to discover (as I expected I would) that its
authors were not particularly knowledgeable about javascript or browser
scripting. To illustrate:-
From a file called "dojo.js" (re-wrapped for newsgroup posting):-
| document.write("<scr"+"ipt type='text/javascript' src='"+
| spath+
| "'></scr"+"ipt>"
| );
In the mark-up string being presented to the - document.write - method
you will see two string concatenation operations being used to
'split-up' the SCRIPT opening and closing tags. This is a mystical
incantation that ignorant script authors chant in the face of a real
issue. The real issues is that when an HTML parser encounters an opening
SCRIPT tag it must determine how much (if any) of the following material
is script code that should be sent to a script engine for processing and
when it should resume processing the input stream as HTML mark-up. The
obvious signal for the end of contents of a SCRIPT element would be the
closing SCRIPT tag. However, the HTML parser has no means of seeing the
characters in the input stream as anything other than characters so if a
javascript string contains the character sequence '</script>' the HTML
parser is going to see that as the character sequence it is interested
in; the end of the contents of the SCRIPT element. Resulting in an
unterminated string literal error in the javascript source and gibberish
text content in the HTML document.
There is also a formal issue that differs slightly form the real issue.
The HTML specification clearly states that CDATA contents of an element
(SCRIPT element contents are CDATA in HTML) may be terminated by the
first occurrence of the character sequence '</'. In practice no browsers
are known to follow this aspect of the HTML specification to the letter,
but a knowledgeable HTML author would have no excuse for complaint if a
future browser did terminate CDATA sections at the point of first
encountering the character sequence '</'.
So the things that make the above code a mystical incantation are:-
1. The string concatenation operation in the opening SCRIPT
tag is a needless runtime overhead to do something that
has no relationship to either the real issue or the formal
issue. It just should never have appeared in any code.
2. The string concatenation operation in the closing SCRIPT
element may deal with the real issue but it does not address
the formal issue. While any approach that did address the
formal issue by breaking up the '</' sequence would also
break up the '</script> sequence.
3. A concatenation operation is a poor approach to this issue
as the HTML parser is only able to see the raw source text
characters. Breaking up the problematic character sequences
with escape (backslash) characters would be just as effective
at concealing them form the HTML parser but would do so in a
way that had no consequences beyond the point where the
string literal was converted into a string primitive value
(during the compiling of the script into an executable). That
is, there is no need for the runtime overhead of two (or
four in this case) string concatenation operations. The
recommended approach is to turn the sequence '</script>' in
string literals into the sequence '<\/script>' and so address
the real and formal issues without any runtime overhead.
4. The code is actually in an external javascript resource and
so will never be presented to an HTML parser for examination.
Neither the real nor the formal issues apply to this code at
all.
Another illustration is to be found in dojo's 'dom.js:-
| if(
| elem == null ||
| ((elem == undefined)&&(typeof elem == "undefined"))
| ){
| dojo.raise("No element given to dojo.dom.setAttributeNS");
| }
Using the type-converting equality operator (- == -) there are precisely
two values that are equal to null. They are null (unsurprisingly) and
the undefined value. In the above tests whenever - elem - is null or
undefined the - elem == null - expression is true and the - ((elem ==
undefined)&&(typeof elem == "undefined")) - expression is not evaluated.
So whenever the - ((elem == undefined)&&(typeof elem == "undefined")) -
expression is evaluated the value of - elem - must be neither null nor
undefined. But if - elem - must be neither null nor undefined then -
(elem == undefined) - must always be false (as only undefined and null
equal (by type-converting equality) undefined), and as - (elem ==
undefined) - must be false the - (typeof elem == "undefined") - can
*never* be evaluated.
We are looking at code where the author has written the test
expression - elem == null - without understanding the operation being
performed and made that ignorance self-evident by following it with a
test that can only have one outcome in its context, and a third test
that can never be evaluated (though if it were evaluated the result
would be as predictably false as the - (elem == undefined) -
expression).
The annoying part of this nonsense is that in its normal use, when -
elem - will be a reference to a DOM Element, that - (elem ==
undefined) - is going to be evaluated, and it is going to produce its
predictably false result. Just another avoidable runtime overhead,
included for no reason other than ignorance.
It is unlikely that dojo is the work of a single individual, but we can
be certain that of everyone involved the individual with the greatest
knowledge of the subject does not know javascript well enough to
understand how the code written is going to behave (or enough to
distinguish between chanting mystical incarnations and browser
scripting). However, you find that the authors of these 'popular'
libraries acquire a strange status in the eyes of (presumably even more
ignorant) others, get invited to speak at conferences, feel themselves
qualified to instruct others on how they should be writing javascript,
and so on.
So yes we do live in a world where the operators of 'major sites' are
misinformed, and likely to stay that way because the odds are that the
next person to 'inform' them will likely be as misinformed themselves.
Richard.
Peter Michaux
wrote:
[snip examples of less than optimal code in dojo]
> So yes we do live in a world where the operators of 'major sites' are
> misinformed, and likely to stay that way because the odds are that the
> next person to 'inform' them will likely be as misinformed themselves.
Would you agree that most niches in the programming world are filled
with people that are misinformed and making decision that are randomly
good or bad? I would say mediocrity and satifaction with just enough
information to avoid being fired extends to some fraction of
individuals in every intellectual field with which I have had contact.
N.B. I'm not claiming I'm anything other than average. I have no
justification to do so.
Peter
Richard Cornford
> On Sep 30, 11:31 am, Richard Cornford wrote:
>
> [snip examples of less than optimal code in dojo]
"Less then optimal"? That code was well into the range of b***dy stupid.
>> So yes we do live in a world where the operators of 'major
>> sites' are misinformed, and likely to stay that way because
>> the odds are that the next person to 'inform' them will
>> likely be as misinformed themselves.
>
> Would you agree that most niches in the programming world are
> filled with people that are misinformed and making decision
> that are randomly good or bad?
Not in my experience.
> I would say mediocrity and satifaction with just enough
> information to avoid being fired extends to some fraction of
> individuals in every intellectual field with which I have
> had contact.
<snip>
There is a big difference between "most" and "some".
But what is your point? Does an inept programmer become competent when
the person sitting at the next desk is worse?
Richard.
Brian Adkins
wrote:
> Brian Adkins wrote:
> > On Sep 29, 10:12 pm, Peter Michaux wrote:
> >> On Sep 29, 6:35 pm, Randy Webb wrote:
> > I think I figured the 'text/html' content type was
> > simply to placate IE and that the XHTML capable browsers would
> > obey the doctype.
>
> Which means that you were also not aware that there is a distinction
> between HTML DOMs and XHTML DOMs.
Correct.
> > I think I'll switch to HTML 4.01 Strict and
> > continue to code in an XHTML style. At least I feel better
> > informed now.
>
> While you are judging the 'significance' of what you find consider the
> consequence of scripting such a document.
Just to clarify. What I meant by 'coding in an XHTML style' is things
like using lowercase attribute names with quotations, using closing
tags even if they're optional, etc. such that the markup is valid HTML
resulting in an HTML DOM.
> The depth, and pervasive nature of, that endemic ignorance is best
> illustrated by the current set of 'popular' javascript libraries. Where
> people who don't know any better are importing the ignorance of others
> into their own projects.
Could it be that people are simply doing their best to try and find a
library that is the lesser of evils to avoid the disadvantages of
writing everything themselves? In my short time on c.l.j, I have seen
many criticisms of JavaScript libraries but few recommendations. It
could be that they simply got lost in the noise.
Are there any JavaScript libraries that you can recommend over
reinventing wheels? I checked the FAQ and didn't see anything.
I'm also curious if the folks criticizing the 'popular' JavaScript
libraries (or their authors) have attempted to improve the code -
either by direct contribution or via educating the authors. Or are
they beyond hope?
Thomas 'PointedEars' Lahn
> On Sep 30, 2:31 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
>> Brian Adkins wrote:
>>> On Sep 29, 10:12 pm, Peter Michaux wrote:
>>>> On Sep 29, 6:35 pm, Randy Webb wrote:
>>> I think I'll switch to HTML 4.01 Strict and
>>> continue to code in an XHTML style. At least I feel better
>>> informed now.
>> While you are judging the 'significance' of what you find consider the
>> consequence of scripting such a document.
>
> Just to clarify. What I meant by 'coding in an XHTML style' is things
> like using lowercase attribute names with quotations, using closing
> tags even if they're optional, etc. such that the markup is valid HTML
> resulting in an HTML DOM.
If you observe more closely, you will see that XHTML cannot be made fully
HTML-compatible this way, at least because IE renders <br></br> as *two*
lines. And XHTML 1.0, Appendix C (which is not normative BTW), fails to
recognize that in a non-tagsoup HTML parser `<br />' equals `<br>>'.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Peter Michaux
> On Sep 30, 2:31 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
>
> > Brian Adkins wrote:
> > > On Sep 29, 10:12 pm, Peter Michaux wrote:
> > >> On Sep 29, 6:35 pm, Randy Webb wrote:
> > > I think I figured the 'text/html' content type was
> > > simply to placate IE and that the XHTML capable browsers would
> > > obey the doctype.
>
> > Which means that you were also not aware that there is a distinction
> > between HTML DOMs and XHTML DOMs.
>
> Correct.
>
> > > I think I'll switch to HTML 4.01 Strict and
> > > continue to code in an XHTML style. At least I feel better
> > > informed now.
>
> > While you are judging the 'significance' of what you find consider the
> > consequence of scripting such a document.
>
> Just to clarify. What I meant by 'coding in an XHTML style' is things
> like using lowercase attribute names with quotations, using closing
> tags even if they're optional, etc. such that the markup is valid HTML
> resulting in an HTML DOM.
Lower case attribute names and quoted values are fine ideas. I
certainly find it easiest to read HTML written this way.
> > The depth, and pervasive nature of, that endemic ignorance is best
> > illustrated by the current set of 'popular' javascript libraries. Where
> > people who don't know any better are importing the ignorance of others
> > into their own projects.
>
> Could it be that people are simply doing their best to try and find a
> library that is the lesser of evils to avoid the disadvantages of
> writing everything themselves?
Many developers, particularly server-side developers, don't like UI
work and really hate dealing with browser bugs. They are happy to have
someone else do the work and if it works in the majority of their
target browser market that is good enough. These days the "good
enough" market is usually IE6/IE6/FF2/O9/S2 with JavaScript, ActiveX,
CSS and images all enabled.
I think many times on comp.lang.javascript the business goals of a
project are forgotten in favor of technical perfection. I wouldn't
want c.l.j to be any other way and focusing on business goals and
"good enough" has led to such a heap of released libraries that really
aren't ready for production.
> In my short time on c.l.j, I have seen
> many criticisms of JavaScript libraries but few recommendations. It
> could be that they simply got lost in the noise.
Quite a few c.l.j regulars think libraries are a bad idea in general.
They do admit to reusing code of their own so in some sense do use
libraries.
A big issue with libraries is what is considered bloat. For a
particular page, how much library code sent to the browser is never
used? If this code is cached is it used on some other page of the
site? It is a balance of library granularity, page load times and
caching.
> Are there any JavaScript libraries that you can recommend over
> reinventing wheels? I checked the FAQ and didn't see anything.
I've never had the opportunity to use a pre-made high-level library
widget component (eg data table, in-window popup, accordion, tabbed
pane, etc). I always need to write custom widgets. These have features
no general purpose library widget would have and are usually something
like a tenth the size of some roughly similar library widget. What I
do find useful are the low-level libraries: Event, Ajax(XHR), DOM
searching/creating. Having most of the low-level browser bugs
normalized with these libraries makes writing custom widgets quite
easy and fast.
> I'm also curious if the folks criticizing the 'popular' JavaScript
> libraries (or their authors) have attempted to improve the code -
> either by direct contribution or via educating the authors. Or are
> they beyond hope?
On various lists for the popular libraries and in posts on c.l.j, I've
seen c.l.j regulars offer very good advice. Take the Prototype
developers as an example. They have had advice hurled at them in
various forms for years. The usual response is something along the
lines of "that just isn't cool"; however, a few months or a year down
the road they realize the wisdom of the advice and do make the change.
The Prototype library is big (~3400 lines) but it is small enough that
someone both familiar with the library and a knowledgeable JavaScript
programmer could sit down and rewrite it in under a month and remove a
slew of bugs and poor design decisions. This would require a big API
change which "just isn't cool"...yet.
I think the majority of c.l.j regulars prefer to roll their own. Then
if something needs changing they can just change it without going
through some long political process to have a patch accepted.
Peter
Brian Adkins
wrote:
> Brian Adkins wrote:
> > Just to clarify. What I meant by 'coding in an XHTML style' is things
> > like using lowercase attribute names with quotations, using closing
> > tags even if they're optional, etc. such that the markup is valid HTML
> > resulting in an HTML DOM.
>
> If you observe more closely, you will see that XHTML cannot be made fully
> HTML-compatible this way, at least because IE renders <br></br> as *two*
> lines. And XHTML 1.0, Appendix C (which is not normative BTW), fails to
> recognize that in a non-tagsoup HTML parser `<br />' equals `<br>>'.
My goal is *not* to make XHTML fully HTML-compatible. I stated "such
that the markup is valid HTML" and referred to "optional" closing
tags, not "forbidden" ones, yet you show <br> with an end tag which is
forbidden (as it is for <img>, <meta>, etc.) according to the spec
here:
http://www.w3.org/TR/html401/index/elements.html
On the other hand, the closing tag for <p> is optional (as is <body>,
<li>, etc.), but in keeping with an XHTML "style" I would choose to
include the closing tag when optional.
I appreciate your enthusiasm, but maybe you could channel this extra
energy into recommending a JavaScript library "that doesn't suck" :)
Peter Michaux
>
> recommending a JavaScript library "that doesn't suck" :)
You realize how dangerous it is for someone to make such a
recommendation on c.l.j? If the library isn't perfect then it "sucks".
I'll stick my neck out and say I think mine doesn't suck. I need to
make a few changes which are mostly stylistic.
<URL: http://forkjavascript.org/>
I've never seen another library tested so widely
<URL: http://forkjavascript.org/welcome/browser_support>
Peter
Thomas 'PointedEars' Lahn
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Brian Adkins wrote:
>>> Just to clarify. What I meant by 'coding in an XHTML style' is things
>>> like using lowercase attribute names with quotations, using closing
>>> tags even if they're optional, etc. such that the markup is valid HTML
>>> resulting in an HTML DOM.
>> If you observe more closely, you will see that XHTML cannot be made fully
>> HTML-compatible this way, at least because IE renders <br></br> as *two*
>> lines. And XHTML 1.0, Appendix C (which is not normative BTW), fails to
>> recognize that in a non-tagsoup HTML parser `<br />' equals `<br>>'.
>
> My goal is *not* to make XHTML fully HTML-compatible.
But that has to be your goal or you have neither Valid XHTML nor Valid HTML
markup that can be used to create a document tree in the DOM.
> I stated "such that the markup is valid HTML" and referred to "optional"
> closing tags, not "forbidden" ones, yet you show <br> with an end tag which
> is forbidden (as it is for <img>, <meta>, etc.) according to the spec
> here:
>
> http://www.w3.org/TR/html401/index/elements.html
Utter nonsense. As you can observe in the specification, all HTML elements
with an empty content model, including the `br', `img' and `meta' elements,
have an *optional* end tag. That goes for HTML 3.2, HTML 4.01 Transitional,
Frameset, and Strict, and (so) even ISO HTML. It is that property of HTML
that can make XHTML 1.0 HTML-compatible generally, if it were not for the
faulty Trident.
> On the other hand, the closing tag for <p> is optional
As is `</br>'.
> [...]
> I appreciate your enthusiasm, but maybe you could channel this extra
> energy into recommending a JavaScript library "that doesn't suck" :)
Since I never had the need for a library for the feature you are looking for
(as the posted links should have proven already), I can not recommend one.
In fact, any script library that would be required for that (in contrast to
a little behavior-.htc) can safely be recommended against on the Web as it
will not degrade gracefully and so it will not be interoperable and the
outcome will not conform to accessibility guidelines.
Thomas 'PointedEars' Lahn
> Brian Adkins wrote:
>> I stated "such that the markup is valid HTML" and referred to "optional"
>> closing tags, not "forbidden" ones, yet you show <br> with an end tag which
>> is forbidden (as it is for <img>, <meta>, etc.) according to the spec
>> here:
>>
>> http://www.w3.org/TR/html401/index/elements.html
>
> Utter nonsense. As you can observe in the specification, all HTML elements
> with an empty content model, including the `br', `img' and `meta' elements,
I can see now how and why you got the impression that the end tags would be
forbidden. You will have to ignore that column of this non-normative index
where there is an "F" for "Forbidden" (as you will have to ignore many
non-normative examples in W3C specifications that propose bad practice).
There is exactly nothing in the DTD that forbids to use an/the optional end
tag for those elements (or any other element), nor is there anything in the
corresponding normative sections of the specification that says so. For
example, the declaration for the HTML `br' element in HTML 4.01 Strict is as
follows:
| <!ELEMENT BR - O EMPTY -- forced line break -->
| <!ATTLIST BR
| %coreattrs; -- id, class, style, title --
| >
You will observe the `-' after the element type identifier `BR' that means
the start tag of the element is _not_ optional. You will also observe the
following `O' that means the end tag of the element *is indeed* optional
(and not at all forbidden), and the `EMPTY' which says that the content
model of the element is empty, i.e. it must not have any content (e.g.
`<br>foo</br>' is indeed forbidden).
HTH
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>
John G Harris
I'm afraid you haven't consulted section 3.3.3 of the HTML 4.01
standard. This says that :
- - means the end tag is compulsory;
- O means the end tag is optional;
- O EMPTY means the end tag is forbidden.
(Note the DTD language uses two bits to index three states).
One possibility is that section 3.3.3 is normative (i.e you are required
to obey it). On the other hand it might be non-normative (i.e it's a
serving suggestion), but then it's an accurate translation of a
normative part of the SGML standard. Either way, you'd better believe
it.
John
--
John Harris
Bart Van der Donck
> 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.
--
Bart
Randy Webb
The only other condition is that you understand that exactly and
precisely ~92.3847201% of Web Statistics are made up on the spot.
I need you to email me about the FAQ Postings. I have some questions and
last time I tried to email you it sent it back to me undeliverable.
Richard Cornford
> On Sep 30, 2:31 pm, Richard Cornford wrote:
>> Brian Adkins wrote:
>>> On Sep 29, 10:12 pm, Peter Michaux wrote:
>>>> On Sep 29, 6:35 pm, Randy Webb wrote:
>>> I think I figured the 'text/html' content type was
>>> simply to placate IE and that the XHTML capable browsers
>>> would obey the doctype.
>
>> Which means that you were also not aware that there is a
>> distinction between HTML DOMs and XHTML DOMs.
>
> Correct.
>
>>> I think I'll switch to HTML 4.01 Strict and
>>> continue to code in an XHTML style. At least I feel better
>>> informed now.
>
>> While you are judging the 'significance' of what you find
>> consider the consequence of scripting such a document.
>
> Just to clarify. What I meant by 'coding in an XHTML style' is
> things like using lowercase attribute names with quotations,
> using closing tags even if they're optional, etc. such that
> the markup is valid HTML resulting in an HTML DOM.
Self imposed discipline. That is usually a good idea in the absence of
externally imposed discipline (and perhaps regardless of it).
>> The depth, and pervasive nature of, that endemic ignorance is
>> best illustrated by the current set of 'popular' javascript
>> libraries. Where people who don't know any better are importing
>> the ignorance of others into their own projects.
>
> Could it be that people are simply doing their best to try and
> find a library that is the lesser of evils to avoid the
> disadvantages of writing everything themselves?
What are the "disadvantages" of writing everything yourself? Whatever
they may be on the plus side if you write something yourself you will
(or should) understand it, and there is a great deal to be said for
understanding the scripts that you use.
There a commonly asserted pre-supposition that the only alternatives
available are facilitating code re-use with the creation of large
general purpose libraries or to re-write everything from scratch each
time you do anything new. That polarized perception should be self
evidently nonsense to anyone who has copied an existing function form
one piece of exiting code to a new one, which will be pretty much
everyone who has got past pure copy-n-paste scripting.
Most of the bias in favour of large scale libraries comes with people
approaching javascript form other programming languages where having
large reservoirs of pre-created code always available to the programmer
makes perfect sense. Indeed so much sense that it becomes difficult to
see how that may not be true for all programming tasks. Which even
extends to the point where, when asked for justifications for using
large general purpose libraries some will not even consider answering
the question as a worthwhile exercise, even though articulating the
justifications would help to make it clear why the normal practice in
other programming environments does not necessarily extend well to
javascript.
There is not much thought given to the issues that follow from
broadcasting all the source code to the user and compiling it each time
it is executed. It should be fairly obviously that if it was necessary
to transmit over the internet, and then compile, all of the source code
for all the standard Java libraries, plus anything application
specifies, each time you wanted to execute any Java program then that
would make Java non-viable. But still that is the inevitable end point
of creating ever more capable (and so ever larger) general purpose
javascript libraries.
There also appears to be a tendency with the authors of such libraries
to react to criticism of the download size by seeking out code
compression strategies. This is something Dojo is attempting, and where
DoJo illustrates the folly of the exercise. In the 0.9.0 version the
file for distribution is 'dojo.js', which is 'compressed' (and actively
decompressed after it loads). The same code is available in full and
commented as 'dojo.js.uncompressed.js'. If you consider that HTTP 1.1
UAs tend to support compressed HTTP transmission it is significant to
consider how javascript source files will compress when considering
download size. When I zip compress 'dojo.js' the result is 25,903 bytes,
while if I remove the comments from 'dojo.js.uncompressed.js' and
compress it the result comes out at 25,862 (fractionally smaller). That
means that the 'compression' technique used in Dojo actually hinders zip
compression and so potentially increases download size, while its need
to de-compress on the client (with javascript) means that the total time
before the result is available to the user is increased by the process.
In truth code re-use is facilitated by any rendering of the specific
more general, from actions as simple as replacing inline code with
parameterised function calls. Given a huge spectrum of possible code
re-use strategies, with the large scale, highly capable, interdependent,
monolithic, general purpose javascript library being no more than a
point at one end of the spectrum, it is probably unwise to fixate on
that one strategy as being the only sensible option without being able
to articulate some pretty robust justifications for that position.
One of the issues faced by the author of a general purpose library is
the need to be truly general. This is well illustrated with one of the
much discussed browser scripting problems; the acquisition of accurate
position and dimension information relating to displayed DOM elements. A
general algorithm would take an element as input and determine the page
relative coordinates of its upper left corner and its width and height,
in some sense, as this is a description of some sort of 'containing
box', which does not necessarily have to be any specific box (in the
sense that CSS talks of boxes) but must be the same box for all
elements, and presumably a useful box to know about.
In the simplest case a DOM element will have offseTop/Left/Width/Height
and an offsetParent, and its position is the sum of all the
offsetTop/Lefts for all its offsetParents and its width/height is just
its offsetWidth/Height. But that is for CSS 'block' elements (as opposed
to inline, list-item, run-in, compact, marker, table, inline-table,
table-row-group, table-header-group, table-footer-group, table-row,
table-column-group, table-column, table-cell and table-caption) with no
borders or padding on the element and any of its offset parents, where
none of the offset parents have scrolling overflow, on browsers that
provide those dimension properties, and quite a bit else besides.
The general algorithm has never been worked out, though it is a
possibility and there are at least a few individuals on the planet that
could work it out and implement it. The reason that none of them have is
that they know that the result would be big (2000 plus statements),
complex, and far too slow to be of any practical use.
This leaves the general purpose library with a problem. It should have
element position and location reporting facilities, but if they are to
be truly general they will inevitably be non-viable because of their
performance and seriously contribute to the library's download bulk.
The best the general purpose library can be is proved a faculty that is
'good enough' for some set of common cases; a compromise. Which then
means that it will insufficient for less common cases (leaving anyone
using the library with no choice but add their own code for those tasks)
and at the same time the code is over the top for simplest cases,
risking sub-optimal performance for no good reason.
A less browser related example might be a 'safe' hash table
implementation. A very capable implementation may reproduce, say, all of
the Java HashTable class in javascript, with all of its methods and the
ability to have multiple live Iterators/Enumerators, while the simplest
may just facilitate the storing and retrieval of values using arbitrary
string keys. If a general purpose library is going to include such a
thing then the odds are it will tend toward the more capable end of the
range of possibilities, while the individual using it may only need the
minimum (making the runtime overheads of supporting live Enumerators
actively undesirable).
A third example of how the difference between the general and the
specific impacts on the general purpose library is the question of
framesets, and where any particular code is to be located in any
possible frame structure. You will often code testing - constructor -
properties against built-in constructor functions, or using -
instanceof - with the same subjects. That is all fine if you are working
with a single global object, but as soon as anyone is attempting to pass
objects about in a frameset structure such texts are invalid. There is
also the question of creating new DOM elements, where using the -
createElement - method of the wrong - document - object will be
disastrous in at lest some common browsers (including IE). So your
general purpose library has two choices; either assume a single global
object, and be insufficient for contexts where framesets are employed,
or do all the extra work to keep track of multiple frame contexts and so
be over the top whenever it is used in a single page site.
One of the characteristics of browser scripting is that it has become a
very diverse activity with many contexts of use; Intranet
sites/applications, web applications, e-commerce, promotional web sites,
public information services, entertainment, and so on. Some design
criteria for any one context do not necessarily even come into the
picture in some other contexts. And the starting point for design
decision making should be the purpose of the system being planned,
without any arbitrary a priori restrictions. And this is itself an issue
with general purpose libraries. Dojo, for example, only works (more or
less) with a few versions of half a dozen browsers (and will really fall
apart if exposed to anything else). That is too few for a public
information service in any jurisdiction that requires such services to
be accessible by law (as the fact that it will fall apart when it fails
will deny the possibility of clean degradation) but it may also be far
too many for a private web application (which may suffer from all the
branching inside the code in order to accommodate browsers that are just
not relevant in the application's context).
One of the arguments suggested in favour of general purpose libraries
(and also used to criticise them) is that learning the library avoids
the need to learn the details of handling web browsers directly. Once
you realise that the compromises that the general purpose libraries must
make (to be as capable as is realistic (for their authors) but no more)
mean that any single general purpose library cannot sensibly be used in
all application contexts you see the need is not to spend time learning
a single general purpose library but instead potentially a whole range
of such libraries, and the bigger and more capable any single example is
the more work is involved in learning to use it. And given that it can
make a lot more sense to spend time learning to script web browsers
directly than to learn the APIs for a series of libraries that may still
not be suitable for all to applications that may come up. (This is
particularly true when standardisation of browser object models means
that 80-odd% of what could be learnt would then be applicable to most
scriptable browsers).
So what is wanted is a code re-use strategy (as we will all agree that
writing everything form scratch for each project is insane) that
maximises the proportion of code being re-used, produces an easily
maintainable and reliable end result and is sufficiently flexible to
produce appropriate code of any given application context without
pre-imposing arbitrary restrictions on the design process or being over
the top in the less complex contexts.
Inevitably there is some disagreement as to how best to achieve this
outcome, but it is fairly obvious that larger-scale general purpose
libraries will not satisfy those considerations (with their overriding
emphasis on code re-use at the cost of seemingly all else).
My preferred strategy is to build code from a large collection of
relatively small interchangeable modules designed around interface
definitions, where any single interface may have numerous
implementations. The resulting architectures start out with a lowest
level that is a layer of modules that abstract out the differences
between browsers by handling them internally. Above that are more layers
of modules that depend upon the interfaces provided by the previous
layer and expose their own interfaces for more complex and task specific
actions, and above that some number of similar layers ending in the
application specific control logic code that must be unique to each
specific action.
The lowest layer includes only items form the collection of interface
implementations that are employed in the context, sufficient for the
context and no more, and usually very well tested. Given a particular
task, say the reporting of view port dimensions and scroll values, a
single interface is used, but any number of objects may exist to
implement that interface. So while a cross-browser version may attempt
to provide that information wherever it is available, in a context where
only a limited set of known browsers are to be used a much simpler
version exists to be used in its place. While any code that employs the
interface does not need to care about any more than getting a reference
to an object that implements the interface, and so does not care about
the specifics of how that is done in the context.
This strategy allows issues like the unreasonable complexity of the
truly general element position reporting algorithm to be avoided. In any
real context it is possible to know enough about which positioning
information is required and why it is required to sidestep most of
complexity of the general problem. If no elements of relevance are to
have scrollable contents, or borders, or be anything but block elements
the task goes from the complex back to the quick and simple, and indeed
enough can be known about the context that many optimisations can be
implemented inside the object providing the element position reporting
interface. It may be the case that a theoretically huge number of such
implementations would be necessary to accommodate all the permutations
but in practice if you start by only implementing the ones that are
needed when they become needed you end up implementing the most
recurrent requirements first (and so creating the most re-useable
objects) and may never actually encounter a real world situation where
the more involved position reporting problems need to be addressed.
Consider what happens when re-design results in maintenance issues. For
the positioning problem; suppose someone re-designs the presentation and
ends up adding elements with scrolling overflow where they had not
previously existed. The object implementing the position reporting
interface can no longer cope as it was never designed to do so. But
either the collection of objects implementing that interface already
contains one that can cope, or a new implementation can be created and
added to that collection. The problem is solved by swapping one object
for another that implements the same interface (but takes more into
account internally) and all of the rest of the code is unaffected by the
change.
The collection of such interchangeable modular interface implementations
from which actual projects are built may be regarded as being a library
(in some sense) but it is not something that can be presented to the
wider world as a library because it is inherently incomplete by design.
The design work, the intellectual effort, goes into designing interfaces
that can sit on top of varying implementations and usefully participate
in flexible hierarchical structures of code. The actual creation of the
objects implementing the interfaces is on an 'as needed' basis, and
while the expectation is that those objects created should then be very
re-useable (in similar contexts, with the likely re-occurring contexts
also being those likely to occur early in the process), the objects for
the more unusual situations may never be needed by any individual, and
so never be created and added to the collection.
> In my short time on c.l.j, I have seen many criticisms of
> JavaScript libraries
Yes, it can be very easy.
> but few recommendations. It could be that they simply got
> lost in the noise.
No, there are few recommendations, and the few people making such
recommendations tend not to be doing so on an informed basis.
> Are there any JavaScript libraries that you can recommend over
> reinventing wheels?
You are certain that those are the only two alternatives?
> I checked the FAQ and didn't see anything.
>
> I'm also curious if the folks criticizing the 'popular'
> JavaScript libraries (or their authors) have attempted
> to improve the code - either by direct contribution or
> via educating the authors.
If the people making the criticism are of the opinion that 'improvement'
would involve a significant re-thinking of the concepts underlying the
enter library design any such attempts to 'improve' would be very likely
to be disregarded by the authors of those libraries.
On the other hand "the folks criticizing" have already done a great deal
to improve the code in these libraries, though maybe not that directly
(or with that specific intention). I my own case inventing what is
apparently destined to be called "Crockford's module pattern" in early
2003, and then participating, with other regular contributors to this
group (and also "folks criticizing ... "), in the development of its
applications over the following two years, has had a very visible impact
on the code in any recent library you could name, and mostly for the
better.
(It is interesting watching the wider world re-inventing the wheel when
it comes to the "Crockford's module pattern". For example, having
started with the singleton implementation used in the YUI blog to
demonstrate the idea (which is an application of the idea from August
2003)-
<URL:
http://nefariousdesigns.co.uk/archive/2007/08/javascript-module-pattern-variations/ >
- shows someone re-tracing the evolution of the scheme and ending up
back with a single function interface, which parallels in structure the
very first examples of non-'Class' related modules I published in May
2003).
Then there is the growth of the understating of, and subsequent use of,
javascript's closures in general. A trend that is also evident in recent
library code and a trend in the wider world that can almost entry be
traced back to my 2004 article on javascript closures written for the
group's FAQ.
Over the years various contributors to this group have written probably
the equivalent of sizable books on the subject of javascript. Mostly
directed towards the better understanding of the language and better
design in its applications. And this has all been done in public (and
archived) in a context where anyone who wants to is free to participate.
If the authors of those 'popular' libraries have preferred to ignore
that and hide away in their own little worlds then that is hardly the
fault of anyone who criticises their code here.
> Or are they beyond hope?
They are beyond hope if the people responsible have their egos so
heavily invested in their creations that they can never recognise their
mistakes.
But to some extent these things become the victims of their own success
as once they have been 'released' and acquired a user base addressing
fundamental design faults becomes very difficult. Given the limited
technical understanding of javascript on the part of their authors, as
demonstrated in the code they write, in most cases it might have been
better if the authors had held off 'releasing' anything until they had
taken the time to learn the language, and gain some experience using it,
because during that time they may have learnt enough about browser
script design issues, and been exposed to more debate related to the
subject, to have started their libraries on a better footing (or in some
cases not started them at all).
Richard.
Peter Michaux
Richard Cornford wrote:
> On Oct 1, 5:07 pm, Brian Adkins wrote:
>
> > Could it be that people are simply doing their best to try and
> > find a library that is the lesser of evils to avoid the
> > disadvantages of writing everything themselves?
>
> What are the "disadvantages" of writing everything yourself?
Not accounting for certain browser bugs/incompatibilities due to not
having a long enough history working with browsers to know about
particular bugs. Testing would show the bugs but testing in currently
rare browsers (eg. IE4, Sunrise, Lobo) may not be considered a wise
cost by the business. Using a prepackaged library that already works
in all cases would be much cheaper and more attractive to a project
manager even with a certain amount of increased download time. Project
timelines and idealism clash on occasion.
<snip>
> There is not much thought given to the issues that follow from
> broadcasting all the source code to the user and compiling it each time
> it is executed. It should be fairly obviously that if it was necessary
> to transmit over the internet, and then compile, all of the source code
> for all the standard Java libraries, plus anything application
> specifies, each time you wanted to execute any Java program then that
> would make Java non-viable. But still that is the inevitable end point
> of creating ever more capable (and so ever larger) general purpose
> javascript libraries.
That may be true of a library like Prototype that is distributed as a
single file. Libraries like Dojo, YUI are distributed in multiple
files so even as the library gains capabilities it doesn't mean the
whole library has to be downloaded for each page.
It seems granularity of a library's distributed source code is a core
source of contention. Should a library be distributed as one file like
Prototype and jQuery or distributed as many files like YUI to be
combined as needed by a developer working on a particular page? If
multiple files how small should each file be. If multiple files, how
should they be combined for a particular page?
<snip>
> This leaves the general purpose library with a problem. It should have
> element position and location reporting facilities, but if they are to
> be truly general they will inevitably be non-viable because of their
> performance and seriously contribute to the library's download bulk.
>
> The best the general purpose library can be is proved a faculty that is
> 'good enough' for some set of common cases; a compromise. Which then
> means that it will insufficient for less common cases (leaving anyone
> using the library with no choice but add their own code for those tasks)
> and at the same time the code is over the top for simplest cases,
> risking sub-optimal performance for no good reason.
I think there is another way to look at what the library is providing
to the user. In the terms you use below, the library is providing an
interface and a base implementation of that interface. In the simple
cases where it is excessively complex, I can see that some developers
would just say "we will never agree how simple the simplest
implementation of this interface should be." It may make sense to some
people that the simplest interface should at least work in the popular
80% of the browsers and having a simpler version for particular
browsers is just more code to maintain. Although performance and
download times are important it is also necessary to retain a small
code base and so a medium complexity implementation of the interface
as the base implementation may be better to some people than having
many simpler ones kicking around the hard drive.
So the library provides a medium complexity base implementation and
when it is insufficient for a less common case the developer writes
code to handle the less common case. This is very similar/identical to
what you are suggesting below.
<snip>
> A third example of how the difference between the general and the
> specific impacts on the general purpose library is the question of
> framesets, and where any particular code is to be located in any
> possible frame structure. You will often code testing - constructor -
> properties against built-in constructor functions, or using -
> instanceof - with the same subjects. That is all fine if you are working
> with a single global object, but as soon as anyone is attempting to pass
> objects about in a frameset structure such texts are invalid. There is
> also the question of creating new DOM elements, where using the -
> createElement - method of the wrong - document - object will be
> disastrous in at lest some common browsers (including IE). So your
> general purpose library has two choices; either assume a single global
> object, and be insufficient for contexts where framesets are employed,
> or do all the extra work to keep track of multiple frame contexts and so
> be over the top whenever it is used in a single page site.
Two implementation of the same library interface. It is not a mistake
to have either or both versions and, at a larger granularity, is
consistent with your ideas below about multiple implementations of a
common interface. Suppose there are two popular libraries and one is
for the single global object and the other is for framesets. The
mistake is that both groups of developers will hype their library as
the one true implementation and create a religious war. And then there
will be backlash against the idea of libraries because of the hype.
<snip>
> So what is wanted is a code re-use strategy (as we will all agree that
> writing everything form scratch for each project is insane) that
> maximises the proportion of code being re-used, produces an easily
> maintainable and reliable end result and is sufficiently flexible to
> produce appropriate code of any given application context without
> pre-imposing arbitrary restrictions on the design process or being over
> the top in the less complex contexts.
This would be ideal.
> Inevitably there is some disagreement as to how best to achieve this
> outcome, but it is fairly obvious that larger-scale general purpose
> libraries will not satisfy those considerations (with their overriding
> emphasis on code re-use at the cost of seemingly all else).
When you write "larger-scale" what do you mean? Do you mean
distributed in a single file or a low number of multiple files? Or do
you mean just many lines of code?
> My preferred strategy is to build code from a large collection of
> relatively small interchangeable modules designed around interface
> definitions, where any single interface may have numerous
> implementations. The resulting architectures start out with a lowest
> level that is a layer of modules that abstract out the differences
> between browsers by handling them internally. Above that are more layers
> of modules that depend upon the interfaces provided by the previous
> layer and expose their own interfaces for more complex and task specific
> actions, and above that some number of similar layers ending in the
> application specific control logic code that must be unique to each
> specific action.
I think this is a great strategy overall. It formalizes the idea of "a
sufficient implementation."
> The lowest layer includes only items form the collection of interface
> implementations that are employed in the context, sufficient for the
> context and no more, and usually very well tested.
Why adhere so strictly to this "and no more" requirement? It is ok
performance-wise or more profitable overall (development dollars vs
net income) in many situations to send 5-10% unused code to the
browser.
This seems to be an argument against having the absolute simplest
implementations in the collections of objects. By having a medium-
complexity interface implementation as the base implementation, when a
CSS re-design occurs there _may_ be no need to swap out the simplest
implementation for a slightly more complex implementation. This saves
developer time which is more expensive then production server time.
> The collection of such interchangeable modular interface implementations
> from which actual projects are built may be regarded as being a library
> (in some sense) but it is not something that can be presented to the
> wider world as a library because it is inherently incomplete by design.
> The design work, the intellectual effort, goes into designing interfaces
> that can sit on top of varying implementations and usefully participate
> in flexible hierarchical structures of code. The actual creation of the
> objects implementing the interfaces is on an 'as needed' basis, and
> while the expectation is that those objects created should then be very
> re-useable (in similar contexts, with the likely re-occurring contexts
> also being those likely to occur early in the process), the objects for
> the more unusual situations may never be needed by any individual, and
> so never be created and added to the collection.
It seems that to implement your strategy of multiple interface
implementations that multiple source files grouped in a directory for
each interface would be a practical approach. Some sort of
configuration file and build process could concatenate the various
appropriate files together for a particular page. Is that similar to
the approach you take?
Peter
Thomas 'PointedEars' Lahn
> Richard Cornford wrote:
>> There is not much thought given to the issues that follow from
>> broadcasting all the source code to the user and compiling it each time
>> it is executed. It should be fairly obviously that if it was necessary
>> to transmit over the internet, and then compile, all of the source code
>> for all the standard Java libraries, plus anything application
>> specifies, each time you wanted to execute any Java program then that
>> would make Java non-viable. But still that is the inevitable end point
>> of creating ever more capable (and so ever larger) general purpose
>> javascript libraries.
>
> That may be true of a library like Prototype that is distributed as a
> single file. Libraries like Dojo, YUI are distributed in multiple
> files so even as the library gains capabilities it doesn't mean the
> whole library has to be downloaded for each page.
>
> It seems granularity of a library's distributed source code is a core
> source of contention. Should a library be distributed as one file like
> Prototype and jQuery or distributed as many files like YUI to be
> combined as needed by a developer working on a particular page? If
> multiple files how small should each file be. If multiple files, how
> should they be combined for a particular page?
I would go even farther. A client-side script library should be like a
real-life library. Not only that you can lend only the books about the
categories you are interested in -- try to use only one script resource for
each aspect of client-side scripting -- but also you can lend only the books
of the category that you need as references for your essay: every script
resource should be written with the possibility in mind that the user of the
library can take a single method from it and include only the methods that
depends on to make it work.
These goals can collide with each other, of course: you may want to
implement a general testing method in one resource and use it in all other
resources. Sometimes then it can be better to copy that testing method to
the other resources so that another dependency is avoided (which introduces
the issue of version management of that method, though).
Of course, I'd rather have a built-in `import' statement which makes the
script engine resolve the dependencies without having to download the entire
script resource where a method depended on is declared. But I doubt this
would be feasible on the Web.
Thomas 'PointedEars' Lahn
> Of course, I'd rather have a built-in `import' statement which makes the
> script engine resolve the dependencies without having to download the entire
> script resource where a method depended on is declared. But I doubt this
> would be feasible on the Web.
Hmmm, in combination with server-side scripting this might be feasible. So
that if the served client-side script resource would be generated by a
server-side script which includes all the dependent code. It seems worth to
investigate that.
PointedEars
Richard Cornford
> Richard Cornford wrote:
>> On Oct 1, 5:07 pm, Brian Adkins wrote:
>>
>>> Could it be that people are simply doing their best to try
>>> and find a library that is the lesser of evils to avoid the
>>> disadvantages of writing everything themselves?
>>
>> What are the "disadvantages" of writing everything yourself?
>
> Not accounting for certain browser bugs/incompatibilities due
> to not having a long enough history working with browsers to
> know about particular bugs. Testing would show the bugs but
> testing in currently rare browsers (eg. IE4, Sunrise, Lobo)
> may not be considered a wise cost by the business. Using a
> prepackaged library that already works in all cases would be
> much cheaper and more attractive to a project manager even
> with a certain amount of increased download time. Project
> timelines and idealism clash on occasion.
That pre-supposes that the 'prepackaged library' was written by someone
familiar with this type of historical browser behaviour (whether is it
be a bug or not). But in practice this is precisely the problem being
discussed in the "when is a function not a function" thread. The authors
of dojo and jquery have themselves not had the experience to know that
it is normal for collections to report 'function' from a typeof
operation. So when they encounter a browser that is doing no more or
less than has been done by many browsers in the past they find that
their code cannot cope, and start reporting that as a bug. Obviously
these individuals are not aware that there code has these issues
following from their inexperience, but now your project manager cannot
solve his problem by just using a library unless he has someone who
knows the issues themselves and so can point out which libraries
properly handle them and which doe not. At which point the original "not
having a long enough history working with browsers" has stopped
applying.
<snip>
>> There is not much thought given to the issues that follow
>> from broadcasting all the source code to the user and
>> compiling it each time it is executed. It should be fairly
>> obviously that if it was necessary to transmit over the
>> internet, and then compile, all of the source code for all
>> the standard Java libraries, plus anything application
>> specifies, each time you wanted to execute any Java program
>> then that would make Java non-viable. But still that is the
>> inevitable end point of creating ever more capable (and so
>> ever larger) general purpose javascript libraries.
>
> That may be true of a library like Prototype that is distributed
> as a single file. Libraries like Dojo, YUI are distributed in
> multiple files so even as the library gains capabilities it
> doesn't mean the whole library has to be downloaded for each
> page.
The extent to which that solves the problem depends on the sizes of the
chinks and how their dependencies work. The base part of dojo is 3500
odd line of code and is pretty much essential for anything else. It is
unlikely that that will tend to get any smaller with the passage of
time.
> It seems granularity of a library's distributed source code
> is a core source of contention. Should a library be distributed
> as one file like Prototype and jQuery or distributed as many
> files like YUI to be combined as needed by a developer working
> on a particular page? If multiple files how small should each
> file be. If multiple files, how should they be combined for a
> particular page?
Generally javascript code should be sent to the browser in as few chunks
as possible. how code is handled before that is optional (and probably
best driven by the requirements of the development context).
<snip>
>> The best the general purpose library can be is proved a
>> faculty that is 'good enough' for some set of common
>> cases; a compromise. Which then means that it will
>> insufficient for less common cases (leaving anyone using
>> the library with no choice but add their own code for those
>> tasks) and at the same time the code is over the top for
>> simplest cases, risking sub-optimal performance for no
>> good reason.
>
> I think there is another way to look at what the library is
> providing to the user.
The user is the person sitting in front of a web browser interacting
with the end result. Users should not be confused with programmers as
programmers have much more responsibility for what they do.
> In the terms you use below, the library is providing an
> interface and a base implementation of that interface.
> In the simple cases where it is excessively complex, I
> can see that some developers would just say "we will
> never agree how simple the simplest implementation of
> this interface should be." It may make sense to some
> people that the simplest interface should at least work
> in the popular 80% of the browsers and having a simpler
> version for particular browsers is just more code to
> maintain. Although performance and download times are
> important it is also necessary to retain a small code
> base and so a medium complexity implementation of the
> interface as the base implementation may be better to
> some people than having many simpler ones kicking around
> the hard drive.
For the general problem of maximising code re-use it is not advantageous
to maintain a small code base (quite the opposite). For an individual
project that may be an advantage, but then you can maintain the
distinction between the modules that are in the application and those
that are not.
> So the library provides a medium complexity base
> implementation and when it is insufficient for a less
> common case
And over the top for the more common cases.
> the developer writes code to handle the less
> common case.
But only if the developer has learnt how to do that.
> This is very similar/identical to
> what you are suggesting below.
Getting there, but it is still important that the interface design stage
takes into account the need to accommodate the whole range of possible
implementations of the interface.
<snip>
>> So what is wanted is a code re-use strategy (as we will all
>> agree that writing everything form scratch for each project
>> is insane) that maximises the proportion of code being re-used,
>> produces an easily maintainable and reliable end result and
>> is sufficiently flexible to produce appropriate code of any
>> given application context without pre-imposing arbitrary
>> restrictions on the design process or being over the top in
>> the less complex contexts.
>
> This would be ideal.
Ideal, and so the question is to what extent it can be achieved in
reality.
>> Inevitably there is some disagreement as to how best to achieve
>> this outcome, but it is fairly obvious that larger-scale
>> general purpose libraries will not satisfy those considerations
>> (with their overriding emphasis on code re-use at the cost of
>> seemingly all else).
>
> When you write "larger-scale" what do you mean? Do you mean
> distributed in a single file or a low number of multiple files?
> Or do you mean just many lines of code?
Files and code are largely irrelevant. Mostly I am getting at
interdependence and the number and diversity of facilities provided in
interdependent units. Physical size does follow when many facilities are
strongly interdependent, but that is just a consequence.
>> My preferred strategy is to build code from a large collection
>> of relatively small interchangeable modules designed around
>> interface definitions, where any single interface may have
>> numerous implementations. The resulting architectures start
>> out with a lowest level that is a layer of modules that
>> abstract out the differences between browsers by handling them
>> internally. Above that are more layers of modules that depend
>> upon the interfaces provided by the previous layer and expose
>> their own interfaces for more complex and task specific
>> actions, and above that some number of similar layers ending
>> in the application specific control logic code that must be
>> unique to each specific action.
>
> I think this is a great strategy overall. It formalizes the
> idea of "a sufficient implementation."
Many 'sufficient implementations', where each is 'sufficient' for
differing requirements.
>> The lowest layer includes only items form the collection of
>> interface implementations that are employed in the context,
>> sufficient for the context and no more, and usually very
>> well tested.
>
> Why adhere so strictly to this "and no more" requirement?
Because that criteria provides constant direction. Abandon it and there
is no telling how far things may end up drifting in the opposite
direction.
> It is ok performance-wise or more profitable overall
> (development dollars vs net income) in many situations
> to send 5-10% unused code to the browser.
Maybe 5-10% but without direction there is nothing to make you stop at
(or near) 10%, and there a plenty of real world cases where an imported
library is being so slightly used that almost all of the downloaded code
is not being used.
<snip>
>> Consider what happens when re-design results in maintenance
>> issues. For the positioning problem; suppose someone
>> re-designs the presentation and ends up adding elements
>> with scrolling overflow where they had not previously
>> existed. The object implementing the position reporting
>> interface can no longer cope as it was never designed to
>> do so. But either the collection of objects implementing
>> that interface already contains one that can cope, or a
>> new implementation can be created and added to that
>> collection. The problem is solved by swapping one object
>> for another that implements the same interface (but takes
>> more into account internally) and all of the rest of the
>> code is unaffected by the change.
>
> This seems to be an argument against having the absolute
> simplest implementations in the collections of objects.
> By having a medium-complexity interface implementation as
> the base implementation, when a CSS re-design occurs there
> _may_ be no need to swap out the simplest implementation
> for a slightly more complex implementation.
But that is a very big "may". One CSS change may bring scrolling
overflow into the picture, another may change a floating block element
into a list item, and a whole spectrum of other possibilities exist.
Your "medium-complexity" implementation just cannot take everything into
account without actual being the complex implementation that everyone is
trying to avoid even writing (let alone using).
Because the future re-design cannot be predicted there is no point in
trying. It makes most sense to deal with the current situation but to do
it in a way that has the flexibility to minimise the effort needed to
accommodate the unknowable future changes.
> This saves developer time which is more expensive then
> production server time.
Yes, so make the task of accommodating any possible future changes in
requirements as quick and simple as possible.
>> The collection of such interchangeable modular interface
>> implementations from which actual projects are built may
>> be regarded as being a library (in some sense) but it is
>> not something that can be presented to the wider world as
>> a library because it is inherently incomplete by design.
>> The design work, the intellectual effort, goes into
>> designing interfaces that can sit on top of varying
>> implementations and usefully participate in flexible
>> hierarchical structures of code. The actual creation of
>> the objects implementing the interfaces is on an 'as
>> needed' basis, and while the expectation is that those
>> objects created should then be very re-useable (in similar
>> contexts, with the likely re-occurring contexts also being
>> those likely to occur early in the process), the objects for
>> the more unusual situations may never be needed by any
>> individual, and so never be created and added to the collection.
>
> It seems that to implement your strategy of multiple interface
> implementations that multiple source files grouped in a directory
> for each interface would be a practical approach.
Yes that certainly would be one sensible structure for such a
collection.
> Some sort of configuration file and build process could
> concatenate the various appropriate files together for a
> particular page.
Could, but aggregating the components necessary for a project with copy
and paste gets the job done. Changes in an application's source files
during the development of a project tend to mostly be additions rather
than changes in what has already been created, so any elaborate "build
process" might be added complexity for no good reason.
> Is that similar to
> the approach you take?
I have not got to the point of expressing capabilities and dependencies
in the sort of machine readable form that would be necessary for an
automated build process. Eventually that may become desirable (or even
necessary), but I prefer to get a good handle on the issues involved
before moving in those sorts of directions (as if you commit yourself to
something inadequate you usually end up getting stuck with it).
Richard.
Thomas 'PointedEars' Lahn
> Peter Michaux wrote:
>> It seems granularity of a library's distributed source code
>> is a core source of contention. Should a library be distributed
>> as one file like Prototype and jQuery or distributed as many
>> files like YUI to be combined as needed by a developer working
>> on a particular page? If multiple files how small should each
>> file be. If multiple files, how should they be combined for a
>> particular page?
>
> Generally javascript code should be sent to the browser in as
Why?
PointedEars
David Mark
wrote:
connections and scripts must be downloaded in their entirety before
the rest of the page can be parsed. Modularity should apply to the
logical design of a script library, but there are other considerations
for the physical file structure.
Peter Michaux
wrote:
To reduce page load time.
Peter
Thomas 'PointedEars' Lahn
Maybe we have a definition problem here. Given that the question was which
would be better, one large or several small script resources, how do you
define a chunk?
PointedEars
David Mark
The fact is that if you break up a large script into smaller chunks
(ie files), it will slow down the page load as additional http
connections are required. That doesn't mean you necessarily should
lump every script together in one file. It is just one thing to
consider when determining the physical file structure of your code,
which often does not mirror its logical modularity.
Peter Michaux
I think "chunks" has meant "files" in this discussion and the question
being do you send the same code as one file or several files. Sending
as one file saves requests. Requests increase download time.
Peter
Peter Michaux
wrote:
Point taken but I think the people adopting some of the worse offender
libraries are deferring to the comparatively greater experience of the
library authors.
> <snip>
>
> >> There is not much thought given to the issues that follow
> >> from broadcasting all the source code to the user and
> >> compiling it each time it is executed. It should be fairly
> >> obviously that if it was necessary to transmit over the
> >> internet, and then compile, all of the source code for all
> >> the standard Java libraries, plus anything application
> >> specifies, each time you wanted to execute any Java program
> >> then that would make Java non-viable. But still that is the
> >> inevitable end point of creating ever more capable (and so
> >> ever larger) general purpose javascript libraries.
>
> > That may be true of a library like Prototype that is distributed
> > as a single file. Libraries like Dojo, YUI are distributed in
> > multiple files so even as the library gains capabilities it
> > doesn't mean the whole library has to be downloaded for each
> > page.
>
> The extent to which that solves the problem depends on the sizes of the
> chinks and how their dependencies work. The base part of dojo is 3500
> odd line of code and is pretty much essential for anything else. It is
> unlikely that that will tend to get any smaller with the passage of
> time.
Agreed. Large base file dependencies certainly are offensive when I am
looking at a library's design.
> > In the terms you use below, the library is providing an
> > interface and a base implementation of that interface.
> > In the simple cases where it is excessively complex, I
> > can see that some developers would just say "we will
> > never agree how simple the simplest implementation of
> > this interface should be." It may make sense to some
> > people that the simplest interface should at least work
> > in the popular 80% of the browsers and having a simpler
> > version for particular browsers is just more code to
> > maintain. Although performance and download times are
> > important it is also necessary to retain a small code
> > base and so a medium complexity implementation of the
> > interface as the base implementation may be better to
> > some people than having many simpler ones kicking around
> > the hard drive.
>
> For the general problem of maximising code re-use it is not advantageous
> to maintain a small code base (quite the opposite).
That seems contradictory. Can you please expound on that statement?
> >> The lowest layer includes only items form the collection of
> >> interface implementations that are employed in the context,
> >> sufficient for the context and no more, and usually very
> >> well tested.
>
> > Why adhere so strictly to this "and no more" requirement?
>
> Because that criteria provides constant direction. Abandon it and there
> is no telling how far things may end up drifting in the opposite
> direction.
This sounds like fear of a slippery slope and adhering to this
principle gives a sense of doing the right thing as opposed to
entering into grey areas. I too like black and white decision making
but I admire people that are comfortable in the grey areas. I'm
consistently amazed how they have such great confidence that what they
are doing is correct when their decisions are based on instinct rather
than a formal argument. I don't think their decision making approach
is invalid.
This purity seems a little too idealistic to me. What I meant is
something like this...if a company uses floating blocks and list items
and has a history of switching between the two then it would make
sense that the base implementation of some interface can handle both
cases rather than one implementation for each situation. If the
company suddenly adds a third variant then it could be lumped in with
the implementation that can handle the previous two situation or a new
implementation could be made. It seems to me that an individual
company will have common gui components or gui experience so the
lumping option isn't a slippery slope to negative infinity. It might
slip to handle five or so cases but that's it. It seems to be more of
a judgement call. The problem in a general purpose library is it could
slip too far because so many companies are trying to wedge their
features into a single implementation.
> > This saves developer time which is more expensive then
> > production server time.
>
> Yes, so make the task of accommodating any possible future changes in
> requirements as quick and simple as possible.
Indeed a good requirement.
What happens when a new browser comes along requiring a change in one
of the interface implementations that has been pasted all over the
place? Sure there is grep or similar but modifying just one file and
typing "build" seems like a better option to me. I really do believe
in the DRY principle for this.
> > Is that similar to
> > the approach you take?
>
> I have not got to the point of expressing capabilities and dependencies
> in the sort of machine readable form that would be necessary for an
> automated build process. Eventually that may become desirable (or even
> necessary), but I prefer to get a good handle on the issues involved
> before moving in those sorts of directions (as if you commit yourself to
> something inadequate you usually end up getting stuck with it).
It certainly has been difficult for me to negotiate a build process
with the server-side programmers. They automatically assume that I
will be writing JavaScript in single files in the format the code be
deployed. To me that is almost the same as expecting a Java programmer
to be directly writing compiled byte code or jar files. The irony is
the server-side programmers have tools galore for accomplishing their
code writing tasks but they don't think I could benefit from some
tools to do my job. I suppose my tools bleed over to their side but
the opposite is not true so my tools are a nuisance.
Peter
Richard Cornford
> On Oct 14, 3:53 pm, Richard Cornford wrote:
>> Peter Michaux wrote:
<snip>
>>> Not accounting for certain browser bugs/incompatibilities
>>> due to not having a long enough history working with
<snip>
>>> Using a prepackaged library that already works in all
>>> cases would be much cheaper and more attractive to a
>>> project manager even with a certain amount of increased
>>> download time. Project timelines and idealism clash on
>>> occasion.
>>
>> That pre-supposes that the 'prepackaged library' was written
>> by someone familiar with this type of historical browser
<snip>
>> Obviously these individuals are not aware that there code
>> has these issues following from their inexperience, but
>> now your project manager cannot solve his problem by just
>> using a library unless he has someone who knows the issues
>> themselves and so can point out which libraries properly
>> handle them and which doe not. At which point the original
>> "not having a long enough history working with browsers"
>> has stopped applying.
>
> Point taken but I think the people adopting some of the worse
> offender libraries are deferring to the comparatively greater
> experience of the library authors.
No doubt, but when you have a situation where inexperience tends to lead
to overconfidence and authors declaration that their own work is fit for
some purpose or another doesn't mean very much.
<snip>
>>> In the terms you use below, the library is providing an
>>> interface and a base implementation of that interface.
>>> In the simple cases where it is excessively complex, I
>>> can see that some developers would just say "we will
>>> never agree how simple the simplest implementation of
>>> this interface should be." It may make sense to some
>>> people that the simplest interface should at least work
>>> in the popular 80% of the browsers and having a simpler
>>> version for particular browsers is just more code to
>>> maintain. Although performance and download times are
>>> important it is also necessary to retain a small code
>>> base and so a medium complexity implementation of the
>>> interface as the base implementation may be better to
>>> some people than having many simpler ones kicking around
>>> the hard drive.
>>
>> For the general problem of maximising code re-use it is
>> not advantageous to maintain a small code base (quite the
>> opposite).
>
> That seems contradictory. Can you please expound on that
> statement?
If a "library" consist of numerous implementations of common interfaces,
where each implementation is suited to a specific application contexts,
then the more of these implementations there are in the "library" the
greater the odds are that the next project will be covered by the
"library" and not require the creation of a new implementation. Thus the
larger the collection the greater the chances of being in a position to
take advantage of code re-use.
This has to recognise that there are two code bases; the "library's"
code base and the application's code base. For the application the
smaller the better, but for the "library" the reverse is likely true.
>>>> The lowest layer includes only items form the collection
>>>> of interface implementations that are employed in the
>>>> context, sufficient for the context and no more, and
>>>> usually very well tested.
>>
>>> Why adhere so strictly to this "and no more" requirement?
>>
>> Because that criteria provides constant direction.
>> Abandon it and there is no telling how far things may
>> end up drifting in the opposite direction.
>
> This sounds like fear of a slippery slope
Where slippery slopes exist trepidation/fear is not an unreasonable
attitude to take towards them.
> and adhering to this principle gives a sense of doing the
> right thing as opposed to entering into grey areas.
A sense of direction is most valuable when working in a grey area.
> I too like black and white decision making but I admire
> people that are comfortable in the grey areas. I'm
> consistently amazed how they have such great confidence
> that what they are doing is correct when their decisions
> are based on instinct rather than a formal argument. I
> don't think their decision making approach is invalid.
Have you considered what an "instinct" is in terms of software
development? surely it is an impression that a move in one direction
would be a change for the worse and that the opposite direction would be
a change for the better?
<snip>
>> Because the future re-design cannot be predicted there is
>> no point in trying. It makes most sense to deal with the
>> current situation but to do it in a way that has the
>> flexibility to minimise the effort needed to accommodate
>> the unknowable future changes.
>
> This purity seems a little too idealistic to me. What I
> meant is something like this...if a company uses floating
> blocks and list items and has a history of switching
> between the two then it would make sense that the base
> implementation of some interface can handle both
> cases rather than one implementation for each situation.
Maybe, but you now have two "if"s. If those "if"s can be seen to be true
at the stage of creating the code then they should be taken into
consideration in the design.
> If the company suddenly adds a third variant then it could
> be lumped in with the implementation that can handle the
> previous two situation or a new implementation could be made.
Unless the new design effectively precludes the previous two, at which
point that is little reason to be executing code that could cope with
what has bee precluded.
> It seems to me that an individual company will have common
> gui components or gui experience so the lumping option isn't
> a slippery slope to negative infinity. It might slip to handle
> five or so cases but that's it.
But what is the point of attempting to handle five or so cases if only
two or them are still possibilities in the context? It is the case that
significant presentation re-design does happen, but it does not happen
frequently and it does tend to unpredictable. Unpredictable because the
characteristic of designers that is valued in this context is their
ability to come up with something appealingly new.
> It seems to be more of a judgement call.
And in my judgement there is no point in trying to second guess the
future discussions of an unknown graphic designed. If that is not the
applicable situation then different judgements may be appropriate.
> The problem in a general purpose library is it could
> slip too far because so many companies are trying to wedge
> their features into a single implementation.
And if it could slip, and could slip too far then we do have a slippery
slope here, and an undesirable destination at the bottom of hat slope.
>>> This saves developer time which is more expensive then
>>> production server time.
>>
>> Yes, so make the task of accommodating any possible future
>> changes in requirements as quick and simple as possible.
>
> Indeed a good requirement.
>
<snip>
> What happens when a new browser comes along requiring a change
> in one of the interface implementations that has been pasted
> all over the place?
Well designed modules (with rationally designed feature detection) do
not tend to require changes when new browsers come along. You will
recall that I started experimenting with these modular component design
principles back in 2003 and the intervening period has seen new versions
of many browsers and a number of entirely new brewers, yet very little
of the 2003-2004 code has needed any modification to cope with them.
> Sure there is grep or similar but modifying just one file and
> typing "build" seems like a better option to me. I really do
> believe in the DRY principle for this.
I am not saying that a build process is a bad idea, only that it is over
the top for the simpler contexts.
>>> Is that similar to the approach you take?
>>
>> I have not got to the point of expressing capabilities and
>> dependencies in the sort of machine readable form that would
>> be necessary for an automated build process. Eventually that
>> may become desirable (or even necessary), but I prefer to
>> get a good handle on the issues involved before moving in
>> those sorts of directions (as if you commit yourself to
>> something inadequate you usually end up getting stuck with it).
>
> It certainly has been difficult for me to negotiate a build
> process with the server-side programmers. They automatically
> assume that I will be writing JavaScript in single files in
> the format the code be deployed.
And also assume that they know enough about your expertise that what
they think of as the right thing to do will be the right thing to do?
> To me that is almost the same as expecting a Java
> programmer to be directly writing compiled byte code
> or jar files.
A slight exaggeration, but still expressing the fact that just because
javascript is delivered as source code it should not be assumed that it
would be developed in its delivered form.
> The irony is the server-side programmers have tools galore
> for accomplishing their code writing tasks but they don't
> think I could benefit from some tools to do my job. I
> suppose my tools bleed over to their side but the opposite
> is not true so my tools are a nuisance.
It is maybe not that surprising that many server-side programmers
exhibit some contempt for javascript programmers, given a general
perception of javascript as a 'toy' language reinforced by the easily
observed fact that most of the people writing it don't really know what
they are doing.
In the end you will be able to change their attitude by demonstrating
that you do know what you are talking about.
Richard.
Brian Adkins
wrote:
> Peter Michaux wrote:
> > Richard Cornford wrote:
> >> On Oct 1, 5:07 pm, Brian Adkins wrote:
>
> >>> Could it be that people are simply doing their best to try
> >>> and find a library that is the lesser of evils to avoid the
> >>> disadvantages of writing everything themselves?
>
> >> What are the "disadvantages" of writing everything yourself?
>
> > Not accounting for certain browser bugs/incompatibilities due
> > to not having a long enough history working with browsers to
> > know about particular bugs. Testing would show the bugs but
> > testing in currently rare browsers (eg. IE4, Sunrise, Lobo)
> > may not be considered a wise cost by the business. Using a
> > prepackaged library that already works in all cases would be
> > much cheaper and more attractive to a project manager even
> > with a certain amount of increased download time. Project
> > timelines and idealism clash on occasion.
>
> That pre-supposes that the 'prepackaged library' was written by someone
> familiar with this type of historical browser behaviour (whether is it
> be a bug or not).
Does it? Maybe it simply pre-supposes the library author is *more*
familiar than the user of the library. There are no perfect solutions
here, so we're left with choosing the least imperfect.
Every "build vs. buy" decision involves pros/cons that must be
evaluated. In my case, although I enjoy the JavaScript language, I
need to spend the majority of my time on server-side development, so I
don't have the time to work out all the browser portability issues,
etc. If a library does a "good enough" job, then it could save
valuable time.
If the detractors of current mainstream JavaScript libraries would
produce better libraries, that would be beneficial, but I expect than
any libraries put forth as an example on this forum would get picked
apart like all the rest.
I doubt you're unaware of these issues, so I'm curious why you asked
the question, "What are the "disadvantages" of writing everything
yourself?"
Brian Adkins
David Mark
In the case of JS libraries, you are left with choosing the least
incompetent.
>
> Every "build vs. buy" decision involves pros/cons that must be
> evaluated. In my case, although I enjoy the JavaScript language, I
> need to spend the majority of my time on server-side development, so I
> don't have the time to work out all the browser portability issues,
> etc. If a library does a "good enough" job, then it could save
> valuable time.
Name one that does a "good enough" job.
>
> If the detractors of current mainstream JavaScript libraries would
> produce better libraries, that would be beneficial, but I expect than
I have. But I choose not to give it away for beer money donations.
It is quite beneficial from where I am sitting. For you, not so much.
> any libraries put forth as an example on this forum would get picked
> apart like all the rest.
I post bits and pieces of my library here all the time. I truly
welcome any attempts to pick apart the examples. If the authors of
the "mainstream libraries" would have done the same, instead of
authoring in a vacuum, perhaps they would have gotten more useful
results.
Brian Adkins
> On Oct 27, 4:14 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > Every "build vs. buy" decision involves pros/cons that must be
> > evaluated. In my case, although I enjoy the JavaScript language, I
> > need to spend the majority of my time on server-side development, so I
> > don't have the time to work out all the browser portability issues,
> > etc. If a library does a "good enough" job, then it could save
> > valuable time.
>
> Name one that does a "good enough" job.
Depending on the context, Prototype, Scriptaculous, Dojo, YUI,
JQuery ...
Now maybe you're salivating right now because you're familiar with
what you think are major problems in each of the above and can't wait
to enlighten us with your "knowledge", so you may want to re-read
"depending on the context" before you reply.
In other words, there are contexts for which it's more beneficial to
use a subset of one of the above libraries than to write the code from
scratch. I know this to be true because I'm using portions of
Prototype.js via Rails integration with absolutely no issues. It's
fairly trivial stuff in my case, but the advantage is that it's pre-
written, pre-tested code that is open source and available for input
from others, so improvements can be made.
> > If the detractors of current mainstream JavaScript libraries would
> > produce better libraries, that would be beneficial, but I expect than
>
> I have. But I choose not to give it away for beer money donations.
> It is quite beneficial from where I am sitting. For you, not so much.
I should have stated "produce better open source libraries".
> > any libraries put forth as an example on this forum would get picked
> > apart like all the rest.
>
> I post bits and pieces of my library here all the time. I truly
> welcome any attempts to pick apart the examples. If the authors of
> the "mainstream libraries" would have done the same, instead of
> authoring in a vacuum, perhaps they would have gotten more useful
> results.
Interesting. Would you be willing to post a bit, or piece, of
significant JavaScript code that would pass the gauntlet of
comp.lang.javascript ? I'm not saying it's impossible, only highly
improbable.
David Mark
> On Oct 27, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Oct 27, 4:14 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > Every "build vs. buy" decision involves pros/cons that must be
> > > evaluated. In my case, although I enjoy the JavaScript language, I
> > > need to spend the majority of my time on server-side development, so I
> > > don't have the time to work out all the browser portability issues,
> > > etc. If a library does a "good enough" job, then it could save
> > > valuable time.
>
> > Name one that does a "good enough" job.
>
> Depending on the context, Prototype, Scriptaculous, Dojo, YUI,
> JQuery ...
>
> Now maybe you're salivating right now because you're familiar with
> what you think are major problems in each of the above and can't wait
> to enlighten us with your "knowledge", so you may want to re-read
I have no desire to enlighten you (or the mouse in your pocket) about
anything. Issues concerning the four libraries listed (and the
Scriptaculous plug-in for Prototype) have been discussed here ad
nauseum.
> "depending on the context" before you reply.
If you failed to catch on, perhaps you should re-read previous threads
on the subject.
>
> In other words, there are contexts for which it's more beneficial to
> use a subset of one of the above libraries than to write the code from
> scratch. I know this to be true because I'm using portions of
> Prototype.js via Rails integration with absolutely no issues. It's
What makes you think there are "absolutely no issues?" Nobody
reported any? Using Prototype alone is a major issue.
> fairly trivial stuff in my case, but the advantage is that it's pre-
If it is fairly trivial stuff, then why use a 70K library to implement
it?
> written, pre-tested code that is open source and available for input
Pre-tested on a small subset of agents and yet there are still lots of
issues.
> from others, so improvements can be made.
Yet the code rarely sees significant changes. I've seen the babbling
that goes on in Rails support tickets. You are up the creek if you
are relying on that group to fix anything in a timely fashion.
>
> > > If the detractors of current mainstream JavaScript libraries would
> > > produce better libraries, that would be beneficial, but I expect than
>
> > I have. But I choose not to give it away for beer money donations.
> > It is quite beneficial from where I am sitting. For you, not so much.
>
> I should have stated "produce better open source libraries".
Yes, you should have.
>
> > > any libraries put forth as an example on this forum would get picked
> > > apart like all the rest.
>
> > I post bits and pieces of my library here all the time. I truly
> > welcome any attempts to pick apart the examples. If the authors of
> > the "mainstream libraries" would have done the same, instead of
> > authoring in a vacuum, perhaps they would have gotten more useful
> > results.
>
> Interesting. Would you be willing to post a bit, or piece, of
> significant JavaScript code that would pass the gauntlet of
> comp.lang.javascript ? I'm not saying it's impossible, only highly
> improbable.
Can and have. And whether code "passes" is not the issue. The point
is that I post code here in hopes of it getting picked apart as I know
there are people here with the experience to do so. If the authors of
Prototype, jQuery, etc. had bothered to do the same, perhaps they
wouldn't have blundered so badly. Certainly they wouldn't continue to
rely on browser sniffing at this late date.
And aren't you the OP who wanted a canned menu script? Don't tell me
that is what you are using Prototype for. Did you notice that I
posted a link to one earlier in the thread? Feel free to use it and
pick it apart all you want. I would say that the sum of its parts is
fairly significant and I welcome any coherent feedback on it.
Richard Cornford
> On Oct 14, 6:53 pm, Richard Cornford wrote:
>> Peter Michaux wrote:
>>> Richard Cornford wrote:
>>>> On Oct 1, 5:07 pm, Brian Adkins wrote:
>>
>>>>> Could it be that people are simply doing their best
>>>>> to try and find a library that is the lesser of
>>>>> evils to avoid the disadvantages of writing
>>>>> everything themselves?
>>
>>>> What are the "disadvantages" of writing everything
>>>> yourself?
>>
>>> Not accounting for certain browser bugs/incompatibilities
>>> due to not having a long enough history working with
>>> browsers to know about particular bugs. Testing would
>>> show the bugs but testing in currently rare browsers
>>> (eg. IE4, Sunrise, Lobo) may not be considered a wise
>>> cost by the business. Using a prepackaged library that
>>> already works in all cases would be much cheaper and
>>> more attractive to a project manager even with a
>>> certain amount of increased download time. Project
>>> timelines and idealism clash on occasion.
>>
>> That pre-supposes that the 'prepackaged library' was
>> written by someone familiar with this type of historical
>> browser behaviour (whether is it be a bug or not).
>
> Does it?
Yes it does.
> Maybe it simply pre-supposes the library author
> is *more* familiar than the user of the library.
If the problem is "not having a long enough history working with
browsers to know about particular bugs" then using code written by
someone else who may have a longer experience but still does not have a
"long enough history" cannot solve that problem. It may represent
abdicating responsibility for the problem, which may be perceived as
sufficient, but that does not change the outcome.
> There are no perfect solutions here,
That depends what the issues are. There are certainly some complete
solutions to these types of issues.
> so we're left with choosing the least imperfect.
If none of these issues had ever been solved, or nobody had ever managed
to create a genuinely cross-browser script then it certainly would by
now be acceptable to always give up the attempt. However, some perfect,
or near perfect, solutions have been demonstrated possible, so defeatism
is not indicated here.
> Every "build vs. buy" decision involves pros/cons that
> must be evaluated. In my case, although I enjoy the
> JavaScript language, I need to spend the majority of my
> time on server-side development, so I don't have the time
> to work out all the browser portability issues, etc. If a
> library does a "good enough" job, then it could save
> valuable time.
The "saves valuable time" argument gets made from time to time, but it
often does not hold water because for any given library there is still a
need to spend time learning how to use the library. And since no single
library can achieve applicability for all contexts without being both
ridiculously bloated and every over the top for most of those contexts
it then becomes necessary to spend time learning how to use many
libraries.
The advantage of spending the same time learning how to address the
issues of browser scripting for yourself is that anything learnt in the
process is generally knowledge that can be applied to all situations,
while learning how to use any single library is worthless knowledge as
soon as that library proves insufficient or inappropriate for any task.
> If the detractors of current mainstream JavaScript libraries
> would produce better libraries, that would be beneficial,
Beneficial to who?
> but I expect than any libraries put forth as an example on
> this forum would get picked apart like all the rest.
Code posted to this newsgroup only gets "picked apart" if it can be
picked apart. And having your own code "picked apart" is an extremely
efficient way of learning to write better code.
> I doubt you're unaware of these issues, so I'm curious why
> you asked the question, "What are the "disadvantages" of
> writing everything yourself?"
I asked the question to see if it would be answered at all, and if
answered to see how coherent the answer would be. Experience here shows
me that many assertions get made as if they were self-evident facts, but
that not all of them are and some of the individuals making the
assertions haven't even thought about what they are saying to the point
of being able to coherently express the reasoning behind their
assertions. This situation is best exposed by asking the questions and
then observing the lack of answers.
Richard.
Richard Cornford
> On Oct 14, 6:53 pm, Richard Cornford wrote:
>> Peter Michaux wrote:
>>> Richard Cornford wrote:
>>>> On Oct 1, 5:07 pm, Brian Adkins wrote:
>>
>>>>> Could it be that people are simply doing their best
>>>>> to try and find a library that is the lesser of
>>>>> evils to avoid the disadvantages of writing
>>>>> everything themselves?
>>
>>>> What are the "disadvantages" of writing everything
>>>> yourself?
>>
>>> Not accounting for certain browser bugs/incompatibilities
>>> due to not having a long enough history working with
>>> browsers to know about particular bugs. Testing would
>>> show the bugs but testing in currently rare browsers
>>> (eg. IE4, Sunrise, Lobo) may not be considered a wise
>>> cost by the business. Using a prepackaged library that
>>> already works in all cases would be much cheaper and
>>> more attractive to a project manager even with a
>>> certain amount of increased download time. Project
>>> timelines and idealism clash on occasion.
>>
>> That pre-supposes that the 'prepackaged library' was
>> written by someone familiar with this type of historical
>> browser behaviour (whether is it be a bug or not).
>
> Does it?
Yes it does.
> Maybe it simply pre-supposes the library author
> is *more* familiar than the user of the library.
If the problem is "not having a long enough history working with
browsers to know about particular bugs" then using code written by
someone else who may have a longer experience but still does not have a
"long enough history" cannot solve that problem. It may represent
abdicating responsibility for the problem, which may be perceived as
sufficient, but that does not change the outcome.
> There are no perfect solutions here,
That depends what the issues are. There are certainly some complete
solutions to these types of issues.
> so we're left with choosing the least imperfect.
If none of these issues had ever been solved, or nobody had ever managed
to create a genuinely cross-browser script then it certainly would by
now be acceptable to always give up the attempt. However, some perfect,
or near perfect, solutions have been demonstrated possible, so defeatism
is not indicated here.
> Every "build vs. buy" decision involves pros/cons that
> must be evaluated. In my case, although I enjoy the
> JavaScript language, I need to spend the majority of my
> time on server-side development, so I don't have the time
> to work out all the browser portability issues, etc. If a
> library does a "good enough" job, then it could save
> valuable time.
The "saves valuable time" argument gets made from time to time, but it
often does not hold water because for any given library there is still a
need to spend time learning how to use the library. And since no single
library can achieve applicability for all contexts without being both
ridiculously bloated and every over the top for most of those contexts
it then becomes necessary to spend time learning how to use many
libraries.
The advantage of spending the same time learning how to address the
issues of browser scripting for yourself is that anything learnt in the
process is generally knowledge that can be applied to all situations,
while learning how to use any single library is worthless knowledge as
soon as that library proves insufficient or inappropriate for any task.
> If the detractors of current mainstream JavaScript libraries
> would produce better libraries, that would be beneficial,
Beneficial to who?
> but I expect than any libraries put forth as an example on
> this forum would get picked apart like all the rest.
Code posted to this newsgroup only gets "picked apart" if it can be
picked apart. And having your own code "picked apart" is an extremely
efficient way of learning to write better code.
> I doubt you're unaware of these issues, so I'm curious why
> you asked the question, "What are the "disadvantages" of
> writing everything yourself?"
I asked the question to see if it would be answered at all, and if
answered to see how coherent the answer would be. Experience here shows
me that many assertions get made as if they were self-evident facts, but
that not all of them are and some of the individuals making the
assertions haven't even thought about what they are saying to the point
of being able to coherently express the reasoning behind their
assertions. This situation is best exposed by asking the questions and
then observing the lack of answers.
Richard.
Richard Cornford
> On Oct 14, 6:53 pm, Richard Cornford wrote:
>> Peter Michaux wrote:
>>> Richard Cornford wrote:
>>>> On Oct 1, 5:07 pm, Brian Adkins wrote:
>>
>>>>> Could it be that people are simply doing their best
>>>>> to try and find a library that is the lesser of
>>>>> evils to avoid the disadvantages of writing
>>>>> everything themselves?
>>
>>>> What are the "disadvantages" of writing everything
>>>> yourself?
>>
>>> Not accounting for certain browser bugs/incompatibilities
>>> due to not having a long enough history working with
>>> browsers to know about particular bugs. Testing would
>>> show the bugs but testing in currently rare browsers
>>> (eg. IE4, Sunrise, Lobo) may not be considered a wise
>>> cost by the business. Using a prepackaged library that
>>> already works in all cases would be much cheaper and
>>> more attractive to a project manager even with a
>>> certain amount of increased download time. Project
>>> timelines and idealism clash on occasion.
>>
>> That pre-supposes that the 'prepackaged library' was
>> written by someone familiar with this type of historical
>> browser behaviour (whether is it be a bug or not).
>
> Does it?
Yes it does.
> Maybe it simply pre-supposes the library author
> is *more* familiar than the user of the library.
If the problem is "not having a long enough history working with
browsers to know about particular bugs" then using code written by
someone else who may have a longer experience but still does not have a
"long enough history" cannot solve that problem. It may represent
abdicating responsibility for the problem, which may be perceived as
sufficient, but that does not change the outcome.
> There are no perfect solutions here,
That depends what the issues are. There are certainly some complete
solutions to these types of issues.
> so we're left with choosing the least imperfect.
If none of these issues had ever been solved, or nobody had ever managed
to create a genuinely cross-browser script then it certainly would by
now be acceptable to always give up the attempt. However, some perfect,
or near perfect, solutions have been demonstrated possible, so defeatism
is not indicated here.
> Every "build vs. buy" decision involves pros/cons that
> must be evaluated. In my case, although I enjoy the
> JavaScript language, I need to spend the majority of my
> time on server-side development, so I don't have the time
> to work out all the browser portability issues, etc. If a
> library does a "good enough" job, then it could save
> valuable time.
The "saves valuable time" argument gets made from time to time, but it
often does not hold water because for any given library there is still a
need to spend time learning how to use the library. And since no single
library can achieve applicability for all contexts without being both
ridiculously bloated and every over the top for most of those contexts
it then becomes necessary to spend time learning how to use many
libraries.
The advantage of spending the same time learning how to address the
issues of browser scripting for yourself is that anything learnt in the
process is generally knowledge that can be applied to all situations,
while learning how to use any single library is worthless knowledge as
soon as that library proves insufficient or inappropriate for any task.
> If the detractors of current mainstream JavaScript libraries
> would produce better libraries, that would be beneficial,
Beneficial to who?
> but I expect than any libraries put forth as an example on
> this forum would get picked apart like all the rest.
Code posted to this newsgroup only gets "picked apart" if it can be
picked apart. And having your own code "picked apart" is an extremely
efficient way of learning to write better code.
> I doubt you're unaware of these issues, so I'm curious why
> you asked the question, "What are the "disadvantages" of
> writing everything yourself?"
I asked the question to see if it would be answered at all, and if
answered to see how coherent the answer would be. Experience here shows
me that many assertions get made as if they were self-evident facts, but
that not all of them are and some of the individuals making the
assertions haven't even thought about what they are saying to the point
of being able to coherently express the reasoning behind their
assertions. This situation is best exposed by asking the questions and
then observing the lack of answers.
Richard.
Brian Adkins
wrote:
> Brian Adkins wrote:
> >
> If none of these issues had ever been solved, or nobody had ever managed
> to create a genuinely cross-browser script then it certainly would by
> now be acceptable to always give up the attempt. However, some perfect,
> or near perfect, solutions have been demonstrated possible, so defeatism
> is not indicated here.
That's good news. Are you aware if this cross-browser JavaScript
knowledge been consolidated and captured somewhere?
> > Every "build vs. buy" decision involves pros/cons that
> > must be evaluated. In my case, although I enjoy the
> > JavaScript language, I need to spend the majority of my
> > time on server-side development, so I don't have the time
> > to work out all the browser portability issues, etc. If a
> > library does a "good enough" job, then it could save
> > valuable time.
>
> The "saves valuable time" argument gets made from time to time, but it
> often does not hold water because for any given library there is still a
> need to spend time learning how to use the library. And since no single
> library can achieve applicability for all contexts without being both
> ridiculously bloated and every over the top for most of those contexts
> it then becomes necessary to spend time learning how to use many
> libraries.
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".
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. Do you think that comes from the constraints of using
libraries in JavaScript, or is there another factor I'm missing?
David Mark
What makes you think you have learned how to use Prototype? The only
way to learn it is to read the code and the only thing you can learn
from that is that it is a bad idea to rely on it.
>
> 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
The attitude is "don't rely on the incompetent output of those who
don't understand browser scripting."
> this newsgroup. Do you think that comes from the constraints of using
> libraries in JavaScript, or is there another factor I'm missing?
You should have said "the constraints of generalized open source
libraries."
What you are missing is that the "million monkey" approach does not
work for JavaScript libraries. This is especially true once a
severely flawed library (e.g. Prototype) achieves widespread use.
Proposals for even minor changes are debated to death and ultimately
dismissed due to paranoia about breaking existing workarounds on
thousands of sites.
If you must use Prototype or the like, you will have to deal with the
consequences sooner or later. There is no point in seeking
affirmation of your delusional decision here.
Richard Cornford
> On Oct 27, 6:28 pm, Richard Cornford wrote:
>> Brian Adkins wrote:
>> If none of these issues had ever been solved, or nobody had
>> ever managed to create a genuinely cross-browser script then
>> it certainly would by now be acceptable to always give up the
>> attempt. However, some perfect, or near perfect, solutions
>> have been demonstrated possible, so defeatism is not
>> indicated here.
>
> 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.
>>> Every "build vs. buy" decision involves pros/cons that
>>> must be evaluated. In my case, although I enjoy the
>>> JavaScript language, I need to spend the majority of my
>>> time on server-side development, so I don't have the time
>>> to work out all the browser portability issues, etc. If a
>>> library does a "good enough" job, then it could save
>>> valuable time.
>>
>> The "saves valuable time" argument gets made from time to time,
>> but it often does not hold water because for any given library
>> there is still a need to spend time learning how to use the
>> library. And since no single library can achieve applicability
>> for all contexts without being both ridiculously bloated and
>> every over the top for most of those contexts it then becomes
>> necessary to spend time learning how to use many libraries.
>
> 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
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, 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
> On Oct 28, 1:40 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> 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, then I'd say it's
> neither captured nor consolidated. I feel you're being purposely
> obtuse here.
Possession does not imply distribution.
>
> > ... 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:
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
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
> Thomas 'PointedEars' Lahn wrote:
> > 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. :-)
--
Rob
Brian Adkins
> On Oct 28, 4:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Oct 28, 6:40 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > > 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.
>
> If "publicly available JavaScript library" means something big like
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:
Peter Michaux
> On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 28, 4:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Oct 28, 6:40 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > > > 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.
>
> > 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.
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
> On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 28, 4:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Oct 28, 6:40 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > > > 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.
>
> > 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
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
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
> On Oct 28, 9:36 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > 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.
>
> 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
> On Oct 29, 12:36 am, Brian Adkins <lojicdot...@gmail.com> wrote:
> > On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > On Oct 28, 4:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > On Oct 28, 6:40 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > > > > 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.
>
> > > 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
>
> 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.
> > 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?
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.
> > 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.
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
> On Oct 29, 7:46 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 29, 12:36 am, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > On Oct 28, 4:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
> > > > > On Oct 28, 6:40 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > > > > > 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.
>
> > > > 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
>
> > 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
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.
>
> > > libraries that were both "publicly available" and "worthwhile to use".
Use for what?
> > > 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 seem to be programmed for failure.
>
> > 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
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.
>
> > > 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.
>
> 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
> On Oct 29, 1:05 am, Peter Michaux <petermich...@gmail.com> wrote:
>
> > On Oct 28, 9:36 pm, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > 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.
>
> > 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?
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
> On Oct 29, 11:24 am, Brian Adkins <lojicdot...@gmail.com> wrote:
> > On Oct 29, 7:46 am, David Mark <dmark.cins...@gmail.com> wrote:
> > > On Oct 29, 12:36 am, Brian Adkins <lojicdot...@gmail.com> wrote:
> > > > On Oct 28, 10:11 pm, Peter Michaux <petermich...@gmail.com> wrote:
> > > > > 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
>
> > > 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
>
> 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.
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.
> > 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.
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.
> > 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.
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?
> > > 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
>
> 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.
> > 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.
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
> On Oct 29, 10:24 am, Brian Adkins <lojicdot...@gmail.com> wrote:
>
> > 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! :)
[ 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
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
>
> > 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.
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?
> > 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.
> 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.
> > (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 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
You hit your cue perfectly ;)
Richard Cornford
> 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.
Brian Adkins
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.
David Mark
[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.
Matt Kruse
> 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
David Mark
> On Oct 30, 9:40 am, David Mark <dmark.cins...@gmail.com> 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?
Matt Kruse
> > 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
David Mark
> On Oct 30, 12:45 pm, David Mark <dmark.cins...@gmail.com> 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.
Richard Cornford
> 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.
Brian Adkins
wrote:
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