Javascript Best Practices Document v1.0

[Matt Kruse]

Re: Javascript Best Practices Document v1.0

Thomas 'PointedEars' Lahn wrote:[color=blue][color=green]
>> 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.[/color]

I disagree.
(And for the record, I've been doing this for 12 years, and I'm quite
informed on the topic.)

A table-based layout renders more consistently across browsers than a
CSS-based layout, in my experience. Except for very basic layouts. With a
table-based layout, I can have my content look mostly the same even in very
old browsers. With CSS-based layout, older browsers see either a very plain
or a broken layout.

I'm very familiar with (although, admittedly not an expert in) CSS-based
designs and layouts. I use CSS extensively myself, and I often use it for
positioning and layout. But some things are very difficult to do
consistently with pure CSS. In many cases, using a CSS approach is _much_
more work than a simple table layout which will work consistently in every
browser you can test in. The reasons for dumping tables in favor of pure CSS
are often unconvincing to me. As soon as a simple 3-column layout becomes
easier and more consistent to do in CSS than with tables, let me know. Until
then, I'll probably stick with a big table for the overall layout and CSS
for the rest. That's just MO.

I love the concept of CSS and CSS-based layouts. Unfortunately, it just
hasn't evolved fully yet. Abusing CSS for page layout is just as bad as
abusing tables for it, IMO. CSS is good for positioning and styling. It's
not so good for layout. And browser support (or lack thereof) certainly
makes it more difficult to use it for layout.
[color=blue]
> You (and, alas, many others) seem to still perceive the Internet
> including the Web as a screen-only medium for non-handicapped people.[/color]

I don't perceive things that way at all. I realize the reality of how the
web is accessed and who is using it.
In most cases, I agree that web authors need to consider all these factors.
In some cases, it doesn't matter. And in some cases, it should be the screen
readers and other accessibility devices that should be improved to cater to
the current state of the web.

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[Randy Webb]

Re: Javascript Best Practices Document v1.0

Gérard Talbot said the following on 10/15/2005 4:54 PM:[color=blue]
> Randy Webb a écrit :
>[color=green]
>> Gérard Talbot said the following on 10/14/2005 10:15 PM:
>>[color=darkred]
>>> Randy Webb a écrit :
>>>[/color][/color]
>
>[color=green][color=darkred]
>>> 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]

That is part of the problem. You are wanting specific examples in light
of a general page. someFunction() can do anything you want. As long as
it returns true/false, what it does (with regards to this thread) is
irrelevant.
[color=blue][color=green]
>> 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=green]
>> is a simple matter of an include statement[/color]
>
>
> Include statement.[/color]


I am not sure how much of the above is a result of your quoting, or, if
it is an intended correction.
[color=blue]
> in a template document and
>[color=green]
>> then the work to accomodate IE4 is zero.[/color]
>
>
> No real live webpage example.[/color]

Again, you are wanting a specific example to a general question.

But, before *anybody* tries to do a gEBI emulation in IE4 they have to
understand, at a minimum, what the impact is. There are some things that
gEBI does that document.all does differently.
[color=blue][color=green]
>> 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.[/color]

There is a gEBI emulation in the FAQ in the DynWrite area. The basics of
it came from the metallusions site. But again, you are wanting specific
answers to a general discussion.

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

[Randy Webb]

Re: Javascript Best Practices Document v1.0

Thomas 'PointedEars' Lahn said the following on 10/16/2005 5:02 PM:
[color=blue]
> Matt Kruse wrote:
>
>[color=green]
>>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]

The web, with it's sites, was *very* static when it began. Simply
because there was no way to make it dynamic.
[color=blue]
>[color=green]
>>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.[/color]

The web browser that is in my cell phone has *NO* support of CSS
positional layout. It does support tables though.

And don't tell me to upgrade it, it is the latest/updated browser
available for it.

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

[Gérard Talbot]

Re: Javascript Best Practices Document v1.0

Matt Kruse a écrit :[color=blue]
> Thomas 'PointedEars' Lahn wrote:
>[color=green][color=darkred]
>>>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
>>alternative s to layout tables.[/color]
>
>
> I disagree.
> (And for the record, I've been doing this for 12 years, and I'm quite
> informed on the topic.)
>
> A table-based layout renders more consistently across browsers than a
> CSS-based layout, in my experience.[/color]

If you code with a given lowest common denominator, then for the sake of
this discussion, you should objectivize this info. If you absolutely
want to create roughly the same page layout in NS4, IE4, Opera 8.50 and
Safari 2.01, then a table-based design for your page will meet such
requirements.
But if you code according to web standards and acknowledged web design
principles, then table-based layout shouldn't be used [for non-tabular
data].

Except for very basic layouts. With a[color=blue]
> table-based layout, I can have my content look mostly the same even in very
> old browsers.[/color]

How old is "very old browsers"? To me, IE 4 and NS 4 are very old,
1997-ish browsers, designed and developed in 1996. To me, MSIE 5.01 is a
very old browser too.
To others, MSIE 6 is a very old browser: MSIE 6 beta 1 was released more
than 4½ years ago, you know.

With CSS-based layout, older browsers see either a very plain[color=blue]
> or a broken layout.
>
> I'm very familiar with (although, admittedly not an expert in) CSS-based
> designs and layouts. I use CSS extensively myself, and I often use it for
> positioning and layout. But some things are very difficult to do
> consistently with pure CSS.[/color]


Consistently. What do you mean with consistently? Do you mean consistent
visual layout across different browsers? Do you mean pixel-perfect
rendering for a webpage designed with pixel-perfect ambitions?
Again, I'm afraid we're talking in general terms, in abstract terms,
regarding non-defined, non-concrete webpage situation.

In many cases, using a CSS approach is _much_[color=blue]
> more work than a simple table layout which will work consistently in every
> browser you can test in.[/color]

"will work consistently in every browser": is that realistic? is that a
sane goal? When you say every browser, you mean MSIE 4, NS 4 or older
than those? Even those who have zero support for CSS?

HTML was never designed to be a layout language. It is perfectly normal
that HTML can be rendered differently in different media, softwares,
etc. and this regardless of CSS support.
As far as accessibility (and accessibility groups, guidelines,
checkpoints, directives, norms, etc..) is concerned, what matters is
that content of a page is/remains accessible and that navigation in a
site is/remains functional. How a webpage will look in a tableless
browser or in a CSS-less browser or.. etc.. is not really the most
important issue: access to content and functional navigation are.

The reasons for dumping tables in favor of pure CSS[color=blue]
> are often unconvincing to me.[/color]

You don't believe in writing markup code without validation errors in
your website to begin with. You don't believe in using a doctype which
will trigger standards compliant rendering mode in modern browsers to
begin with.
You believe in deprecated markup. And then you want pure CSS to work in
your pages?

As soon as a simple 3-column layout becomes[color=blue]
> easier and more consistent to do in CSS than with tables, let me know.[/color]

Well, they are available. It all depends on your requirements in terms of
- lowest common denominator browser/requirement,
- how consistent and accurately consistent the layout should be for
browsers like, say, IE4, IE5.x, etc.
- if the 3-column layout must be based on floats and/or abs. pos.,
- if the layout must be fluid or rigid,
- if the layout must be scalable or not,
- if the layout must be controled by js,
- etc...

It all depends on how much constraints, requirements you may have. But I
assure you that a "simple" 3-column layout has been around/available for
many years.

Until[color=blue]
> then, I'll probably stick with a big table for the overall layout and CSS
> for the rest. That's just MO.
>
> I love the concept of CSS and CSS-based layouts. Unfortunately, it just
> hasn't evolved fully yet. Abusing CSS for page layout is just as bad as
> abusing tables for it, IMO. CSS is good for positioning and styling. It's
> not so good for layout.[/color]

Zen Garden: th beauty of CSS design

http://www.csszengarden.com/

Go ahead and send an email to the creators of that site stating that CSS
is "not so good for layout" and you'll get replies for sure.

regards

Gérard
--
remove blah to email me

[Matt Kruse]

Re: Javascript Best Practices Document v1.0

Gérard Talbot wrote:[color=blue]
> If you
> absolutely want to create roughly the same page layout in NS4, IE4,
> Opera 8.50 and Safari 2.01, then a table-based design for your page
> will meet such requirements.[/color]

Thank you. That was my point.
[color=blue]
> You don't believe in writing markup code without validation errors in
> your website to begin with.[/color]

As I continue to work on the design and content of
www.JavascriptToolbox.com, I am validating it (The url still points to my
old site, but I am trying to get time to put up the new content). I see
value in validating, but if something doesn't validate and I have a reason
for it to be so, I don't mind at all.
[color=blue]
> You don't believe in using a doctype which
> will trigger standards compliant rendering mode in modern browsers to
> begin with.[/color]

On the contrary, I do. In fact, every page on my new site will have
user-selectable doctype links at the top so that scripts can be tested in
whichever doctype the user happens to be using.
[color=blue]
> Zen Garden: th beauty of CSS design
> http://www.csszengarden.com/
> Go ahead and send an email to the creators of that site stating that
> CSS is "not so good for layout" and you'll get replies for sure.[/color]

If you look at some of the stylesheets created for the site, you quickly
realize that CSS is not good for layout.

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[Michael Winter]

Re: Javascript Best Practices Document v1.0

On 17/10/2005 04:48, Gérard Talbot wrote:

[snip]
[color=blue]
> http://www.csszengarden.com/
> Go ahead and send an email to the creators of that site stating that CSS
> is "not so good for layout" and you'll get replies for sure.[/color]

CSS Zen Garden is an exhibition of good graphical design (exquisite, in
some cases). It demonstrates that attractive layouts can be achieved
with CSS. However, neither the markup nor many of the sample layouts can
be considered good Web design.

The markup is bloated so that there are plenty of hooks for the
different style sheets (this is even acknowledged in the markup). Many
of the style sheets are inappropriate because they produce inflexible
and potentially fragile designs, as well as exhibiting bad practices
(pixel-defined fonts and text containers, dependency upon background
images, etc.).

The site shows what /can/ be done, but doesn't necessarily demonstrate
/how/ to go about doing it.

Mike

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

[Gérard Talbot]

Re: Javascript Best Practices Document v1.0

Matt Kruse a écrit :[color=blue]
> Gérard Talbot wrote:
>[color=green]
>>If you
>>absolutely want to create roughly the same page layout in NS4, IE4,
>>Opera 8.50 and Safari 2.01, then a table-based design for your page
>>will meet such requirements.[/color]
>
>
> Thank you. That was my point.
>
>[color=green]
>>You don't believe in writing markup code without validation errors in
>>your website to begin with.[/color]
>
>
> As I continue to work on the design and content of
> www.JavascriptToolbox.com, I am validating it (The url still points to my
> old site, but I am trying to get time to put up the new content).[/color]

I was referring to your whole site. I was not referring to the
javascript section. I have not find a single page on your whole website
using a strict DTD. Nowhere do I see a doctype decl. in any of your
webpages. So you never trigger standards compliant rendering mode in
modern browsers.

I see[color=blue]
> value in validating, but if something doesn't validate and I have a reason
> for it to be so, I don't mind at all.
>[/color]

You won't mind validation errors if you do not find compelling reason to
fix these either. Browsers and browser versions don't just consult
*_you_* before rendering a page, you know. Unless you actually test your
webpages with all available browsers and browser versions and web-aware
softwares, you can't just dismiss validation errors on a gut/random
feeling just like that... in particular if layout consistency across
browser is something you highly value.

There is no formal error condition in HTML. That is why it is much more
important to validate the markup code. Furthermore if consistent layout
(as consistent it may be) is a goal in itself for a web developer.
[color=blue]
>[color=green]
>>You don't believe in using a doctype which
>>will trigger standards compliant rendering mode in modern browsers to
>>begin with.[/color]
>
>
> On the contrary, I do.[/color]

I have not found a single webpage on your whole website which uses a
doctype triggering web standards compliant rendering mode in modern
browsers. And the thing is that so far you have demonstrated a high
consideration layout consistency across browsers.
I see contradictions in some of your posts on this precise issue.

In fact, every page on my new site will have[color=blue]
> user-selectable doctype links at the top so that scripts can be tested in
> whichever doctype the user happens to be using.
>
>[color=green]
>>Zen Garden: th beauty of CSS design
>>http://www.csszengarden.com/
>>Go ahead and send an email to the creators of that site stating that
>>CSS is "not so good for layout" and you'll get replies for sure.[/color]
>[/color]

You said word for word that CSS is not so good for layout. I am quoting
you fair and square here. You somehow "blame" CSS for not producing as
accurate and consistent layout as tables can but
- you want to support old browsers like NS4, IE4 and other browsers
which have buggy and incomplete support for CSS
- it seems you want pixel-accurate layout for every/all browsers
- you have not defined the configuration of your 3 columns layout
"needs" in terms fluid/fixed design, scalability, float vs abs. pos.,
css hacks or no, etc. There are plenty of 3 columns layout available and
free out there.
[color=blue]
> If you look at some of the stylesheets created for the site, you quickly
> realize that CSS is not good for layout.[/color]

I don't follow you. I don't understand you at all on this. I thought
your site was

http://www.mattkruse.com/

which starts exactly as follows:

<HTML>
<HEAD>
<TITLE>Matt Kruse's Site</TITLE>
<style>
BODY {
scrollbar-face-color:#006666;
scrollbar-arrow-color:#ffffff;
scrollbar-track-color:#66aaaa;
scrollbar-shadow-color:#006666;
scrollbar-highlight-color:#ffffff;
scrollbar-3dlight-color:#66aaaa;
scrollbar-darkshadow-Color:black;
}
..SPONSOR {
color:#006666;
}
</style>
</HEAD>

<BODY BGCOLOR="#FFFFF F" LINK="#006666" VLINK="#004444" >

<center>
<table width=99% border=0 cellpadding=0 cellspacing=0>
(...)

Gérard
--
remove blah to email me

[Matt Kruse]

Re: Javascript Best Practices Document v1.0

Gérard Talbot wrote:[color=blue]
> I was referring to your whole site. I was not referring to the
> javascript section. I have not find a single page on your whole
> website using a strict DTD. Nowhere do I see a doctype decl. in any
> of your webpages.[/color]

My personal site is a whole different matter. It's evolved (or in many cases
hasn't changed at all) over the last _TWELVE YEARS_. It is certainly no
representation of my knowledge or skills. It's a personal site, and I don't
care if it validates or looks ugly to some people. I have a family and a
job, and updating my personal web site is certainly a very, very, very low
priority in my life ;)

You're welcome to view the source at http://www.ajaxtoolbox.com/ which does
in fact use a strict doctype and probably looks more like what you'd like to
see.
[color=blue]
> - you want to support old browsers like NS4, IE4 and other browsers
> which have buggy and incomplete support for CSS[/color]

If I can with a table layout, but not with a CSS layout, why should I use a
CSS layout?
[color=blue]
> - it seems you want pixel-accurate layout for every/all browsers[/color]

Nope, not at all.
[color=blue]
> - you have not defined the configuration of your 3 columns layout
> "needs" in terms fluid/fixed design, scalability, float vs abs. pos.,
> css hacks or no, etc. There are plenty of 3 columns layout available
> and free out there.[/color]

Take for example the layout at http://www.ajaxtoolbox.com/

If you can duplicate that layout with pure CSS and it:
a) Is simpler to code
b) Is fairly consistent across browsers, even older ones
c) Looks just like what I have

then I'll consider the alternative.
[color=blue][color=green]
>> If you look at some of the stylesheets created for the site, you
>> quickly realize that CSS is not good for layout.[/color]
> I don't follow you. I don't understand you at all on this. I thought
> your site was...[/color]

My site has nothing to do with csszengarden. I stated that in order to
ahieve the impressive layouts that you see on _that_ site, you quickly
realize why CSS is not good layout. The resulting code using CSS is often
quite a disaster.

But really, this discussion is *way* off from javascript, and I don't see
what your goal is...

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[Richard Cornford]

Re: Javascript Best Practices Document v1.0

Matt Kruse wrote (2005:10:16):[color=blue]
> Richard Cornford wrote:[color=green][color=darkred]
>>> 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.[/color]

It is not necessary to be an expert in order to understand browser
scripting.
[color=blue]
> 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.[/color]

You are describing someone in an extremely responsible position.
Responsible for web site, database and network security (in relation to
external connections/access), responsible for a public face, and
consequent credibility, of the organisation, potentially responsible for
a significant revenue source, etc.

You are also describing someone who does not need to use javascript at
all, it is not compulsory.
[color=blue]
> Very few people in the real world would be an expert in all
> of those areas,[/color]

And most of them will realise that they are not qualified to do that job
and so not apply for it.
[color=blue]
> or have anywhere close to enough time to study each
> area in-depth.[/color]

In a responsible position, where the potential to do harm exceeds the
individuals wages, not having the skills to do the job effectively is
seriously unprofessional. And in the event of finding ones self
manoeuvred into that position without the skills it is seriously
unprofessional not to make the time to learn the required skills. But
even so, those skills do not necessarily need to include javascript at
all, as a web site can get by without it easily enough.
[color=blue]
> For many, the best hope is to keep things working
> and _slowly_ advance knowledge in each of those areas.[/color]

To admit that advancing knowledge in each area is advantageous is to
question the rational of necessarily doing so slowly.
[color=blue][color=green]
>> 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]

So nobody manages the use of the available resources to take best
advantage of the skills they have?
[color=blue][color=green]
>> 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".[/color]

Officially I am a Java and javascript programmer, but I have not written
a single line of Java in the last year, and am unlikely to be able to do
so in the next year.
[color=blue]
> 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.[/color]

It is fairly obvious form job adverts that many organisations have
little idea of which skills, technical and otherwise, they should expect
to hire in one individual. When someone advertises for a 'web designer
with DHTML' they are asking for a graphic designer and a programmer, two
skills that would rarely be available in equal measure in the same
individual.
[color=blue]
> Again, I think your current work environment - whatever it
> is - does not represent the norm for many, many developers
> out there.[/color]

That may well be true, I have always programmed for software houses
(mostly working on e-commerce web sites and web applications, as I
presently am). Software houses are, however, very interested in the
efficient and cost-effective creation of reliable and easily maintained
software.

An organisation such as a web design agency may be very differently
managed, but when they find themselves in the business of writing
software maybe they should be looking at how the business of writing
software is practiced professionally.
[color=blue]
> Certainly not for those developers who aren't even _in_
> a work environment.[/color]

The degree to which the attitudes and behave of individual amateur
developers may be regarded as professional is not that important.
[color=blue][color=green]
>> 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.[/color]

It is not a question of being "picky", hiring someone to white browser
scripts who cannot write browser script would be an expensive mistake.
[color=blue]
> Not every company can.[/color]

Companies cannot verify that the people they hire possess the skills
they purport to have? I think you will find that they can.
[color=blue]
> 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.[/color]

Would I? As I recall I have put considerable effort into demonstrating
that much of what your are calling "cool javascript functionality" can
be achieved without introducing a javascript dependency, and so without
having a negative impact on the viability of any site that uses them.
[color=blue]
> You don't know enough."[/color]

I may in practice make it evened that any given individual doesn't know
enough to handle the issues involved in using javascript on a web site,
but I tend to suggest that the answer to that problem is acquiring the
knowledge.
[color=blue]
> Whereas I would tell them, "sure, you can do that.
> Download X and Y and put Z in your HTML, and it will
> work."[/color]

And you use a definition of 'work' that falls short. You introduce
dependencies and penalties without properly explaining them, and then
deny their significance when others raise the issues. In short, you give
someone who might be capable of doing better the ability to do harm
without necessarily being aware that they are doing so.
[color=blue]
> Whose approach do you think _they_ prefer?[/color]

When people are doing harm, to their employer, or their employer's
clients, or their own clients, or just some organisation that they have
volunteered to 'help', then they are usually happier to be unaware that
they are doing harm (assuming some personal moral integrity).
[color=blue][color=green]
>> 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?[/color]

No, of course not. It is general enough to be re-used in any context
within the application that may require a date picker.
[color=blue]
> If not, then you've solved 1 problem when you could have
> solved 1,000 problems with a little more work.[/color]

I solved the problem in the context of the problem. Any additional work
solving other people's problems would represent a dishonest use of my
employer's resources.
[color=blue][color=green][color=darkred]
>>>> you increase the download for everyone who has no use
>>>> or interest in that facility.
>>> 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]

A large part of the point of the code design/implementation strategy I
have been promoting is that there is no extra time involved in
implementing it. Indeed, because code re-use is maximised the time spent
actually writing code is minimised.
[color=blue][color=green]
>> 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.[/color]

People care.
[color=blue]
> 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,[/color]

And as soon as you have 10 libraries providing separate functionality
you have 10 opportunities for essentially the same code to be appearing
in more than one of them.
[color=blue]
> I think you would have a hard time finding anyone who
> realistically cared.[/color]

My CEO maintains that fast web applications sell better, and because he
cares all of the management cares. So, no I don't have to look far to
find someone who cares.
[color=blue][color=green][color=darkred]
>>> 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.[/color]

But do the people who don't have the skill also not have the potential
to acquire that skill?
[color=blue]
> b) People such as yourself who write these functions often
> refuse to document and share them.[/color]

A layered design based on low-level re-usable components is a design
pattern not a collection of specific code.
[color=blue]
> c) Therefore, people without the time or skill to write those
> functions cannot use your approach.[/color]

They can once they have acquired the knowledge to do so.
[color=blue]
> 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]

Because I understand that a code design strategy is independent of
actual code, and that the actual components are amenable to may styles
of implementation with no good reason to believe that any individual
implementation would be automatically superior to one in another style.

What developers need in order to exploit the pattern is an understanding
of the idea and some examples of individual components.

<snip>[color=blue]
> 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.[/color]

Which is exactly what I have been saying. As soon as you put two such
libraries together any such code they both employ is needlessly
repeated, with the problem increasing as any individual libraries are
added.
[color=blue]
> 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.[/color]

You are mistaking not being interested in the topic with not being
interested in helping you. You have to remember that everyone knows what
you are going to be doing with any information/examples you are given.
It is not surprising that people should be reluctant to aid you in
making the Internet worse that it could be.
[color=blue]
> 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.[/color]

You haven't noticed the Usenet archives then?
[color=blue]
> People such as yourself - who _ADVOCATE_ such a method of
> development - do not share your solutions so that others
> may benefit.[/color]

I put them in a public place, if you don't care to look that is your
choice.

<snip>[color=blue][color=green]
>> 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.[/color]

It reads like marketing-speak and so would be assumed to have no real
meaning.
[color=blue]
> 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]

You used added "value" in the context of someone adopting one of your
"Best Practices" without understanding what the purpose of the "Best
Practice" is, or understanding why they were adopting it. And, as I
pointed out in the paragraph that you edited from your quoted response
(without marking the edit), the change in state that represents this
added "value" would consequently be negligible. As someone working with
a technology of which they are largely ignorant has the capacity to do
enormous damage without being aware that they are doing so describing
this negligible change of state as adding "value" is like characterising
the swatting of a mosquito as adding value to the fight against malaria.
It might sound good but it really doesn't mean much.
[color=blue][color=green][color=darkred]
>>> 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]

Editing out the paragraph following the question "why?" without any
indication that you have done so is seriously disingenuous. That
paragraph whent on to ask how long it took you to acquire the skills you
have, and how long you would expect to take learning skills you do not
have. You may be right in your implication and there may actually be
people who are capable of acquiring skills instantaneously , but the
majority are like me in that they will have to devote time to learning
anything new.
[color=blue][color=green][color=darkred]
>>> 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?[/color]

No I don't. If the outcome of a problem solving process is acceptable
then it is a solution to the problem. If that acceptable outcome is not
actually a solution to the stated problem then the initial problem was
incorrectly stated/analysed.
[color=blue]
> Let's take an easy example - medicine.[/color]

Interesting choice. You have been arguing here for a tolerance of
individuals working in a professional capacity without a working
understanding of the technology they are using. How well does that
notion translate into medicine? May the general practitioner be excused
for not finding the time to gain an understanding of skin diseases, or
the surgeon for attempting brain surgery prior to gaining some expertise
in the subject? And is the pharmacist rational in his expectation to be
allowed to work as a surgeon?

The situation is more extreme because the consequences of the
harm that can be done in the field of medicine are potentially lethal,
while in web development they are mostly fiscal.
[color=blue]
> 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]

The "problem of the disease" is a poor analyse of the situation. The
problems may be 1. finding a cure for the decease, 2. finding a
prevention for the decease, and 3. finding a palliative for the symptoms
of the decease. Your proposal is a full solution to the problem of
finding a palliative, not a partial solution to either of the other
problems. Indeed it does not even address either of the other problems,
though a solution to either of the other problems would eventually
negate the need for a palliative.
[color=blue][color=green][color=darkred]
>>> 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.[/color]

So the criteria for web development "Best Practices" are to be governed
by absolute beginners making amateur web sites?
[color=blue]
> 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,[/color]

You have proposed someone who is "learning web development", and so time
spent learning the technologies involved will be valuable, and should be
expected to take time.
[color=blue]
> when they could have downloaded a solution with 10k of
> 'code bloat' and had it working in their page in less than an
> hour.[/color]

You question doesn't make it clear whether it is "learning web
development" or "to make a school bad web site" that is the point of the
exercise. In the latter case you proposal may contribute to the outcome
in a way that does not require any learning of web development. If
learning something is the point of the exercise then learning to deploy
a third party library without understanding it (or the possible
consequences) is barely a contribution at all.
[color=blue]
> Ask them which approach is more realistic and practical.[/color]
<snip>

The judgement of someone who has no understanding of a subject as to
what would be practical and realistic in relation to that subject is of
little value. You would just be asking someone whether they would prefer
not to spend time learning how to go about doing something that they
want to do. It is an appeal to innate idleness in humans, and yes we
would all prefer not to have to spend time learning how to do what we
want to be able to do. However, if pressed, even you high school student
would have to admit that it is not a very realistic desire.

Richard.

[Randy Webb]

Re: Javascript Best Practices Document v1.0

Richard Cornford said the following on 10/23/2005 11:04 AM:
[color=blue]
> Matt Kruse wrote (2005:10:16):
>[color=green]
>>Richard Cornford wrote:
>>[color=darkred]
>>>>Many have no interest in learning the language or its
>>>>quirks, nor do they want to spend hours learning best
>>>>practices of FAQs.
>>>
>>>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.[/color]
>
>
> It is not necessary to be an expert in order to understand browser
> scripting.
>
>[color=green]
>>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.[/color]
>
>
> You are describing someone in an extremely responsible position.
> Responsible for web site, database and network security (in relation to
> external connections/access), responsible for a public face, and
> consequent credibility, of the organisation, potentially responsible for
> a significant revenue source, etc.
>
> You are also describing someone who does not need to use javascript at
> all, it is not compulsory.
>
>[color=green]
>>Very few people in the real world would be an expert in all
>>of those areas,[/color]
>
>
> And most of them will realise that they are not qualified to do that job
> and so not apply for it.[/color]

Theory: Every Javascript Programmer should have at least a 99%
understanding of the language.
Reality: Less than perhaps 1% do.

Theory: Every webmaster should have a very proficient understanding of
the technologies they are using.
Reality: Very few do.

Theory: Every person who isn't qualified 100% to do a job shouldn't apply.
Reality: If that were true, 99% of the world would be unemployed.

Theory: Every webpage should be totally, 100%, accessible and degrade
gracefully.
Reality: Less than 1% do (if that many).

The Theory/Reality list can go on for pages.

You are an awesome Theorist Richard. But Theory, the Web and Reality are
a disaster in the making when you try to force Theory onto the Web and
Reality. The difference is night and day.


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

[Matt Kruse]

Re: Javascript Best Practices Document v1.0

Richard Cornford wrote:[color=blue]
> It is not necessary to be an expert in order to understand browser
> scripting.[/color]

It does require extensive learning, trial-and-error, and personal
experience. A reference document is not enough. One needs to experiment with
browsers and quirks in order to build something that is useable, in many
cases.
[color=blue][color=green]
>> Rather than considering yourself and your job position, consider
>> a one-man 'webmaster' for a small company...[/color]
> You are also describing someone who does not need to use javascript at
> all, it is not compulsory.[/color]

Obviously. _Nothing_ is required. You could write plain text and not learn
HTML, too.
The point is, sometimes some more advanced functionality is desired, and not
everyone can fulfill your 'requirements' to be able to accomplish that
functionality.
[color=blue]
> Officially I am a Java and javascript programmer, but I have not
> written a single line of Java in the last year, and am unlikely to be
> able to do so in the next year.[/color]

I believe your position makes you _highly_ biased, and I question your
ability to identify with the needs and conditions that a more typical web
developer is faced with. You seem to be unable to grasp that not everyone is
capable of being in the position you are, either in terms of work
environment or ability to learn skills. Your solution for someone who is not
like you seems to be to become more like you. Which is highly unrealistic,
and perhaps not even desireable.

If you were an average web developer without much experience, put into a
position where you needed to develop some javascript functionality, I think
you would be like a deer in headlights. You wouldn't know what to do. Your
only recommendation would be to spend weeks or months learning the skills
required to implement things from scratch, which is a naive and completely
impractical suggestion for most.
[color=blue][color=green]
>> Certainly not for those developers who aren't even _in_
>> a work environment.[/color]
> The degree to which the attitudes and behave of individual amateur
> developers may be regarded as professional is not that important.[/color]

You missed the point entirely.
Many people learn and practice web development and javascript outside of a
work environment. The idea of spending many hours learning a programming
language is not at all practical.
[color=blue]
> And as soon as you have 10 libraries providing separate functionality
> you have 10 opportunities for essentially the same code to be
> appearing in more than one of them.[/color]

Is that a problem? Even code you've posted yourself has code duplication,
such as multiple instances of a returnFalse() function, etc.
Having the same code appear multiple times is not ideal, but it's only bad
if it has a negative effect on performance or some other factor.
[color=blue][color=green]
>> a) Not everyone has the skill to develop low-level reusable
>> functions such as you have done.[/color]
> But do the people who don't have the skill also not have the potential
> to acquire that skill?[/color]

Sometimes they don't, no.
Often employers don't have the free time to devote to properly training
people or giving them the opportunity to learn.
In cases where peoeple are volunteering their time or learning outside of
work, they may have families and other things which prevent them from
devoting the required time to learn.
And finally, some people just aren't programmers at all, and have no
interest in learning the particulars of something that they can download and
use without a big learning curve.
[color=blue][color=green]
>> b) People such as yourself who write these functions often
>> refuse to document and share them.[/color]
> A layered design based on low-level re-usable components is a design
> pattern not a collection of specific code.[/color]

I realize this.
But if you have solved the problem of, for example, finding the position or
size of an object in a way that works in as many browsers as possible and as
many specific cases as possible, that code can be reused by others rather
than them writing it from scratch and discovering all the quirks which need
to be adjusted for between browsers.
[color=blue][color=green]
>> c) Therefore, people without the time or skill to write those
>> functions cannot use your approach.[/color]
> They can once they have acquired the knowledge to do so.[/color]

This prerequisite of yours has already been shown to be unrealistic and
impractical for many people.
[color=blue]
> You are mistaking not being interested in the topic with not being
> interested in helping you. You have to remember that everyone knows
> what you are going to be doing with any information/examples you are
> given. It is not surprising that people should be reluctant to aid
> you in making the Internet worse that it could be.[/color]

And you know the term used for such people? Elitist assholes. They're the
people no one likes in person and no one invites to parties. I'm sure you
understand ;)

The fact is, as I am redesigning my javascript site, I am putting in a
section for low-level solutions to specific problems. If you want to do X,
then here is a function Y which solves that very specific problem.

My libraries will of course make use of the low-level functionality, but the
goal is to have those available separately also, so that if someone wants to
find just a specific piece of functionality which they can include in their
work, it is there. Since some functionality can be difficult to develop for
in a browser-neutral way, such low-level functions are best developed with
the advice and suggestions of several people, IMO. A single author can
rarely accomplish the same level of detail and thorougness that several can.
[color=blue][color=green]
>> 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.[/color]
> You haven't noticed the Usenet archives then?[/color]

You think that usenet archives are a better repository than a single web
site with contents that reflect the concensus of a number of expert
developers?
[color=blue][color=green][color=darkred]
>>> You like to talk of "adding value"...[/color][/color]
> It reads like marketing-speak and so would be assumed to have no real
> meaning.[/color]

Like most of the novels you write in this group ;)
[color=blue][color=green]
>> Go find a high school student who is learning web development
>> to make a school band web site and wants to use some javascript.[/color]
> So the criteria for web development "Best Practices" are to be
> governed by absolute beginners making amateur web sites?[/color]

Perhaps.
Expert developers rarely need to consult 'best practices' documents.

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[Matt Kruse]

Re: Javascript Best Practices Document v1.0

Randy Webb wrote:[color=blue]
> You are an awesome Theorist Richard. But Theory, the Web and Reality
> are a disaster in the making when you try to force Theory onto the
> Web and Reality. The difference is night and day.[/color]

Yeah. What he said, much better than I ever do ;)

Theory is great. But it doesn't necessarily do any good in many real-world,
every-day problems.

I think theory is interesting (and great for more advanced developers), but
I much prefer to deal in reality. It doesn't matter if you think people
OUGHT to spend hours learning javascript and write code from scratch using
their own reusable low-level functions.

IT AINT GONNA HAPPEN!

You can either shield your eyes from this reality and continue with the same
old mantra which doesn't actually help anyone, or you can accept the reality
and develop solutions, guides, suggestions, and libraries which help people
in real-world situations.

I'm not saying I take the absolute best approach possible. My code needs
improvements (many of which I've already developed, but documenting things,
creating a web site with examples, and supporting them is extremely
time-consuming), but I do believe that I'm doing more of a service to the
web community than Mr. Cornford, Mr. Stockton, et al, who continue to
complain about my approach, and also refuse to make any real constructive
criticisms of my code. They can talk theory all they want, but in reality
I'm not sure they really help many people. *shrug*

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[VK]

Re: Javascript Best Practices Document v1.0


Michael Winter wrote:
[color=blue]
> This might also be a good time to follow on and dispel the idea about
> hash 'arrays'.[/color]

It's going to be more difficult than this spring because besides
Microsoft
<http://msdn.microsoft. com/library/default.asp?url =/library/en-us/script56/html/jsobjdictionary .asp>


I now got the Mozilla Foundation support:
<http://www.mozilla.org/projects/xpcom/hashtable-guide.html>

Good luck though, my pen is still ready ;-)

[color=blue]
> frames and form elements addressing[/color]
Academically very right, but supposed to deal with some abstract ideal
browser implementation. As there is no such, should we mention
particular issues of earthy rivals (IE & FF at least).
<http://www.geocities.c om/schools_ring/ArrayAndHash.ht ml#HTMLCollecti on>
has some inspirational cases linked.

[color=blue]
> eval() is evil[/color]

But runtime code generation can be very effective (or even the only
option). Should we mention new Function(args, body) method as a legal
alternative to eval() ?

[Lasse Reichstein Nielsen]

Re: Javascript Best Practices Document v1.0

"VK" <schools_ring@y ahoo.com> writes:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> This might also be a good time to follow on and dispel the idea about
>> hash 'arrays'.[/color]
>
> It's going to be more difficult than this spring because besides
> Microsoft
> <http://msdn.microsoft. com/library/default.asp?url =/library/en-us/script56/html/jsobjdictionary .asp>[/color]

.... which show an example of a dictionary, which is a mapping from keys
to values, and not a Javascript array ...
[color=blue]
> I now got the Mozilla Foundation support:
> <http://www.mozilla.org/projects/xpcom/hashtable-guide.html>[/color]


.... which show an implementation of a hashtable, and states that it is
different from an array (and how it is different).
[color=blue]
> But runtime code generation can be very effective (or even the only
> option). Should we mention new Function(args, body) method as a legal
> alternative to eval() ?[/color]

No, that's evil too :)

Runtime code generation is rarely, if ever, needed. In the few, highly
specialized, cases where it is, it will hopefully be an experienced
developer who is doing it. Working with code as stings is extremely
unsafe and should be avoided if at all possible.

I have still to see a case of runtime code generation where it's not a
testing utility that executes user entered Javascript (which isn't really
generating) or a re-implementation of a newer feature for older browsers
(like apply). Modern browsers don't need code generation.
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[VK]

Re: Javascript Best Practices Document v1.0

> Detecting Browser Versions
.... and related scripts.

I think that really best practice for object/method detection should be
the usage of "in" operator. It's nice that JavaScript converts
undefined and null into boolean false for us, but it seems a bit durty
and may hurt you when moving on strictly typed languages.

So instead of
if ( (someObject) && (someObject.som eMethod) )

we should use:
if ( (someObject in objectContainer ) && (someMethod in someObject) )

As objectContainer nearly always is window, the most common case would
be:
if ( (someObject in self) && (someMethod in someObject) )
// using "self" reference to the *current* window is more reliable
// than simply "window" because "window" may be contectually
// ambiguous in some very rare but possible cases.