Javascript Best Practices Document v1.0
Matt Kruse
I started writing this up as a guide for some people who were looking for
general tips on how to do things the 'right way' with Javascript. Their code
was littered with document.all and eval, for example, and I wanted to create
a practical list of best practices that they could easily put to use.
The above URL is version 1.0 (draft) that resulted. IMO, it is not a
replacement for the FAQ, but a more practical guide for fixing some of the
problems that commonly get pushed into web sites.
Any comments?
PS: Ignore the formatting. It's ugly, for now ;)
PPS: I know that there are exceptions to many of the 'best practices' in
very specific situations when approached by an experienced author, but the
goal of this document is to help the average joe developer fix common
problems and write more acceptable code.
--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Gérard Talbot
> http://www.JavascriptToolbox.com/bestpractices/
>
> I started writing this up as a guide for some people who were looking for
> general tips on how to do things the 'right way' with Javascript.
Good idea! I support such initiative.
Their code
> was littered with document.all and eval,
You're most likely right. The top nr 1 problem with DHTML/javascript
code on the web is still the recourse to document.all. Still today, in
this very newsgroup, a lot of people are still promoting it in the name
of supporting MSIE 4 ... which I think is just stupid. Less than 0.5% of
internet/web users worldwide are still using MSIE 4 and the chances that
some DHTML/javascript stuff can effectively work on MSIE 4 is very slim.
So, I'd recommend to ditch document.all everywhere... including in this
newsgroup.
for example, and I wanted to create
> a practical list of best practices that they could easily put to use.
>
> The above URL is version 1.0 (draft) that resulted. IMO, it is not a
> replacement for the FAQ, but a more practical guide for fixing some of the
> problems that commonly get pushed into web sites.
>
> Any comments?
>
> PS: Ignore the formatting. It's ugly, for now ;)
The formatting is ok for me.
1- I think you should start with something as basic as explaining that
document.all is bad, wrong, deprecated, obsolete, etc..
2- The web standards way to reference a form input element is:
document.forms.namedItem("formname").elements.namedItem("inputname")
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-1689064
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-21069976
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-76728479
3- "All forms should have a name attribute. Referencing forms using
indexes, such as document.forms[0] is bad practice."
name attribute for form was dropped in XHTML specification. So you may
want to add such nuance/relativity in there.
4- <form name="myform">
<input type="text" name="val1" value="1">
<input type="text" name="val2" value="2">
</form>
will trigger a validation markup error with a DTD strict.
5- "To fix this problem, Javascript needs a hint to tell it to treat the
values as numbers, rather than strings. Subtracting 0 from the value
will force javascript to consider the value as a number, and then using
the + operator on a number will perform addition, rather than
concatenation."
I think you may be in fact teaching a wrong trick. What's wrong with
offering to use parseInt(strValParam, indexParam) to achieve exactly
what you want to achieve... which is converting a string into an integer
or to use parseFloat(strValParam).
6- "This is why 'return false;' is often included at the end of the code
within an onClick handler."
I would remove that sentence. The sentence does not perfectly make
sense. Also, we have no idea what the doSomething() function does exactly...
7- "Often, links will just contain href="#" for the sake of simplicity,
when you know for sure that your users will have javascript enabled."
This is what a lot of people denounce also as bad coding practices. A
link should be a link. A rose should be a rose. And href="#" is just bad
practice IMO.
Addendum: I see that you later discourage that practice.
8- IMO, you do not sufficiently explain why href="javascript:..." is
bad. May I recommend some of the reasons listed here:
http://developer.mozilla.org/en/docs/DOM:window.open#Never_use_this_form_of_code_for_links:.3Ca_href.3D.22javascript:window.open.28....29.22_....3E
9- In your "Detecting Browser Versions" section, you may want to give
more references:
- Browser identification approach (aka "browser sniffing"): not best,
not reliable approach
http://www.mozilla.org/docs/web-developer/upgrade_2.html#BrowserIdent
- Using Object/Feature detection approach: best and overall most reliable
http://www.mozilla.org/docs/web-developer/upgrade_2.html#ObjectFeatDetect
- Browser detection - No; Object detection - Yes by Peter-Paul Koch
http://www.quirksmode.org/js/support.html
- Browser Detection and Cross Browser Support (in particular, sections 5
and 6):
http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support
10-
"The rules for using document.all are
2. Only fall back to using document.all as a last resort
3. Only use it if you need IE 5.0 support or earlier "
but IE 5.0 supports getElementById. The only possible reason to use
document.all is if you absolutely need to code for IE 4.x. And why would
you want to do some DHTML which would (could possibly) work in IE 4.x?
I don't see a reason for using document.all anymore.
Regards,
Gérard
--
remove blah to email me
RobG
> http://www.JavascriptToolbox.com/bestpractices/
>
> I started writing this up as a guide for some people who were looking for
> general tips on how to do things the 'right way' with Javascript.
Have you thought of putting it up as a wiki? That way contributors
build your 'best of' site for you - it might get quite extensive though!
It would be good to have some 'best practice' examples or stubs for
various things - form validation, dynamic HTML stuff getting xml files,
calendars and date pickers, etc. - rather than a plethora of sites with
half-baked solutions.
[...]
--
Rob
Michael Winter
[snip]
> 1- I think you should start with something as basic as explaining that
> document.all is bad, wrong, deprecated, obsolete, etc..
But the all collection is neither bad nor wrong. It can be argued that
it is largely redundant, but even in IE5.x is has a useful purpose
(though not IE6).
> 2- The web standards way to reference a form input element is:
>
> document.forms.namedItem("formname").elements.namedItem("inputname")
What Matt wrote is just as 'compliant'. Read the ECMAScript bindings. It
also benefits from better support (so it is better in itself).
> 3- "All forms should have a name attribute. Referencing forms using
> indexes, such as document.forms[0] is bad practice."
> name attribute for form was dropped in XHTML specification.
So? What's that got to do with anything?
If NN4 (and the like) aren't a consideration (and they needn't be for
client-side form validation), then use an id attribute, or pass
references directly and omit an identifier entirely. However, if a name
attribute is necessary, then use it.
> 4- <form name="myform">
> <input type="text" name="val1" value="1">
> <input type="text" name="val2" value="2">
> </form>
> will trigger a validation markup error with a DTD strict.
If you're writing to an XHTML Strict DTD, but that is arguably worse
than reasonable defiance of the DTD.
> 5- "To fix this problem, Javascript needs a hint to tell it to treat the
> values as numbers, rather than strings. Subtracting 0 from the value
> will force javascript to consider the value as a number, and then using
> the + operator on a number will perform addition, rather than
> concatenation."
I would recommend the unary plus (+) operator instead.
> I think you may be in fact teaching a wrong trick. What's wrong with
> offering to use parseInt(strValParam, indexParam) to achieve exactly
> what you want to achieve...
It's overkill in most cases. The value should have been validated
already, so all that's necessary is to convert the value which the unary
plus operator does very well.
The parseInt function can be very useful when using it to simultaneously
strip non-numeric trailing characters and convert, such as with CSS
length values.
> 6- "This is why 'return false;' is often included at the end of the code
> within an onClick handler."
> I would remove that sentence. The sentence does not perfectly make
> sense.
It makes perfect sense when taken in context.
> Also, we have no idea what the doSomething() function does exactly...
You do know that it's just an example, don't you. :P
> 7- "Often, links will just contain href="#" for the sake of simplicity,
> when you know for sure that your users will have javascript enabled."
> This is what a lot of people denounce also as bad coding practices.
It's bad practice when that's used outside the scope of a script.
However, if a script generates such a link, then it's not an issue. I
believe that's what Matt was aiming at (notice, 'know for sure'), but
perhaps it should be emphasised as the caveat might not be noticed.
[snip]
I haven't really read the document yet. I'll get around to it at some
point... :)
Mike
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Dr John Stockton
02:02:23, seen in news:comp.lang.javascript, Gérard Talbot
<newsbl...@gtalbot.org> posted :
>Matt Kruse a écrit :
>> http://www.JavascriptToolbox.com/bestpractices/
>>
>> I started writing this up as a guide for some people who were looking for
>> general tips on how to do things the 'right way' with Javascript.
It will no doubt encourage a bloated programming style.
>5- "To fix this problem, Javascript needs a hint to tell it to treat the
>values as numbers, rather than strings. Subtracting 0 from the value
>will force javascript to consider the value as a number, and then using
>the + operator on a number will perform addition, rather than
>concatenation."
>I think you may be in fact teaching a wrong trick. What's wrong with
>offering to use parseInt(strValParam, indexParam) to achieve exactly
>what you want to achieve... which is converting a string into an integer
>or to use parseFloat(strValParam).
Does unary + not work in the circumstances?
Note that if the actual parameter is a number already, unary + is
essentially a no-op, whereas parseInt will cause a conversion to String
(perhaps 1e+21) and a conversion of that to integer Number, with results
maybe not as intended.
X = 987654321987654321987654321
Z = parseInt(X) // Z = 9
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Matt Kruse
>>> http://www.JavascriptToolbox.com/bestpractices/
>>> I started writing this up as a guide for some people who were
>>> looking for general tips on how to do things the 'right way' with
>>> Javascript.
> It will no doubt encourage a bloated programming style.
Did you read it?
No? I didn't think so.
Your comments are worthless, as usual.
Randy Webb
> http://www.JavascriptToolbox.com/bestpractices/
>
> I started writing this up as a guide for some people who were looking for
> general tips on how to do things the 'right way' with Javascript. Their code
> was littered with document.all and eval, for example, and I wanted to create
> a practical list of best practices that they could easily put to use.
>
> The above URL is version 1.0 (draft) that resulted. IMO, it is not a
> replacement for the FAQ, but a more practical guide for fixing some of the
> problems that commonly get pushed into web sites.
>
> Any comments?
<quote>
Otherwise, it's always a good idea to put a local fall-back page that
will be loaded for users without it disabled
</quote>
"for users with it disabled"
The "What not to do" section on anchors should have a note - or maybe a
seperate page - that explains why you shouldn't do those things.
Including, but not limited, to the negative impacts they can have.
document.all in IE
<quote>
Only use it if you need IE 5.0 support or earlier
</quote>
IE5.0, IIRC, supports gEBI so it should be priort to 5.0
Also, somewhere in there, some type of paragraph or so on innerHTML and
some of it's inherent strength's and weaknesses.
The only major problem with the whole page is the last few lines about
using Libraries which I totally disagree with. A newbe shouldn't be
using tools that they don't understand and the whole page seems to be
geared to some of the newbe mistakes that we were all guilty of
committing at times (and I still do it myself occassionaly).
Libraries are a personal choice and to me people should understand
enough about the language to know when to use a Library not just how to
use it. If all a person ever learns is that if they do this:
DynWrite('someDiv',someHTML);
That the page changes then they never learn and understand the inherent
problems with DynWrite itself (which it does have) and that function
comes straight from the FAQ itself for this group.
Sidenote: The major problem with innerHTML is when the string being
assigned is plain text. innerHTML has been proven, repeatedly, to be
considerably slower that DOM methods or even the IE proprietary
innerText property.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?
Randy Webb
> JRS: In article <3r12raF...@uni-berlin.de>, dated Tue, 11 Oct 2005
> 02:02:23, seen in news:comp.lang.javascript, Gérard Talbot
> <newsbl...@gtalbot.org> posted :
>
>>Matt Kruse a écrit :
>>
>>>http://www.JavascriptToolbox.com/bestpractices/
>>>
>>>I started writing this up as a guide for some people who were looking for
>>>general tips on how to do things the 'right way' with Javascript.
>
>
> It will no doubt encourage a bloated programming style.
Before babbling nonsense like that you should, at minimum, at least read
and be familiar with what you are babbling about.
But, where is *your* guide to best practices?
Gérard Talbot
> On 11/10/2005 07:02, Gérard Talbot wrote:
>
> [snip]
>
>> 1- I think you should start with something as basic as explaining that
>> document.all is bad, wrong, deprecated, obsolete, etc..
>
>
> But the all collection is neither bad nor wrong. It can be argued that
> it is largely redundant, but even in IE5.x is has a useful purpose
> (though not IE6).
>
Useful purpose for IE 5.x? Can you elaborate on this? what do you mean...
>> 2- The web standards way to reference a form input element is:
>>
>> document.forms.namedItem("formname").elements.namedItem("inputname")
>
>
> What Matt wrote is just as 'compliant'. Read the ECMAScript bindings. It
> also benefits from better support (so it is better in itself).
>
Better support? Yes, it's possible. I just mentioned a purely web
standards (DOM 2 HTML) way in there. That's all.
>> 3- "All forms should have a name attribute. Referencing forms using
>> indexes, such as document.forms[0] is bad practice."
>> name attribute for form was dropped in XHTML specification.
>
>
> So? What's that got to do with anything?
>
What I was suggesting here is that one can not declare, just like that,
that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
practice in XHTML
and when what you formally recommend implies an invalid (markup code)
practice in XHTML.
Just compare the following 2 quotes/statements:
"All forms should have a name attribute." Matt K.
"HTML 4 defined the name attribute for the elements a, applet, form,
frame, iframe, img, and map. (...) in XHTML 1.0, the name attribute of
these elements is formally deprecated, and will be removed in a
subsequent version of XHTML."
http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10
> If NN4 (and the like) aren't a consideration (and they needn't be for
> client-side form validation), then use an id attribute, or pass
> references directly and omit an identifier entirely. However, if a name
> attribute is necessary, then use it.
>
Yes, id attribute is another way. name attribute can not be the only way
since it implies invalid markup code in XHTML.
>> 4- <form name="myform">
>> <input type="text" name="val1" value="1">
>> <input type="text" name="val2" value="2">
>> </form>
>> will trigger a validation markup error with a DTD strict.
>
>
> If you're writing to an XHTML Strict DTD, but that is arguably worse
> than reasonable defiance of the DTD.
>
Well, what if I am writing in HTML 4.01 strict then? The above code will
be reported as invalid markup by validators. I am repeating myself here.
>> 5- "To fix this problem, Javascript needs a hint to tell it to treat
>> the values as numbers, rather than strings. Subtracting 0 from the
>> value will force javascript to consider the value as a number, and
>> then using the + operator on a number will perform addition, rather
>> than concatenation."
>
>
> I would recommend the unary plus (+) operator instead.
>
>> I think you may be in fact teaching a wrong trick. What's wrong with
>> offering to use parseInt(strValParam, indexParam) to achieve exactly
>> what you want to achieve...
>
>
> It's overkill in most cases. The value should have been validated
> already, so all that's necessary is to convert the value which the unary
> plus operator does very well.
>
I don't agree with you. parseInt function original purpose (specific
purpose, defined task) is to parse a string and convert it into
integers. Isn't it what Matt Kruse' code wanted to specifically achieve
to begin with?
+ is an overloaded operator; it's not even a function.
> The parseInt function can be very useful when using it to simultaneously
> strip non-numeric trailing characters and convert, such as with CSS
> length values.
>
>> 6- "This is why 'return false;' is often included at the end of the
>> code within an onClick handler."
>> I would remove that sentence. The sentence does not perfectly make sense.
>
>
> It makes perfect sense when taken in context.
>
I disagree. It does not make sense within the context, as written
in the document. We have no idea what doSomething() function actually does.
>> Also, we have no idea what the doSomething() function does exactly...
>
>
> You do know that it's just an example, don't you. :P
>
The provided code is an abstract example. It's not a defined example.
It's not a concrete example, serving a specified purpose.
This page:
https://bugzilla.mozilla.org/attachment.cgi?id=111215
(from bug 44449 at bugzilla)
is a concrete example showing and testing a precise issue.
This example:
http://developer.mozilla.org/en/docs/DOM:window.open#Best_practices
is a whole concrete example showing, demontrating, accomplishing a
precise, concrete goal, task.
There is no general rule for returning false in a script, in an onclick
event attribute. It all depends on what a script actually does within a
real-live webapge context. The Matt K. document suggests otherwise.
>> 7- "Often, links will just contain href="#" for the sake of
>> simplicity, when you know for sure that your users will have
>> javascript enabled."
>> This is what a lot of people denounce also as bad coding practices.
>
>
> It's bad practice when that's used outside the scope of a script.
I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
href="#" should never be used anywhere.
Matt K. discourage href="#" but not to the level I would.
> However, if a script generates such a link, then it's not an issue.
... then a real button describing the purpose of the script should be
used, not a link. A rose is a rose is a rose. A link should be a real
link should be a real link. And a script modifying a DOM tree or a
document structure should be described as such.
"Links that don't behave as expected undermine users' understanding of
their own system. A link should be a simple hypertext reference that
replaces the current page with new content"
J. Nielsen
> [snip]
>
> I haven't really read the document yet.
Well, then, maybe it would be a good idea to do so.
> I'll get around to it at some
> point... :)
>
> Mike
Gérard
Michael Winter
[The all collection]
> Useful purpose for IE 5.x? Can you elaborate on this? what do you
> mean...
The getElementsByTagName method is not implemented properly in IE5.x.
Passing an asterisk (*) will always return an empty collection, rather
than one that contains all descendants of the node. The most reasonable
solution is to detect this failure and use the all collection in place.
[Using the namedItem methods of collections, rather than square brackets]
> Better support? Yes, it's possible.
It's guaranteed.
> I just mentioned a purely web standards (DOM 2 HTML) way in there.
> That's all.
Using square brackets /is/ a 'purely web standards [...] way'.
[The name attribute in XHTML]
> What I was suggesting here is that one can not declare, just like that,
> that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
> practice in XHTML
Unless one is iterating through a collection, using numeric indices is
not a recommended practice as changes to markup mandate a change to the
script, whereas using some form of identifier (or direct reference,
which is what I really recommend) does not.
> and when what you formally recommend implies an invalid (markup code)
> practice in XHTML.
As you were told in ciwah, validation is not a goal in itself. There can
be justified reasons for writing invalid markup[1], and using the name
attribute is not going to break a browser if you truly understand how
browsers will be treating the markup. After all, they won't be parsing
the document as XHTML anyway, so use that notation is, at most,
superficial use of an XML-based language. You would be better off
abandoning XHTML as an output format for the time being (for several
years, at least) and using HTML. That is a better use of your time than
worrying about a single attribute.
[snip]
>>> 4- <form name="myform">
>>> <input type="text" name="val1" value="1">
>>> <input type="text" name="val2" value="2">
>>> </form>
[snip]
> Well, what if I am writing in HTML 4.01 strict then? The above code
> will be reported as invalid markup by validators.
For a different reason, yes, which has nothing to do with what we've
just been discussing.
There is no reason to omit the action attribute in actual markup, but
again this is an example to illustrate an entirely unrelated concept;
potential conflicts between concatenation and addition.
[snip]
>> [The parseInt function is] overkill in most cases. The value should
>> have been validated already, so all that's necessary is to convert
>> the value which the unary plus operator does very well.
>
> I don't agree with you. parseInt function original purpose (specific
> purpose, defined task) is to parse a string and convert it into
> integers.
If the string has been validated as a number, which it should have been,
then the only operation that is needed is conversion. The sole purpose
of the unary plus operator is to convert its operand to a number. The
parseInt function, on the other hand, parses only to an integer -
totally different and often not as useful.
> Isn't it what Matt Kruse' code wanted to specifically achieve
> to begin with?
No. Matt describes string to number conversion, not string to integer.
> + is an overloaded operator; it's not even a function.
The addition operator and the plus (+) symbol itself is overloaded. The
unary plus operator is not. That the latter isn't a function is utterly
irrelevant.
[snip]
>>> 6- "This is why 'return false;' is often included at the end of the
>>> code within an onClick handler."
[snip]
> I disagree. It does not make sense within the context, as written
> in the document. We have no idea what doSomething() function actually does.
It doesn't matter what that function does. Matt is demonstrating event
cancellation (specifically, cancelling link navigation). Anything could
be placed before the return statement, including a comment like
/* Some code here */
[snip]
> There is no general rule for returning false in a script, in an onclick
> event attribute.
No, there isn't, but Matt isn't defining a general rule. The heading of
the section is "Using onClick in <A> tags", and returning false in that
context is well-defined.
>>> 7- "Often, links will just contain href="#" for the sake of
>>> simplicity, when you know for sure that your users will have
>>> javascript enabled."
[snip]
> I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
In markup, I agree with you absolutely, and I wouldn't use it in a
script, either; I wouldn't use a link that's not a link.
The reason why a "#" href attribute value is frowned upon is because is
doesn't do anything. If the script cannot act, for whatever reason, the
user is left with a link that doesn't do anything. This is contrary to
what a link implies. If the script generates the link, and the link's
scripted action can be /guaranteed/ to work, then the usability issue
doesn't imply. The argument now is just whether it's appropriate to use
a link at all.
>> I haven't really read the document yet.
>
> Well, then, maybe it would be a good idea to do so.
I had neither the time, nor the inclination last night to read
through that document and possibly draft my own response. However, I
thought your post needed commenting upon as I felt parts of it were
suggesting changes that were misguided.
Mike
[1] I don't believe that structurally invalid markup is acceptable,
but certain minor violations /can/ be justified. However, I do
advocate that authors should learn and practice writing valid
documents whenever possible.
Matt Kruse
> What I was suggesting here is that one can not declare, just like
> that, that document.forms[0] is a bad practice when it is a DOM 2
> HTML valid practice in XHTML
> and when what you formally recommend implies an invalid (markup code)
> practice in XHTML.
XHTML sucks :)
In reality, most people don't need to consider it, and anyone being forced
to use XHTML surely is not looking for the basic level of suggestions that I
included in my document.
If you include every exception and side-notes about every other way of doing
things, the document becomes huge and unreadable to most average users who
just want a few hints on how to do things better.
> Well, what if I am writing in HTML 4.01 strict then? The above code
> will be reported as invalid markup by validators. I am repeating
> myself here.
It's an abbreviated example to show the point. It is not intended to be
full, correct markup.
> I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
> href="#" should never be used anywhere.
Well, then we disagree. I use href="#" all the time within web apps that
require javascript. Especially when there are hundreds of links on a page,
having each one contain a useless href is pointless, when the user is known
to have javascript enabled. You're welcome to write and publish your own
Best Practices document :)
Michael Winter
> http://www.JavascriptToolbox.com/bestpractices/
"Square Bracket Notation"
You might want to note the different restrictions that both forms have.
That is, the token that forms each part of the dot notation property
accessor must conform to the Identifier production, whereas property
names used with square brackets have no such restrictions. However, the
expression within the brackets will /always/ be type-converted to a string.
This might also be a good time to follow on and dispel the idea about
hash 'arrays'.
I don't know about always using square bracket notation.
"Referencing Forms And Form Elements"
Further to Gérard's complaint, it might be better to refer abstractly to
form identifiers (as both the name and id attributes are supposed to be
unique identifiers), unless the author is referring to the form through
an event listener in which case no identifier is needed.
"Problems With Concatenation"
+theform.elements["val1"].value + +theform.elements["val2"].value
I think it's better to use parentheses around the unary expression,
especially with the right-hand operand above.
It might be better to reference the elements collection directly, rather
than the form (at least when you aren't dealing with the form itself).
var controls = document.forms.myForm.elements,
total = +controls.val1.value + (+controls.val2.value);
"Getting And Setting Form Values"
"[Using unified functions for] forms with only 1 radio button
in a group [...]"
A singular radio button should never exist. If the document is generated
server-side (surely the only reason this situation could occur), that
form control should be removed and the served script altered to only
deal with a single control.
Mike
Matt Kruse
> [snip]
I've corrected a few of the things you've suggested. Thanks!
> The only major problem with the whole page is the last few lines about
> using Libraries which I totally disagree with. A newbe shouldn't be
> using tools that they don't understand...
The use of "libraries" will always be a debate among regulars of this group.
My take has always been that it would be fantastic if everyone could
understand javascript well enough to write their own widgets when they need
them, or at least pick the best ones of those available.
But _reality_ is something different. Most people don't want to learn a lot
about javascript, or don't have time to implement a generalized
cross-browser solution to some problems. I've received hundreds if not
thousands of thank-you's from people saying things like "I needed to add a
calendar popup in my project at work, and I had almost no time left. I
implemented yours in literally 10 minutes and it works perfectly. Thank you
so much!" I think libraries are important for situations like that, and also
for situations where users know what they want but don't have the expertise
to implement it. A person need not be an expert in everything in order to
use the tools available.
A javascript "library" is simply a packaged solution with an
easily-understood interface. We all use those all the time. I bet you aren't
telneting to your news server and issuing NNTP commands by hand, are you?
You're using a higher-level tool so that you don't _have_ to understand the
NNTP protocol. If you have to understand the inner-workings of every tool
you use daily, you could never accomplish anything. Using libraries and
higher-level tools is essential to being more creative and building bigger
and better solutions.
If a javascript library is implemented well enough, with a good interface,
with not a lot of extra code, then I don't see any reason not to use it or
recommend that others use it. I know others disagree, and that's fine. But I
won't be convinced any time soon. Especially when I get thousands of
visitors to my libraries each day, many thank-you emails each month, and
donations from companies and individuals whose projects and timelines were
saved because they found a packaged solution to a common problem that they
could implement in minutes rather than hours or days. And _especially_ when
many of the "anti-library" folks don't offer feasible alternatives for
people faced with challenges that are easily solved by using a decent
library :)
Dr John Stockton
2005 23:15:34, seen in news:comp.lang.javascript, Randy Webb
<HikksNo...@aol.com> posted :
>
>Sidenote: The major problem with innerHTML is when the string being
>assigned is plain text. innerHTML has been proven, repeatedly, to be
>considerably slower that DOM methods or even the IE proprietary
>innerText property.
Which in the majority of cases is totally unimportant. Since the aim is
to change the information presented to the mind of the user, the time
taken is usually significant only if it exceeds about 200 ms.
My Holidays page computes and writes a whole annual holidays table
(about 1.5 windows high) covering 6 years, using DynWrite, in a
perceptible fraction of a second, on a 300 MHz PII. That's good enough.
Gérard Talbot
> On 12/10/2005 04:56, Gérard Talbot wrote:
>
> [The all collection]
>
>> Useful purpose for IE 5.x? Can you elaborate on this? what do you
>> mean...
>
>
> The getElementsByTagName method is not implemented properly in IE5.x.
> Passing an asterisk (*) will always return an empty collection,
I didn't know that.
rather
> than one that contains all descendants of the node. The most reasonable
> solution is to detect this failure and use the all collection in place.
>
>
> Using square brackets /is/ a 'purely web standards [...] way'.
>
> [The name attribute in XHTML]
>
>> What I was suggesting here is that one can not declare, just like that,
>> that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
>> practice in XHTML
>
>
> Unless one is iterating through a collection, using numeric indices is
> not a recommended practice
Matt K. explicitly states that numeric indices is a bad practice.
"Referencing forms using indexes, such as document.forms[0] is bad
practice."
as changes to markup mandate a change to the
> script, whereas using some form of identifier (or direct reference,
> which is what I really recommend) does not.
>
>> and when what you formally recommend implies an invalid (markup code)
>> practice in XHTML.
>
>
> As you were told in ciwah, validation is not a goal in itself. There can
> be justified reasons for writing invalid markup[1],
I don't recall being told that.
and using the name
> attribute is not going to break a browser if you truly understand how
> browsers will be treating the markup. After all, they won't be parsing
> the document as XHTML anyway, so use that notation is, at most,
> superficial use of an XML-based language. You would be better off
> abandoning XHTML as an output format for the time being (for several
> years, at least) and using HTML.
A document about javascript best practices can not and should not rule
out/exclude people who serve XHTML document as application/xhtml+xml.
Otherwise, at the very least, the document should then state that it is
intended for HTML based documents only.
> That is a better use of your time than
> worrying about a single attribute.
Somehow the tone of your post has become personal. All my posts were
referring to the draft document.
I never used more than 2 forms in a single page. Most of the time, I
only have 1. So what's the big deal with numeric indice?
All I can read in the document is a simple directive in the document
regarding numeric indice: no explanation as to why such directive and no
recommended solution for XHTML-based documents.
It wouldn't take a lot of words to compensate for these 2 issues...
> [snip]
>
>>>> 4- <form name="myform">
>>>> <input type="text" name="val1" value="1">
>>>> <input type="text" name="val2" value="2">
>>>> </form>
>
>
> [snip]
>
>> Well, what if I am writing in HTML 4.01 strict then? The above code
>> will be reported as invalid markup by validators.
>
>
> For a different reason, yes, which has nothing to do with what we've
> just been discussing.
>
When should someone bring this up then? When a "HTML Best Practices"
document is released? Writing valid markup code should always be the norm.
> There is no reason to omit the action attribute in actual markup, but
> again this is an example to illustrate an entirely unrelated concept;
> potential conflicts between concatenation and addition.
This example is not just an isolated chunck of code in an ordinary
webpage. Matt K. actually wants people to follow such example and other
examples as well. So why not make it perfectly valid then?
<form name="myform" action="[URL]">
<p>
<input type="text" name="val1" value="1">
<input type="text" name="val2" value="2">
</p>
</form>
It takes a grand total of an extra 20 characters to fullfil the validity
requirements. What's so difficult here?
>
> [snip]
>
>>> [The parseInt function is] overkill in most cases. The value should
>>> have been validated already, so all that's necessary is to convert
>>> the value which the unary plus operator does very well.
>>
>>
>> I don't agree with you. parseInt function original purpose (specific
>> purpose, defined task) is to parse a string and convert it into
>> integers.
>
>
> If the string has been validated as a number, which it should have been,
> then the only operation that is needed is conversion. The sole purpose
> of the unary plus operator is to convert its operand to a number. The
> parseInt function, on the other hand, parses only to an integer -
> totally different and often not as useful.
Ok, what about parseFloat() then? I mentioned it in my original post.
>
>> Isn't it what Matt Kruse' code wanted to specifically achieve
>> to begin with?
>
>
> No. Matt describes string to number conversion, not string to integer.
>
>> + is an overloaded operator; it's not even a function.
>
>
> The addition operator and the plus (+) symbol itself is overloaded. The
> unary plus operator is not. That the latter isn't a function is utterly
> irrelevant.
>
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.
One example: Javascript Bible 4th edition by D. Goodman on "Converting
strings to numbers" p.78-79. Not one word on + and - tricks: everything
in his words clearly refers to the use of parseInt and of parseFloat. Is
he way off the fact and the matter?
> [snip]
>
>>>> 6- "This is why 'return false;' is often included at the end of the
>>>> code within an onClick handler."
>
>
> [snip]
>
>> I disagree. It does not make sense within the context, as written
>> in the document. We have no idea what doSomething() function actually
>> does.
>
>
> It doesn't matter what that function does. Matt is demonstrating event
> cancellation (specifically, cancelling link navigation). Anything could
> be placed before the return statement, including a comment like
>
> /* Some code here */
>
> [snip]
>
>> There is no general rule for returning false in a script, in an onclick
>> event attribute.
>
>
> No, there isn't, but Matt isn't defining a general rule. The heading of
> the section is "Using onClick in <A> tags", and returning false in that
> context is well-defined.
>
Ok. Let me repeat what you've said so that no one gets you wrong. You
say Matt K. in that document is not defining a general rule regarding
the use of returning false in an onclick even attribute.
>>>> 7- "Often, links will just contain href="#" for the sake of
>>>> simplicity, when you know for sure that your users will have
>>>> javascript enabled."
>
>
> [snip]
>
>> I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
>
>
> In markup, I agree with you absolutely, and I wouldn't use it in a
> script, either; I wouldn't use a link that's not a link.
>
> The reason why a "#" href attribute value is frowned upon is because is
> doesn't do anything. If the script cannot act, for whatever reason, the
> user is left with a link that doesn't do anything. This is contrary to
> what a link implies. If the script generates the link, and the link's
> scripted action can be /guaranteed/ to work, then the usability issue
> doesn't imply. The argument now is just whether it's appropriate to use
> a link at all.
Right. I say that a link should be a link, should look like a link,
should act like a link. Otherwise, a button should be used with a proper
caption, text describing its action. It's about proper use of markup,
semantics.
[snipped]
>
> [1] I don't believe that structurally invalid markup is acceptable,
> but certain minor violations /can/ be justified. However, I do
> advocate that authors should learn and practice writing valid
> documents whenever possible.
If a document aspires to promote good, recommendable, sound coding
practices, then its constructed examples should first of all practice
the document's intended goals, should be a model.
Gérard Talbot
> Gérard Talbot wrote:
>
>>What I was suggesting here is that one can not declare, just like
>>that, that document.forms[0] is a bad practice when it is a DOM 2
>>HTML valid practice in XHTML
>>and when what you formally recommend implies an invalid (markup code)
>>practice in XHTML.
>
>
> XHTML sucks :)
> In reality, most people don't need to consider it, and anyone being forced
> to use XHTML surely is not looking for the basic level of suggestions that I
> included in my document.
>
I think it would be fair to indicate to all readers of that page that
your best practices are for HTML documents only, then.
> If you include every exception and side-notes about every other way of doing
> things, the document becomes huge and unreadable
This is exaggerated.
to most average users who
> just want a few hints on how to do things better.
>
>
>>Well, what if I am writing in HTML 4.01 strict then? The above code
>>will be reported as invalid markup by validators. I am repeating
>>myself here.
>
>
> It's an abbreviated example to show the point. It is not intended to be
> full, correct markup.
>
But people don't know that. And newbies can not and will not know that.
The web is litterally full of webpages where examples were tried, were
trusted, copied and pasted. Dynamicdrive.com and other javascript
copy-N-paste are full of examples of dubious quality, poor coding
practices and invalid markup code.
It wouldn't take a lot more typing to correct this. Writing valid markup
code shouldn't be a luxury in your document. Just consider what your
document aspires to present: javascript best practices.
>
>>I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
>>href="#" should never be used anywhere.
>
>
> Well, then we disagree. I use href="#" all the time within web apps that
> require javascript. Especially when there are hundreds of links on a page,
> having each one contain a useless href is pointless, when the user is known
> to have javascript enabled. You're welcome to write and publish your own
> Best Practices document :)
WCAG groups and J. Nielsen have already written on this whole issue.
A script triggered by an onclick event handler in a link should not do a
lot more than a plain vanilla link does otherwise you're not using a
link for its intended purpose to begin with. In such case, you may be
misusing the <a> element; a <button type="button"
onclick="doSomething();"> would most likely be better markup usage,
better semantic.
You never gave an example of what doSomething() would be about, could
do. So, the doSomething() example is not concrete, not demonstrating a
possible good usage, etc. The doSomething() example is promoting a
general use of canceling the return value.
Richard Cornford
> Randy Webb wrote:
>> [snip]
>
> I've corrected a few of the things you've suggested. Thanks!
>
>> The only major problem with the whole page is the last few lines
>> about using Libraries which I totally disagree with. A newbe
>> shouldn't be using tools that they don't understand...
>
> The use of "libraries" will always be a debate among
> regulars of this group.
It isn't debated that much, the only people who seem to argue in favour
of libraries are individuals who have libraries to promote. It seems
that the vested interest and unwillingness to abandon the time already
invested tends to encourage intransigence. When we have the debate the
majority of expressed opinion has always been against the use of
monolithic generalised libraries as an inappropriate concept in browser
scripting.
> My take has always been that it would be fantastic if
> everyone could understand javascript well enough to
> write their own widgets when they need them, or at least
> pick the best ones of those available.
>
> But _reality_ is something different. Most people don't want
> to learn a lot about javascript, or don't have time to
> implement a generalized cross-browser solution to some problems.
It is perverse to state this in the context of a request for comments on
a document that asserts that its subject is "best Practices". Here you
are arguing for expedience, but "best practice" most definitely is about
ideals that should be aspired to and not short term expedience.
> I've received hundreds if not thousands of thank-you's from
> people saying things like "I needed to add a calendar popup
> in my project at work, and I had almost no time left.
> I implemented yours in literally 10 minutes and it works
> perfectly. Thank you so much!"
So a developer who either could not write the code they had undertaken
to create, or could not accurately/effectively schedule their tasks gets
to conceal their incompetence form their employer while reducing the
viability (and so potential profitability) of whatever they have
created? Yes, I can see widespread appeal for having that facility, it
still doesn't make it a good idea.
<snip>
> ... , and donations from companies and individuals whose ...
<snip>
So your public support for libraries in general, and repeated promotion
of your own libraries, is not without some financial motivation, and
direct returns? I am reminded of Ira Baxter, who, in the face of
widespread explanations of why javascript obfuscation is worthless,
still maintains that it is a valuable practice, and then references
people to the javascript obfuscateor that her employers sell.
Anyway, to the "best practices" page; What I like to see when someone
proposes something as a "best practice" is an explanation of why it
might be considered a best Practice. Without that the assertion has only
the weight of the individual who is making the assertion, and needs
filtering through an appreciation of the personal prejudices (and vested
interests of) the individual in question. With an explanation of why
something could be regarded as a best practice it is possible to asses
the proposal on the merits of the argument made for it. So, for example,
when Gérard Talbot proposes:-
document.forms.namedItem("formname").elements.namedItem("inputname")
- as, in some sense, a "best practice" (or "correct practice") in
accessing form controls, and supports that assertion with the
justification:-
"The web standards way to reference a form input element is:"
- it is possible to assess the suggestion on the basis of its
justification. And observe that the proposal is no more (and no less)
"web standards" than the more ECMAScript-style and more cross-browser:-
document.forms["formname"].elements["inputname"]
That is, because there was a justification for the assertion it is
possible to determine with certainty that it is bogus. Any practice
proposed with a justification that cannot be as easily dismissed stands
a much better chance of qualifying as a "best practice".
Your page makes no justifications for the items it proposes as "best
practice" and so is reduced to a sequence of personal assertions. And
some of them are distinctly odd in context. For example, you propose
that people use bracket notation, seemingly to the exclusion of dot
notation (insane as that would be). I am not even sure that using
bracket notation qualifies as a "practice" (in the sense of "best
practice") at all. The best that can be said of bracket notation in the
direction of "best practice" is that it should not be disregarded when
using property accessors (particularly in favour of eval). But that is
really just proposing that it is "best practice" to be familiar with the
constructs, syntax, and behaviour of the language you are writing in
(which is a bit too obvious an assertion to have been explicitly stated
in any code authoring standards document that I have read to date).
Without any justification for the proposed "best practices", and so
their reduction to the status of personal assertions, it is interesting
to note the number of links in the page to technical articles written by
others. That seems almost a rhetorical ploy; the quality of the advice
given on the page is bolstered by the quality of the material referenced
from the page.
On the whole your page is too superficial to justify its title, and the
items covered are more reminiscent of a trivial FAQ than what it
purports to be. Much that is widely held to be "best practice", in
javascript or in programming in general is not mentioned at all. For
example, the formal structuring and block indenting of development code
(and the imposition of a single style of such formatting within
organisations) is certainly a "best practice", but gets no mention.
On the other hand, given your record of unusual applications of meaning
to English statements perhaps the inappropriate title is just another
manifestation of that.
Richard.
Richard Cornford
> Michael Winter a écrit :
>> On 12/10/2005 04:56, Gérard Talbot wrote:
>>
>> [The all collection]
>>
>>> Useful purpose for IE 5.x? Can you elaborate on this? what do you
>>> mean...
>>
>>
>> The getElementsByTagName method is not implemented properly in IE5.x.
>> Passing an asterisk (*) will always return an empty collection,
>
> I didn't know that.
This should not be particularly surprising as the '*' wildcard for tag
names is not mentioned in the W3C Core DOM Level 1 standard, and IE 5
was (at best) a DOM Level 1 browser. This is also true for Opera <= 6
and NetFront 4, for example.
<snip>
> IMO, tricks based on + and -0 can not be the best recommendable
They are not tricks, they are just type-conversion. An aspect of a
loosely-typed language that authors need to appreciate. If forced
type-conversion is wanted only two constructs can be recommenced; Unary
+, because it is the fastest technique (so the best to use when speed
matters) and passing the numeric string as the argument to the -
Number - constructor called as a function, because it is
self-documenting (and so should be used when clarity of source code is
desired).
It is often proposed that when Unary + is used the unary expression
should be parenthesised so that the + symbol is not easily mistaken for
addition/concatenation or typoed pre and post increment.
> way to convert a string to a number. parseInt or parseFloat
> should be used instead.
Apart from their unexpected treatment of some forms of input (which
should be precluded with regular expression validation of numeric
strings where there is doubt) parseFloat and parseInt are the slowest
method of turning a string into a number and less self-documenting than
the use of the Number constructor (though javascript authors should be
familiar enough with them for that not to be a real problem).
> One example: Javascript Bible 4th edition by D. Goodman on
> "Converting strings to numbers" p.78-79. Not one word on +
> and - tricks: everything in his words clearly refers to the
> use of parseInt and of parseFloat.
> Is he way off the fact and the matter?
Danny Goodman is so 'way off' that the best advice would be to burn his
books unread. He has done enough harm to javascript authoring already.
Richard.
Gérard Talbot
> JRS: In article <28ydnUsTDYQ...@comcast.com>, dated Tue, 11 Oct
> 2005 23:15:34, seen in news:comp.lang.javascript, Randy Webb
> <HikksNo...@aol.com> posted :
>
>>Sidenote: The major problem with innerHTML is when the string being
>>assigned is plain text. innerHTML has been proven, repeatedly, to be
>>considerably slower that DOM methods or even the IE proprietary
>>innerText property.
>
>
> Which in the majority of cases is totally unimportant. Since the aim is
> to change the information presented to the mind of the user, the time
> taken is usually significant only if it exceeds about 200 ms.
>
The question remains though: what's the *best practice* (for beginners,
intermediate users, etc) when the string being assigned is plain text.
Most of us will grant you that the gain in time is negligeable if the
string is short and if the user system resources are considerable.
When is it best to use innerHTML? When is a DOM method a better choice
over innerHTML?
This page:
innerHTML VS DOM.
http://www.developer-x.com/content/innerHTML/default.html
suggests there are more problems with usage of innerHTML.
Michael Winter
> Michael Winter a écrit :
[snip]
>> Unless one is iterating through a collection, using numeric indices is
>> not a recommended practice
>
> Matt K. explicitly states that numeric indices is a bad practice.
> "Referencing forms using indexes, such as document.forms[0] is bad
> practice."
And I'm saying more-or-less the same thing. Just less strongly.
[snip]
>> As you were told in ciwah, validation is not a goal in itself. There can
>> be justified reasons for writing invalid markup[1],
>
> I don't recall being told that.
Which part?
You certainly were told the former in the recent '3 questions on
validation' thread. For instance, the first response by Travis Newbury:
You seem to have missed the point that validation is a "tool" not
a "goal"
-- Travis Newbury,
<1128011997.6...@g43g2000cwa.googlegroups.com>
I'm saying the latter now, though others have in other discussions. So
did Jukka in his article, '"HTML validation" is a good tool, but just a
tool'[1], which he referenced in the same thread as the quote above.
[snip]
> A document about javascript best practices can not and should not rule
> out/exclude people who serve XHTML document as application/xhtml+xml.
Serving a non-trivial script with a document served as
application/xhtml+xml is often a completely different kettle of fish as
the objects models are different, and would warrant its own document.
Anyway, if an author is knowledgeable enough to correctly
content-negotiate a document, then they should know enough to correctly
transfer remarks about HTML to XHTML.
>> That is a better use of your time than worrying about a single attribute.
>
> Somehow the tone of your post has become personal. All my posts were
> referring to the draft document.
My apologies. That sentence wasn't directed at you. It was the sloppy
use a of second-person pronoun meant generically in text that used the
fourth-person in that situation, more often than not. The word, "your",
should have been "one's".
[snip]
> So what's the big deal with numeric indice?
It isn't a 'big deal', but an identifier is immune to markup changes
whereas an index may not be. But still, and I reiterate (again), I'd
recommend using element references wherever possible and avoid the issue
entirely.
> All I can read in the document is a simple directive in the document
> regarding numeric indice: no explanation as to why such directive and no
> recommended solution for XHTML-based documents.
If an author wants to write valid XHTML markup, but needs to be told to
use an id attribute in place of a name attribute (or see above), I think
the author may need a career change.
[A missing action attribute]
> When should someone bring this up then? When a "HTML Best Practices"
> document is released?
Forms are designed to be submitted. The action attribute is used to
specify where the data is sent. Ergo, an author is almost certainly
going to include one, anyway. I doubt that any reader of Matt's document
will stop just because he omitted it in a trivial example.
I have no problem with him including a dummy attribute value, but it
really isn't a big deal if he doesn't.
And yes, an 'HTML best practices' article would be more on-topic. :D
[Converting to number]
> Ok, what about parseFloat() then? I mentioned it in my original post.
It still does more than necessary with no added advantages in return.
[snip]
> IMO, tricks based on + and -0 can not be the best recommendable way to
> convert a string to a number.
Subtracting zero is a trick, and I don't recommend it either. However,
the unary plus operator is not a trick.
The unary + operator converts its operand to Number type.
-- Section 11.4.6, ECMA-262 3rd Ed.
> One example: Javascript Bible 4th edition by D. Goodman [...]
Danny Goodman is not a recommended author in this group and neither is
his book. I haven't read it, but from what I have seen from him, I'm
inclined to agree.
[snip]
> Ok. Let me repeat what you've said so that no one gets you wrong. You
> say Matt K. in that document is not defining a general rule regarding
> the use of returning false in an onclick even attribute.
That is correct. That entire section of the article only refers to A
(anchor) elements. The references to 'link', 'anchor', or 'href' in the
first three paragraphs (of five), plus the heading and examples should
make that very clear.
[snip]
Mike
[1] "HTML validation" is a good tool, but just a tool
<URL:http://www.cs.tut.fi/~jkorpela/html/validation.html>
Matt Kruse
>> The use of "libraries" will always be a debate among
>> regulars of this group.
> It isn't debated that much, the only people who seem to argue in
> favour of libraries are individuals who have libraries to promote.
It makes sense that if you favor an approach to development, that you would
have something to offer which takes that approach. Much the same way that
you 'promote' closures and offer documentation and example scripts using the
approach.
> When we have the
> debate the majority of expressed opinion has always been against the
> use of monolithic generalised libraries as an inappropriate concept
> in browser scripting.
Few would argue in favor of 'monolithic' generalised libraries. Libs with a
specific purpose and just a little extra 'code bloat' as some might call it
is a different story entirely. You often confuse the two.
> Here
> you are arguing for expedience, but "best practice" most definitely
> is about ideals that should be aspired to and not short term
> expedience.
The two goals are not mutually exclusive. A developer may need a short-term
solution, yet be interested in learning to do things the 'right' way
long-term.
> So a developer who either could not write the code they had undertaken
> to create, or could not accurately/effectively schedule their tasks
> gets to conceal their incompetence form their employer while reducing
> the viability (and so potential profitability) of whatever they have
> created?
Ridiculous statement.
I've used many 3rd-party Java libraries which I certainly would not be able
to develop on my own. Yet I benefitted by being able to deliver more
advanced functionality in a shorter timeline.
You seem to argue in favor of writing everything of scratch, which is
absurd. You surely don't follow that reasoning yourself. You just define it
differently to suit your needs.
> So your public support for libraries in general, and repeated
> promotion of your own libraries, is not without some financial
> motivation, and direct returns?
I do not 'promote' my libraries. I offer them as solutions to specific cases
in this group where my already-developed solution matches exactly what the
poster needs. There is no financial motivation. There may be some financial
reward, but it is certainly not a motivating factor.
> Anyway, to the "best practices" page; What I like to see when someone
> proposes something as a "best practice" is an explanation of why it
> might be considered a best Practice.
This is a valid thought, and I had considered adding a "Why?" link which
would open up a pre-hidden DIV explaining in a little more detail the
rationale behind the recommendation.
> Your page makes no justifications for the items it proposes as "best
> practice" and so is reduced to a sequence of personal assertions.
As is any recommendation. Having a detailed justification doesn't make it
any more 'correct', and readers are still open to disagree with the
justification. Any 'truth' is only as good as your faith in the person
telling it to you. But philosophy is not really on topic...
> For example, you propose
> that people use bracket notation, seemingly to the exclusion of dot
> notation (insane as that would be).
For any developer who doesn't know enough to decide for themselves to do
differently, I think it is the 'safest' recommendation. It will certainly
lead to fewer problems and less confusion for the average web developer.
> On the whole your page is too superficial to justify its title
On the contrary, I've received great feedback so far from many others who
said they immediately benefitted from it.
Javascript is a mystery to many. A short, concise, easy to understand
document such as thing can be very valuable to those who may be experienced
programmers but just want a push in the right direction when it comes to
javascript. The FAQ is great, but it's too big, too long, and too bloated to
be scanned quickly in a lunch break by someone who wants to avoid typical
day-to-day JS problems.
For one who criticizes so much, I would expect to see your alternative 'Best
Practices' document offered on the web somewhere. It is conspicuously
absent.
Randy Webb
> Matt Kruse a écrit :
>
<snip>
>> Well, then we disagree. I use href="#" all the time within web apps
>> that require javascript. Especially when there are hundreds of links
>> on a page, having each one contain a useless href is pointless, when
>> the user is known to have javascript enabled. You're welcome to write
>> and publish your own Best Practices document :)
>
>
> WCAG groups and J. Nielsen have already written on this whole issue.
> A script triggered by an onclick event handler in a link should not do a
> lot more than a plain vanilla link does otherwise you're not using a
> link for its intended purpose to begin with. In such case, you may be
> misusing the <a> element; a <button type="button"
> onclick="doSomething();"> would most likely be better markup usage,
> better semantic.
And is totally useless with JS disabled.......
Matt Kruse
> It wouldn't take a lot more typing to correct this. Writing valid
> markup code shouldn't be a luxury in your document. Just consider
> what your document aspires to present: javascript best practices.
I've updated a few places pointed out to be more 'correct', fwiw.
>> Well, then we disagree. I use href="#" all the time within web apps
>> that require javascript.
> WCAG groups and J. Nielsen have already written on this whole issue.
> A script triggered by an onclick event handler in a link should not
> do a lot more than a plain vanilla link does otherwise you're not
> using a link for its intended purpose to begin with.
So?
1) Using things for their intended purpose leads to less innovation. The web
wouldn't be where it is at now if people only used things for their
'intended purpose'.
2) Links are often preferred for triggering javascript functionality because
of design issues. For example, a DIV showing a list of matches to a
partially-filled input box may be <a> links which trigger a function to
populate the box. Having them as buttons would be ridiculous. And sometimes,
links just look and behave better.
3) J. Nielsen is not god. I think he's right on many points, and
ridiculously wrong on many points. I lose no sleep when he disagrees with
me.
Randy Webb
> JRS: In article <28ydnUsTDYQ...@comcast.com>, dated Tue, 11 Oct
> 2005 23:15:34, seen in news:comp.lang.javascript, Randy Webb
> <HikksNo...@aol.com> posted :
>
>>Sidenote: The major problem with innerHTML is when the string being
>>assigned is plain text. innerHTML has been proven, repeatedly, to be
>>considerably slower that DOM methods or even the IE proprietary
>>innerText property.
>
>
> Which in the majority of cases is totally unimportant. Since the aim is
> to change the information presented to the mind of the user, the time
> taken is usually significant only if it exceeds about 200 ms.
Then why is it that with this code:
var s="10";
var t="12";
var total = Number(s) + Number(t);
alert(total);
That you are one of the first ones to point out:
"Don't convert Strings to Numbers that way, use the unary + because its
*faster*"
Either its speed or its "good enough". Whats the standard?
> My Holidays page computes and writes a whole annual holidays table
> (about 1.5 windows high) covering 6 years, using DynWrite, in a
> perceptible fraction of a second, on a 300 MHz PII. That's good enough.
And if you writing an entire holidays table then you are writing HTML
and not text so your comparison is irrelevant.
But that aside, the standard I have for myself is not to be "good
enough", it's to be the best that I can.
Randy Webb
> The FAQ is great, but it's too big, too long, and too bloated to
> be scanned quickly in a lunch break by someone who wants to avoid typical
> day-to-day JS problems.
Ditto. It's becoming an "FAQ Book", not an FAQ document. Maximized at
1280x1024, it is somewhere around 20 pages long. I am scared to see how
many pages long it is at 800x600 or so.
Randy Webb
> Randy Webb wrote:
>
>>[snip]
>
>
> I've corrected a few of the things you've suggested. Thanks!
Sure thing. Maybe some day when I get around to creating a good test
page, you can test one of my day dream creations.
>
>>The only major problem with the whole page is the last few lines about
>>using Libraries which I totally disagree with. A newbe shouldn't be
>>using tools that they don't understand...
>
>
> The use of "libraries" will always be a debate among regulars of this group.
They have advantages and disadvantages. The best you and I can do is
agree to disagree on them. To each his own, ya know?
Richard Cornford
> Richard Cornford wrote:
>>> The use of "libraries" will always be a debate among
>>> regulars of this group.
>> It isn't debated that much, the only people who seem
>> to argue in favour of libraries are individuals who
>> have libraries to promote.
>
> It makes sense that if you favor an approach to development,
> that you would have something to offer which takes that
> approach.
"Something to offer" is a bit of a loaded term.
> Much the same way that you 'promote' closures and offer
> documentation and example scripts using the approach.
I do not "offer" anything. I have written and published explanations of
closures and example of their application. I have also written
extensively on my approach to browser scripting, and published numerous
specific examples. If you have not seen them then that is probably
because you have not been looking.
>> When we have the debate the majority of expressed
>> opinion has always been against the use of monolithic
>> generalised libraries as an inappropriate concept
>> in browser scripting.
>
> Few would argue in favor of 'monolithic' generalised
> libraries.
Few here would, but they are argued in favour of.
> Libs with a specific purpose and just a little extra
> 'code bloat' as some might call it is a different story
> entirely.
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. Every time you need to do something
you must do it in the most general way available, while many actual
applications may preclude much of what the general code must take into
account. Allowing simpler, faster, more specific code to be used in its
place, if that general approach was not lost in the depths of an
interdependent library file. 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.
So they are not entirely different stories. Your strategy is a reduction
of a significant problem that is present in monolithic generalised
libraries, but only a small reduction offering diminishing returns as
more of your libraries are used together.
A layered approach to code re-use where systems are built upon many low
level components providing small sets of facilities to all the higher
layers in the system allows the minimisation of redundant code in any
application, and allows the choosing of components that provide those
facilities in a way that closely matches the context in which they are
used, removing the overheads of being general in the face of the
specific. Thus providing the benefits of code re-use for efficient
software authoring but avoiding the bloat and overheads inherent in high
level self-contained general libraries.
> You often confuse the two.
The two are not sufficiently different to justify the distinction in
many cases. If you propose that the reduction in code bloat achieved by
moving form monolithic generalised libraries to task specific libraries
is an important difference then the fact that the remaining inherent
code bloat can largely be removed by adopting a third strategy makes
drawing a distinction between the two less effective strategies
superfluous.
>> Here you are arguing for expedience, but "best practice"
>> most definitely is about ideals that should be aspired
>> to and not short term expedience.
>
> The two goals are not mutually exclusive.
But short-term expedience is not a justification for a particular
practice as a "Best Practice".
> A developer may need a short-term solution, yet be interested
> in learning to do things the 'right' way long-term.
Or, more likely, recognise a best practice but see expedience as a
reason for not employing it in a specific context.
>> So a developer who either could not write the code they
>> had undertaken to create, or could not accurately/effectively
>> schedule their tasks gets to conceal their incompetence form
>> their employer while reducing the viability (and so potential
>> profitability) of whatever they have created?
>
> Ridiculous statement.
> I've used many 3rd-party Java libraries which I
> certainly would not be able to develop on my own.
And Java is a language where the use of libraries is fundamental to the
language's design.
> Yet I benefitted by being able to deliver more
> advanced functionality in a shorter timeline.
And the relevance of Java authoring to browser scripting is?
> You seem to argue in favor of writing everything of scratch,
You know that I don't.
> which is absurd.
As it would be, if true.
> You surely don't follow that reasoning yourself. You just
> define it differently to suit your needs.
>
>> So your public support for libraries in general, and
>> repeated promotion of your own libraries, is not without
>> some financial motivation, and direct returns?
>
> I do not 'promote' my libraries.
Oh yes you do. Look at the domain names you have purchased and tell me
you are not in the business of promoting your scripts.
> I offer them as solutions to specific cases in this group
> where my already-developed solution matches exactly what
> the poster needs.
If that was actually true your activities would not have attracted any
comment. You frequently propose the use of your scripts without any
indication that the OP is working in the restricted contexts in which
many of them are appropriate, or any indication that the OP is capable
of doing the extra work necessary to deploy them in a reliable way in
the default Internet context (and given the attitude towards "average
web developers" expressed below it appears that your assumption would be
that they were incapable of undertaking that extra work).
> There is no financial motivation. There may be some
> financial reward, but it is certainly not a motivating
> factor.
Ira Baxter also maintains that it is not the financial return that
leaves her promoting her obfuscator in the face of the reasoned
arguments for its futility. It looks like behaviour that can only be
explained by a vested interest or mental illness.
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. So
encountering persistent intransigence suggests questioning its
motivation.
>> Anyway, to the "best practices" page; What I like to see
>> when someone proposes something as a "best practice" is
>> an explanation of why it might be considered a best Practice.
>
> This is a valid thought, and I had considered adding a
> "Why?" link which would open up a pre-hidden DIV explaining
> in a little more detail the rationale behind the
> recommendation.
That seems a needlessly complicated approach to presenting necessary
information, but let us know when it is done as it is the rational
behind a recommendation that is necessary in assessing its worth.
>> Your page makes no justifications for the items it proposes
>> as "best practice" and so is reduced to a sequence of personal
>> assertions.
>
> As is any recommendation. Having a detailed justification
> doesn't make it any more 'correct', and readers are still
> open to disagree with the justification.
The point of providing a justification for any recommendation is
precisely so that the reader can disagree with the recommendation. Any
proposed "Best Practice" that has a flawed or hollow justification is
unlikely to actually be a "Best Practice". You need to know why
something is being proposed in order to see what it is that makes it a
"Best Practice". And is something really is a "Best Practice" there
should be a really good reason for that being the case.
> Any 'truth' is only as good as your faith in
> the person telling it to you.
Truth is based entirely on an appeal to authority? You cannot really
believe that?
> But philosophy is not really on topic...
Epistemology is entirely relevant to the question of identifying "Best
Practice" form a set of proposed "Best Practices".
>> For example, you propose that people use bracket notation,
>> seemingly to the exclusion of dot notation (insane as that
>> would be).
>
> For any developer who doesn't know enough to decide for
> themselves to do differently,
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.
> I think it is the 'safest' recommendation.
So your are proposing that bracket notation should be used to the
exclusion of dot notation (and proposing it as a "best practice")? Such
a proposal is insane. Bracket notation is slower than dot notation
because of the additional requirement to evaluate the expression within
the brackets and type-convert the result to a string. It should be the
less used property accessor, with bracket notation being used where it
is necessary, and possibly where it contributes to source code clarity
(such as in differentiating between names originating in the HTML and
the javascript).
> It will certainly lead to fewer problems and less
> confusion for the average web developer.
Only if the "average web developer" really is a headless chicken. The
very worst web developers may well be that incapable of understanding
what they are doing, but for the majority the real solution to not
knowing enough to "decide for themselves" is to provide the explanation
that would facilitate informed decision making.
>> On the whole your page is too superficial to justify
>> its title
>
> On the contrary, I've received great feedback so far from
> many others who said they immediately benefitted from it.
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.
> Javascript is a mystery to many. A short, concise, easy
> to understand document such as thing can be very valuable
> to those who may be experienced programmers but just want
> a push in the right direction when it comes to javascript.
And a short concise easy to understand document can also do significant
harm, depending on its contents. Being short is not of itself a good
thing, when the result can be too superficial to promote understanding.
But then if you start form the presupposition that the average web
developer is incapable of achieving a technical understanding of what
they are doing omitting all technical explanation may seem more
justified than its inclusion.
> The FAQ is great, but it's too big, too long, and too
> bloated to be scanned quickly in a lunch break by
> someone who wants to avoid typical day-to-day JS problems.
This group's FAQ is quite big, and all the pressure is to make it
bigger. It never was designed to be read in a lunch break. 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.
> For one who criticizes so much, I would expect to see your
> alternative 'Best Practices' document offered on the web
> somewhere. It is conspicuously absent.
You see a superficial document as appropriate in addressing the question
of "Best Practice", I don't. 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 intention was to lay down formal
rules and "Best Practices" to be followed by our sub-contractors in
creating javascript (but inevitably, once formalised, those same rules
would also have to be followed internally). The resulting document is 50
sides of A4 and does no more than lay down rules that will be followed.
The criteria for choosing those rules, the reasoning behind them, the
arguments about them and the decision making that resolved those
arguments are not part of that document. They were the subject of
discussion in various meetings and extensive e-mail conversations, and
then only when a specific "Best Practice" was subject to disagreement
(as most were adopted without opposition or debate).
I think that a document about "best Practices" should be about best
practices, rather than a list of practices that one individual believes
to be "best Practices". So such a document has to include the
explanations/justifications that allow the reader to understand why a
practice is being proposed, what benefits are expected to follow from
its adoption, and how its adoption is likely to impact upon other
aspects of the scripting task. And for me such a document should include
practices that are argued as best practices but with which I personally
disagree, along with their justifications. The result should be a
document that allowed reader to cherry-pick the set of "best practices"
that best suited their authoring context, and do so on the basis of
informed decision making.
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?
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.
Richard.
Matt Kruse
> [snip]
Richard, your posts are too verbose to be responded to in detail, and we've
disagreed on this before. As I've said before, you're an intelligent guy and
you do good stuff, but your perspective is very different from mine. Your
experience with Javascript is not the norm. In my experience with many web
developers, Javascript is this piece-of-crap scripting language that they
have to deal with and struggle with. It gets in the way of what they want to
do, but they have to use it. Many have no interest in learning the language
or its quirks, nor do they want to spend hours learning best practices of
FAQs.
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?
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? Or do
you offer a generalized library that might have some 'bloat' but
accomplishes the task way better than they would have written themselves?
Not everyone wants to be a javascript expert. You do. That's nice. But don't
pigeon-hole everyone into your mindset.
> 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.
The point is - who cares? If it's an extra 5k or even 10k, that is often way
over-shadowed by graphics sizes, flash, etc.
If your goal is to create tight, compact pages, then fine - don't use libs.
But that is _NOT_ a requirement for most people.
The convenience of using a lib with a little code bloat is more important
than the extra few k of text that is downloaded.
> 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.
Not if used correctly.
>> Yet I benefitted by being able to deliver more
>> advanced functionality in a shorter timeline.
> And the relevance of Java authoring to browser scripting is?
Same concept, different language/environment.
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.
> 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.
I'd say that I definitely fall into that categorization.
> The point of providing a justification for any recommendation is
> precisely so that the reader can disagree with the recommendation.
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. Or
they may not even care. They just want their stuff to work.
> 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.
It describes the reality in _many_ organizations, and _many_ individuals.
You don't see regularly how many people _DESPISE_ javascript?
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.
>> On the contrary, I've received great feedback so far from
>> many others who said they immediately benefitted from it.
> 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.
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.
> 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.
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.
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. 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.
> 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.
Such a document would be completely worthless to most web developers.
> 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?
There is value in partially solving a problem.
If you can add value in a specific area, even without solving the entire
problem, that is a good thing.
A 'Best Practices' document doesn't need to cover everything. IMO.
> 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.
I'm realistic. You're idealistic.
I'm practical. You're a perfectionist.
I cater to the masses. You cater to those you deem worthy.
I understand the problems of the average developer. You tell them to RTFM.
I prefer my view.
Dr John Stockton
19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
<newsbl...@gtalbot.org> posted :
>Matt K. explicitly states that numeric indices is a bad practice.
>"Referencing forms using indexes, such as document.forms[0] is bad
>practice."
If he wrote only that about it, he's wrong, through not giving the
possibilities adequate consideration.
Using fixed numeric indices to refer to what could be a named form is
indeed bad, since the page might get edited into another order. If a
page clearly will only ever have a single form, the practice is
harmless.
If one must iterate through all forms, then sing varying numeric indices
is reasonable, perhaps inevitable.
And if for some unaccountable reason one were to need to refer, say, to
the form which comes third, even after possible rearrangement, then a
fixed index would be appropriate.
>>>> [The parseInt function is] overkill in most cases. The value should
>>>> have been validated already, so all that's necessary is to convert
>>>> the value which the unary plus operator does very well.
>>>
>>>
>>> I don't agree with you. parseInt function original purpose (specific
>>> purpose, defined task) is to parse a string and convert it into
>>> integers.
>>
>>
>> If the string has been validated as a number, which it should have been,
>> then the only operation that is needed is conversion. The sole purpose
>> of the unary plus operator is to convert its operand to a number. The
>> parseInt function, on the other hand, parses only to an integer -
>> totally different and often not as useful.
>
>Ok, what about parseFloat() then? I mentioned it in my original post.
>
>>
>>> Isn't it what Matt Kruse' code wanted to specifically achieve
>>> to begin with?
>>
>>
>> No. Matt describes string to number conversion, not string to integer.
>>
>>> + is an overloaded operator; it's not even a function.
>>
>>
>> The addition operator and the plus (+) symbol itself is overloaded. The
>> unary plus operator is not. That the latter isn't a function is utterly
>> irrelevant.
>>
>
>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.
>One example: Javascript Bible 4th edition by D. Goodman on "Converting
>strings to numbers" p.78-79. Not one word on + and - tricks: everything
>in his words clearly refers to the use of parseInt and of parseFloat. Is
>he way off the fact and the matter?
Yes, but the book does date from before the matter was (possibly first)
raised here.
Dr John Stockton
Oct 2005 00:52:31, seen in news:comp.lang.javascript, Richard Cornford
<Ric...@litotes.demon.co.uk> posted :
>Matt Kruse wrote:
>> The use of "libraries" will always be a debate among
>> regulars of this group.
>
>It isn't debated that much, the only people who seem to argue in favour
>of libraries are individuals who have libraries to promote. It seems
>that the vested interest and unwillingness to abandon the time already
>invested tends to encourage intransigence. When we have the debate the
>majority of expressed opinion has always been against the use of
>monolithic generalised libraries as an inappropriate concept in browser
>scripting.
One should, however, distinguish in debate between at least two distinct
forms of bloat javascript bloat.
(0) Writing multiply-repeated code, for example to add a leading zero or
to check that a field is non-empty, when it would be perfectly simple to
write a function (or method) to be called multiple times.
(1) Putting a large number of perhaps well-written functions in a single
include file, so that all readers of any page that uses any of the
functions must fetch the whole lot.
(2) Writing and using a single large function to do many varieties of
one thing, perhaps controlled by parameters, when only one variety will
be used at any given time, but the whole must be loaded. Example, a
function to read and validate a date in various field orders, possibly
with suffices, possibly with months in letters, in various languages,
possibly with roman numerals. Writing it as an exercise is harmless;
deployment in full is generally wasteful.
>> But _reality_ is something different. Most people don't want
>> to learn a lot about javascript, or don't have time to
>> implement a generalized cross-browser solution to some problems.
>
>It is perverse to state this in the context of a request for comments on
>a document that asserts that its subject is "best Practices". Here you
>are arguing for expedience, but "best practice" most definitely is about
>ideals that should be aspired to and not short term expedience.
You think that, Richard : but then you're not a Merkin. Perhaps the
document should be called "Javascript for dummies", though IIRC that
title has already been taken.
Dr John Stockton
2005 23:33:07, seen in news:comp.lang.javascript, Randy Webb
<HikksNo...@aol.com> posted :
>Dr John Stockton said the following on 10/12/2005 4:59 PM:
>
>> JRS: In article <28ydnUsTDYQ...@comcast.com>, dated Tue, 11 Oct
>> 2005 23:15:34, seen in news:comp.lang.javascript, Randy Webb
>> <HikksNo...@aol.com> posted :
>>
>>>Sidenote: The major problem with innerHTML is when the string being
>>>assigned is plain text. innerHTML has been proven, repeatedly, to be
>>>considerably slower that DOM methods or even the IE proprietary
>>>innerText property.
>>
>>
>> Which in the majority of cases is totally unimportant. Since the aim is
>> to change the information presented to the mind of the user, the time
>> taken is usually significant only if it exceeds about 200 ms.
>
>Then why is it that with this code:
>
>var s="10";
>var t="12";
>var total = Number(s) + Number(t);
>alert(total);
>
>That you are one of the first ones to point out:
>
>"Don't convert Strings to Numbers that way, use the unary + because its
>*faster*"
The apparently quoted sentence is making a general statement about
string-to-number conversion, prompted (you say) by the code above; it
makes no claim that the particular example would execute perceptibly
faster.
For string-to-number, unary + has several advantages. It's faster to
type and faster to download, being briefer. It never treats a pure
decimal digit string as other than decimal; no concern about forgetting
the parameter 10.
And it's possible to use it in a loop that takes longer than user
reaction time, so that a gain in speed is not useless.
>Either its speed or its "good enough". Whats the standard?
>
>> My Holidays page computes and writes a whole annual holidays table
>> (about 1.5 windows high) covering 6 years, using DynWrite, in a
>> perceptible fraction of a second, on a 300 MHz PII. That's good enough.
>
>And if you writing an entire holidays table then you are writing HTML
>and not text so your comparison is irrelevant.
Writing and executing HTML will take at least as long as writing and
displaying a similar amount of plain text. Therefore if HTML is not too
slow, plain text will not be.
So I tested with plain text; DynWrite took under 100 ms to write 15000
characters (in eval(), too). That's well over a screenful. So my point
is mow better demonstrated.
>But that aside, the standard I have for myself is not to be "good
>enough", it's to be the best that I can.
Then why are your criticisms nowadays always so ill-judged? ... must be
the best that you can do.
Randy Webb
Oh geez John, you get worse and worse everyday. Let me find you another
quote that I recall:
<quote>
Once upon a time, you made only intelligent remarks.
</quote>
You are beginning to fit that bill. You can't seem to make up your mind
what practices you want to suggest/follow. It seems to depend on the day
of the week.
Your perception that "innerHTML is good enough" is just plain ignorant
at best.
> For string-to-number, unary + has several advantages.
And several disadvantages.
> It's faster to type and faster to download, being briefer.
If you type so slow that typing Number takes you that much longer than
typing +, then you don't need to be writing code, you need to be taking
typing lessons.
And, are you really serious about the "faster to download" when it comes
to 5 characters of data?
> It never treats a pure decimal digit string as other than decimal;
> no concern about forgetting the parameter 10.
I wrote nothing about the parameter 10 which Number does not need. I
used Number for that very specific reason instead of parseInt and
parseFloat.
But, are you saying that Number(k) will treat a pure decimal digit
string as anything other than decimal?
> And it's possible to use it in a loop that takes longer than user
> reaction time, so that a gain in speed is not useless.
So now you use it for speed but use the slower innerHTML because its
"good enough"?
Main Entry: hyp·o·crite
Pronunciation: 'hi-p&-"krit
Function: noun
Etymology: Middle English ypocrite, from Old French, from Late Latin
hypocrita, from Greek hypokrites actor, hypocrite, from hypokrinesthai
: a person who puts on a false appearance of virtue or religion
- hypocrite adjective
>
>>Either its speed or its "good enough". Whats the standard?
>>
>>
>>>My Holidays page computes and writes a whole annual holidays table
>>>(about 1.5 windows high) covering 6 years, using DynWrite, in a
>>>perceptible fraction of a second, on a 300 MHz PII. That's good enough.
>>
>>And if you writing an entire holidays table then you are writing HTML
>>and not text so your comparison is irrelevant.
>
>
> Writing and executing HTML will take at least as long as writing and
> displaying a similar amount of plain text. Therefore if HTML is not too
> slow, plain text will not be.
The time it takes will be directly proportional to the amount of HTML
that is in the string.
> So I tested with plain text; DynWrite took under 100 ms to write 15000
> characters (in eval(), too). That's well over a screenful. So my point
> is mow better demonstrated.
No, writing plain text using innerHTML will NOT show its speed problems.
Perhaps you should test the DOM2 methods to inject plain text into a
wrapper element. But does your antiquated IE4 support it?
>
>>But that aside, the standard I have for myself is not to be "good
>>enough", it's to be the best that I can.
>
>
> Then why are your criticisms nowadays always so ill-judged? ... must be
> the best that you can do.
It probably would be the "best that I can do" if I aspired to be only as
good as you. I have higher goals/standards/expectations than that for
myself - you should consider doing the same. It would help you tremendously.
Now, you can babble all you want. I have better things to do than argue
with you about your ignorance of what you are writing about. Stick to
numbers and dates, they are your strong point. dHTML and the speed of it
is not.
John G Harris
<j...@merlyn.demon.co.uk> writes
>JRS: In article <3r5kl8F...@uni-berlin.de>, dated Wed, 12 Oct 2005
>19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
><newsbl...@gtalbot.org> posted :
<snip>
>>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.
<snip>
Not funny. This newsgroup is read by beginners; we mustn't trick them
into writing ParseInt (with a capital P).
DB is an abbreviation for database.
dB is a ratio.
dBaseII is (was?) a trade mark.
DBaseII is not, or is a different trade mark.
mW powers your torch.
MW melts scrap metal.
John
--
John Harris
Gérard Talbot
<body onload="document.getElementById('idParg').style.display =
'block';" (...)>
(...)
<p id="idParg" style="display: none;"><button type="button"
onclick="doSomething();">Some caption describing action</button></p>
If JS is enabled, then the button will be visible and usable. If JS is
disabled, the button won't be visible nor usable.
You may even use (toggle) alternate content depending on JS support
depending on what exactly the JS action is supposed to do, should do.
There are many possibities depending on the page goals.
I still insist that a link should be a link, should behave like a link,
should look like a link, etc... Otherwise, it's misusing markup code,
semantic markup code.
Gérard Talbot
> Gérard Talbot wrote:
>
>>It wouldn't take a lot more typing to correct this. Writing valid
>>markup code shouldn't be a luxury in your document. Just consider
>>what your document aspires to present: javascript best practices.
>
>
> I've updated a few places pointed out to be more 'correct', fwiw.
>
>
>>>Well, then we disagree. I use href="#" all the time within web apps
>>>that require javascript.
>>
>>WCAG groups and J. Nielsen have already written on this whole issue.
>>A script triggered by an onclick event handler in a link should not
>>do a lot more than a plain vanilla link does otherwise you're not
>>using a link for its intended purpose to begin with.
>
>
> So?
>
> 1) Using things for their intended purpose leads to less innovation.
This is over-exaggerated. This is confusing issues.
The web
> wouldn't be where it is at now if people only used things for their
> 'intended purpose'.
>
Using tables for page layout is not innovation.
Using dozens of <br> instead of CSS margin-top or margin-bottom is not
innovation.
Using dozens of instead of CSS padding or CSS text-indent is not
innovation.
Using empty <p></p> instead of CSS margin-bottom is not innovation.
Using <blockquote> to indent a section when such text section has
nothing to do with a quote is not innovation. etc..
There are billions of webpages which do just that which make their
webpages bloated, a nightmare tag soup mess impossible to update, slow
to download, etc..
> 2) Links are often preferred for triggering javascript functionality because
> of design issues. For example, a DIV showing a list of matches to a
> partially-filled input box may be <a> links which trigger a function to
> populate the box. Having them as buttons would be ridiculous. And sometimes,
> links just look and behave better.
>
If the <a> links brings up a new page content into a window, then it
would be adequate usage. I don't know for sure in the example you give
since I do not see, can not examine the example you are referring to.
What I am against is improper use of markup which will inevitably affect
the way conformant user agents will address such markup. It's about
software interoperability.
E.g.: A form submission should be using a button that looks/is/behaves
like a submit button, not a link (<a>). Search engines do not index
submit buttons but they will index links semantically used as links. A
lot of assistive technologies (speech browsers, translation features,
etc.) will try to render as best they can what is semantically coded as
links to begin with.
Regards,
Gérard Talbot
> I've updated a few places pointed out to be more 'correct', fwiw.
This is one of your change:
<form name="myform" action="[url]">
<input type="text" name="val1" value="1">
<input type="text" name="val2" value="2">
</form>
If the document is HTML 4.01 strict, it will still trigger a validation
error while
<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.
Michael Winter
[snip]
> <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.
True, but since when have INPUT elements been part of a paragraph? A DIV
or FIELDSET element is more appropriate.
Mike
Matt Kruse
> <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.
I don't see that as a compelling reason to change it.
Validation is a tool, not a goal in itself.
Matt Kruse
> The web
>> wouldn't be where it is at now if people only used things for their
>> 'intended purpose'.
> Using tables for page layout is not innovation.
Oh yeah? Were you around to remember when the <table> tag was introduced by
Netscape? It made page layout *possible*. Although it may not have been its
inteded purpose, it certainly was a huge step in moving the web towards more
where it is today.
Had everyone stuck to the rules that purists have about when to use tables,
the web would have been much uglier for much longer.
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 "semantically" wrong. It works. Better than the alternatives in
most cases.
There are many factors that must be taken into consideration when deciding
which approaches to use for the web. Validation is just one of those
factors, and for me it's very low on the list. People who put it at the top
are usually missing the point, IMO.
Randy Webb
> Randy Webb a écrit :
>
>> Gérard Talbot said the following on 10/12/2005 7:52 PM:
>>
>>> Matt Kruse a écrit :
>>>
>>
>> <snip>
>>
>>>> Well, then we disagree. I use href="#" all the time within web apps
>>>> that require javascript. Especially when there are hundreds of links
>>>> on a page, having each one contain a useless href is pointless, when
>>>> the user is known to have javascript enabled. You're welcome to
>>>> write and publish your own Best Practices document :)
>>>
>>>
>>>
>>>
>>> WCAG groups and J. Nielsen have already written on this whole issue.
>>> A script triggered by an onclick event handler in a link should not
>>> do a lot more than a plain vanilla link does otherwise you're not
>>> using a link for its intended purpose to begin with. In such case,
>>> you may be misusing the <a> element; a <button type="button"
>>> onclick="doSomething();"> would most likely be better markup usage,
>>> better semantic.
>>
>>
>>
>> And is totally useless with JS disabled.......
>>
>
> <body onload="document.getElementById('idParg').style.display =
> 'block';" (...)>
> (...)
> <p id="idParg" style="display: none;"><button type="button"
> onclick="doSomething();">Some caption describing action</button></p>
If you want a button that is JS dependent, then have JS generate that
button :)
JS generating the button also doesn't require as much feature detection
as the above onload /should/ do but doesn't.
> If JS is enabled, then the button will be visible and usable. If JS is
> disabled, the button won't be visible nor usable.
If the page error's any time before the onload fires, then the user
doesn't get the button even though scripting is enabled. That same
problem arises with the JS generated button though.
Randy Webb
> In article <TFyo9qDt...@merlyn.demon.co.uk>, Dr John Stockton
> <j...@merlyn.demon.co.uk> writes
>
>>JRS: In article <3r5kl8F...@uni-berlin.de>, dated Wed, 12 Oct 2005
>>19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
>><newsbl...@gtalbot.org> posted :
>
>
> <snip>
>
>>>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.
>
> <snip>
>
> Not funny. This newsgroup is read by beginners; we mustn't trick them
> into writing ParseInt (with a capital P).
And if you had written ParseInt then he would have undoubtedly noted
that it should be parseInt :-)
> DB is an abbreviation for database.
> dB is a ratio.
>
> dBaseII is (was?) a trade mark.
> DBaseII is not, or is a different trade mark.
>
> mW powers your torch.
> MW melts scrap metal.
>
Don't fret the good doc John, he isn't worth it :)
Although I personally think a "better practice" for converting a String
to a Number is by Number(string).
Gérard Talbot
That is also a possibility. I personally hate using document.write(),
even with a defer attribute ... but that's another ball game/discussion.
> JS generating the button also doesn't require as much feature detection
> as the above onload /should/ do but doesn't.
Your comment is interesting because it meets another point that I tried
to make in this thread. If your goal is to support modern browsers (1),
then why do you need to detect the support for getElementById ? I said
in my first post in this thread that MSIE 5.x support getElementById.
You gave examples and a how-to to support MSIE 4.x in your 1st draft of
your document and I still see that in your fallback recommendation for
that unique particular browser version. I disagree with such
recommendation. IMO, if an user visits a webpage that has/uses DHTML
with MSIE 4, then he should be told to upgrade, period. Your document
still keeps the door open to MSIE 4.
If I (or anyone) do not see a single reason as to resort to
document.all, document.all[] and document.all(), then I (or anyone)
should not see a single reason to verify the support for
document.getElementById() either.
>> If JS is enabled, then the button will be visible and usable. If JS is
>> disabled, the button won't be visible nor usable.
>
> If the page error's any time before the onload fires, then the user
> doesn't get the button even though scripting is enabled.
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) to
begin with and that the page context is under normal conditions... Of
course, if there is a tsunami happening or if the user unplugs his
computer as the document is loading, then the script won't achieve its
goals.
That same
> problem arises with the JS generated button though.
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>).
In this thread, I believe I've tried to bring up chunks of code,
references, more complete examples trying to substantiate my claims.
(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.
Gérard Talbot
> Gérard Talbot wrote:
>
>>The web
>>
>>>wouldn't be where it is at now if people only used things for their
>>>'intended purpose'.
>>
>>Using tables for page layout is not innovation.
>
>
> Oh yeah? Were you around to remember when the <table> tag was introduced by
> Netscape? It made page layout *possible*. Although it may not have been its
> inteded purpose, it certainly was a huge step in moving the web towards more
> where it is today.
Same thing with the invention of wheels and fire. That was then. Now is
much different. We live now in houses, work in buildings, etc.. which
are constructed, built according to standards, norms, checkings, laws,
etc... Don't get me wrong: I will always agree with you that the
invention of wheels and fire were major innovations.
>
> Had everyone stuck to the rules that purists have about when to use tables,
> the web would have been much uglier for much longer.
>
That's your opinion.
> I still use tables for layout. Why? Because it works consistently across
> browsers,
People are using more and more mobile devices for which tables and
nested tables used for layout cause accessibility problems. Less and
less people are using old browsers (MSIE 4, NS 4, etc.).
it's much easier to accomplish nice layouts that equivalent CSS
> layout, it degrades more consistently than CSS, and it's easier.
People are moving toward more CSS compliant browsers, not the opposite.
And there are now several dozens of freely available CSS templates which
can replace table design.
I don't
> care if it's "semantically" wrong. It works. Better than the alternatives in
> most cases.
We're a bit off topic here (you chose to address one single sentence of
my post - table design vs CSS).
I assure you that a "Javascript Best Practices" document should try to
be a model of quality in its content, in its example, in its design.
There is enough javascript copy-N-paste sites around promoting pretty
much anything/everything with overall typical "Krusty burger" quality.
> There are many factors that must be taken into consideration when deciding
> which approaches to use for the web. Validation is just one of those
> factors, and for me it's very low on the list.
Then you should clearly indicate this into your document. You should
explicitly indicate that your Javascript Best Practices document refers
to HTML pages, not XHTML pages. You should explicitly indicate in your
Javascript Best Practices that semantic and validation are very low
priorities, are not important issues, validation is just a tool,
whatever... It's your document: you should feel confortable with doing this.
People who put it at the top
> are usually missing the point, IMO.
I don't have Safari 1.x, Safari 2.x, Icab 3.x, etc.. installed on my
computer. Now, since I can not test my webpages with these browsers (and
a lot of other browsers and compliant user agents) and since I want to
support browsers and applications which are web standards compliant,
then my best shot is to write valid webpages in strict DTD. So, I
consider validation to be a 1st priority (not the sole one) when
finalizing the code of my webpages.
Gérard Talbot
> Randy Webb a écrit :
> You
I'm sorry Randy. Somehow, I thought I was replying to Matt K.
> gave examples and a how-to to support MSIE 4.x in your 1st draft of
> your document and I still see that in your fallback recommendation for
> that unique particular browser version. I disagree with such
> recommendation. IMO, if an user visits a webpage that has/uses DHTML
> with MSIE 4, then he should be told to upgrade, period. Your document
> still keeps the door open to MSIE 4.
Gérard
Randy Webb
True. Very true. But document.write is not the only way to dynamically
generate a button. Use the onload to trigger a function that will create
and append the button or insert it into a container.
>> JS generating the button also doesn't require as much feature
>> detection as the above onload /should/ do but doesn't.
>
>
>
> Your comment is interesting because it meets another point that I tried
> to make in this thread. If your goal is to support modern browsers (1),
> then why do you need to detect the support for getElementById ? I said
> in my first post in this thread that MSIE 5.x support getElementById.
> You gave examples and a how-to to support MSIE 4.x in your 1st draft of
> your document and I still see that in your fallback recommendation for
> that unique particular browser version. I disagree with such
> recommendation. IMO, if an user visits a webpage that has/uses DHTML
> with MSIE 4, then he should be told to upgrade, period. Your document
> still keeps the door open to MSIE 4.
>
> If I (or anyone) do not see a single reason as to resort to
> document.all, document.all[] and document.all(), then I (or anyone)
> should not see a single reason to verify the support for
> document.getElementById() either.
I think you have me mistaken for Matt. He wrote the document in
discussion, not me.
If you look at this entire thread, in a tree display, at my first reply
you will see that I also pointed out that IE5.0 supported gEBI.
If you go back through the c.l.j archives and search for the
document.all snippet that is in the clj FAQ then you will find that I
(Randy, not Matt) am the one that originally proposed it to be added to
the FAQ itself.
But the document.all versus document.getElementByID wasn't the subject
of my comment about feature/object detection. It was the assumption of
the style and display properties.
<snip>
>>That same problem arises with the JS generated button though.
>
>
> 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>).
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?
> In this thread, I believe I've tried to bring up chunks of code,
> references, more complete examples trying to substantiate my claims.
And I have presented my thoughts and nothing more.
> (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.
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".
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, it
is a simple matter of an include statement in a template document and
then the work to accomodate IE4 is zero.
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, you would have to prototype everything that a gEBI browser
supports that IE4 doesn't. It is *that* requirement that makes IE4 not
worth supporting.
My definition of "modern browser" though is one of "the last version of
each vendors browser".
Randy Webb
> Gérard Talbot a écrit :
>> Randy Webb a écrit :
>> You
> I'm sorry Randy. Somehow, I thought I was replying to Matt K.
No problem.
Michael Winter
[snip]
> [Using TABLE elements for layout] certainly was a huge step in moving
> the web towards more where it is today.
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]
Michael Winter
[snip]
> I personally hate using document.write(), even with a defer attribute
> [...]
If you're using the write method, then should never use the defer attribute.
[snip]
> If your goal is to support modern browsers [...], then why do you
> need to detect the support for getElementById ?
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]
> IMO, if an user visits a webpage that has/uses DHTML with MSIE 4,
> then he should be told to upgrade, period.
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]
> If I (or anyone) do not see a single reason as to resort to
> document.all [...]
I already gave one, and it had nothing to do with IE4.
[snip]
>> If the page error's any time before the onload fires, then the user
>> doesn't get the button even though scripting is enabled.
>
> 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) [...]
"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".
Dr John Stockton
Oct 2005 19:41:23, seen in news:comp.lang.javascript, John G Harris
<jo...@nospam.demon.co.uk> posted :
>In article <TFyo9qDt...@merlyn.demon.co.uk>, Dr John Stockton
><j...@merlyn.demon.co.uk> writes
>>JRS: In article <3r5kl8F...@uni-berlin.de>, dated Wed, 12 Oct 2005
>>19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
>><newsbl...@gtalbot.org> posted :
>
> <snip>
>>>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.
> <snip>
>
>Not funny. This newsgroup is read by beginners; we mustn't trick them
>into writing ParseInt (with a capital P).
Agreed. The solution is to recast the sentence so that parseInt does
not come first. Putting "Function " before it is generally
satisfactory.
>mW powers your torch.
>MW melts scrap metal.
Neither makes a good start for a sentence.
--
© John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.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
> On 15/10/2005 03:15, Gérard Talbot wrote:
>
>> If your goal is to support modern browsers [...], then why do you
>> need to detect the support for getElementById ?
>
> 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.
I think you don't understand what I mean. Anyway, I'm tired of repeating
myself, explaining myself and providing examples, etc.
>> IMO, if an user visits a webpage that has/uses DHTML with MSIE 4,
>> then he should be told to upgrade, period.
>
>
> 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]
>
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.org 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.
>> If I (or anyone) do not see a single reason as to resort to
>> document.all [...]
>
>
> I already gave one, and it had nothing to do with IE4.
>
> [snip]
>
I've never had to use getElementsByTagName() myself before or ... maybe
once I did. I certainly never used getElementsByTagName("*").
There are also and already many other DOM 1 methods returning a
collection of nodes or a named list.
document.links
document.anchors
document.images
document.forms
objTable.rows
objTableRow.cells
objSelect.options
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 Talbot
> Gérard Talbot said the following on 10/14/2005 10:15 PM:
>
>> Randy Webb a écrit :
>>
>
>
> <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
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
> 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?
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 Talbot
> Gérard Talbot said the following on 10/14/2005 10:15 PM:
>
>> Randy Webb a écrit :
>>
>> 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>).
>
>
> 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?
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.
>> In this thread, I believe I've tried to bring up chunks of code,
>> references, more complete examples trying to substantiate my claims.
>
>
> And I have presented my thoughts and nothing more.
>
>> (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.
>
>
> 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".
>
I agree with you that such expressions would need to be defined explicitly.
> 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,
With proper server-side scripting.
it
> is a simple matter of an include statement
Include statement.
in a template document and
> then the work to accomodate IE4 is zero.
No real live webpage example.
> 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,
gEBI emulation. No code. No url. No concrete reference.
you would have to prototype everything that a gEBI browser
> supports that IE4 doesn't. It is *that* requirement that makes IE4 not
> worth supporting.
Anyway. Whatever. I promise never to get into a discussion on supporting
IE4 ever again.
Gérard Talbot
> On 14/10/2005 21:13, Gérard Talbot wrote:
>
> [snip]
>
>> <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.
>
>
> True, but since when have INPUT elements been part of a paragraph? A DIV
> or FIELDSET element is more appropriate.
>
> Mike
>
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"><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 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">email: </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="multipart/form-data"
method="post">
<P>
What is your name? <INPUT type="text" name="name_of_sender">
What files are you sending? <INPUT type="file" name="name_of_files">
</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"><BR>
<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.
Michael Winter
[Paragraphs in forms]
> This semantic issue all depends on your whole page design actually.
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]
> These examples all come from the HTML 4.01 specification.
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>Personal 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.
Michael Winter
> Michael Winter a écrit :
[snip]
>> 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.
>
> 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.
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]
> I've never had to use getElementsByTagName() myself before or ...
> maybe once I did. I certainly never used getElementsByTagName("*").
What's your point?
[snip]
> document.all is mostly used in webpages (and seen in webpages as) to
> access single nodes.
And most of these scripts will be badly written. When did I write that
the all collection /should/ be used to access single nodes?
> So I still do not see a single reason to resort to document.all.
Evidentially.
Richard Cornford
> Richard Cornford wrote:
<snip>
> In my experience with many web developers, Javascript
> is this piece-of-crap scripting language that they have
> to deal with and struggle with.
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.
> It gets in the way of what they want to do, but they
> have to use it.
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.
> 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.
> 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?
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.
> 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?
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.
> Or do you offer a generalized library that might have
> some 'bloat' but accomplishes the task way better than
> they would have written themselves?
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).
> Not everyone wants to be a javascript expert. You do.
> That's nice. But don't pigeon-hole everyone into your
> mindset.
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.
>> 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.
>
> The point is - who cares?
Everyone cares, to the extent that everyone wants everything to be
delivered as soon as they want it.
> If it's an extra 5k or even 10k, that is
> often way over-shadowed by graphics sizes, flash, etc.
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.
> If your goal is to create tight, compact pages, then
> fine - don't use libs. But that is _NOT_ a requirement
> for most people.
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.
> The convenience of using a lib with a little code bloat
> is more important than the extra few k of text that is
> downloaded.
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.
>> 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.
>
> Not if used correctly.
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?
>>> Yet I benefitted by being able to deliver more
>>> advanced functionality in a shorter timeline.
>> And the relevance of Java authoring to browser scripting is?
>
> Same concept, different language/environment.
And it is the difference between the language and environments that
modifies the appropriateness of the concept.
> 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.
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.
>> 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.
>
> I'd say that I definitely fall into that categorization.
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".
>> The point of providing a justification for any
>> recommendation is precisely so that the reader can
>> disagree with the recommendation.
>
> 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.
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.
> Or they may not even care. They just want their stuff to
> work.
Isn't it obvious that just wanting ones stuff to work will never be
enough, on its own, to get ones stuff to work?
>> 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.
>
> It describes the reality in _many_ organizations, and
> _many_ individuals.
If it is a reality does that make it a good thing?
> You don't see regularly how many people _DESPISE_
> javascript?
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.
> 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.
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.
>>> On the contrary, I've received great feedback so far from
>>> many others who said they immediately benefitted from it.
>>
>> 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.
>
> 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.
Would that be more or less "value" than would result form them acquiring
a less basic understanding?
>> 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.
>
> 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.
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.
> 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.
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.
> 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.
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 unprofessionalism.
>> 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.
>
> Such a document would be completely worthless to most web
> developers.
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.
>> 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?
>
> There is value in partially solving a problem.
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.
> If you can add value in a specific area, even without
> solving the entire problem, that is a good thing.
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?
> A 'Best Practices' document doesn't need to cover
> everything. IMO.
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.
>> 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.
>
> I'm realistic. You're idealistic.
> I'm practical. You're a perfectionist.
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.
> I cater to the masses.
Well, above it read more like 'patronise' but you can call it 'cater' if
you want.
> You cater to those you deem worthy.
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.
> I understand the problems of the average developer.
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.
> You tell them to RTFM.
Yep, if it is a technical subject RTFM. I have no problem with that.
Matt Kruse
>> 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.
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.
> 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.
I'd like to know more about your work environment.
It sounds very different from any that I have worked in or worked with.
> If a project needs something like a date picker, and it does not
> already exist, then the task goes to a javascript programmer.
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.
> And a
> javascript programmer who cannot already write a date picker for
> themselves is not going to be offered a job with us.
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?
> 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).
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.
>>> you increase the download for everyone who has no use
>>> or interest in that facility.
>> The point is - who cares?
> Everyone cares, to the extent that everyone wants everything to be
> delivered as soon as they want it.
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.
> 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.
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.
>> The convenience of using a lib with a little code bloat
>> is more important than the extra few k of text that is
>> downloaded.
> 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.
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?
> 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".
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.
> 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.
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.
> 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?
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.
>> 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.
> Why?
Because not everyone is like you, Richard.
Is that a hard concept to understand?
>> There is value in partially solving a problem.
> 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"
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. :)
>> I'm realistic. You're idealistic.
>> I'm practical. You're a perfectionist.
> 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.
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.
>> You tell them to RTFM.
> Yep, if it is a technical subject RTFM. I have no problem with that.
I had so many responses to this line that I couldn't even decide which one
to use. Luck you ;)
Randy Webb
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.
John G Harris
<j...@merlyn.demon.co.uk> writes
>JRS: In article <SzlSvQCTv$TDF...@jgharris.demon.co.uk>, dated Fri, 14
>Oct 2005 19:41:23, seen in news:comp.lang.javascript, John G Harris
><jo...@nospam.demon.co.uk> posted :
>>In article <TFyo9qDt...@merlyn.demon.co.uk>, Dr John Stockton
>><j...@merlyn.demon.co.uk> writes
>>>JRS: In article <3r5kl8F...@uni-berlin.de>, dated Wed, 12 Oct 2005
>>>19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
>>><newsbl...@gtalbot.org> posted :
>>
>> <snip>
>>>>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.
>> <snip>
>>
>>Not funny. This newsgroup is read by beginners; we mustn't trick them
>>into writing ParseInt (with a capital P).
>
>Agreed. The solution is to recast the sentence so that parseInt does
>not come first. Putting "Function " before it is generally
>satisfactory.
What a very silly thing to say.
>>mW powers your torch.
>>MW melts scrap metal.
>
>Neither makes a good start for a sentence.
What is the symbol for milliwatts? mW. Thanks.
John
--
John Harris
Thomas 'PointedEars' Lahn
> Had everyone stuck to the rules that purists have about when to use
> tables, the web would have been much uglier for much longer.
Rubbish. Your thinking seems to base on a static medium which the Web
certainly is not and has never been.
> 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 "semantically" wrong. It works. Better than the alternatives
> in most cases.
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
Matt Kruse
>> 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 "semantically" wrong. It works.
>> Better than the alternatives in most cases.
> 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.
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.
> You (and, alas, many others) seem to still perceive the Internet
> including the Web as a screen-only medium for non-handicapped people.
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.
Randy Webb
> Randy Webb a écrit :
>
>> Gérard Talbot said the following on 10/14/2005 10:15 PM:
>>
>>> Randy Webb a écrit :
>>>
>
>
>>> 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>).
>>
>>
>>
>> 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?
>
>
> 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.
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.
>> 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,
>
>
> With proper server-side scripting.
>
> it
>
>> is a simple matter of an include statement
>
>
> Include statement.
I am not sure how much of the above is a result of your quoting, or, if
it is an intended correction.
> in a template document and
>
>> then the work to accomodate IE4 is zero.
>
>
> No real live webpage example.
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.
>> 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,
>
>
> gEBI emulation. No code. No url. No concrete reference.
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 Webb
> Matt Kruse wrote:
>
>
>>Had everyone stuck to the rules that purists have about when to use
>>tables, the web would have been much uglier for much longer.
>
>
> Rubbish. Your thinking seems to base on a static medium which the Web
> certainly is not and has never been.
The web, with it's sites, was *very* static when it began. Simply
because there was no way to make it dynamic.
>
>>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 "semantically" wrong. It works. Better than the alternatives
>>in most cases.
>
>
> 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.
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.
Gérard Talbot
> Thomas 'PointedEars' Lahn wrote:
>
>>>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 "semantically" wrong. It works.
>>>Better than the alternatives in most cases.
>>
>>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.
>
>
> 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.
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
> table-based layout, I can have my content look mostly the same even in very
> old browsers.
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
> 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.
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_
> more work than a simple table layout which will work consistently in every
> browser you can test in.
"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
> are often unconvincing to me.
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
> easier and more consistent to do in CSS than with tables, let me know.
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
> 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.
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
Matt Kruse
> 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.
Thank you. That was my point.
> You don't believe in writing markup code without validation errors in
> your website to begin with.
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.
> You don't believe in using a doctype which
> will trigger standards compliant rendering mode in modern browsers to
> begin with.
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.
> 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.
If you look at some of the stylesheets created for the site, you quickly
realize that CSS is not good for layout.
Michael Winter
[snip]
> 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.
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.
Gérard Talbot
> Gérard Talbot wrote:
>
>>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.
>
>
> Thank you. That was my point.
>
>
>>You don't believe in writing markup code without validation errors in
>>your website to begin with.
>
>
> 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 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
> 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.
>
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.
>
>>You don't believe in using a doctype which
>>will trigger standards compliant rendering mode in modern browsers to
>>begin with.
>
>
> On the contrary, I do.
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
> user-selectable doctype links at the top so that scripts can be tested in
> whichever doctype the user happens to be using.
>
>
>>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.
>
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.
> If you look at some of the stylesheets created for the site, you quickly
> realize that CSS is not good for layout.
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="#FFFFFF" LINK="#006666" VLINK="#004444">
<center>
<table width=99% border=0 cellpadding=0 cellspacing=0>
(...)
Matt Kruse
> 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.
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.
> - you want to support old browsers like NS4, IE4 and other browsers
> which have buggy and incomplete support for CSS
If I can with a table layout, but not with a CSS layout, why should I use a
CSS layout?
> - it seems you want pixel-accurate layout for every/all browsers
Nope, not at all.
> - 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.
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.
>> If you look at some of the stylesheets created for the site, you
>> quickly realize that CSS is not good for layout.
> I don't follow you. I don't understand you at all on this. I thought
> your site was...
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...
Richard Cornford
> Richard Cornford wrote:
>>> 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.
>
> No one can be an expert in everything.
It is not necessary to be an expert in order to understand browser
scripting.
> 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.
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.
> Very few people in the real world would be an expert in all
> of those areas,
And most of them will realise that they are not qualified to do that job
and so not apply for it.
> or have anywhere close to enough time to study each
> area in-depth.
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.
> For many, the best hope is to keep things working
> and _slowly_ advance knowledge in each of those areas.
To admit that advancing knowledge in each area is advantageous is to
question the rational of necessarily doing so slowly.
>> 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.
>
> I'd like to know more about your work environment.
> It sounds very different from any that I have worked in or
> worked with.
So nobody manages the use of the available resources to take best
advantage of the skills they have?
>> If a project needs something like a date picker, and it does not
>> already exist, then the task goes to a javascript programmer.
>
> 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".
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.
> 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.
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.
> Again, I think your current work environment - whatever it
> is - does not represent the norm for many, many developers
> out there.
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.
> Certainly not for those developers who aren't even _in_
> a work environment.
The degree to which the attitudes and behave of individual amateur
developers may be regarded as professional is not that important.
>> And a javascript programmer who cannot
>> already write a date picker for
>> themselves is not going to be offered a job with us.
>
> Good for you. You can be picky.
It is not a question of being "picky", hiring someone to white browser
scripts who cannot write browser script would be an expensive mistake.
> Not every company can.
Companies cannot verify that the people they hire possess the skills
they purport to have? I think you will find that they 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.
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.
> You don't know enough."
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.
> Whereas I would tell them, "sure, you can do that.
> Download X and Y and put Z in your HTML, and it will
> work."
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.
> Whose approach do you think _they_ prefer?
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).
>> 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).
>
> 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?
No, of course not. It is general enough to be re-used in any context
within the application that may require a date picker.
> If not, then you've solved 1 problem when you could have
> solved 1,000 problems with a little more work.
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.
>>>> you increase the download for everyone who has no use
>>>> or interest in that facility.
>>> The point is - who cares?
>> Everyone cares, to the extent that everyone wants everything to be
>> delivered as soon as they want it.
>
> 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.
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.
>> 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.
>
> Code bloat only matters if people care.
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,
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.
> I think you would have a hard time finding anyone who
> realistically cared.
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.
>>> The convenience of using a lib with a little code bloat
>>> is more important than the extra few k of text that is
>>> downloaded.
>> 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.
>
> a) Not everyone has the skill to develop low-level reusable
> functions such as you have done.
But do the people who don't have the skill also not have the potential
to acquire that skill?
> b) People such as yourself who write these functions often
> refuse to document and share them.
A layered design based on low-level re-usable components is a design
pattern not a collection of specific code.
> c) Therefore, people without the time or skill to write those
> functions cannot use your approach.
They can once they have acquired the knowledge to do so.
> 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?
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>
> 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.
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.
> 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.
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.
> 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.
You haven't noticed the Usenet archives then?
> People such as yourself - who _ADVOCATE_ such a method of
> development - do not share your solutions so that others
> may benefit.
I put them in a public place, if you don't care to look that is your
choice.
<snip>
>> 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?
>
> It's a phrase whose meaning should be obvious.
It reads like marketing-speak and so would be assumed to have no real
meaning.
> 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.
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.
>>> 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.
>> Why?
>
> Because not everyone is like you, Richard.
> Is that a hard concept to understand?
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.
>>> There is value in partially solving a problem.
>> 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"
>
> You don't?
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.
> Let's take an easy example - medicine.
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.
> 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. :)
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.
>>> I'm realistic. You're idealistic.
>>> I'm practical. You're a perfectionist.
>> 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.
>
> 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.
So the criteria for web development "Best Practices" are to be governed
by absolute beginners making amateur web sites?
> 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,
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.
> when they could have downloaded a solution with 10k of
> 'code bloat' and had it working in their page in less than an
> hour.
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.
> Ask them which approach is more realistic and practical.
<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
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.
Matt Kruse
> It is not necessary to be an expert in order to understand browser
> scripting.
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.
>> Rather than considering yourself and your job position, consider
>> a one-man 'webmaster' for a small company...
> You are also describing someone who does not need to use javascript at
> all, it is not compulsory.
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.
> 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.
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.
>> Certainly not for those developers who aren't even _in_
>> a work environment.
> The degree to which the attitudes and behave of individual amateur
> developers may be regarded as professional is not that important.
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.
> 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.
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.
>> a) Not everyone has the skill to develop low-level reusable
>> functions such as you have done.
> But do the people who don't have the skill also not have the potential
> to acquire that skill?
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.
>> b) People such as yourself who write these functions often
>> refuse to document and share them.
> A layered design based on low-level re-usable components is a design
> pattern not a collection of specific code.
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.
>> c) Therefore, people without the time or skill to write those
>> functions cannot use your approach.
> They can once they have acquired the knowledge to do so.
This prerequisite of yours has already been shown to be unrealistic and
impractical for many people.
> 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.
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.
>> 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.
> You haven't noticed the Usenet archives then?
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?
>>> You like to talk of "adding value"...
> It reads like marketing-speak and so would be assumed to have no real
> meaning.
Like most of the novels you write in this group ;)
>> Go find a high school student who is learning web development
>> to make a school band web site and wants to use some javascript.
> So the criteria for web development "Best Practices" are to be
> governed by absolute beginners making amateur web sites?
Perhaps.
Expert developers rarely need to consult 'best practices' documents.
Matt Kruse
> 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.
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*
VK
Michael Winter wrote:
> This might also be a good time to follow on and dispel the idea about
> hash 'arrays'.
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 ;-)
> frames and form elements addressing
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.com/schools_ring/ArrayAndHash.html#HTMLCollection>
has some inspirational cases linked.
> eval() is evil
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
> Michael Winter wrote:
>
>> This might also be a good time to follow on and dispel the idea about
>> hash 'arrays'.
>
> 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>
... which show an example of a dictionary, which is a mapping from keys
to values, and not a Javascript array ...
> I now got the Mozilla Foundation support:
> <http://www.mozilla.org/projects/xpcom/hashtable-guide.html>
... which show an implementation of a hashtable, and states that it is
different from an array (and how it is different).
> 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() ?
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 - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
VK
... 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.someMethod) )
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.
Randy Webb
>>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.someMethod) )
>
> we should use:
> if ( (someObject in objectContainer) && (someMethod in someObject) )
Test case where it is better? It would seem to be slower but may not be.
> 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.
How is using self to point to the window object less error prone than
using window? Without giving it a lot of though, window.property would
seem to be less error-prone than self.property for no other reason than
scope issues.
Michael Winter
[snip]
> I think that really best practice for object/method detection should
> be the usage of "in" operator.
Why? That will throw a syntax exception in several browsers.
> It's nice that JavaScript converts undefined and null into boolean
> false for us,
Yes, it is. If you don't like that, then use the typeof operator. Just
be aware that IE considers host object methods as objects, not functions.
> but it seems a bit durty and may hurt you when moving on strictly
> typed languages.
What on Earth does that have to do with /anything/?
[snip]
Thomas 'PointedEars' Lahn
>> Detecting Browser Versions
> ... and related scripts.
>
> I think that really best practice for object/method detection should be
> the usage of "in" operator.
Why should a not far enough downwards compatible feature be considered
"best practice"? typeof ... != "undefined" is sufficient in most cases
and downwards compatible to JavaScript 1.1, JScript 1, ECMAScript 1.
If really an ECMAScript 3 compliant approach would be taken, it would not be
the "in" operator but the hasProperty() method which can much more easily
be tested for than the former. Besides, "in" would seldom suffice as
before calling a method you would need to make sure that it *is* a method
and not a non-function property.
Your assumption that `window' "nearly always" refers to the Global Object
is wrong, by the way. There is a low probability that it does not within
a HTML document context, but JS can be used in other contexts. And `self'
is merely a property of `window', if existent, not of the Global Object;
using it (untested) is only making bad things worse.
PointedEars
VK
> VK wrote:
>
> >> Detecting Browser Versions
> > ... and related scripts.
> >
> > I think that really best practice for object/method detection should be
> > the usage of "in" operator.
>
> Why should a not far enough downwards compatible feature be considered
> "best practice"?
By "not far enough" you mean NN 2.x - NN 4.x ? IE supports it since
3.02
If some other browser still doesn't have it implemented properly, the
primary task would be to see such browser disappeared from the human
memory as quick as possible, rather than support it an any way.
The most important is that if (someObject) method fails easily in too
many curcumstances appeared after prototypes and constructors
introduction. Check this sample:
<html>
<head>
<title>Testcase</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
function test() {
self.abort = undefined;
// Bad practice
// if (someObject.someMethod){...) method
// fails on prototype change
if (abort) {
alert('I still know it was originally here');
}
else {
alert('Oops, I\'ve been easily cheated');
}
// Good practice:
// if (someObject in objectContainer) {...} method
// works reliably on prototype change
// As one cannot use delete() on default property,
// you cannot be mislead in any situation
if('abort' in self) {
alert('Do not try to cheat me!');
}
else {
alert('Oops, I\'ve been cheated too');
}
}
alert(self.hasProperty)
</script>
</head>
<body bgcolor="#FFFFFF">
<form method="post" action="">
<input type="button" name="Button01" value="Test" onclick="test()">
</form>
</body>
</html>
> If really an ECMAScript 3 compliant approach would be taken, it would not be
> the "in" operator but the hasProperty() method which can much more easily
> be tested for than the former.
Where did you get method? You mean HasProperty moniker from .Net
framework? It has no relation with the discussion.
> Besides, "in" would seldom suffice as
> before calling a method you would need to make sure that it *is* a method
> and not a non-function property.
Why in the name you need to check the type of property in question?
What can it prove? Even if it's indeed a method (so it's typeof
"function"), what proof do you have that this is *that* method and not
some bogus? And even if it's indeed *that* method, what proof do you
have that it was implemented as documented? You can only protect
yourselve from initial "Object expected error" by doing
if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
The rest remains in the hands of the Lord and browser makers.
> Your assumption that `window' "nearly always" refers to the Global Object
> is wrong, by the way. There is a low probability that it does not within
> a HTML document context, but JS can be used in other contexts. And `self'
> is merely a property of `window', if existent, not of the Global Object;
> using it (untested) is only making bad things worse.
"self" has the only context to be. Unless you've created a "self"
variable and did your whole script dizzy:
...
self = something;
// var self = something ?
// window.self = something ?
...
As "self" is one of so-called "tasty words" for identifiers, I see this
happens here and there and should be each time pointed.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> VK wrote:
>> >> Detecting Browser Versions
>> > ... and related scripts.
>> >
>> > I think that really best practice for object/method detection should be
>> > the usage of "in" operator.
>>
>> Why should a not far enough downwards compatible feature be considered
>> "best practice"?
>
> By "not far enough" you mean NN 2.x - NN 4.x ?
Not only, but they are included. At least NN 4.x definitely is.
> IE supports it since 3.02
So? IE is probably the widest distributed, but not the only user agent
around. And the `in' operator has AFAIS not been specified in ECMAScript
before Edition 3.
> If some other browser still doesn't have it implemented properly, the
> primary task would be to see such browser disappeared from the human
> memory as quick as possible, rather than support it an any way.
Let's just say your perception of reality appears to me to be somewhat
strange.
> The most important is that if (someObject) method fails easily in too
> many curcumstances appeared after prototypes and constructors
> introduction.
Nobody unconditionally recommended `if (someObject)', instead you
used it as vessel for your "argumentation". You are confused, yes?
> Check this
(... not Valid ...)
> sample:
>
> <html>
> <head>
> <title>Testcase</title>
> <meta http-equiv="Content-Type" content="text/html;
> charset=iso-8859-1">
> <script type="text/javascript">
> function test() {
>
> self.abort = undefined;
So you had to construct a less-than-probable case to prove
your otherwise unfounded assumption. You made my day.
> // Good practice:
No, it is not. The "in" operator is certainly a viable approach, but since
it lacks wide support, it cannot be considered best practice or even good
practice. But then you have seldom, if ever, bothered with such details.
Your experience in JS programming is still (despite several attempts of
explanation by experts to you) questionable at best. Since this is not
the first time, I strongly advise you read more before you post further
such bold statements here.
> alert(self.hasProperty)
Your point being?
>> If really an ECMAScript 3 compliant approach would be taken, it would not
>> be the "in" operator but the hasProperty() method which can much more
>> easily be tested for than the former.
>
> Where did you get method? You mean HasProperty moniker from .Net
> framework? It has no relation with the discussion.
No, I mean(t) Object.prototype.hasOwnProperty() as specified in
ECMAScript 3 and implemented in JavaScript 1.5+, JScript 5.6+.
Since I seldom have to use it, I remembered the identifier wrong.
>> Besides, "in" would seldom suffice as
>> before calling a method you would need to make sure that it *is* a method
>> and not a non-function property.
>
> Why in the name you need to check the type of property in question?
Because that is the most viable approach to check it exists in the
sense that it refers to useful value.
> What can it prove?
It can prove that it is not undefined, i.e. that it was not defined or
assigned undefined. It also can prove that the call operator may be
applied to it (see below).
> Even if it's indeed a method (so it's typeof "function"),
... or typeof ... == "object", for IE's DOM objects
> what proof do you have that this is *that* method and not
> some bogus?
I don't have. However, it has proven to be a viable approach to expect
methods that are named as documented to do what is documented, with only
a few exceptions in the implementation of the W3C DOM in IE.
I know when I mess with those methods in my included scripts and I know
who to blame then if it does not work. And since JS's object model is
dynamic, if either the UA's vendor or the user decide to cripple its
client-side script support or DOM, there is nothing a JS developer can
do about it. As JS/ECMAScript developer you always have to cope with the
host environment it runs in. So I simply don't need to bother with it.
For example if a property called `document.getElementsByTagName' exists
and it is a method, I have to assume that it can be called and returns
either `null', a HTMLCollection or not a HTMLCollection. Of course I
have to check its return value in some way before referring to it.
> And even if it's indeed *that* method, what proof do you
> have that it was implemented as documented? You can only protect
> yourselve from initial "Object expected error" by doing
> if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
Rubbish. There cannot be such an error produced (and it can only in IE)
unless the call operator is applied to a non-undefined property or the
object model the host environment is completely broken. However, I
consider implementations that return something other than "function" or
"object" for a method to be badly broken, and so I do not support them.
> The rest remains in the hands of the Lord and browser makers.
No, there are certain standards specified to adhere to, and UA vendors
state in the documentation what standards they support. Most of the time,
those statements have proven to be correct.
>> Your assumption that `window' "nearly always" refers to the Global Object
>> is wrong, by the way. There is a low probability that it does not within
>> a HTML document context, but JS can be used in other contexts. And
>> `self' is merely a property of `window', if existent, not of the Global
>> Object; using it (untested) is only making bad things worse.
>
> "self" has the only context to be.
You are talking nonsense. `self' has been and it is still a property of
Window objects, not by definition of the Global Object. Get yourself
informed, please.
> Unless you've created a "self" variable and did your whole script dizzy:
> self = something;
> // var self = something ?
> // window.self = something ?
> ...
That proves or disproves which one of my arguments? Again you are virtually
*constructing* something to try and fail to prove one of your arguments.
> As "self" is one of so-called "tasty words" for identifiers, I see this
> happens here and there and should be each time pointed.
Pardon? You are the one who suggested using `self' in the first place.
Unfortunately, I more and more get the impression that you do not really
know what you are talking about nor, more important, do you have any idea
what you are argueing against/for. Maybe a pillowful of decent sleep will
help you. Goodnight.
PointedEars
Thomas 'PointedEars' Lahn
> VK wrote:
>> And even if it's indeed *that* method, what proof do you
>> have that it was implemented as documented? You can only protect
>> yourselve from initial "Object expected error" by doing
>> if ( (neededObject in self) && (neededStuff in neededObject) ) {...}
>
> Rubbish. There cannot be such an error produced (and it can only in IE)
> unless the call operator is applied to a non-undefined property [...]
It should read "unless ... to an undefined property", of course.
VK
>> self.abort = undefined;
Thomas 'PointedEars' Lahn wrote:
> So you had to construct a less-than-probable case
> to prove your otherwise unfounded assumption.
> You made my day.
And to make your evening also take a look at the title of this thread.
If say method X works in 98% of cases and method Y works in 99% of
cases then given all other issues being equal (simplicity, code
readability etc.), then method Y is a better practice.
In the "IN vs. UNDEFINED" case I don't see "other issues" equal
neither. They are definitely benifiting to "IN":
[1]
if ('someProperty' in someObject) {...}
follows the human language structure so it's easy to understand and
remember even for a non-experienced programmer: "if [there is]
someProperty in someObject". It's not a requirement of cource in the
programming languages but it's a suggested part of the common
programming culture.
[2]
if ('someProperty' in someObject) {...}
contains only one operation (hash LOOKUP)
while
if (someObject.someProperty) {...} has two operations:
1) resolve someObject.someProperty (hash LOOKUP)
2) do background casting to false/true
so the same for
if (typeof(someObject) == 'function')
1) get someObject typeof
2) compare with string
On double check
if ('someProperty1' in someObject) && ('someProperty2' in
someProperty1) {...}
we save on two unnecessary operation avoided.
> The "in" operator is certainly a viable approach, but since
it lacks wide support,...
Do not get redicilous now. You mean that 99's ECMA lacks wide support?
Something like: "Behold: Pan 0.13.0 - The Whole Remains Beautiful just
failed to execute my script" ?
As we are talking about cross-platform scripting here then terms like
"some browsers" should be sctrictly avoided in the discussion.
Otherwise it's just a hidden way to say "I simply don't like it/you".
There are not "some browsers". There is IE 3.x - 7.x, Netscape 2.x -
8.x, Firefox 1.0.x, Pan 0.x and so on and so on. You think that a
particular method will fail in some environment? So tell us where
exactly including brends and major/minor versions. In many cases the
issue will desappear by itself just because you'll not be willing to
get funny on public by showing *what* browser you're hiding you
personal preferences behind of.
> I mean(t) Object.prototype.hasOwnProperty() as specified in
> ECMAScript 3 and implemented in JavaScript 1.5+, JScript 5.6+.
> Since I seldom have to use it, I remembered the identifier wrong.
hasOwnProperty() method deals with script objects *only* and it doesn't
work for DOM interface check, which we are discussing now (try
hasOwnProperty on window). IN method covers both cases.
But I'm still glad to see that despite some luck of experience you're
showing more theoretical knowledge as it was demonstrated before. KOK
(Kick On Kick)
Thomas 'PointedEars' Lahn
[Please learn how to quote, see the FAQ. Quotation levels corrected here.]
> Thomas 'PointedEars' Lahn wrote:
>>> VK wrote:
>>> self.abort = undefined;
>>
>> So you had to construct a less-than-probable case
>> to prove your otherwise unfounded assumption.
>> You made my day.
>
> And to make your evening also take a look at the title of this thread.
Ahh, yes. Quite bold of you to give it v1.0; it's more like v0.1.
> If say method X works in 98% of cases and method Y works in 99% of
> cases then given all other issues being equal (simplicity, code
> readability etc.), then method Y is a better practice.
Which exactly is why "in" is not.
> In the "IN vs. UNDEFINED" case I don't see "other issues" equal
> neither. They are definitely benifiting to "IN":
^^^^^^^^^^
(May I say that even as a person with English as foreign language myself
I am quite astonished by the overall "style" of your pos(t)ings?)
> [1]
> if ('someProperty' in someObject) {...}
> follows the human language structure so it's easy to understand [...]
You are completely missing the point again. This feature of the operand
identifier was not debated. What was debated and is still debatable was
the extend of the support of the operand as a feature of the programming
language implementation(s).
> [2]
> if ('someProperty' in someObject) {...}
> contains only one operation (hash LOOKUP)
No, if you had bothered to read ECMAScript 3 (as suggested to you
several times before), section 11.8.7., you would have known that
the "in" operation requires 8 steps total. If all subalgorithms
are considered, it takes even more steps:
| The production
|
| RelationalExpression :
| RelationalExpression in ShiftExpression
|
| is evaluated as follows:
|
| 1. Evaluate RelationalExpression.
| RelationalExpression :
| ShiftExpression
| RelationalExpression < ShiftExpression
| RelationalExpression > ShiftExpression
| RelationalExpression <= ShiftExpression
| RelationalExpression >= ShiftExpression
| RelationalExpression instanceof ShiftExpression
| RelationalExpression in ShiftExpression
|
| (I save you the details of that here, read for yourself)
|
| 2. Call GetValue(Result(1)).
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| GetBase(V). Returns the base object component of the reference
| V.
| 3. If Result(2) is null, throw a ReferenceError exception.
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| GetPropertyName(V). Returns the property name component of the
| reference V.
| 5. Return Result(4).
|
| 3. Evaluate ShiftExpression.
|
| ShiftExpression :
| AdditiveExpression
| ShiftExpression << AdditiveExpression
| ShiftExpression >> AdditiveExpression
| ShiftExpression >>> AdditiveExpression
|
| (again, no more details here)
|
| 4. Call GetValue(Result(3)).
| 1. If Type(V) is not Reference, return V.
| 2. Call GetBase(V).
| 3. If Result(2) is null, throw a ReferenceError exception.
| 4. Call the [[Get]] method of Result(2), passing GetPropertyName(V)
| for the property name.
| 5. Return Result(4).
|
| 5. If Result(4) is not an object, throw a TypeError exception.
| 6. Call ToString(Result(2)).
See section "9.8 ToString" for details.
|
| 7. Call the [[HasProperty]] method of Result(4) with parameter Result(6).
| 8. Return Result(7)
> while
> if (someObject.someProperty) {...} has two operations:
> 1) resolve someObject.someProperty (hash LOOKUP)
> 2) do background casting to false/true
Actually, it's
| 1. Evaluate MemberExpression.
| 2. Call GetValue(Result(1)).
| 3. Evaluate Expression.
| 4. Call GetValue(Result(3)).
| 5. Call ToObject(Result(2)).
See section "9.9 ToObject" for details.
| 6. Call ToString(Result(4)).
See section "9.8 ToString" for details.
| 7. Return a value of type Reference whose base object
| is Result(5) and whose property name is Result(6).
and then type-cast the return value to Boolean.
> so the same for
> if (typeof(someObject) == 'function')
typeof is an operator, not a function. The parentheses are unnecessary.
> 1) get someObject typeof
> 2) compare with string
That's actually
| 1. Evaluate UnaryExpression.
| 2. If Type(Result(1)) is not Reference, go to step 4.
| 3. If GetBase(Result(1)) is null, return "undefined".
| 4. Call GetValue(Result(1)).
| 5. Return a string determined by Type(Result(4)) according to the
| following table: [see "11.4.3 The typeof Operator" for more]
and then compare the return value with the string value.
> On double check
> if ('someProperty1' in someObject) && ('someProperty2' in
> someProperty1) {...}
> we save on two unnecessary operation avoided.
See above. What looks simple in the source code is not at all simple
or efficient in the implementation. This could be considered rule of
thumb since complexity does not simply vanish because of convenience.
BTW: You do know that the former throws a TypeError exception if
`someObject' does not refer to an object, too?
>> The "in" operator is certainly a viable approach, but since
>> it lacks wide support,...
>
> Do not get redicilous now.
^^^^^^^^^^
What?
> You mean that 99's ECMA lacks wide support?
The specification is called ECMAScript or ECMA-262. ECMA is the
standardization body that publishes it. ECMAScript Edition 3 Final
is dated March 24, 2000.
Most features of ECMAScript 3 are implemented as (and extended by)
JScript 5.6 (IE 6), JavaScript 1.5 (Mozilla/5.0) and by the scripting
engine of newer Opera versions.
> As we are talking about cross-platform scripting here then terms like
> "some browsers" should be sctrictly avoided in the discussion.
Pardon? "some browsers" and interoperability is the whole point of
cross-platform scripting!
> Otherwise it's just a hidden way to say "I simply don't like it/you".
You are talking nonsense again. More important, you are fighting your
own argument. If "I simply don't like you" is not what you want, then
insisting on having a not supported feature to be called best practice
is a step towards the wrong direction by 180°.
> There are not "some browsers".
There are.
> There is IE 3.x - 7.x, Netscape 2.x - 8.x, Firefox 1.0.x, Pan 0.x and
> so on and so on.
Obviously you gave last part not enough thought.
> You think that a particular method will fail in some environment?
I *know* that it will fail in some environments just because environments
are different. The probability that "in" will fail is higher than the
probability that "typeof" will fail, just because the former came last.
> So tell us
That's cute of you talking the "we" although replies indicated that
your humble opinion is definitely not shared by everyone interested.
> where exactly including brends and major/minor versions.
I fail to catch the meaning of this sentence. Probably you mean I have to
prove something here. Well, I don't. I did anyway on occasion here in the
hope you might learn from that.
> In many cases the issue will desappear by itself just because you'll not
> be willing to get funny on public by showing *what* browser you're hiding
> you personal preferences behind of.
You express yourselves to the degree you appear to be able to understand the
matters discussed here.
>> I mean(t) Object.prototype.hasOwnProperty() as specified in
>> ECMAScript 3 and implemented in JavaScript 1.5+, JScript 5.6+.
>> Since I seldom have to use it, I remembered the identifier wrong.
>
> hasOwnProperty() method deals with script objects *only*
What exactly are you calling a "script object"?
> and it doesn't work for DOM interface check,
That depends on what DOM we are talking about.
> which we are discussing now
Ohh, thank you very much for telling me what we were *really* discussing.
IYVHO.
> (try hasOwnProperty on window).
this.hasOwnProperty('window') in global context yields `true' here
[Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922
Firefox/1.0.7 (Debian package 1.0.7-1) Mnenhy/0.7.2.0].
Since `window' is a property of the Global Object in almost all
HTML DOMs including the Gecko DOM, that result is correct.
The same goes for window.hasOwnProperty("document").
It does not for document.hasOwnProperty("images") and other
HTMLCollections.
> IN method covers both cases.
It does, but you are still missing the point.
PointedEars
Michael Winter
[The in operator]
> IE supports it since 3.02
That's odd. IE5.0 errors out, here. Just me?
Thomas 'PointedEars' Lahn
> On 26/10/2005 22:33, VK wrote:
> [The in operator]
>> IE supports it since 3.02
>
> That's odd. IE5.0 errors out, here. Just me?
Dunno, I have no IE here. Either that or the MSDN Library is
again not as correct as it should be (nothing new, though.)
PointedEars
Randy Webb
> VK wrote:
>
> [Please learn how to quote, see the FAQ. Quotation levels corrected here.]
>
>
>>Thomas 'PointedEars' Lahn wrote:
>>
>>>>VK wrote:
>>>> self.abort = undefined;
>>>
>>>So you had to construct a less-than-probable case
>>>to prove your otherwise unfounded assumption.
>>>You made my day.
>>
>>And to make your evening also take a look at the title of this thread.
>
>
> Ahh, yes. Quite bold of you to give it v1.0; it's more like v0.1.
Perhaps you should go back and look at who started this thread, who
created that document, and gave it a version number. It was *not* VK
Richard Cornford
> Richard Cornford wrote:
>> It is not necessary to be an expert in order to understand
>> browser scripting.
>
> 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.
And a similar statement can be made about any other learnt skill.
>>> Rather than considering yourself and your job position,
>>> consider a one-man 'webmaster' for a small company...
>> You are also describing someone who does not need to
>> use javascript at all, it is not compulsory.
>
> Obviously. _Nothing_ is required. You could write plain
> text and not learn HTML, too.
Yes, the skills you are willing to acquire should be expected to limit
what you can achieve.
> The point is, sometimes some more advanced functionality is
> desired, and not everyone can fulfill your 'requirements'
> to be able to accomplish that functionality.
Why should a desire to do something excuse the consequences of someone
who only knows enough to do it badly doing so anyway? A desire to be a
surgeon will never be enough on its own to justify having a go at it,
and a desire to use javascript will not be enough on its own to avoid
attempting to use it from doing harm.
>> 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.
>
> 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.
I don't expect everyone to be capable of being in the piston I am in,
and I don't expect the vast majority of everyone particularly wants to.
But I do believe that anyone capable of effectively functioning as a web
developer is capable of learning everything that I have learnt (and much
that I haven't) in exchange for trying.
I can see your belief that the average web developer is an intellectual
jelly would suggest otherwise.
> Your solution for someone who is not like you seems to be
> to become more like you.
My "solution"? Solution to what exactly? If someone expresses a desire
to understand javascript I am likely to propose that they learn
javascript. It is not really a solution, as it is really too obvious.
> Which is highly unrealistic, and perhaps not even desireable.
>
> If you were an average web developer
I am an average web developer.
> without much experience,
And as I am older than the web there inevitably was a time when I had no
experience of it.
> put into a position where you needed to develop some
> javascript functionality,
How exactly do you imagine that I started writing javascript?
> I think you would be like a deer in headlights.
> You wouldn't know what to do.
Throughout my time programming there has been a continuous sequence of
new challenges. My experience is that the best way of handling these has
been to put some effort into understanding the pertinent subject, which
is why I will continue to recommend that strategy to others.
> 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.
So your would imagine that I learnt JSP by writing a Java Application
server?
>>> Certainly not for those developers who aren't even _in_
>>> a work environment.
>> The degree to which the attitudes and behave of individual amateur
>> developers may be regarded as professional is not that important.
>
> You missed the point entirely.
> Many people learn and practice web development and javascript
> outside of a work environment.
And if they never clam to be capable of being professional web
developers it doesn't really matter (and isn't particularly surprising)
if they are not very good at. They are also not going to be in a
position to allow their lack of skills to do harm to others.
> The idea of spending many hours learning a
> programming language is not at all practical.
Was that the "point" I missed? If the idea of spending many hours
learning a programming language is not practical then the fact that it
takes many hours learning any programming language would man that there
are no programmers.
<snip>
>>> a) Not everyone has the skill to develop low-level reusable
>>> functions such as you have done.
>> But do the people who don't have the skill also not have the
>> potential to acquire that skill?
>
> Sometimes they don't, no.
This would be your "average web developer" again?
<snip>
>>> b) People such as yourself who write these functions often
>>> refuse to document and share them.
>> A layered design based on low-level re-usable components is
>> a design pattern not a collection of specific code.
>
> 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, ...
A large part of the point of the exercise is not to address as many
specific cases as possible, but instead to only implement the component
versions for the specific cases actually encountered, as and when the
are encountered. Avoiding writing specific code until it is needed, and
still creating easily re-useable code, is one of the characteristics
that makes the strategy efficient.
<snip>
>>> c) Therefore, people without the time or skill to write
>>> those functions cannot use your approach.
>> They can once they have acquired the knowledge to do so.
>
> This prerequisite of yours has already been shown to be
> unrealistic and impractical for many people.
I don't know about 'shown', we only have your word for it that the
average web developer is intellectually incapable.
>> 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.
>
> And you know the term used for such people? Elitist assholes.
<snip>
It is ironic that you should describe others as "Elitist assholes" when
your characterisation of "the average web developer" as incapable of
achieving even your level of understanding of the subject carries the
implication that you consider yourself their innate superior.
On the other hand, your attitude toward the "average web developer" may
explain why you have never yet posted a single technical explanation of
anything to this group.
Richard.
Richard Cornford
>> Detecting Browser Versions
> ... and related scripts.
>
> I think that really best practice for object/method detection
> should be the usage of "in" operator.
The applicable 'Best Practice' is to perform feature detection tests to
verify support for and behaviour of, features of the environment (and
suspect features of the language) prior to using them. The nature of
those tests should not be considered subject to any arbitrary rules. A
test is intended to provide a discriminating answer to a question. So
you start choosing a test by deciding what it is you want to know, and
having done that you determine which formulations of code will provide a
discriminating answer. And only in the event that there is more than one
possible test formulation do you need to even start considering which
formulation is the best to use in the applicable context.
The - in - operator has the significant problem that - in - is a late
addition to the language and produces a syntax error when not supported.
Syntax errors may result in an error dialog being shown to the user (the
biggest indicator of author incompetence possible) and they cannot be
recovered from, so they preclude controlled paths of failure. And
language features that cause syntax errors when not supported are among
the most difficult aspects of the language to apply reliable feature
detection test to.
> 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.
Loosely typed languages are very much in the minority, so it is much
more likely that someone would come to javascript with preconceptions
acquired from a strongly typed language rather then the other way
around. However, using a loosely typed language demands a appreciation
of the way in which type-conversion happens and hiding form
type-conversion would just be seriously tying your own hands and require
a much better justification than some vague perception of disapproval.
Knowing that an object has a property is not the same as knowing that
the value of that property type-converts to true, and knowing that the
value type-converts to true is not the same as knowing which string that
value does (or does not) produce when the - typeof - operator is applied
to it. First decide what it is that you need to know, and then decide
which text will best tell you the answer.
> So instead of
> if ( (someObject) && (someObject.someMethod) )
The implication of this test is that "someObject" is an existing
property name of an object on the current scope chain, that its value
type-converts to true (is an Object of some sort, or boolean true, a
non-empty string or a non-zero and non-NaN number). If the first
expression does type-convert to true then the second expression is safe,
as any of the 'true' primitive values will be type-converted to their
corresponding object (Boolean, String or Number objects) and none of
those objects has a 'someMethod' property[1], so the second expression
will evaluate to false. Only if the first expression actually is an
Object (of some sort) could the second expression evaluate to true. So
you know that - someObject - is an Object reference and that its -
someMehtod - property type-converts to true.
The only possible exception-throwing condition is when 'someObject' is
not an existing named property of some object on the scope chain. Once
that is know to be the case the following code will not error-out under
any circumstances.
[1] This assumes that the prototypes of Boolean, String and Number have
not been augmented with a 'someMethod' property, but that should be a
known condition in the environment as the script author is the one who
would be augmenting their prototypes.
> we should use:
> if ( (someObject in objectContainer) && (someMethod in someObject) )
Correcting the above to the much more rational:-
if ( ('someObject' in objectContainer) &&
('someMethod' in objectContainer.someObject) )
This also starts with the assumption that 'objectContainer' is a named
property of an object on the scope chain, which can never be true of a
reference to the Activation/Variable object itself. It also assumes that
that property is a reference to an object (as the ShiftExpression is not
subject to type-conversion), all primitive values will cause exceptions
to be thrown. The first - in - expression is true whenever the -
objectContainer - object (or any object on its prototype chain) has a
property with the name represented by the type-converted to string,
value of - 'someObject' -. The actual value of that property is not
tested and so could be a non-Object value, which would cause the
second - in - expression to throw an exception when evaluated.
So, you have precluded the possibility of testing local variables, and
the passing of the first - in - expression does not guarantee that the
second will successfully execute. While the restriction form the
type-converting test, that the first unqualified Identifier, refer to an
existing named property of an object on the scope chain, applies just as
much to this test.
But if this test is necessary it should be a test that will not
error-out. And so not only is the - in - test dubious because of
language support, it is dubious because it is pretty much necessarily to
be certain of values of the properties prior to verifying that they
exist, which is a bit of a contradiction. But otherwise you have no
guarantee that execution will even get to the end of test, let alone be
able to act upon the result.
> 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.
If that was true it would be possible to create a test case that
demonstrates the phenomenon. As the - window - and - self - properties
are non-specified but traditional properties of the window object in web
browsers they have effectively equal status and are likely to be subject
to equivalent handling in browser environments. So each would be as
reliable as the other.
Without a demonstration of the phenomenon your assertion deserves to be
dismissed as just another manifestation of your misconception of browser
scripting.
Richard.
Matt Kruse
> If someone expresses a desire to understand javascript I am
> likely to propose that they learn javascript.
The point you missed: Not everyone wants to understand javascript. Some just
want to take advantage of its features by implementing packaged solutions.
> If the idea of spending many hours
> learning a programming language is not practical then the fact that it
> takes many hours learning any programming language would man that
> there are no programmers.
Your statement is as ridiculous as saying that if it weren't practical for
people to learn to repair their own cars, we wouldn't have auto mechanics.
It's not, in fact, practical for many people. I didn't say it was not
practical for anyone.
> A large part of the point of the exercise is not to address as many
> specific cases as possible, but instead to only implement the
> component versions for the specific cases actually encountered, as
> and when the are encountered. Avoiding writing specific code until
> it is needed, and still creating easily re-useable code, is one of
> the characteristics that makes the strategy efficient.
I disagree.
You are solving the specific case each time a new one comes up. I find it to
be more challenging, rewarding, and beneficial to try to solve the general
case (as much as possible) and then apply it to the specific case at hand.
If someone asks, "how do I find the position of my object on the page?" and
you supply the simplest solution which will work on their example page, you
may not be helping as much as you could. Tomorrow, if they introduce
scrollable areas into their page, change their layout with CSS, or put some
browsers into standards mode, your solution may break. And the person will
once again have no idea to fix it, because you gave them a very
limited-scope solution which can't be applied in varied situations.
Instead, you can solve the general case which also happens to solve their
specific example. Then, when their page changes, they don't need to change
their code, because the general solution already considers it correctly. The
few extra k of code which is not actually executed in each case is easily
offset by the fact that you don't need to go back and re-visit the code to
solve the new specific case, or change the code used every time your layout
changes.
The obvious fact to me is that most people prefer the approach taken by me
and many others. You may not, and that's fine, because obviously you have
the time and talent to do things your own way. But I see many people every
day downloading and using my solutions and thanking me for them. I don't see
you converting anyone to your approach with your postings on this group or
your web site examples. I do hear _lots_ of people say "wow, I found this
packaged solution, implemented it in 10 minutes, and got exactly what I
wanted". I don't hear anyone saying, "Thank god I didn't implement a
packaged solution, but instead spent the last 3 months learning and
experimenting with javascript so I could build up my own low-level function
library and solve the specific requirement that I had 3 months ago!"
Compare it to some every-day examples:
When you buy a new TV, do you learn electronics from scratch and build your
own to only have the features you want? Or do you buy one that costs a
little more and has more than you need, but gives you a TV right away and
gives you options in the future?
When you want a new computer, do you research and buy all the parts
separately and spend time assembling them to get the maximum possible
performance? Or you do buy a pre-packaged computer that may not match your
needs exactly but is certainly more convenient than building your own from
scratch?
When you choose an OS, do you build it from scratch and make it consist of
the fewest possible features that you need to use, in order to optimize
performance? Or do you use a packaged solution with lots more functionality
than you'll ever need, which uses more disk space and CPU, but makes your
life easier and more convenient?
Using a pre-packaged, generalized solution to a given problem is not lazy or
a cop-out as you seem to suggest. It's a realistic approach to take when you
consider all the factors involved and decide that building your own from
scratch just isn't advantageous. Why you object to it as a concept continues
to baffle me. I can only assume that you either have no understanding of the
real problems and priorities faced by many developers in the world, or that
you must dismiss generalized solutions in order to justify your own work to
yourself.
> It is ironic that you should describe others as "Elitist assholes"
> when your characterisation of "the average web developer" as
> incapable of achieving even your level of understanding of the
> subject carries the implication that you consider yourself their
> innate superior.
Incorrect.
Many people can achieve the level of understanding that I, you, or anyone
else has. I understand that many people don't _want_ to, and many people
don't have _time_ to, and many people have higher priorities. I'm not
superior, and they aren't stupid. They just aren't focused on the same
things as I am, and I see no reason to tell them that they need to be (as
you do).
Thomas 'PointedEars' Lahn
> The obvious fact to me is that most people prefer the approach taken by me
> and many others. You may not, and that's fine, because obviously you have
> the time and talent to do things your own way. But I see many people every
> day downloading and using my solutions and thanking me for them. I don't
> see you converting anyone to your approach with your postings on this
> group or your web site examples. I do hear _lots_ of people say "wow, I
> found this packaged solution, implemented it in 10 minutes, and got
> exactly what I wanted". I don't hear anyone saying, "Thank god I didn't
> implement a packaged solution, but instead spent the last 3 months
> learning and experimenting with javascript so I could build up my own
> low-level function library and solve the specific requirement that I had 3
> months ago!"
Giving people what they want is not always the best approach. Most people
do not know what they really want. One has to consider what they probably
*really* *need*.
> Compare it to some every-day examples:
>
> When you buy a new TV, do you learn electronics from scratch and build
> your own to only have the features you want? Or do you buy one that costs
> a little more and has more than you need, but gives you a TV right away
> and gives you options in the future?
No, because the effort necessary on my part would not justify the result
to be expected. This is of course natural laziness in some way intrinsic
to the psyche of all living beings. What makes them thrive and evolve is
need. What throws them back again is the urge to satisfy that need with
the least effort possible.
If you deny that you have not looked into it deep enough and you deny
yourself. Because you (and I) then would not have build libraries but
write that code from scratch every time. But, may I say, both of us are
professionals who wrote the code ourselves, who have come to understand
the basics needed for that. Others are in most cases merely consumers
of that code which puts them into a completely different position. They
have to be guided on how to use that work of ours properly which includes,
but not ends with, proper documentation.
> When you want a new computer, do you research and buy all the parts
> separately and spend time assembling them to get the maximum possible
> performance?
Actually, I did, about four years ago. And I have not regretted it
to date, even though I have had some hardware and software upgrades.
> Or you do buy a pre-packaged computer that may not match your
> needs exactly but is certainly more convenient than building your own from
> scratch?
The convenience of a pre-packaged solution is almost always balanced by
the problems that arise later because it does not fit special needs.
For example, pre-packaged solutions often contain bulk or low-performance
components to make the solution cheaper and easier to use. The components
are certainly able to do their basic tasks, but when it comes to getting
more of the average out of them they not only inevitably fail to do so but
cause problems when trying to enhance the particular performance level.
Think about a on-board graphics card often part of such hardware solutions
which is not good enough for your brand-new 3D game but interferes with the
new graphics card you just bought to counteract that, even though the
former is disabled in the BIOS Setup.
> When you choose an OS, do you build it from scratch and make it consist of
> the fewest possible features that you need to use, in order to optimize
> performance? Or do you use a packaged solution with lots more
> functionality than you'll ever need, which uses more disk space and CPU,
> but makes your life easier and more convenient?
I use GNU/Linux, where I have downloaded the Debian distribution from
<http://debian.org/> and the Linux source from <http://kernel.org/>.
I compile my kernels to be suited to my computer (aided by sophisticated
configuration menu and make scripts), because not only their overall
performance then is better than the pre-packaged solution (which exists
anyway) but it also saves me trouble disabling things (kernel options,
including modules) I seldom or never want or need but which will
potentially and are known to interfere with the things I do need.
That does not mean I have to build the OS from scratch.
On the other hand, I use Debian packages for GNU whenever possible and
viable (up-to-date) because I have come to love the apt-get tools and
their efficient child's-play way to maintain the rest of the operating
system.
It's a not a black-and-white universe but one with many colors and shades.
> Using a pre-packaged, generalized solution to a given problem is not lazy
> or a cop-out as you seem to suggest. It's a realistic approach to take
> when you consider all the factors involved and decide that building your
> own from scratch just isn't advantageous.
As I said, the advantage is easy implementation which is why users of
pre-packages solutions are almost always very thankful for them.
The disadvantage in that is that if you have not bothered to learn to
understand how the implementation works, you will definitely have a hard
time or even be unable to apply it to your specific needs later. This
makes you completely dependent on the author of the solution -- whom you
will definitely not thank for and almost never contact them about it --
and on his will to fix or extend it if it does not work as supposed
-- for which you will rather wait because you have become so accustomed
to being fed that you will seldom consider the alternatives. It is the
way how Closed Source software works, and it's definitely a Bad Thing,
at least in the mid-term.
This is of course a matter of (personal) philosophy. Mine and it seems
also Richard's is:
"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."
PointedEars
Randy Webb
> Matt Kruse wrote:
>
<snip>
> This is of course a matter of (personal) philosophy. Mine and it seems
> also Richard's is:
>
> "Give a man a fish; you have fed him for today.
> Teach a man to fish; and you have fed him for a lifetime."
True but Richards, at times, seems to expand to:
"Give a man a fish; you have fed him for today.
Make a man a commercial fisherman; and you have fed him for a lifetime."
Matt Kruse
> Giving people what they want is not always the best approach. Most
> people do not know what they really want. One has to consider what
> they probably *really* *need*.
In some cases I agree, and in other cases I think that is an elitist
knot-it-all attitude. It depends.
> The convenience of a pre-packaged solution is almost always balanced
> by the problems that arise later because it does not fit special
> needs.
Yet for most average 'consumers', the pre-packaged solution works just fine.
And in the few cases where it doesn't, they don't mind.
Most people are not 'power users' of a given technology or device. The
'typical' version works fine. Most people don't tweak their OS, customize
their web browsers, choose hardware piece by piece, mod their xbox, etc,
etc. Yet most people who are 'experts' (especially when it comes to
computers) can't quite comprehend this. They think everyone should learn and
tweak like they do, to get the most of everything. This is also why computer
nerds get made fun of so often ;)
With javascript development, the 'consumer' isn't just the end user viewing
the results in their web browser. The 'consumer' of code is also thousands
of average people who may not have much (or any) programming experience, but
who are working on a web site or a web app for their own use, and want to
put some advanced functionality into it.
If they were required to start from scratch and learn programming concepts
and then the javascript language and then the quirks of a web browser
scripting environment, many probably would never touch it. But if you can
give them a solution to plug in, it will solve their problem now and perhaps
give them insight into how it works. They can examine the code and read more
about it if they wish, and the whole idea of javascript programming won't
seem so intimidating.
> As I said, the advantage is easy implementation which is why users of
> pre-packages solutions are almost always very thankful for them.
> The disadvantage in that is that if you have not bothered to learn to
> understand how the implementation works, you will definitely have a
> hard time or even be unable to apply it to your specific needs later.
This is indeed the trade-off, and I've never denied that such a trade-off
exists.
Pre-packaged solutions can work great for the exact cases which they cover.
When a more customized solution is required, the user may lack the ability
to make the changes they need, and be lost. Or, perhaps the user *is*
knowledgeable enough to customize the code, then they have their needs
mostly met, with only minor additional coding needed. This is the trade-off
with *any* packaged solution. You get convenience, but at the expense of a
solution tailored to your specific needs.
As a consumer, I sometimes prefer the pre-packaged solution, and I sometimes
prefer to build things myself.
But to deny the benefit of pre-packaged solutions entirely, as Richard and
others often do, is extremely biased and naive. When a person advocates a
single viewpoint and refuses to acknowledge that other viewpoints might have
some credibility, it makes them less believable, imo.
> This is of course a matter of (personal) philosophy. Mine and it
> seems also Richard's is:
> "Give a man a fish; you have fed him for today.
> Teach a man to fish; and you have fed him for a lifetime."
Using analogies usually takes a discussion off-course, but I'll bite ;)
1) If someone is starving, teaching them to fish isn't helping. They need
fish now. They might also learn to fish on their own, which will take time,
but for right now, they need a fish!
2) Someone need not learn how to fish if they know how to go to the store
and buy fish every time they need some. We can't all learn to fish!
Plus, I don't even like fish ;)
Matt Kruse
> True but Richards, at times, seems to expand to:
> "Give a man a fish; you have fed him for today.
> Make a man a commercial fisherman; and you have fed him for a
> lifetime."
Or how about,
"If you give a man a fish, you have catered to a lazy person who can't even
spend the time required to learn how to get their own fish. You've also
given them bones and other parts that they probably don't want to eat.
Furthermore, you haven't informed them of the potential harm that eating
fish could do to them. What if they are pregnant and they get too much
mercury? To give the person a fish without them understanding all of the
potential hazards is irresponsible. Therefore, fish should never be given to
anyone.
Instead, anyone in the world who wants fish should become a fisherman. There
is plenty of information out there about how to fish. It just takes
practice. And a boat. And a net. And lots of free time. If you don't have
all that, you don't deserve to eat fish anyway. But if you really want fish,
then you need to buy those things and practice and build up your skills so
that some day you can catch the exact kind of fish you want to eat. And by
the way, if anyone else asks you for a fish that you caught, tell them hell
no. Get their own damn fish."
:)
Dr John Stockton
11:05:16, seen in news:comp.lang.javascript, Matt Kruse
<newsg...@mattkruse.com> posted :
>"If you give a man a fish, you have catered to a lazy person who can't even
>spend the time required to learn how to get their own fish. You've also
>given them bones and other parts that they probably don't want to eat.
>Furthermore, you haven't informed them of the potential harm that eating
>fish could do to them. What if they are pregnant and they get too much
>mercury?
IMHO, very few men worry about the possibility of being themselves in
the state described in the last quoted sentence.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Matt Silberstein
Webb <HikksNo...@aol.com> in <HL2dnfM6dsI...@comcast.com>
wrote:
>Thomas 'PointedEars' Lahn said the following on 10/29/2005 6:41 AM:
>
>> Matt Kruse wrote:
>>
>
><snip>
>
>> This is of course a matter of (personal) philosophy. Mine and it seems
>> also Richard's is:
>>
>> "Give a man a fish; you have fed him for today.
>> Teach a man to fish; and you have fed him for a lifetime."
>
>True but Richards, at times, seems to expand to:
>"Give a man a fish; you have fed him for today.
>Make a man a commercial fisherman; and you have fed him for a lifetime."
Teach a village to fish and they soon depopulate the lake.
Teach a man to cook a fish and he starves to death with a greater
appreciation of what he is missing.
--
Matt Silberstein
Do something today about the Darfur Genocide
http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org
"Darfur: A Genocide We can Stop"
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> The convenience of a pre-packaged solution is almost always balanced
>> by the problems that arise later because it does not fit special
>> needs.
>
> Yet for most average 'consumers', the pre-packaged solution works just
> fine. And in the few cases where it doesn't, they don't mind.
Well, as I wrote, due to the nature of people, you cannot know neither for
sure. Not that they are few cases and not that people don't mind. For
example, I have heard too many people complaining about MS Windows: that
it is too slow for them, takes too much system resources for simple tasks,
too whatever; yet the same people in almost all cases refuse to put some
effort into just exploring alternatives, let alone using them. And when
I ask them about it, still nobody ever considered sending those complains
to MS to make the OS better; they rather wait for it to happen.
> Most people are not 'power users' of a given technology or device. The
> 'typical' version works fine.
Not in all, most or even many cases, which is the problem.
> Most people don't tweak their OS, customize their web browsers, choose
> hardware piece by piece, mod their xbox, etc, etc.
Which does not mean in any way that they are happy with what they have.
It does not mean the opposite either, of course.
> Yet most people who are 'experts' (especially when it comes to
> computers) can't quite comprehend this. They think everyone should learn
> and tweak like they do, to get the most of everything. This is also why
> computer nerds get made fun of so often ;)
Public opinion is seldom based on rational thinking.
> With javascript development, the 'consumer' isn't just the end user
> viewing the results in their web browser. The 'consumer' of code is also
> thousands of average people who may not have much (or any) programming
> experience, but who are working on a web site or a web app for their own
> use, and want to put some advanced functionality into it.
That's the point. When I write `consumer' I mean the first-level consumer,
that is, the Web site responsible. And the Web site is for consumers, too,
even if only non-commercial visitors. However, if your customer/consumer
does not really know what he does, how can you expect that he will provide
a viable service to his customers/consumers? He depends entirely on you,
so he makes you responsible if something goes wrong, whether you deny that
in a legal statement or not.
I appears to be a Good Thing to shift responsibilities by allowing the
first-level customer to learn. I don't know whether that is a viable
approach, but why not provide a solution of components instead of a
complete solution? This would create the need for that customer to
understand how to make the components work together to achieve what
he wants.
> If they were required to start from scratch and learn programming concepts
> and then the javascript language and then the quirks of a web browser
> scripting environment, many probably would never touch it.
To completely refuse learning before doing, would that not be a sure sign
of incompetence? Would they not deserve to have a not-so-good Web site,
if any? Ahh -- but there's the commercial aspect which brings us back to
the least-effort behavioral pattern. Why put effort in learning if it
*appears* that you can buy (or copy) knowledge?
> But if you can give them a solution to plug in, it will solve their
> problem now and perhaps give them insight into how it works. They can
> examine the code and read more about it if they wish, and the whole
> idea of javascript programming won't seem so intimidating.
Will they ever bother to learn if you keep feeding them?
> But to deny the benefit of pre-packaged solutions entirely, as Richard and
> others often do, is extremely biased and naive. When a person advocates a
> single viewpoint and refuses to acknowledge that other viewpoints might
> have some credibility, it makes them less believable, imo.
It of course depends on the matter discussed, but I tend to agree.
>> This is of course a matter of (personal) philosophy. Mine and it
>> seems also Richard's is:
>> "Give a man a fish; you have fed him for today.
>> Teach a man to fish; and you have fed him for a lifetime."
>
> Using analogies usually takes a discussion off-course, but I'll bite ;)
I'm a hell of a good "fisherman", I suppose? ;-)
> 1) If someone is starving, teaching them to fish isn't helping. They need
> fish now. They might also learn to fish on their own, which will take
> time, but for right now, they need a fish!
I doubt that they really "starving". But to speculate on people's motives
won't bring us further in this discussion.
> 2) Someone need not learn how to fish if they know how to go to the store
> and buy fish every time they need some. We can't all learn to fish!
But perhaps to make "fish soup".
> Plus, I don't even like fish ;)
Me neither, I'm vegetarian. Yet I happen to like the proverb.
You may replace "to fish" with "to grow crops" or so ;-)
PointedEars
VK
fisherman's talks have to do with the announced topic? My wild guess
would be that it is somehow related with the question "What of our
godlike knowledge should we give to mortal people and what is suitable
to know between gods only?". If I'm right here then I engage you to
leave the Olympus right now as you get there by the wrong ticket.
comp.lang.javascript is a good newsgroup but not only one source of
knowledge of JavaScript - and it's definitely *not* the ultimate source
of knowledge of common programming principles. Anyone can get the
answer from here or from any other place of her choice.
If you decided to give some "Best Practice" programming advises in
relation to ECMAScript-based languages then let's discuss it. If anyone
still remembers these are:
1. Square Bracket Notation
2. Referencing Forms And Form Elements
3. Referencing Forms From Element Handlers
4. Problems With Concatenation
5. Using onClick in <A> tags
6. Eval
7. Detecting Browser Versions
8. Don't Use document.all
9. Getting And Setting Form Values
I see nothing where what wouldn't be covered already in FAQ's but OK -
it could be a nice FAQ add-on. If the discussion is set over, OP is
welcome set a link on it from the FAQ page.
Most importantly you need to decide what is the "Best Paractice"? Is
the code that follows the "Best Practice" i) most readable or ii) most
universal or iii) most error-protected or iv) most resource effective
or v) most time effective.
These are all different and often mutually-exceptive issues. I say that
the best practice has to lead to code which is the most universal and
(upon the possibility priority level 1) most error-protected and (upon
the possibility priority level 2) most readable.
>From this position say "Eval is Evil" is totally right and nothing to
discuss here.
But let's us take "iv) most resource effective or v) most time
effective" priorities, and "Eval is Evil" becomes a good sounding but
pointless slogan. With the above mentioned priorities we should say
instead "Recursion has a Curse on". JavaScript is an interpreted
language and you have to accept this fact as say its loose typing. As
one of consequences of it recursions in JavaScript are almost never as
effective as runtime code generation. I have a set of *practical*
samples (starting from full array copy *including* nested arrays) to
demonstrate it. Actually better you may try to make a non-"new
Function()" based solution which would *be no more than two times
slower* than a "new Function()" based.
But again - it's all priorities' based. So the parting question would
be: what is the "Best Practice" definition in this thread?
P.S. And please stop profanities like "reusable libraries should not be
used in the programming". There may be children around here to hear
that.
Matt Kruse
> For example, I have heard too many people complaining
> about MS Windows: that it is too slow for them, takes too much system
> resources for simple tasks, too whatever; yet the same people in
> almost all cases refuse to put some effort into just exploring
> alternatives, let alone using them. And when
> I ask them about it, still nobody ever considered sending those
> complains to MS to make the OS better; they rather wait for it to
> happen.
Which illustrates my point: That people value the convenience of a
pre-packed solution far more than the value of a better solution which
requires additional effort. And even when better alternatives are available,
people will _still_ stick with the packaged solutions. Which means, no
matter how hard Richard or you or anyone else promotes the idea that
packaged javascript solutions are bad, it won't matter. People will still
search for them and use them. You can either let them all use low-quality
offerings, or write your own solutions and aspire to higher quality so that
you can benefit a wide range of people.
> why not provide a solution of components instead of a
> complete solution? This would create the need for that customer to
> understand how to make the components work together to achieve what
> he wants.
This is exactly the approach I would like to take. I would like to build a
repository of components which solve very specific problems, but which by
themselves offer no functionality. I would love to get the best programmers
on this group to combine their efforts into a standard repository of these
components. Then anyone building sites or apps or even packaged solutions
can reuse these solid low-level components and achieve higher quality.
Given a standard repository of components, I'm certain that a number of
developers who now choose packaged solutions would instead decide to build
their own. Because despite what some might argue, some of these low-level
components are not, in fact, trivial to develop and test. Developing
cross-browser scripts even for some simple things requires digging into
different DOM implementations, testing in a wide variety of browsers,
reading through different documentation, and dealing with quirks in browsers
where things don't work exactly as they ought to.
When I promote something like that, Richard replies with, "we won't help
you, because we know what your goal is, and your goal sucks." That's what I
call the 'elitist asshole' attitude. And when he promotes his own
methodology and publishes examples using his own low-level components, yet
refuses to make them available to others to benefit from, or even document
his approach, I have to wonder what he's really thinking...
>> If they were required to start from scratch and learn programming
>> concepts and then the javascript language and then the quirks of a
>> web browser scripting environment, many probably would never touch
>> it.
> To completely refuse learning before doing, would that not be a sure
> sign of incompetence? Would they not deserve to have a not-so-good
> Web site, if any? Ahh -- but there's the commercial aspect which
> brings us back to the least-effort behavioral pattern. Why put
> effort in learning if it *appears* that you can buy (or copy)
> knowledge?
Let's not deny that every one of us benefits from buying, copying, or using
the packaged knowledge of others. I don't think that the viewpoint that we
must all learn to do everything ourselves and not benefit by using the
solutions of others has any merit at all. The only way to achieve greater
and more complex goals is to treat some knowledge as a 'black box' and add
your own knowledge to go one step further.
Clearly, if someone's goal is to be javascript programmer or an expert web
developer, then relying only on packaged javascript solutions is not a good
plan. They should learn the skills required to develop the code on their
own.
But if their goal is to have a decent web site where their small church can
make information available (for example), then understanding the underlying
technologies to their fullest is _not_ something they care about. They can
achieve their goal by either paying someone who understands everything
(often not an option) or they can use the knowledge of others without fully
understanding it, so they can achieve their goal. To say that they only
deserve a not-so-good website, if any, is an elitist response that I find
incredibly rude. If they can achieve decent results and accomplish their
goal and benefit from it - even if they didn't learn to do it themselves -
then I say good for them. I certainly wouldn't tell them that they don't
deserve it.