Re: Javascript Best Practices Document v1.0

Michael Winter a écrit : 
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
--
remove blah to email me
.

Relevant Pages

  • Re: XHTML transitional and Frontpage 2003 validator
    ... do it in the first place, and it will allow you to retain your XHTML ... validation. ... > To change to work with java script once is no problem but the site is ... > Frontpage and using its nice easy to learn techniques... ...
    (microsoft.public.frontpage.client)
  • Re: Sound of j and z in Hindi films and songs
    ... "Official Policy" to remove the dots from j-dot etc, ... there was a practice of writing an anuswar on certain words like ... the dictionaries and the script followed later. ... I also notice that the more vibrant a language more tolerant it is. ...
    (rec.music.indian.misc)
  • Re: prompt not working
    ... >> A) a) You are declaring an XHTML document type and serve it ... > code I infer from the above that XHTML must be the "default" document ... The document type must be explicitly declared, ... > The book that I am using says to use comment tags to enclose all script ...
    (comp.lang.javascript)
  • Re: Opera guesses encoding for "application/xml"
    ... Do you dispute the fact that XML Schema validation is more powerful than ... powerful" than HTML DTD validation? ... how to change non DTD constraints, ... extra constraints that XHTML requires, ...
    (comp.infosystems.www.authoring.html)
  • Re: Javascript Best Practices Document v1.0
    ... that document.formsis a bad practice when it is a DOM 2 HTML valid practice in XHTML ... browsers will be treating the markup. ... a button should be used with a proper ...
    (comp.lang.javascript)