Javascript Best Practices Document v1.0

[Randy Webb]

Re: Javascript Best Practices Document v1.0

Gérard Talbot said the following on 10/14/2005 11:10 PM:
[color=blue]
> Gérard Talbot a écrit :[color=green]
>> Randy Webb a écrit :
>> You[/color]
> I'm sorry Randy. Somehow, I thought I was replying to Matt K.[/color]

No problem.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly

[Michael Winter]

Re: Javascript Best Practices Document v1.0

On 14/10/2005 22:00, Matt Kruse wrote:

[snip]
[color=blue]
> [Using TABLE elements for layout] certainly was a huge step in moving
> the web towards more where it is today.[/color]

That's debatable. The idea of style sheets occurred quite early on, but
early proposals didn't concentrate on layout. It would actually appear
that layout tables moved the Web away from the direction that is being
taken today.

I doubt that anyone could truly predict what would have happened if both
style sheets had become layout-oriented and tables were semantic from
the outset. The Web may never had had to endure the abominations that
were published, and still are (to an extent).

Anyway, this is a topic for another group.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Michael Winter]

Re: Javascript Best Practices Document v1.0

On 15/10/2005 03:15, Gérard Talbot wrote:

[snip]
[color=blue]
> I personally hate using document.write( ), even with a defer attribute
> [...][/color]

If you're using the write method, then should never use the defer attribute.

[snip]
[color=blue]
> If your goal is to support modern browsers [...], then why do you
> need to detect the support for getElementById ?[/color]

Because not directly supporting browsers doesn't mean generating errors
in them, especially when those errors can be avoided. Doing otherwise
makes the author look amateurish - that they didn't know what they were
doing.

[snip]
[color=blue]
> IMO, if an user visits a webpage that has/uses DHTML with MSIE 4,
> then he should be told to upgrade, period.[/color]

Telling a user to upgrade is hardly a reasonable thing for a Web
developer to be doing. That's similar to thinking that one can tell a
user to enable client-side scripting; the user must be backwards if they
don't.

[snip]
[color=blue]
> If I (or anyone) do not see a single reason as to resort to
> document.all [...][/color]

I already gave one, and it had nothing to do with IE4.

[snip]
[color=blue][color=green]
>> If the page error's any time before the onload fires, then the user
>> doesn't get the button even though scripting is enabled.[/color]
>
> We're already talking about an exception here. I have assumed that
> the page is correctly and properly coded (markup code, CSS code, JS
> code) [...][/color]

"Proper coding" doesn't stop a browser from erroring out if one tries to
use a method or object that doesn't exist unless feature detection is
considered to be part of "proper coding".

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Dr John Stockton]

Re: Javascript Best Practices Document v1.0

JRS: In article <SzlSvQCTv$TDFw +1@jgharris.dem on.co.uk>, dated Fri, 14
Oct 2005 19:41:23, seen in news:comp.lang. javascript, John G Harris
<john@nospam.de mon.co.uk> posted :[color=blue]
>In article <TFyo9qDtZsTDFw Nu@merlyn.demon .co.uk>, Dr John Stockton
><jrs@merlyn.de mon.co.uk> writes[color=green]
>>JRS: In article <3r5kl8Fhsi2sU1 @uni-berlin.de>, dated Wed, 12 Oct 2005
>>19:30:42, seen in news:comp.lang. javascript, Gérard Talbot
>><newsblahgrou p@gtalbot.org> posted :[/color]
>
> <snip>[color=green][color=darkred]
>>>IMO, tricks based on + and -0 can not be the best recommendable way to
>>>convert a string to a number. parseInt or parseFloat should be used instead.[/color]
>>
>>Then you are wrong; and sentences should start with a capital letter.[/color]
> <snip>
>
>Not funny. This newsgroup is read by beginners; we mustn't trick them
>into writing ParseInt (with a capital P).[/color]

Agreed. The solution is to recast the sentence so that parseInt does
not come first. Putting "Function " before it is generally
satisfactory.

[color=blue]
>mW powers your torch.
>MW melts scrap metal.[/color]

Neither makes a good start for a sentence.

--
© John Stockton, Surrey, UK. ???@merlyn.demo n.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demo n.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[Gérard Talbot]

Re: Javascript Best Practices Document v1.0

Michael Winter a écrit :[color=blue]
> On 15/10/2005 03:15, Gérard Talbot wrote:
>[color=green]
>> If your goal is to support modern browsers [...], then why do you
>> need to detect the support for getElementById ?[/color]
>
> Because not directly supporting browsers doesn't mean generating errors
> in them, especially when those errors can be avoided. Doing otherwise
> makes the author look amateurish - that they didn't know what they were
> doing.[/color]

I think you don't understand what I mean. Anyway, I'm tired of repeating
myself, explaining myself and providing examples, etc.
[color=blue][color=green]
>> IMO, if an user visits a webpage that has/uses DHTML with MSIE 4,
>> then he should be told to upgrade, period.[/color]
>
>
> Telling a user to upgrade is hardly a reasonable thing for a Web
> developer to be doing. That's similar to thinking that one can tell a
> user to enable client-side scripting; the user must be backwards if they
> don't.
>
> [snip]
>[/color]

Well, I def. disagree. I know I'm not the only one thinking that IE 4
and NS 4 users should be invited to upgrade.
webstandards.or g Browser upgrade campain some years ago
browserhappy campain
alternate browser campain
modern browser campain
2 years ago, Netscape DevEdge had

http://devedge-temp.mozilla.org/upgrade.html

not to mention microsoft itself which dropped support for IE 4 many
years ago.
Even my own ISP told me they invite their users to upgrade and help IE 4
and NS 4 users to upgrade to recent browser versions.
Comparing enabling client-side script with conforting and encouraging
tacitly to continue to use IE4 is a big stretch and a very debatable
comparison.
[color=blue][color=green]
>> If I (or anyone) do not see a single reason as to resort to
>> document.all [...][/color]
>
>
> I already gave one, and it had nothing to do with IE4.
>
> [snip]
>[/color]

I've never had to use getElementsByTa gName() myself before or ... maybe
once I did. I certainly never used getElementsByTa gName("*").
There are also and already many other DOM 1 methods returning a
collection of nodes or a named list.
document.links
document.anchor s
document.images
document.forms
objTable.rows
objTableRow.cel ls
objSelect.optio ns
elements
etc.

document.all is mostly used in webpages (and seen in webpages as) to
access single nodes.
So I still do not see a single reason to resort to document.all.
But Matt K.'s document provides explanations on how to maintain its
usage, specifically for IE 4 users.
"
# Only fall back to using document.all as a last resort
# Only use it if you need to support IE versions earlier than 5.0
"

Gérard
--
remove blah to email me

[Gérard Talbot]

Re: Javascript Best Practices Document v1.0

Randy Webb a écrit :[color=blue]
> Gérard Talbot said the following on 10/14/2005 10:15 PM:
>[color=green]
>> Randy Webb a écrit :
>>[/color]
>
> That depends on how the <a> is coded.
>
> <a href="somePage. html" onclick="return someFunction()" >Some Page</a>
>
> If the function someFunction() either displays the contents of
> somePage.html in the current window, opens a new window, or toggles
> display on a div tag that contains the data in somePage.html[/color]

I am not sure I understand that part: "toggles display on a div tag that
contains the data in somePage.html"

Wouldn't an <iframe src="foo.html" ...> or <object data="foo.html"
type="text/html" ...> be semantically better?

I believe the part of the document titled "Using onClick in <A> tags" is
a bit abstract and would benefit from having a concrete example or some
references.

then if JS[color=blue]
> is disabled the end user still gets the same content, but via a
> different mechanism.
>
> And when an a tag is used to invoke a function, and it is coded
> correctly, then it degrades gracefully in the absence of JS.
>
> How is that bad coding?[/color]

I don't know. I can't say. It depends. I see no full page example. No
concrete code. No url. Just doSomething(). Or someFunction(). And a
general description.

Gérard
--
remove blah to email me

[Gérard Talbot]

Re: Javascript Best Practices Document v1.0

Randy Webb a écrit :[color=blue]
> Gérard Talbot said the following on 10/14/2005 10:15 PM:
>[color=green]
>> Randy Webb a écrit :
>>[/color][/color]

[color=blue][color=green]
>> I replied a code to the situation where JS was disabled. Basically the
>> same code could have been provided for a badly semantically coded <a>
>> link (instead of a <button>).[/color]
>
>
> That depends on how the <a> is coded.
>
> <a href="somePage. html" onclick="return someFunction()" >Some Page</a>
>
> If the function someFunction() either displays the contents of
> somePage.html in the current window, opens a new window, or toggles
> display on a div tag that contains the data in somePage.html then if JS
> is disabled the end user still gets the same content, but via a
> different mechanism.
>
> And when an a tag is used to invoke a function, and it is coded
> correctly, then it degrades gracefully in the absence of JS.
>
> How is that bad coding?[/color]

It's kinda difficult to maintain a long discussion on several sharp
topics while having doSomething() function and long reading to do. IMO,
a full-page example would certainly bring some light, would refresh this
long thread.

[color=blue][color=green]
>> In this thread, I believe I've tried to bring up chunks of code,
>> references, more complete examples trying to substantiate my claims.[/color]
>
>
> And I have presented my thoughts and nothing more.
>[color=green]
>> (1) Some refer to browsers/browser versions released after 2001. Some
>> others refer to 5th generation browsers. Some others to browsers being
>> js-capable of modifying its DOM tree. In all cases, MSIE 4 does not
>> meet any of the above conditions.[/color]
>
>
> If a "modern browser" is a "5th Generation Browser" then where does that
> leave Firefox 1.0.xx?
>
> "5th Generation Browser" is as ambiguous a term as "modern browser".
>[/color]

I agree with you that such expressions would need to be defined explicitly.
[color=blue]
> My goal is to support as many browsers as I can (modern or not) that do
> not require a lot of extra effort. And including a snippet of code that
> allows a lot of JS to be execute in IE4 without a document.all branch in
> every place I want to do something, then I do it. Even if it is just 1%,
> the cost of doing it is neglible. With proper server-side scripting,[/color]

With proper server-side scripting.

it[color=blue]
> is a simple matter of an include statement[/color]

Include statement.

in a template document and[color=blue]
> then the work to accomodate IE4 is zero.[/color]

No real live webpage example.
[color=blue]
> The problem I have with IE4 support now is not with document.all itself.
> When I gave the URL to the emulation that is in the FAQ it was not as
> outdated as it is now. To /properly/ support IE4 now with the gEBI
> emulation,[/color]

gEBI emulation. No code. No url. No concrete reference.

you would have to prototype everything that a gEBI browser[color=blue]
> supports that IE4 doesn't. It is *that* requirement that makes IE4 not
> worth supporting.[/color]

Anyway. Whatever. I promise never to get into a discussion on supporting
IE4 ever again.

Gérard
--
remove blah to email me

[Gérard Talbot]

Re: Javascript Best Practices Document v1.0

Michael Winter a écrit :[color=blue]
> On 14/10/2005 21:13, Gérard Talbot wrote:
>
> [snip]
>[color=green]
>> <form name="myform" action="[url]">
>> <p><input type="text" name="val1" value="1">
>> <input type="text" name="val2" value="2"></p>
>> </form>
>>
>> will not trigger a validation error.[/color]
>
>
> True, but since when have INPUT elements been part of a paragraph? A DIV
> or FIELDSET element is more appropriate.
>
> Mike
>[/color]

This semantic issue all depends on your whole page design actually. How
many inputs you have. How are they organized. etc.. A page division
might be better. A paragraph might be correct. Or sufficient. It all
depends on the whole page. A fieldset is certainly ok too.

Now, let's try to find an example somewhere.

<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
First name: <INPUT type="text" name="firstname "><BR>
Last name: <INPUT type="text" name="lastname" ><BR>
email: <INPUT type="text" name="email"><B R>
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</P>
</FORM>

or maybe better

<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
<LABEL for="firstname" >First name: </LABEL>
<INPUT type="text" id="firstname"> <BR>
<LABEL for="lastname"> Last name: </LABEL>
<INPUT type="text" id="lastname">< BR>
<LABEL for="email">ema il: </LABEL>
<INPUT type="text" id="email"><BR >
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</P>
</FORM>

or even

<FORM action="http://server.dom/cgi/handle"
enctype="multip art/form-data"
method="post">
<P>
What is your name? <INPUT type="text" name="name_of_s ender">
What files are you sending? <INPUT type="file" name="name_of_f iles">
</P>
</FORM>

and what about

<FORM action="http://somesite.com/prog/adduser" method="post">
<P>
First name: <INPUT type="text" name="firstname "><BR>
Last name: <INPUT type="text" name="lastname" ><BR>
email: <INPUT type="text" name="email"><B R>
<INPUT type="radio" name="sex" value="Male"> Male<BR>
<INPUT type="radio" name="sex" value="Female"> Female<BR>
<BUTTON name="submit" value="submit" type="submit">
Send<IMG src="/icons/wow.gif" alt="wow"></BUTTON>
<BUTTON name="reset" type="reset">
Reset<IMG src="/icons/oops.gif" alt="oops"></BUTTON>
</P>
</FORM>

These examples all come from the HTML 4.01 specification.

Gérard
--
remove blah to email me

[Michael Winter]

Re: Javascript Best Practices Document v1.0

On 15/10/2005 22:08, Gérard Talbot wrote:

[Paragraphs in forms]
[color=blue]
> This semantic issue all depends on your whole page design actually.[/color]

It depends upon what's inside the paragraph. If an INPUT element is
actually part of a paragraph of text, then fine, "but since when have
INPUT elements been part of a paragraph?"

[snip]
[color=blue]
> These examples all come from the HTML 4.01 specification.[/color]

The document also contains:

<FORM action="..." method="post">
<P>
<INPUT type="button" value="Click Me" onclick="verify ()">
</FORM>

and there's no way that you can say a single button with the text,
"Click Me", constitutes a paragraph.

In fact, I'm convinced that they simply followed all of their FORM
opening tags with paragraphs for simplicity. Even the FIELDSET example
includes one:

<FORM action="..." method="post">
<P>
<FIELDSET>
<LEGEND>Persona l Information</LEGEND>

despite the fact that the paragraph is superfluous, and would be
immediately closed and empty (something the specification recommends
against doing).

The examples in the specification are just examples and they are not
perfect.

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Michael Winter]

Re: Javascript Best Practices Document v1.0

On 15/10/2005 21:19, Gérard Talbot wrote:
[color=blue]
> Michael Winter a écrit :[/color]

[snip]
[color=blue][color=green]
>> Telling a user to upgrade is hardly a reasonable thing for a Web
>> developer to be doing. That's similar to thinking that one can tell
>> a user to enable client-side scripting; the user must be backwards
>> if they don't.[/color]
>
> Well, I def. disagree. I know I'm not the only one thinking that IE 4
> and NS 4 users should be invited to upgrade.[/color]

Whether a user should upgrade or not is irrelevant. It isn't your place,
nor any other developer's, to make an issue of it.

Given that any critical system should be functional with any browser
that implements HTML and HTTP reasonably well, it shouldn't matter
whether users do use something antiquated like IE4. The script won't
execute, won't cause any errors, and will gracefully degrade back to
support provided by the server (if necessary), just like users that have
scripting disabled entirely.

I can only think of two reasons why people still use NN4 and the like.

1) They made a concious choice to use an old browser.
2) They have no option but to use an old browser.

That a user would be unaware /many/ years later that there are new
versions is very unlikely.

In either of the two cases above, telling the user to upgrade is futile,
and arrogant at best; insulting at worst.

[snip]
[color=blue]
> I've never had to use getElementsByTa gName() myself before or ...
> maybe once I did. I certainly never used getElementsByTa gName("*").[/color]

What's your point?

[snip]
[color=blue]
> document.all is mostly used in webpages (and seen in webpages as) to
> access single nodes.[/color]

And most of these scripts will be badly written. When did I write that
the all collection /should/ be used to access single nodes?
[color=blue]
> So I still do not see a single reason to resort to document.all.[/color]

Evidentially.

[snip]

Mike

--
Michael Winter
Prefix subject with [News] before replying by e-mail.

[Richard Cornford]

Re: Javascript Best Practices Document v1.0

Matt Kruse wrote:[color=blue]
> Richard Cornford wrote:[/color]
<snip>[color=blue]
> In my experience with many web developers, Javascript
> is this piece-of-crap scripting language that they have
> to deal with and struggle with.[/color]

As soon someone accepts that they have to deal with javascript (and they
don't have to deal with it if they don't want to) then they are
accepting that their best interests lie in understanding how to use it.
And people who find themselves having to "struggle with" it have the
choice of learning what they are doing, and only struggling with the
code design issues they would have to address in any programming
context, or they can remain ignorant and continue to struggle with
javascript itself. The latter choice is self-inflicted and does not
deserve any sympathy.
[color=blue]
> It gets in the way of what they want to do, but they
> have to use it.[/color]

How can it "get in the way of what they want to do"? It is either
facilitating what they want to do or they don't need to use it at all.
[color=blue]
> Many have no interest in learning the language or its
> quirks, nor do they want to spend hours learning best
> practices of FAQs.[/color]

And that is an attitude appropriate for anyone who never has to use
javascript at all. Anyone expecting the be paid for using javascript is
seriously misguided if they believe they should not be expected to
understand what they are doing.
[color=blue]
> My approach is to cater to those people and others who
> have no interest in becoming javascript experts. I realize
> and accept that they will not read the FAQ or a book on
> the topic, nor will they experiment with browser quirks or
> other js-related topics. The question is, if you're working
> with these people, do you continue to let them make common
> easily-corrected mistakes, or do you identify the "low
> hanging fruit" and help them fix the most common problems
> quickly and easily, so you can at least get some immediate
> benefit?[/color]

I work with lots of web developers who don't understand javascript, are
not interested in learning it and will not be reading books or FAQs on
the subject. We deal with that situation by never asking them write
javascript, but instead to use the technologies (server-side and
database) that they do know how to use.
[color=blue]
> Do you tell them to 'write their own' calendar popups
> and tree structures because they need to know the
> inner-workings, only to see that their end result is
> horrible and goes into production because of the
> deadline?[/color]

If a project needs something like a date picker, and it does not already
exist, then the task goes to a javascript programmer. And a javascript
programmer who cannot already write a date picker for themselves is not
going to be offered a job with us.
[color=blue]
> Or do you offer a generalized library that might have
> some 'bloat' but accomplishes the task way better than
> they would have written themselves?[/color]

As it happens there was a requirement to add a date picker to the
client-side code for the web application that I am currently working on,
and I was given the task of writing it. And because I am writing in a
system that employs a layered design based on self-contained low level
components and already contains reliable and well tested components for
all of the GUI and date manipulation required by a date picker the task
only involved writing about 150 line of date picker specific logic
(about 3k, fully formatted and commented).
[color=blue]
> Not everyone wants to be a javascript expert. You do.
> That's nice. But don't pigeon-hole everyone into your
> mindset.[/color]

I am not asking anyone to write javascript if they don't want to, all I
am doing is proposing that people who do write javascript will benefit
from understanding what they are doing. And, to some extent, promoting
that understanding.
[color=blue][color=green]
>> What you characterise as a "little extra" code bloat
>> is not necessarily that little. Every time one of your
>> libraries satisfies a demand for a less common facility
>> you increase the download for everyone who has no use
>> or interest in that facility.[/color]
>
> The point is - who cares?[/color]

Everyone cares, to the extent that everyone wants everything to be
delivered as soon as they want it.
[color=blue]
> If it's an extra 5k or even 10k, that is
> often way over-shadowed by graphics sizes, flash, etc.[/color]

Graphics can be a considerable source of needless bloat on the web. My
observations of web graphics have revealed common graphic bloat of up to
a factor of 60, with a factor of 10 being normal. Again this is a
consequence of people not really understanding what they are doing,
though in this case the culprits tend to be designers rather than
programmers.

We have HTML bloat, we have graphic bloat and we have script bloat. It
is the script authors who are responsible for the script bloat, and
falling down in that area is not justified by others falling down in
their area.
[color=blue]
> If your goal is to create tight, compact pages, then
> fine - don't use libs. But that is _NOT_ a requirement
> for most people.[/color]

Have you ever heard someone saying "it works fine but we would rather it
was a bit slower"? It doesn't happen. If there is a quibble about
performance the problem is always that something is not fast enough. It
may never be an explicitly stated requirement that a software product be
sufficiently fast but that expectation is implied anyway.
[color=blue]
> The convenience of using a lib with a little code bloat
> is more important than the extra few k of text that is
> downloaded.[/color]

Convenience? Do you imagine that it was not convenient for me to be able
to add a date picker to a system with no more than 150 lines of code?
Convenience without the bloat.
[color=blue][color=green]
>> And every time more than one library is used the
>> odds are good that entire chunks of more or less
>> identical functionality are being reproduced in
>> each one.[/color]
>
> Not if used correctly.[/color]

Very funny. You declare that you are in the business of catering for an
"average web developer" who does not know enough to decide what sort of
property accessor they should be using and then expect them to satisfy
some criteria of "use correctly" when deploying libraries that they have
chosen to use in order to avoid learning how to understand the code they
contain. You don't get to have it both ways, if they are incapable of
doing any more than stuffing a complete library file into a page then
they can only add facilities by stuffing another complete library file
into a page. And so there will be considerable redundancy in the
totality of the resulting code.

But what do you imagine "correctly" would be? Dissecting the libraries
to identify the commonalties behind then and then re-writing either or
both libraries so that they can each use the same code for any specific
requirement they share? That certainly is not going to be practical
without an understanding of javascript, and if "used correctly" implies
removing common features of multiple libraries and re-writing them as
lower level components that can be shared between the libraries then
doesn't it now make more sense to approach code re-use in the way I have
been suggesting and build the final script up form low level components
designed to be shared by all code that requires their facilities?
[color=blue][color=green][color=darkred]
>>> Yet I benefitted by being able to deliver more
>>> advanced functionality in a shorter timeline.[/color]
>> And the relevance of Java authoring to browser scripting is?[/color]
>
> Same concept, different language/environment.[/color]

And it is the difference between the language and environments that
modifies the appropriateness of the concept.
[color=blue]
> Develop a solution to a general problem and package
> it up with an interface. People can then use your
> solution to the problem in their work, even if your
> solution contains much more functionality than they
> actually need.[/color]

While in javascript you can address a general problem while forcing the
download of much redundant code to support unwanted functionality you
can also address the specific problem in the real context and do nothing
else, and you can employ re-useable code in doing so.
[color=blue][color=green]
>> Without a vested interest my expectation would be that
>> individuals would be interested in identifying the best
>> possible approaches towards achieving their goals. And
>> willing to engage in, and be swayed by, reasoned debate
>> about the possible approaches, even to experiment with
>> the possibilities to better assess their relative merits.[/color]
>
> I'd say that I definitely fall into that categorization.[/color]

That is not apparent in your words or actions. If you had, for example,
experimented with designs based on low-level re-usable self-contained
components providing consistent interfaces to various aspects of web
browser environments you would either have realised that they are a
fast, convenient and efficient approach to browser scripting, or you
would have found some tangible reason for not using them and would not
have to keep supporting your maintaining your status quo with appeals to
the stupidity of the "average web developer".
[color=blue][color=green]
>> The point of providing a justification for any
>> recommendation is precisely so that the reader can
>> disagree with the recommendation.[/color]
>
> The target audience for my recommendations (which should
> be clear by the content) are generally people who may not
> even have enough knowledge to decide for themselves whether
> the justification is reasonable or not.[/color]

Your vision of a world of web developers who are incapable of
comprehending reasoned argument is extremely depressing. Are things
really that bad in the United States? How does anyone mange to decide
anything?

I just don't see it though. I have encountered many web developers for
whom idleness and/or arrogance get in the way of their learning anything
new, but I have never encountered one for whom the lack of intelligence
was the problem. On the whole web developers, even web designers, seem
to be of above average intelligence. If I didn't believe that I would
not spend so much of my time explaining how things work to them.
[color=blue]
> Or they may not even care. They just want their stuff to
> work.[/color]

Isn't it obvious that just wanting ones stuff to work will never be
enough, on its own, to get ones stuff to work?
[color=blue][color=green]
>> A "developer who doesn't know enough to decide for
>> themselves" which type of property accessor to use
>> in any given context? A vision of web development as
>> a bunch of headless chickens careering about in the
>> dark continuously bumping into each other and bouncing
>> off walls. The pity is that that does appear to describe
>> the reality in some organisations, but it does no good
>> to be pandering to the notion that this would be an
>> acceptable situation.[/color]
>
> It describes the reality in _many_ organizations, and
> _many_ individuals.[/color]

If it is a reality does that make it a good thing?
[color=blue]
> You don't see regularly how many people _DESPISE_
> javascript?[/color]

I do regularly see that, and observe that most of the justifications
that accompany that attitude have nothing to do with javascript as such,
but are the result of what people attempt to do with javascript when
they don't really understand what they are doing.
[color=blue]
> I see absolutely horrible javascript practices so often that
> even suggesting the most basic of 'best practices' would add
> value to many people. And that is my goal.[/color]

You like to talk of "adding value", to people, to web pages, to scripts.
Does it really mean anything or is it just a turn of phrase that just
sounds positive? What is a person to whom "value" has been added? Who
perceives this value, who benefits?

Given that your reader is apparently a heedless chicken, incapable of
comprehending the reason for adopting one of your "Best Practices", and
is doing so apparently on the basis of your authority alone, the change
that represents this added "value" must be nearly negligible. They don't
actually know or understand any more than they did before.
[color=blue][color=green][color=darkred]
>>> On the contrary, I've received great feedback so far from
>>> many others who said they immediately benefitted from it.[/color]
>>
>> Marvellous, you demonstrate utter contempt for the intellectual
>> potential of the "average web developer" and then cite their
>> opinion as in some way significant to an assessment of your
>> page.[/color]
>
> No, my point is, there are many who have a very basic
> understanding of javascript, and a document like this is
> short, practical, and adds immediate value to their development.[/color]

Would that be more or less "value" than would result form them acquiring
a less basic understanding?
[color=blue][color=green]
>> But then you cannot learn javascript in a lunch break, or
>> 24 hours, or a couple of weeks, and expecting to be able
>> to do so is totally unrealistic.[/color]
>
> And yet your expectation is that every web developer in the world
> should devote this much time to learning it and using it correctly.
> That expectation is highly absurd.[/color]

Why? How long did you take learning to write Java? How long would you
expect to spend learning C++, .NET, PHP, CSS and so on. Nothing is
instant, even the designers who hide from the real technologies by using
Dreamweaver should have no expectation of being able to use it well
without at least a few weeks devoted to learning how it works.

It takes time to learn to do things, and cross-browser scripting is
inherently difficult because of the variations in execution
environments, so it cannot be learnt instantly.
[color=blue]
> My point is, people don't have to invest that much time to
> do many of the tasks which they want to accomplish. If all
> they want is a date picker on their page, they can have one
> in 10 minutes. They don't need to spend weeks learning
> Javascript to implement one.[/color]

No, people do not have to spend time learning to write javascript to do
something like that. There are plenty of copy-and-paste script
collections offering scripts that can be stuffed into web pages without
a moment's thought.

The problem with doing that in utter ignorance of the technology being
used is the consequence of doing so. A moments unconsidered
copy-and-paste can transform a fully interoperable system into something
that will only work on one browser, with potentially significant
consequences for the client who is paying them to do this. And then
there are the consequences for things like site maintenance when the
people who are responsible for undertaking that maintenance do not
understand the technologies that they have chosen to use.

So yes people can stuff any script they like into a web page, but when
they do it in ignorance then the odds are good that the are doing a
serious disservice to however is employing them when they do.
[color=blue]
> Yet your 'elitist' approach would say they are not worthy
> of one if they aren't willing to invest the time. That's
> completely unrealistic.[/color]

If an unwillingness to invest time in learning to use a technology
results in inconvenience and extra work for colleagues, unnecessary
expanse for employers and inconvenience to end users then that
unwillingness to learn is a manifestation of unprofessionali sm.
[color=blue][color=green]
>> Late last year I was involved in the process of creating
>> a javascript authoring standards document for the software
>> house for which I work.
>> ...
>> The resulting document is 50 sides of A4 and does no
>> more than lay down rules that will be followed.[/color]
>
> Such a document would be completely worthless to most web
> developers.[/color]

Did I propose that that document would be of any use to most web
developers? The document is intended to make sub-contractors create code
that is consistent with code produced internally. The sub-contractors
either follow the document or they don't get paid, so it doesn't have to
include any justification for the rules it lays down.
[color=blue][color=green]
>> The result is not a screen full of text, it is probably
>> about the size of a largish chapter in a book. So is it
>> surprising that I have not created such a document, given
>> the amount of work involved?[/color]
>
> There is value in partially solving a problem.[/color]

It has become clear in the past that we attach very different meanings
to the words 'solving' and 'solution'. I don't believe that there is
such a thing as a "partial solution", I would regard the creation of
such as resulting in a different problem, and never regard the process
of going from one problem to another as qualifying as a solution.
[color=blue]
> If you can add value in a specific area, even without
> solving the entire problem, that is a good thing.[/color]

The vague addition of "value" again? So; 'it doesn't work, but it
doesn't not work as badly as it did before' is a good thing?
[color=blue]
> A 'Best Practices' document doesn't need to cover
> everything. IMO.[/color]

Maybe, and it is unlikely that anything written by one individual could
cover everything, but the more comprehensive such a document is the more
useful it is likely to be. Of course individual practices, proposed as
qualifying as "best" are often discussed on this group (indeed this very
thread discusses at least two such proposals), so the group's archives
may serve as a resource for researching the subject item by item.
[color=blue][color=green]
>> That is a fundamental difference between us. I will not be satisfied
>> to publish anything less than a document that allows its readers to
>> make informed decisions about the adoption of best practices (and so
>> also make informed decisions about when it might be expedient to
>> disregarded them), and you see your best interests in pandering to a
>> flock of headless chickens.[/color]
>
> I'm realistic. You're idealistic.
> I'm practical. You're a perfectionist.[/color]

That is only a meaningful distinction if the prefect and ideal strategy
towards javascript development for a web browser environment wasn't
realistic and practical. But if not practical and realistic first then
they could never qualify as prefect or ideal. The pursuit of perfection
(even if never achieved, or achievable) produces practical benefits
along the way.
[color=blue]
> I cater to the masses.[/color]

Well, above it read more like 'patronise' but you can call it 'cater' if
you want.
[color=blue]
> You cater to those you deem worthy.[/color]

I 'cater' to the people who pay me. Whatever I make available for free
is on a take it or leave it bases, their choice not mine.
[color=blue]
> I understand the problems of the average developer.[/color]

You have just been telling me that the problem of the average web
developer is apparently that they are incapable of using thought to
direct their actions.
[color=blue]
> You tell them to RTFM.[/color]

Yep, if it is a technical subject RTFM. I have no problem with that.

[Matt Kruse]

Re: Javascript Best Practices Document v1.0

Richard Cornford wrote:[color=blue][color=green]
>> Many have no interest in learning the language or its
>> quirks, nor do they want to spend hours learning best
>> practices of FAQs.[/color]
> And that is an attitude appropriate for anyone who never has to use
> javascript at all. Anyone expecting the be paid for using javascript
> is seriously misguided if they believe they should not be expected to
> understand what they are doing.[/color]

No one can be an expert in everything.

Rather than considering yourself and your job position, consider a one-man
'webmaster' for a small company who must run the web server, the external
web site, the internal intranet, code in HTML and PHP, do some database
work, write some javascript, create some images, etc. Very few people in the
real world would be an expert in all of those areas, or have anywhere close
to enough time to study each area in-depth. For many, the best hope is to
keep things working and _slowly_ advance knowledge in each of those areas.
[color=blue]
> I work with lots of web developers who don't understand javascript,
> are not interested in learning it and will not be reading books or
> FAQs on the subject. We deal with that situation by never asking them
> write javascript, but instead to use the technologies (server-side and
> database) that they do know how to use.[/color]

I'd like to know more about your work environment.
It sounds very different from any that I have worked in or worked with.
[color=blue]
> If a project needs something like a date picker, and it does not
> already exist, then the task goes to a javascript programmer.[/color]

In the places I have worked or worked with, and the people I've known, I've
never yet seen someone who was simply a "javascript programmer". In almost
every case I've witnessed, javascript has been an 'add-on' technology that
web developers are expected to use, but that employers almost never devote
any time or training towards.

Again, I think your current work environment - whatever it is - does not
represent the norm for many, many developers out there. Certainly not for
those developers who aren't even _in_ a work environment.
[color=blue]
> And a
> javascript programmer who cannot already write a date picker for
> themselves is not going to be offered a job with us.[/color]

Good for you. You can be picky. Not every company can.
Hell, many web sites are made by _volunteers_! It could be for their church,
their local charity, their boy scout troop, or whatever. These people may
not even be programmers. If they want some cool javascript functionality on
their site, you would probably tell them "too bad, you can't. You don't know
enough." Whereas I would tell them, "sure, you can do that. Download X and Y
and put Z in your HTML, and it will work."

Whose approach do you think _they_ prefer?
[color=blue]
> As it happens there was a requirement to add a date picker to the
> client-side code for the web application that I am currently working
> on, and I was given the task of writing it.
> ... the task only involved writing about 150 line of date
> picker specific logic (about 3k, fully formatted and commented).[/color]

That's great, if it solves your specific problem. But is it general enough
to be used by thousands of other people around the world? If not, then
you've solved 1 problem when you could have solved 1,000 problems with a
little more work.
[color=blue][color=green][color=darkred]
>>> you increase the download for everyone who has no use
>>> or interest in that facility.[/color]
>> The point is - who cares?[/color]
> Everyone cares, to the extent that everyone wants everything to be
> delivered as soon as they want it.[/color]

A few extra k doesn't matter in most cases.
I'm never convinced by theoretical savings, whether it be reducing code from
10k to 9k, or by speeding up a code block by 5ms.
There comes a point where the "savings" do not justify the time invested to
achieve them.
[color=blue]
> We have HTML bloat, we have graphic bloat and we have script bloat. It
> is the script authors who are responsible for the script bloat, and
> falling down in that area is not justified by others falling down in
> their area.[/color]

Code bloat only matters if people care.
If you have 200k of javascript, I agree, people might actually care.
If you have a 30k lib that is cached and used repeatedly on a site, I think
you would have a hard time finding anyone who realistically cared.
[color=blue][color=green]
>> The convenience of using a lib with a little code bloat
>> is more important than the extra few k of text that is
>> downloaded.[/color]
> Convenience? Do you imagine that it was not convenient for me to be
> able to add a date picker to a system with no more than 150 lines of
> code? Convenience without the bloat.[/color]

a) Not everyone has the skill to develop low-level reusable functions such
as you have done.
b) People such as yourself who write these functions often refuse to
document and share them.
c) Therefore, people without the time or skill to write those functions
cannot use your approach.

If I were you - someone repeatedly advocating reusable low-level functions
being combined to achieve a larger task - then I would certainly be
documenting those functions and making them available to other
lesser-skilled javascript developers, so that everyone could benefit from my
approach. Why don't you?
[color=blue]
> That is not apparent in your words or actions. If you had, for
> example, experimented with designs based on low-level re-usable
> self-contained components providing consistent interfaces to various
> aspects of web browser environments you would either have realised
> that they are a fast, convenient and efficient approach to browser
> scripting, or you would have found some tangible reason for not using
> them and would not have to keep supporting your maintaining your
> status quo with appeals to the stupidity of the "average web
> developer".[/color]

It's not so black and white.

I do have my own low-level reusable components for various tasks. Many work
very well, some could use some more tweaking. My libraries use these
reusable components and package them into usable form for developers. If
they want to break it down and write things on their own using the low-level
components, that's fine. My approach is to package them up in usable form so
they don't _need_ to do all that work.

I am constantly looking for the best low-level reusable functions to perform
very specific tasks. In fact, I've asked for assistance several times in
this group in writing some very specific, reusable low-level functions, and
people aren't really interested in the topic. I would think that the
regulars here would _love_ to work together to find the best way to solve
specific, low-level tasks and document them in a repository of reusable
code.

People such as yourself - who _ADVOCATE_ such a method of development - do
not share your solutions so that others may benefit. I don't see the logic
in your methods. You have the best way to develop (in your opinion), you
have great low-level components (in your opinion), and you think everyone
could benefit from developing like you - and yet you refuse to share your
work? I don't get it. At least all my stuff - good or bad - is out there for
everyone to look at, use, and criticize. Some of it is out of date and
doesn't even represent my preferred way of solving some problems anymore
(having a wife, dogs, kid, and baby on the way doesn't leave much spare time
to update web sites) but I do the best I can to put stuff up there that
others can actually benefit from.
[color=blue]
> On the whole web developers, even web
> designers, seem to be of above average intelligence. If I didn't
> believe that I would not spend so much of my time explaining how
> things work to them.[/color]

The point is, many people making web sites and apps don't even do it for a
living. They do it in their free time. They may be assembling cars at their
job, then come home and work on a web site for their softball team. They are
not unintelligent people. They just lack the education, experience, time,
and knowledge that someone such as yourself might have. So you can talk all
you want about how they _should_ be doing things, but the fact is that
they're not even listening to you because you're so far off from what they
need.
[color=blue]
> You like to talk of "adding value", to people, to web pages, to
> scripts. Does it really mean anything or is it just a turn of phrase
> that just sounds positive?[/color]

It's a phrase whose meaning should be obvious.
If you've added value to something, you've increased a positive trait or
reduced a negative one. The end result is worth more, or is superior to the
original state. Maybe you increased productivity, made something more
robust, made something easier to maintain, saved money, etc, etc.
[color=blue][color=green]
>> And yet your expectation is that every web developer in the world
>> should devote this much time to learning it and using it correctly.
>> That expectation is highly absurd.[/color]
> Why?[/color]

Because not everyone is like you, Richard.
Is that a hard concept to understand?
[color=blue][color=green]
>> There is value in partially solving a problem.[/color]
> It has become clear in the past that we attach very different meanings
> to the words 'solving' and 'solution'. I don't believe that there is
> such a thing as a "partial solution"[/color]

You don't?

Let's take an easy example - medicine. If I have an incurable disease, I
sure would appreciate having medicine to fight the side-effects, and to
delay the inevitable results of the disease. The problem of the disease is
not solved. But it has been partially solved - I will be more comfortable,
and I will live longer than if I didn't take the medicine. I sure would
appreciate such a partial solution to the problem. :)
[color=blue][color=green]
>> I'm realistic. You're idealistic.
>> I'm practical. You're a perfectionist.[/color]
> That is only a meaningful distinction if the prefect and ideal
> strategy towards javascript development for a web browser environment
> wasn't realistic and practical.[/color]

If you believe that your approach is perfect and ideal (or at least closer
than mine) for most people, then I think you are wrong. Sure, it may be
realistic and practical for some, but certainly not most. IMO.

Go find a high school student who is learning web development to make a
school band web site and wants to use some javascript. Ask them if it's
realistic and practical to invest weeks of learning and testing to figure
out how browser scripting works, then spend weeks writing their own
low-level reusable functions, then spend time combining them to perform the
specific task they wanted to achieve on their site. Ask if that approach is
realistic and practical for them, when they could have downloaded a solution
with 10k of 'code bloat' and had it working in their page in less than an
hour. Ask them which approach is more realistic and practical.
[color=blue][color=green]
>> You tell them to RTFM.[/color]
> Yep, if it is a technical subject RTFM. I have no problem with that.[/color]

I had so many responses to this line that I couldn't even decide which one
to use. Luck you ;)

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[Randy Webb]

Re: Javascript Best Practices Document v1.0

Richard Cornford said the following on 10/15/2005 10:47 PM:
[color=blue]
> Matt Kruse wrote:
>[color=green]
>>Richard Cornford wrote:
>>You tell them to RTFM.[/color]
>
>
> Yep, if it is a technical subject RTFM. I have no problem with that.[/color]

Too bad the Manual for Javascript is next to useless.

It's a good theory (ECMAScript) but is so far away from reality in some
situations that it makes it useless.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly

[John G Harris]

Re: Javascript Best Practices Document v1.0

In article <vq8XW1FICSUDFw wR@merlyn.demon .co.uk>, Dr John Stockton
<jrs@merlyn.dem on.co.uk> writes[color=blue]
>JRS: In article <SzlSvQCTv$TDFw +1@jgharris.dem on.co.uk>, dated Fri, 14
>Oct 2005 19:41:23, seen in news:comp.lang. javascript, John G Harris
><john@nospam.d emon.co.uk> posted :[color=green]
>>In article <TFyo9qDtZsTDFw Nu@merlyn.demon .co.uk>, Dr John Stockton
>><jrs@merlyn.d emon.co.uk> writes[color=darkred]
>>>JRS: In article <3r5kl8Fhsi2sU1 @uni-berlin.de>, dated Wed, 12 Oct 2005
>>>19:30:42, seen in news:comp.lang. javascript, Gérard Talbot
>>><newsblahgro up@gtalbot.org> posted :[/color]
>>
>> <snip>[color=darkred]
>>>>IMO, tricks based on + and -0 can not be the best recommendable way to
>>>>convert a string to a number. parseInt or parseFloat should be used instead.
>>>
>>>Then you are wrong; and sentences should start with a capital letter.[/color]
>> <snip>
>>
>>Not funny. This newsgroup is read by beginners; we mustn't trick them
>>into writing ParseInt (with a capital P).[/color]
>
>Agreed. The solution is to recast the sentence so that parseInt does
>not come first. Putting "Function " before it is generally
>satisfactory .[/color]

What a very silly thing to say.
[color=blue][color=green]
>>mW powers your torch.
>>MW melts scrap metal.[/color]
>
>Neither makes a good start for a sentence.[/color]

What is the symbol for milliwatts? mW. Thanks.

John
--
John Harris

[Thomas 'PointedEars' Lahn]

Re: Javascript Best Practices Document v1.0

Matt Kruse wrote:
[color=blue]
> Had everyone stuck to the rules that purists have about when to use
> tables, the web would have been much uglier for much longer.[/color]

Rubbish. Your thinking seems to base on a static medium which the Web
certainly is not and has never been.
[color=blue]
> I still use tables for layout. Why? Because it works consistently across
> browsers, it's much easier to accomplish nice layouts that equivalent CSS
> layout, it degrades more consistently than CSS, and it's easier. I don't
> care if it's "semantical ly" wrong. It works. Better than the alternatives
> in most cases.[/color]

No, it certainly does not, and to state such can only be based on shallow
or no insight, and bad examples of the otherwise very viable alternatives
to layout tables.

A table is a table is a table. [psf 3.8]

You (and, alas, many others) seem to still perceive the Internet including
the Web as a screen-only medium for non-handicapped people. However, that
is no longer the case. The Internet, especially the Web, has moved far
beyond the desktop application it once was and more and more users,
including handicapped ones, trying to have access to it. A competent Web
author has to take this into account, and, fortunately and consequently,
current Web standards provide means to do so.

But, as Michael said correctly, this belongs to another newsgroup.


PointedEars