It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.
I was looking through the JS FAQ for any question that
identifies the warning signs to look out for, the things
that most easily and clearly identify the author of code
as something less than a master of the art.
I did not find an FAQ that answered it, but I think the FAQ
should contain the info., so, here is my proposed list..
<FAQENTRY class='more_Speculative_For_Discussion_OK?'>
1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or another reality?
2 if (navigator.userAgent.indexOf("IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascript :somefunction()"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write("<p>Important content.."); // delivering content.
</FAQENTRY>
What is your opinion? Are these the top 7?
Which 28 did I miss?
Also, why does the FAQ not contain the words "degrade",
"graceful" or "noscript" (I guess I might have been
looking for the wrong term with the first two, but
no mention of NOSCRIPT? That surprised me.)
BTW - The Jibbering JS FAQ is the single greatest FAQ*
I use, but I just have a hankerin' to get mentioned in
it, or at least contribute to it. ;-)
* I have my own (fledgling) Java FAQ that I hope might
approach the quality of the JS FAQ one day, and am a
contributor to the recently expanded and improved
c.i.w.a.s. FAQ.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane 109  5723 
*Andrew Thompson* wrote in comp.lang.javascript :
[snip] <FAQENTRY class='more_Speculative_For_Discussion_OK?'>
1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or another reality?
2 if (navigator.userAgent.indexOf("IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascript:somefunction()"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write("<p>Important content.."); // delivering content.
</FAQENTRY>
What is your opinion?
[snip]
Just a quick note (or seven):
Re: #6: I personally tend to use javascript only in roles that are
optional - e.g. in a non-compulsory assistive capacity. In such
circumstances a noscript element is not required, yet there is still
graceful fallback (either via HTML or the web server). I don't think
I've ever used a noscript element in an open WWW environment to provide
alternative functionality, only as an empty element to stop simplistic
accessibility testing tools from crying foul!
I'm unsure of chastising #4 owing to the things that can be implicitly
cast to a Boolean.
8. document.getElementById("myId").style.color = "#ff3333"; // Not
testing for methods and properties before using them
9. document.myFormName.myTextInputName.value = "dummy"; // Using
hierarchy shortcuts that may not work as intended in non-IE browsers.
(NB: I really need to check up on how modern browsers cope with such
things)
10. Attempting to use IE-only methods and properties in a WWW
environment.
11. Use of 'InnerHTML' can be considered bad style, but it is
significantly more usable (though abusable) than the alternatives.
12. onblur, onfocus, onchange - usually used to surprise the user by
making form controls behave in unexpected non-standard ways.
--
Andrew Urquhart
- FAQ: http://www.jibbering.com/faq/
- Archive: http://groups.google.com/groups?grou...ang.javascript
- Contact me: http://andrewu.co.uk/contact/
On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote:
(A.T.) 6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
Re: #6: I personally tend to use javascript only in roles that are
optional - ..
That one requires clarification, I would suggest it is
not required for JS that is *completely* optional.
(Ultimately it might be better to encourage authors to at
least document lack of <NOSRCIPT> tag, if it is meant to
be used in a WWW context.)
4 if (..==true) // !understanding boolean.
I'm unsure of chastising #4 owing to the things
that can be implicitly cast to a Boolean.
I may have written that incorrectly, or expressed it
badly, I meant to indicate testing for true when
the result of a computaion was already 'true'.
The other points you added were excellent, thank you.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
Andrew Thompson wrote: It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.
Isn't it just?
I was looking through the JS FAQ for any question that
identifies the warning signs to look out for, the things
that most easily and clearly identify the author of code
as something less than a master of the art.
I did not find an FAQ that answered it, but I think the FAQ
should contain the info., so, here is my proposed list..
Something like a quick guide to identifying bad scripts.
<F ... Y class='more_Speculative_For_Discussion_OK?'>
1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or
another reality?
<SCRIPT LANGUAGE='JavaScript1.2'> - is more indicative of out of date
and ill-informed authoring. The valid HTML question (while I support and
endorse it) is more ambiguous as the LANGUAGE attribute will never
directly harm a script in an HTML browser in itself. Should it actually
be considered bad to include the superfluous? Although once
superfluousness is identified the sane will tend to omit the language
attribute.
If this is to be included then script 'hiding' with HTML comments will
have to go in as well.
2 if (navigator.userAgent.indexOf("IE")) // #FAQ4_26
Yes.
3 eval(); // #FAQ4_40 (usually)
Yes.
4 if (..==true) // !understanding boolean.
Maybe (it certainly demonstrates a questionable grasp of the nature of
boolean values, and that is not a good sign in a programmer).
5 <a href="javascript:somefunction()"> // #FAQ4_24
I have never actually thought of that one as indicative of bad
scripting. But since you bring it up it does qualify (given the many
reasons for *never* using that construct (at least to execute pure
side-effect functions)).
6 <NOSCRIPT> // If missing, the script does not
degrade gracefully.
Unexpected as it might seem the reverse is actually true. Using NOSCRIPT
will tend to act as a barrier to clean degradation. The problem being
that instead of there being two possibilities, script or noscript, there
are actually three: scripted features supported, script features
unsupported and no script execution. NOSCRIPT cannot address the
circumstances where the browser supports javascript (and it is enabled)
but does not support the features that the script wants to use. Coding
for clean degradation in the face of the browser's lack of features for
the script will tend to negate the use of NOSCRIPT tags as that path of
degradation remains available when scripting itself is
unsupported/unavailable.
Jim has requested, and I am part way through writing, a page for the FAQ
notes explaining how little practical use NOSCRIPT tags are.
The main strategy for effective clean degradation is to put the
important content in the HTML and manipulate it from there using
scripts. Failure of the script (for any reason) will tend to leave that
content in place in the HTML where it is available to all. Successful
execution of the script can then remove and replace that content,
transform it into the actively scripted GUI components that may be
wanted, or any similar action. No need for any additional content in
NOSCRIPT tags and no holes in the user's ability to access that
important content.
7 document.write("<p>Important content.."); // delivering
content.
Yes, but:-
if(featureX && document.write){
document.write('<input type="button" onclick="useFeatureX()">');
}
- has arguments in its favour, so it is not the - document.write - but
rather a question of what it is that is written.
</F ... Y>
What is your opinion? Are these the top 7?
Which 28 did I miss?
Browser detecting by object inference should be included.
Failing to adapt to the user's choice of font size and overridden styles
with User style sheets might be candidates (though not many scripts will
pass those criteria).
Accessibility might also be a candidate, keyboard operation being one
obvious first consideration (possibly that would be considered an
excessive criteria as it isn't legally required in much of the world,
and the inability to actively operate a script with the keyboard is not
always a barrier to accessibility (there are alternative strategies).
Also, why does the FAQ not contain the words "degrade",
"graceful" or "noscript" (I guess I might have been
looking for the wrong term with the first two, but
no mention of NOSCRIPT? That surprised me.)
I think I have explained why "noscript" might not be expected to appear.
Degradation, clean, graceful or otherwise, is a script design issue that
probably goes beyond what is appropriate in the quick answers section.
BTW - The Jibbering JS FAQ is the single greatest FAQ*
I use, but I just have a hankerin' to get mentioned in
it, or at least contribute to it. ;-)
<snip>
If you want to guarantee your name appears in association with the FAQ
you could write an article for the notes on some subject where you have
experience/expertise (or are willing to put a lot of research into
making good) (and subject to peer-review). Scripting Java applets might
be your subject. ;-)
Richard.
On Mon, 20 Sep 2004 01:02:53 GMT, Andrew Thompson wrote: On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote:
(A.T.) 6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
Re: #6: I personally tend to use javascript only in roles that are
optional - ..
That one requires clarification, ..
It's out. Richard suggests it is completely redundant,
I will take that to be the case unless proven otherwise.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote: 8. document.getElementById("myId").style.color = "#ff3333"; // Not
testing for methods and properties before using them
Feature detection degrading gracefully, yes.
So many of these ideas seem to come back to
either graceful degradation, ..
9. document.myFormName.myTextInputName.value = "dummy"; // Using
hierarchy shortcuts that may not work as intended in non-IE browsers.
(NB: I really need to check up on how modern browsers cope with such
things)
10. Attempting to use IE-only methods and properties in a WWW
environment.
... or being UA specific in a WWW context, which I
agree is very bad.
11. Use of 'InnerHTML' can be considered bad style, but it is
significantly more usable (though abusable) than the alternatives.
Can you expand on that? I have only started paying
attention to innerHTML recently, and have not really
got the gist of it yet.
12. onblur, onfocus, onchange - usually used to surprise the user by
making form controls behave in unexpected non-standard ways.
Aaah yes, amongst other things that seems to
relate to accessibility. Also general *useability*,
in the wider question of whether a script author
can better determine how the browser of a web-surfer
should operate for the user.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
Andrew Thompson wrote: On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote:
<--snip--> 11. Use of 'InnerHTML' can be considered bad style, but it is
significantly more usable (though abusable) than the alternatives.
Can you expand on that? I have only started paying
attention to innerHTML recently, and have not really
got the gist of it yet.
innerHTML is a proprietary method created by Microsoft and adopted by
other browsers. The alternative is to create a textNode and insert it,
which seems to have less browser support.
Basically what it does is take a string of HTML and insert it into a
tag, making the string its inner HTML, there is also an MS-only
outerHTML that allows you to completely remove the enclosing tag and
replace it with something else (never found a good use for that one though) 12. onblur, onfocus, onchange - usually used to surprise the user by
making form controls behave in unexpected non-standard ways.
Aaah yes, amongst other things that seems to
relate to accessibility. Also general *useability*,
in the wider question of whether a script author
can better determine how the browser of a web-surfer
should operate for the user.
onblur being the worst of them. User inputs data, validation is called,
it creates an alert, which blurs the input, the user clicks OK, the
validation is called again since the element lost focus, and so on...
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
On Mon, 20 Sep 2004 02:27:15 +0100, Richard Cornford wrote: Andrew Thompson wrote:
... 1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or
another reality?
<SCRIPT LANGUAGE='JavaScript1.2'> - is more indicative of out of date
and ill-informed authoring.
OK yes, I agree go with that refinement..
..The valid HTML question (while I support and
endorse it) is more ambiguous as the LANGUAGE attribute will never
directly harm a script in an HTML browser in itself. Should it actually
be considered bad to include the superfluous?
I vote yes. It is extra bytes for no good reason,
it is invalid and effectively 'gets in the way' of
seeing the actual HTML errors when validating*.
* It seems we are all pretty much agreed that HTML should
be validated prior to posting questions about malfunctioning
scripts (though it rarely happens), and if trivial errors
such as lack of img alt text and language='javascript'
attributes are 99 of the 101 errors on a page, it is easy
to miss the last two, which might be the cause of the problem.
If this is to be included then script 'hiding' with HTML comments will
have to go in as well.
Good idea.
4 if (..==true) // !understanding boolean.
Maybe (it certainly demonstrates a questionable grasp of the nature of
boolean values, and that is not a good sign in a programmer).
I will see what others have to say. So far Andrew
felt it shouldn't be in, and you question it, it's
looking like I might have been wrong.
5 <a href="javascript:somefunction()"> // #FAQ4_24
I have never actually thought of that one as indicative of bad
scripting. But since you bring it up it does qualify (given the many
reasons for *never* using that construct (at least to execute pure
side-effect functions)).
Yep. Accessiblility and graceful degradation have
been much on my mind recently, ..users should never
have to deal with 'broken links', or at the very
least be connected to a page that explains that JS
is required for the functionaloty that link represents.
6 <NOSCRIPT> // If missing, the script does not
degrade gracefully.
Unexpected as it might seem the reverse is actually true.
<snip> Jim has requested, and I am part way through writing, a page for the FAQ
notes explaining how little practical use NOSCRIPT tags are.
.... The main strategy for effective clean degradation is to put the
important content in the HTML and manipulate it from there using
scripts.
OK.. but, I have actually used the <noscript>
tag recently, mostly for arcane applications that
must work or be informative to why they don't, and
on browsers back to NN 4.78.
Were you saying recently that even NN 4.78 was conducive
to element display/hide using JS? The reason I ask is
that I became so disillusioned with NN 4.78 rendering
of CSS that I dropped it back to background and
foreground color, and font-size (100%). I could not even
get that obolete US to reliably retain a font-face
all the way to the bottom of the page. I find it
hard to believe it could reliably be used for showing
(and/or hiding) content.
7 document.write("<p>Important content.."); // delivering
content.
Yes, but:-
if(featureX && document.write){
document.write('<input type="button" onclick="useFeatureX()">');
}
- has arguments in its favour, so it is not the - document.write - but
rather a question of what it is that is written.
That is why I wrote "<p>Important content..",
but it might need rephrasing.
</F ... Y>
What is your opinion? Are these the top 7?
Which 28 did I miss?
Browser detecting by object inference should be included.
Do not recall seeing the term, but I think I can guess
what it means, I will research it a bit further.
Failing to adapt to the user's choice of font size
Yes. I had not thought of that, but with the
way browsers are going, attempts to do so will
inevitably fall apart when the page author's
'carefully chosen' 8px verdana that exactly
fills the 54 pix width assigned in the table,
is zoomed to 14px by the user. ;-)
..and overridden styles
with User style sheets might be candidates (though not many scripts will
pass those criteria).
That is a problem, I have thus far only been interested
in adjusting visiblility of elements defined in the HTML.
But now you mention it, I can see a lot of potential
clashes between scripts that want to set colors and
sizes, and a User stylesheet that does whatever the
heck the user requires of it.
Accessibility might also be a candidate, keyboard operation being one
obvious first consideration (possibly that would be considered an
excessive criteria as it isn't legally required in much of the world,
and the inability to actively operate a script with the keyboard is not
always a barrier to accessibility (there are alternative strategies).
I think accessibility is extremely important, screw
the technicalities of the national legal requirements..
<http://www.physci.org/rights/declaration.jsp#27>
As far as I am concerned, web-developers should
be looking at at the bigger picture, and I regard
the internet as being part of the 'cultural life
of the community'. We should endeavour to bring
the benefits of the internet to as wide an audience
as practical.
Also, why does the FAQ not contain the words "degrade",
"graceful" or "noscript" (I guess I might have been
looking for the wrong term with the first two, but
no mention of NOSCRIPT? That surprised me.)
I think I have explained why "noscript" might not be expected to appear.
Yep.
Degradation, clean, graceful or otherwise, is a script design issue that
probably goes beyond what is appropriate in the quick answers section.
<musing>
Maybe it should be mentioned in a section, perhaps
combined with accessibility(?)
</musing> BTW - The Jibbering JS FAQ is the single greatest FAQ*
I use, but I just have a hankerin' to get mentioned in
it, or at least contribute to it. ;-)
<snip>
If you want to guarantee your name appears in association with the FAQ
you could write an article for the notes on some subject where you have
experience/expertise (or are willing to put a lot of research into
making good) (and subject to peer-review). Scripting Java applets might
be your subject. ;-)
(chuckles) I think all the concepts are in place,
but I still have to turn it into a single robust
example that can handle the vast majority of
situations cleanly and informatively.
Thanks for your response Richard, there are some
great ideas being put forward (and I am also getting
a few good tips on clearing up some misconceptions
I had, to boot!).
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
Andrew Thompson wrote: It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.
I think it's even more of a pity that most of the people who proclaim to
write excellent code offer so little to the web in terms of real-world,
practical solutions for people who lack the skill to write them on their
own!
[Richard, let's not even start this thread again... ;)]
the things
that most easily and clearly identify the author of code
as something less than a master of the art.
While I agree that it's best to find solutions from people who are the most
knowledgeable in the field, it's also important to note that value can come
in many different packages. If you're trying to solve problem X, and no
'masters' have published solutions for X, while several intermediate hackers
have, using the solutions you find or at least using them as a starting
point is not a bad thing.
1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or another
Much code was written years ago and continually adapted. The above used to
be the standard way of declaring the <script> tag. It doesn't point to bad
code, just maybe code that needs touched up.
3 eval(); // #FAQ4_40 (usually)
However, a correct use of eval might be a good indicator that the person
does know what they are doing ;)
4 if (..==true) // !understanding boolean.
I agree with this, but I would not agree with this:
if (var==1) //bad
bviously, 1 evals to true and so the ==1 is not required, but I disagree
with many who say this is bad style. I think it's better to include the ==1
or ==0.
5 <a href="javascript:somefunction()"> // #FAQ4_24
This is too broad of a condemnation. Similar to eval, it does have its
place.
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
Completely not true, especially if the script in question is 'add-on'
functionality and lack of javascript capability in the browser doesn't
matter at all.
--
Matt Kruse http://www.JavascriptToolbox.com
On Sun, 19 Sep 2004 23:04:30 -0500, Matt Kruse wrote: Andrew Thompson wrote:
... ..the things
that most easily and clearly identify the author of code
as something less than a master of the art.
While I agree that it's best to find solutions from people who are the most
knowledgeable in the field, it's also important to note that value can come
in many different packages.
I agree Matt. Even though I would avoid pre-packaged
code in most situations (my script needs are either
relatively simple, or rather unusual), I recongize
that there are circumstance where there is a well
written, well tested library that can provide great
DHTML functionality to a site that would otherwise
miss out.
I can see possible problems with the web-developers
*use* of pre-packaged code, whether it is a full code
library, or even 'a couple of lines of script',
if they don't know what they are doing.
That is not a reason to stop supplying pre-packaged
*robust* code though, the supplier cannot be expected to
account for the idiocy of every person that may lay
their hands on the code subsequently, and who might
ignore the useage warnings and documentation.
...If you're trying to solve problem X, and no
'masters' have published solutions for X, while several intermediate hackers
have, using the solutions you find or at least using them as a starting
point is not a bad thing.
I do not know specifically of what you are speaking,
but could I will take a guess/punt and you can let
me know if I'm on track.
If a script is presented as being 'A SlideShow with
extra functionality in some browsers', and is a standard
fully functional image slideshow in Mozilla/Opera and most
other browsers made this millennium, but in IE it has an
image slideshow that *fades* between one image and another.
That is a great package to get it if is described as
'SlideShow with (extra) fade functionality for IE'
Excellent script, it performs as advertised, and presents
a useable slideshow on all the major browsers.
If somebody came into the group looking for an
'image slideshow' I would gladly recommend it.
But if they approached the group asking for a 'fade between
images slideshow' for their web-site, I would point out that
no JS can do that cross-browser, though their is one IE specific
package.. OR another alternative is Java (which might or not
mean a larger total potential user base than an IE only script).
But if a person asks 'how can I do X', I assume they are
talking doing X on the WWW, X-Browser/X-plat and in a way
that degrades gracefully. Anything less should come with
warnings and caveats. 1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or another
Much code was written years ago and continually adapted. The above used to
be the standard way of declaring the <script> tag. It doesn't point to bad
code, just maybe code that needs touched up.
I agree that there is oodles of production code
out there that is not seriously damaged by the
attribute, but I put much higher standards on
anything used as a *teaching* material, and the
code that hits these groups is often presented
by people learning Java, so perhaps even beyond
whether or not such JS is good, solid code, we
should take it that such code was *not* intended
to teach people, just to do stuff.
In fact, that has just made one penny drop for me.
Changing to a subject I'm more familiar with for
a moment (Java) I will describe a situation that
I am confident you will recognize.
You are just putting the finishing touches in some
code where you just figured how to do some wizz-bang
thing and considering how to present it.
The code may be 18Kb, but to optimize it for download
speed and size, you can make all the internal var names
very short and meaningless and shink the code to ..13Kb.
A siginficant improvement in delivery speed.
On the other hand, that would make the code almost
illegible, so the other way to go if it is intended
as example code, is to put in further comments and
check that all your vars have descriptive (read long)
names. This code is 26Kb, but is very instructive,
and documented not just functions in the the code, but
also the internal implementation details are explained.
Which code is 'better'?
In most situations, obviously, the first, bandwidth
optimized code. The thousands of users who download
the 13Kb do not care what goes on inside that 'black box'
that is their browser, just so long as they can see the
funky stuff. After all, the primary purpose of JS is to
execute, not teach!
OTOH, I understand it is relatively easy to run utilities
that will do that code compression for you, so we should
be perhaps encourage people to learn with comments. Then
later, when they are more proficient and making extensive
code plug-ins that act as black-boxes, to compress the
script then. 4 if (..==true) // !understanding boolean.
I agree with this, but I would not agree with this:
if (var==1) //bad
bviously, 1 evals to true and so the ==1 is not required, but I disagree
with many who say this is bad style. I think it's better to include the ==1
or ==0.
I can understand your thinking on that, for much
the same reasons as my last answer. It is more
obvious what is happening, so the code is better
documented for any that might wish to modify or
update it later. 5 <a href="javascript:somefunction()"> // #FAQ4_24
This is too broad of a condemnation. Similar to eval, it does have its
place.
I need to refine it to be more specific, same
with eval(), I am hoping the relevant anchors
might go part way to explaining. 6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
Completely not true, especially if the script in question is 'add-on'
functionality and lack of javascript capability in the browser doesn't
matter at all.
Yep. I was way off on that.
It might have been accurate to say..
"In some rare, arcane and extremely unusual circumstances
the lack of <NOSCRIPT> *might* be indicative of a bad
script.. but more likely it's *inclusion* is indication
of a bad script."
That kind of lacks the 'punch' of the single line point
I had originally, besides being almost (but not quite
entirely) unlike that statement in content and meaning. ;-)
Thanks for your thoughts, Matt.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Sun, 19 Sep 2004 23:42:04 GMT, Andrew Thompson
<Se********@www.invalid> wrote: 6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
This is definately not BAD, I never use NOSCRIPT, it's bad (it relies
on the idea that script support is a boolean - it's not! perhaps if
UA's after erroring worked as if script was disabled and redrew the
page with NOSCRIPTS then maybe... but they don't!)
BTW - The Jibbering JS FAQ is the single greatest FAQ*
I use, but I just have a hankerin' to get mentioned in
it, or at least contribute to it. ;-)
It's 8 or 9 years old now, with many different editors and lots of
input from the group, it's a good example of what you can get when
usenet groups do contribute well to the faq I think.
Jim.
On Mon, 20 Sep 2004 02:15:01 GMT, Andrew Thompson
<Se********@www.invalid> wrote: On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote: 10. Attempting to use IE-only methods and properties in a WWW
environment.
.. or being UA specific in a WWW context, which I
agree is very bad.
Afraid not, if your content degrades, it doesn't matter that you're UA
specific, since JS is only an optional extra, there may be very
sensible reasons to keep the QA and maintenance costs manageable by
only attempting a subset of UA's - it depends on what you're doing of
course, but I don't think it's as cut and dried as you suggest.
Jim.
On Sun, 19 Sep 2004 23:04:30 -0500, "Matt Kruse"
<ne********@mattkruse.com> wrote: Andrew Thompson wrote:
I agree with this, but I would not agree with this:
if (var==1) //bad
bviously, 1 evals to true and so the ==1 is not required, but I disagree
with many who say this is bad style. I think it's better to include the ==1
or ==0.
+1 5 <a href="javascript:somefunction()"> // #FAQ4_24
This is too broad of a condemnation. Similar to eval, it does have its
place.
Hmm, I don't agree with this, there's always more reliable ways to do
the same - especially with IE service packs removing the ability to
script the resulting document (when somefunction returns a document).
Did you have something in mind?
Jim.
On Mon, 20 Sep 2004 07:05:29 GMT, Jim Ley wrote: On Mon, 20 Sep 2004 02:15:01 GMT, Andrew Thompson
<Se********@www.invalid> wrote:
On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote: 10. Attempting to use IE-only methods and properties in a WWW
environment.
.. or being UA specific in a WWW context, which I
agree is very bad.
Afraid not, if your content degrades, it doesn't matter that you're UA
specific, since JS is only an optional extra, there may be very
sensible reasons to keep the QA and maintenance costs manageable by
only attempting a subset of UA's - it depends on what you're doing of
course, but I don't think it's as cut and dried as you suggest.
OK. I must admit that sometimes my definition
of 'degrade gracefully' is to have a message
appear in older browsers using CSS import hacks
to display the message 'we have not been able
to extend the provision of ... to this browser'
I was more thinking of JS that works in only a single
browser due to that particular UA maker's use of a
proprietary element or functionality.
In the reply to Matt, I mentioned an example of
a SlideShow with fade transtitions. The SlideShow
itself cross-browser, but the fading effect available
only on IE.
Could that be a suitable example (for a WWW context)
of a 'SlideShow' - yes, of a 'SlideShow with fading
image transitions', no.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
How about adding lame efforts to disable the context menu (e.g.
"document.onclick = function(){return false};")
--
Philip Ronan ph***********@virgin.net
(Please remove the "z"s if replying by email)
Andrew Thompson wrote on 20 sep 2004 in comp.lang.javascript : 4 if (..==true) // !understanding boolean.
I'm unsure of chastising #4 owing to the things
that can be implicitly cast to a Boolean.
I may have written that incorrectly, or expressed it
badly, I meant to indicate testing for true when
the result of a computaion was already 'true'.
... already boolean [could be false too]
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress,
but let us keep the discussions in the newsgroup)
On Sun, 19 Sep 2004 22:40:40 -0400, Randy Webb wrote:
(Andrew Urquhart) 11. Use of 'InnerHTML' can be considered bad style, but it is
significantly more usable (though abusable) than the alternatives.
(A.T.) Can you expand on that? I have only started paying
attention to innerHTML recently, and have not really
got the gist of it yet.
innerHTML is a proprietary method created by Microsoft and adopted by
other browsers. The alternative is to create a textNode and insert it,
which seems to have less browser support.
From that description, I do not think a blanket
'use of innerHTML is bad' is justifiable, and the
circumstances where it *is* bad style seem to come
back to the more general idea of degrading gracefully
based upon feature detection.
Does that sound right?
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Mon, 20 Sep 2004 03:05:58 GMT, Andrew Thompson <Se********@www.invalid>
wrote: On Mon, 20 Sep 2004 02:27:15 +0100, Richard Cornford wrote:
[snip]
..The valid HTML question (while I support and
endorse it) is more ambiguous as the LANGUAGE attribute will never
directly harm a script in an HTML browser in itself. Should it actually
be considered bad to include the superfluous?
I vote yes. It is extra bytes for no good reason,
it is invalid and effectively 'gets in the way' of
seeing the actual HTML errors when validating*.
The problem with using the language attribute occurs when a version is
specified, and a browser actually respects that version.
Richard's example of v1.2 is the worst as some basic language rules were
changed, resulting in unexpected behaviour. An example is:
var a = 10,
b = 20;
if(a = b) {
Normally, this would assign the value of b to a and the expression,
converted to boolean, would evaluate as true. However, under v1.2 rules,
this would actually be a comparison and evaluate to false.
This is the worrying thing about most script collections. They use the
language attribute, needlessly specify version information; completely
unaware of its potential implications.
Richard did write a piece on the SCRIPT element and its attributes for the
FAQ notes, but it hasn't made it in yet.
[snip]
4 if (..==true) // !understanding boolean.
Maybe (it certainly demonstrates a questionable grasp of the nature of
boolean values, and that is not a good sign in a programmer).
I will see what others have to say. So far Andrew
felt it shouldn't be in, and you question it, it's
looking like I might have been wrong.
I agree with Richard. It's not bad code, per se, but it does show a lack
of knowledge or confidence with the language. Most programmers are
comfortable with the implicit type conversions that occur and know
precisely what the evaluation of numbers as booleans will do. Those less
comfortable will prefer to explicitly state the comparison.
I wouldn't recommend it, though, purely from a style perspective. It's
redundant and clutters expressions.
[snip]
Were you saying recently that even NN 4.78 was conducive
to element display/hide using JS?
You can hide layers (LAYERs or positioned DIVs) in 4.77 (that the earliest
I have) using the visibility property. However, the syntax changes
somewhat, and the values are different.
<div id="test" style="position: absolute;">Page content</div>
var d = document.layers['test'];
d.visibility = 'hidden'; // Hide the DIV
d.visibility = 'visible'; // Show the DIV
The awkward part comes when you try to check the current state. Whilst you
can assign hidden and visible and the achieve the expected behaviour,
reading the value back will give you 'hide' and 'show', respectively.
I don't believe this can be applied to any other elements, though.
[snip] Browser detecting by object inference should be included.
Do not recall seeing the term, but I think I can guess
what it means, I will research it a bit further.
The common example is:
if(document.all) {
// Using IE
which is ridiculous because Opera supports the all collection, and I'm
lead to believe that recent versions of ICEbrowser does, too. I'm sure
there will be others.
This particular strategy can fail disasterously as all it takes for many
dependent scripts to break is for Mozilla to include the all collection in
its DOM. I believe there's some discussion about this, but hopefully it
won't happen, simply because I hate IE-isms and that one is particularly
useless with the advent of the W3C DOM.
[snip]
Mike
--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
>><FAQENTRY class='more_Speculative_For_Discussion_OK?'> 1 <SCRIPT LANGUAGE='JavaScript'> // last millenium, or another reality?
2 if (navigator.userAgent.indexOf("IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascript:somefunction()"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write("<p>Important content.."); // delivering content.
</FAQENTRY>
8. document.getElementById("myId").style.color = "#ff3333"; // Not
testing for methods and properties before using them
9. document.myFormName.myTextInputName.value = "dummy"; // Using
hierarchy shortcuts that may not work as intended in non-IE browsers.
(NB: I really need to check up on how modern browsers cope with such
things)
10. Attempting to use IE-only methods and properties in a WWW
environment.
11. Use of 'InnerHTML' can be considered bad style, but it is
significantly more usable (though abusable) than the alternatives.
12. onblur, onfocus, onchange - usually used to surprise the user by
making form controls behave in unexpected non-standard ways.
0. It does not pass JSLINT. http://www.crockford.com/javascript/lint.html
Jim Ley wrote: Hmm, I don't agree with this, there's always more reliable ways to do
the same - especially with IE service packs removing the ability to
script the resulting document (when somefunction returns a document).
Wait, what? Does SP2 remove the ability for a function to return the
document?
How about including the source inlike like javascript :'<html>...' ?
I've not yet loaded SP2, but I'm trying to get a machine loaded with it to
see what all might be affected.
--
Matt Kruse http://www.JavascriptToolbox.com
On Mon, 20 Sep 2004 09:03:55 -0500, "Matt Kruse"
<ne********@mattkruse.com> wrote: Jim Ley wrote: Hmm, I don't agree with this, there's always more reliable ways to do
the same - especially with IE service packs removing the ability to
script the resulting document (when somefunction returns a document).
Wait, what? Does SP2 remove the ability for a function to return the
document?
How about including the source inlike like javascript:'<html>...' ?
No, it doesn't prevent it, it (actually I think it was a different
hotfix) stops you scripting it - so whilst you could go
<iframe src="javascript :<body>test</body>">
iframeref.document.write( ... )
You can no longer do so - equally you have similar problems with
iframes without a src.
Jim.
On Mon, 20 Sep 2004 07:01:00 -0700, Douglas Crockford wrote: 0. It does not pass JSLINT. http://www.crockford.com/javascript/lint.html
Thanks Douglas. I had seen reference to it before,
but it had not occured to me to investigate automated
means of script checking.
Yes. 'The 0th law of JS validation' sounds a bit
'I Robot' though, so I'm inclined to slot it in at #1
and adjut the others, when an outomated tool can detect
errors, it .
_____________________
As an aside, I have also linked to it from my
page on preparing examples for others..
<http://www.physci.org/codes/sscce.jsp#co>
...it is a concept that I promote widely on the Java
groups particularly. New posters on c.l.j.* are even
beginning to refer to example Java codes as SSCCE's! ;-)
I do not mention that page much in c.l.js, but it, in
combination with Spartanicus' page on web-page/styles
examples*, might help communicate the idea that a well
prepared example is much more likely to get attention
and to be solved.
* <http://www.spartanicus.utvinternet.ie/help_us_help_you.htm>
The JS FAQ covers most of the points I make in my SSCCE
page, but they are spread throughout the FAQ, and often
mentioned as a small part of volumes of other information.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Mon, 20 Sep 2004 15:03:32 GMT, Andrew Thompson wrote: Yes. 'The 0th law of JS validation' sounds a bit
'I Robot' though, so I'm inclined to slot it in at #1
and adjut the others, when an outomated tool can detect
errors, it .
I apparently did not insert enough change for that
paragraph, I'll try it again.
"..so I'm inclined to slot it in at #1 and adjust the
others accordingly. When an automated tool can detect
errors, it makes sense to use it as the first line
of attack for solving problems."
Yes.. yes that's better.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
Jim Ley wrote: No, it doesn't prevent it, it (actually I think it was a different
hotfix) stops you scripting it - so whilst you could go
<iframe src="javascript:<body>test</body>">
iframeref.document.write( ... )
You can no longer do so - equally you have similar problems with
iframes without a src.
I'd like more info about this. Do you have a test case?
In my version of IE6 - which is completely up-to-date except for SP2 - I can
do a document.write() to an iframe document without any problems.
--
Matt Kruse http://www.JavascriptToolbox.com
Andrew Thompson said:
On Mon, 20 Sep 2004 15:03:32 GMT, Andrew Thompson wrote:
Yes. 'The 0th law of JS validation' sounds a bit
'I Robot' though, so I'm inclined to slot it in at #1
and adjut the others, when an outomated tool can detect
errors, it .
I apparently did not insert enough change for that
paragraph, I'll try it again.
"..so I'm inclined to slot it in at #1 and adjust the
others accordingly. When an automated tool can detect
errors, it makes sense to use it as the first line
of attack for solving problems."
Keep in mind that it detects *probable* errors.
A few of the things it flags are useful if used carefully
and the intention is well documented. I don't think it
would flag anything in any of my production code, but I
wouldn't trust it blindly to declare code to be "bad".
Matt Kruse wrote: Jim Ley wrote:
No, it doesn't prevent it, it (actually I think it was a different
hotfix) stops you scripting it - so whilst you could go
<iframe src="javascript:<body>test</body>">
iframeref.document.write( ... )
You can no longer do so - equally you have similar problems with
iframes without a src.
I'd like more info about this. Do you have a test case?
In my version of IE6 - which is completely up-to-date except for SP2 - I can
do a document.write() to an iframe document without any problems.
<script type="text/javascript">
function changeIFrame(){
myIFrame.document.write('new Content')
myIFrame.close()
}
<body onload="changeIFrame()">
<iframe src="javascript :'<body>test</body>'" id="myIFrame"
name="myIFRame' onload="alert(this.src)"></iframe>
Seems to work in IE6 SP2 on WinXP SP2.
So I am not sure what Jim is alluding to.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
JRS: In article <yc*****************************@40tude.net>, dated
Sun, 19 Sep 2004 23:42:04, seen in news:comp.lang.javascript, Andrew
Thompson <Se********@www.invalid> posted : It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.
I was looking through the JS FAQ for any question that
identifies the warning signs to look out for, the things
that most easily and clearly identify the author of code
as something less than a master of the art.
Another one is spelling/grammar errors, at least in the case of those
who seem to be writing in there native language <G>.
I did not find an FAQ that answered it, but I think the FAQ
should contain the info., so, here is my proposed list..
4 if (..==true) // !understanding boolean.
include ..==false
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
On the whole, agreed. Although a well-designed site may look
magnificent with scripting, and adequately excellent without, the
scripting should only be used if it adds value; a user who does not get
this value should be informed that added value is available. This
probably justifies at least one NOSCRIPT, but does not require one for
every SCRIPT.
7 document.write("<p>Important content.."); // delivering content.
Such a line is valid as the beginning of a section of computed content.
Also :
Use of getYear, especially if combined with unreliable "century" code,
and more so if that code fails for dates after 1999.
Use of 24*60*60*1000 and vice versa, rather than 864e5 or 86400000; use
of that number in a manner which will fail across Summer Time changes,
or away from GMT.
Others in <URL:http://www.merlyn.demon.co.uk/js-dates.htm#SPF>.
Presenting dates in FFF.
--
© 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.
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes: <SCRIPT LANGUAGE='JavaScript1.2'> - is more indicative of out of date
and ill-informed authoring.
Definitly, that goes from just bad to directly dangerous.
.... as the LANGUAGE attribute will never directly harm a script in an
HTML browser in itself.
Sure it will. Try running the following in Mozilla and IE, and wonder
why they give different results.
---
<script language="JavaScript1.2">
var y = {someObject: false};
//...maybe some code that *could* do "y=null", but didn't
var x;
if (x = y) {
alert("x is now equal to y");
} else {
alert("y was not an object");
}
</script>
---
Writing language="JavaScript1.2" is explicitly asking for trouble!
I know, it's not a good idea to have an assignment in a condition,
but it's valid Javascript.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
On Mon, 20 Sep 2004 12:40:33 -0400, Randy Webb
<Hi************@aol.com> wrote: Matt Kruse wrote: I'd like more info about this. Do you have a test case?
In my version of IE6 - which is completely up-to-date except for SP2 - I can
do a document.write() to an iframe document without any problems.
<script type="text/javascript">
function changeIFrame(){
myIFrame.document.write('new Content')
myIFrame.close()
}
<body onload="changeIFrame()">
<iframe src="javascript:'<body>test</body>'" id="myIFrame"
name="myIFRame' onload="alert(this.src)"></iframe>
Seems to work in IE6 SP2 on WinXP SP2.
So I am not sure what Jim is alluding to.
I'll see if I can dig up a test case, but as my reserve laptop's
screen just broke aswell as my main one, it may take awhile...
You're replacing the content there, though, maybe it was calling
methods...
Jim.
Jim Ley wrote: On Mon, 20 Sep 2004 12:40:33 -0400, Randy Webb
<Hi************@aol.com> wrote:
<--snip-->
So I am not sure what Jim is alluding to.
I'll see if I can dig up a test case, but as my reserve laptop's
screen just broke aswell as my main one, it may take awhile...
Yikes!
You're replacing the content there, though, maybe it was calling
methods...
Maybe. If you can dig up the test case, I don't mind testing it to make
sure its an SP2 issue. I have both a non-updated and an updated XP that
I can test on to compare the two results.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Andrew Thompson wrote: Richard Cornford wrote:
<snip> Were you saying recently that even NN 4.78 was
conducive to element display/hide using JS?
Netscape 4 allows CSS positioned (absolute and relative) elements and
its LAYER and ILAYER elements to be hidden and shown, and their content
to be re-written (but not read.). But the Netscape 4 DHTML model is so
different form current browsers that these days it probably isn't worth
the effort to design DHTML for active Netscape 4 support (and with
sensible degradation designed in that still isn't the end of the world
for those that are still using Netscape 4).
<snip> Browser detecting by object inference should be included.
Do not recall seeing the term, but I think I can guess
what it means, I will research it a bit further.
It was actually coined by Lasse Reichstein Nielsen to express (in part)
the style of browser detecting that makes conclusions about a browser's
entire object model based on tests applied to a few (and often only one)
feature of that browser. I use it because the term 'object detecting'
has (erroneously) been applied to that style of browser detecting in
addition to real feature detecting. So to avoid confusion I don't use
'objet detecting' to label anything, preferring the more specific and
descriptive terms.
It is also applied to structures such as:-
if(document.images){
x = new Image();
x.src = 'img.gif';
}
- where the existence of the - Image - constructor is *inferred* from
the existence of the - document.images - collection. While true feature
detection would require that the existence of the - Image - constructor
should be directly verified with - if(window.Image) - and the like,
prior to the use of the constructor, because the obvious one-to-one
relationship in that test virtually guarantees the safe execution of the
code that it guards.
<snip> Degradation, clean, graceful or otherwise, is a script
design issue that probably goes beyond what is
appropriate in the quick answers section.
<musing>
Maybe it should be mentioned in a section, perhaps
combined with accessibility(?)
</musing>
<snip>
I wish it could be a simple as just mentioning script design and
accessibility. Both huge subjects about which little has been
pinned-down to the extent that any form of rules could be applied (as
opposed to general advice and guidelines).
Getting back to the subject of this thread. You are proposing we create
a list of telltale indicators of bad scripts. Presumably as guidance for
those not knowledgeable/experienced enough to apply their own judgement.
That is a bit of a problem in itself as it means that those indicators
should not require too much technically informed interpretation (else
they become unnecessarily).
LANGUAGE='JavaScript1.2' - always bad.
browser detection (by any means) - always bad.
eval(' ... '); - so exceptionally valid that
it can be stated as bad.
href="javascript :somefunction()" - wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.
Failing to degrade to a viable
web page (for any reason including
the absence of script support) - easily objectively tested and
certainly bad.
Failing to adapt to variables
known to be beyond the control
of a script author (font size
and the like) - easily objectively tested and
probably bad.
Crippling the normal browser
functionality - difficult to ever justify so bad.
However:-
Insufficiently defensive
scripting - not an easy judgement for someone
who hasn't learnt how to do it
themselves.
JSLINT - errors are bad, warnings take a bit
of judgement (It is not often that
I do things that JSLINT would flag,
but when I do it is informed and
intended).
Functional but
sub-optimal (24*60*60*1000)
or perverse (x.checked == true)
scripting - difficult to generalise about for the
inexpert, and inappropriate to
explicitly list.
If the intention is to provide the inexperienced with criteria for
identifying scripts that they should not consider examining as a
learning exercise, or deploying on a public web site, then the criteria
should be clear and easy to identify and test. That probably means
avoiding any attempt to build a comprehensive list and instead
concentrating on those things that provide the most (and most useful)
discrimination with the least need to judge and interpret the results of
tests.
Otherwise we are looking at a more in-depth document with guidance on
the application of the criteria and the interpretation of the results
(not impossible but also not a quick answer). As usual the optimum
solution would be a combination of the quick and simple and a more
in-depth document covering all the points raised, but it would help to
determine (agree upon) the best candidates for the quick answers entry.
Richard.
Lasse Reichstein Nielsen wrote: Richard Cornford writes: <SCRIPT LANGUAGE='JavaScript1.2'> - is more indicative
of out of date and ill-informed authoring.
Definitly, that goes from just bad to directly dangerous.
... as the LANGUAGE attribute will never directly harm a
script in an HTML browser in itself.
Sure it will. Try running the following in Mozilla and IE,
and wonder why they give different results.
<snip>
I was thinking in terms of the language attribute as in Andrew's
original example, though I could have expressed that better. With the
language version (and particularly 1.2) it certainly has the potential
for harm.
Richard.
Dr John Stockton wrote:
Another one is spelling/grammar errors, at least in the case of those
who seem to be writing in there native language <G>.
Er. "There" should be "their".
--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
On 20 Sep 2004 09:18:38 -0700, Lee wrote:
(JSLint) Keep in mind that it detects *probable* errors.
A few of the things it flags are useful if used carefully
and the intention is well documented. I don't think it
would flag anything in any of my production code, but I
wouldn't trust it blindly to declare code to be "bad".
Could you provide some concrete examples Lee?
I would want to make note of, and provide some
examples of 'false positives'.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Tue, 21 Sep 2004 01:36:55 +0100, Richard Cornford wrote: Lasse Reichstein Nielsen wrote: Richard Cornford writes: <SCRIPT LANGUAGE='JavaScript1.2'> - is more indicative
of out of date and ill-informed authoring.
as the LANGUAGE attribute will never directly harm a
script in an HTML browser in itself.
Sure it will. Try running the following in Mozilla and IE,
and wonder why they give different results.
<snip>
I was thinking in terms of the language attribute as in Andrew's
original example, though I could have expressed that better.
OK (though invalid) <SCRIPT LANGUAGE='JavaScript'>
Bad always <SCRIPT LANGUAGE='JavaScript1.2'>
The warning list would need to stress the
distinction between the two, and while I see
the point about invalid attributes not causing
harm, I am uncomfartable with -not- pointing out
invalid HTML..
OTOH, it seems the "LANGUAGE='JavaScript'" does
go beyond the scope of filtering out bad scripts.
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Tue, 21 Sep 2004 01:36:50 +0100, Richard Cornford wrote: Andrew Thompson wrote: Richard Cornford wrote: <snip> Were you saying recently that even NN 4.78 was
conducive to element display/hide using JS?
Netscape 4 allows CSS positioned (absolute and relative) elements and
its LAYER and ILAYER elements to be hidden and shown,
( Just to go a little off topic for a moment )
Excellent, that was all I am requiring of it
for my uses, but...
..But the Netscape 4 DHTML model is so
different form current browsers that these days it probably isn't worth
the effort to design DHTML for active Netscape 4 support ..
I take it (hope that) 'active Netscape 4 support' is
referring DHTML beyond showing/hiding elements?
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Tue, 21 Sep 2004 01:36:50 +0100, Richard Cornford wrote: Andrew Thompson wrote: Richard Cornford wrote:
.... Browser detecting by object inference should be included.
... It was actually coined by Lasse Reichstein Nielsen to express (in part)
the style of browser detecting that makes conclusions about a browser's
entire object model
.... if(document.images){
x = new Image();
x.src = 'img.gif';
}
OK, got it. Yes, I agree.
<snip> Degradation, clean, graceful or otherwise, is a script
design issue that probably goes beyond what is
appropriate in the quick answers section.
<musing>
Maybe it should be mentioned in a section, perhaps
combined with accessibility(?)
</musing>
<snip>
I wish it could be a simple as just mentioning script design and
accessibility. Both huge subjects about which little has been
pinned-down to the extent that any form of rules could be applied (as
opposed to general advice and guidelines).
I will have a look through the FAQ for such things,
if I do not feel they cover it, I might draft
something myself for Jim's consideration.
But then it would probably become quite a long article,
mostly about HTML, CSS and general UI design, so it might
be better to host it at my own site and suggest it as a link.
Getting back to the subject of this thread. You are proposing we create
a list of telltale indicators of bad scripts. Presumably as guidance for
those not knowledgeable/experienced enough to apply their own judgement.
That is a bit of a problem in itself as it means that those indicators
should not require too much technically informed interpretation (else
they become unnecessarily).
Yes, if it comes down to a degree of expertise to make
a judgement, it is not really suitable for the list.
Crippling the normal browser
functionality - difficult to ever justify so bad.
Several posters have poinetd out to me that something
that is bad for UI design or useability is not necessarily
a poorly written script, which is a good point.
I am torn between including things which are just plain stupid,
*or* strictly limiting it to script that is shoddily written.
<snip> JSLINT - errors are bad, warnings take a bit
of judgement
I think it might be best to include it as first,
but note it is the *errors* that are a dead giveaway.
<snip> Functional but ...
.... or perverse (x.checked == true)
scripting - difficult to generalise about for the
inexpert, and inappropriate to
explicitly list.
Whereas '==true' contrasts to the 'solid script doing stupid things'
by being the (slightly) inept way of doing things which may be
quite sensible.
I would tend to consider it an indication the author's knowledge
could not be trusted. I think I'll count votes on this one in the end..
Thanks for the further comments Richard..
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
On Mon, 20 Sep 2004 16:49:54 +0100, Dr John Stockton wrote: JRS: In article <yc*****************************@40tude.net>, dated
Sun, 19 Sep 2004 23:42:04, seen in news:comp.lang.javascript, Andrew
Thompson <Se********@www.invalid> posted :
...6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
On the whole, agreed.
I must admit I am now tending against this one.
As a simple statement to someone assessing a script,
it is more often wrong than write, ...right. ;-)
7 document.write("<p>Important content.."); // delivering content.
Such a line is valid as the beginning of a section of computed content.
Well.. I don't know what to say here, how about..
7 document.write("<p>Important content that is not computed.."); //
delivering content.
But *damn* *it* that line wraps.. (VBG)
My point here, is that while several people have criticized
it, I also have a hankering to hear how they might phrase it.
Use of getYear, especially if combined with unreliable "century" code,
and more so if that code fails for dates after 1999.
Yup. I was waiting to hear something from you on dates. :)
Use of 24*60*60*1000 and vice versa, rather than 864e5 or 86400000; use
of that number in a manner which will fail across Summer Time changes,
or away from GMT.
Richard also expressed that such rough-shod dealing
with dates was bad form, but..
If I wanted to know the dividend of a share that matures
Feb. 1st 2005, I would want it accurate to the cent.
OTOH, if one of my relatives had a page that reported their
kid was '108 days old' I would shrug and reply, "..whatever,
get back to me when it stops drooling".
I am not quite convinced that an ..approximate
date is unacceptable in a lot of the many (seemingly
quite trivial) situations in which it is used.
Perhaps my perception of most date scripts being used
for trivial ends is quite incorrect? How much of it
is going on behind the scenes that is not immediately
apparent to the web-surfer?
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
>>Keep in mind that it detects *probable* errors. A few of the things it flags are useful if used carefully
and the intention is well documented. I don't think it
would flag anything in any of my production code, but I
wouldn't trust it blindly to declare code to be "bad".
Could you provide some concrete examples Lee?
I would want to make note of, and provide some
examples of 'false positives'.
From time to time I get requests to have JSLINT ignore
beloved-but-faulty coding patterns. There is code that runs correctly
but fails JSLINT because it is sloppy in some way. All code is improved
by conforming to JSLINT. http://www.crockford.com/javascript/lint.html
Douglas Crockford said: Keep in mind that it detects *probable* errors.
A few of the things it flags are useful if used carefully
and the intention is well documented. I don't think it
would flag anything in any of my production code, but I
wouldn't trust it blindly to declare code to be "bad".
Could you provide some concrete examples Lee?
I would want to make note of, and provide some
examples of 'false positives'.
From time to time I get requests to have JSLINT ignore
beloved-but-faulty coding patterns. There is code that runs correctly
but fails JSLINT because it is sloppy in some way. All code is improved
by conforming to JSLINT.
There are few sloppy coding practices that are as dangerous
as taking well-tested code and modifying it to remove a "faulty"
coding pattern.
Even if we accept the statement that all code is improved by
conforming to your tool, that doesn't mean that code that doesn't
conform should be blindly and automatically labeled as "bad".
Many of the rules that JSLINT enforces are intended to prevent
confusion on the part of future readers. Proper documentation
is an alternative to conformity. The fact that your tool cannot
detect proper documentation should not rule it out.
I would not ban the comma operator in all cases. Unfortunately,
it would be difficult for your tool to detect only the cases
that are likely to be confusing. The following, while not best
practice, should not cause an entire script to be rejected as
bad code:
for(i=1,j=0;j<alpha.length;i++,j++)
Uppercase HTML tags are not a sign of bad code. Out of date,
perhaps, but not to be automatically flagged as a bad example.
Labels of which you disapprove are not necessarily a sign of
bad code. I've known people to use labels where most of us
would use comments, to flag special blocks of code.
The labels are not used in the code. It's a harmless quirk.
Using labels that match variable names should not automatically
be rejected. You need to actually look at the code and apply
judgment to decide if the usage is potentially dangerous.
There are probably more examples. These are just from my memory
of having read the description of JSLINT. The bottom line is
that LINT-like tools are very handy for the developer to use to
identify code that may be confusing, but the tool lacks judgment
to decide whether each case is actually dangerous code.
JRS: In article <iv********************@giganews.com>, dated Mon, 20
Sep 2004 23:26:21, seen in news:comp.lang.javascript, jmm-list-gn <jmm- li***********@sohnen-moe.com> posted : Dr John Stockton wrote:
Another one is spelling/grammar errors, at least in the case of those
who seem to be writing in there native language <G>.
Er. "There" should be "their".
Yes. The <G> was to show that I did it on purpose, having noted that
the previous poster had done it (for reasons unknown) in the first
paragraph that I had quoted. PKUATBT.
--
© 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.
JRS: In article <ci*******************@news.demon.co.uk>, dated Tue, 21
Sep 2004 01:36:50, seen in news:comp.lang.javascript, Richard Cornford
<Ri*****@litotes.demon.co.uk> posted : Getting back to the subject of this thread.
eval(' ... '); - so exceptionally valid that
it can be stated as bad.
Disagree :
(a) in objecting, ISTM unreasonable to object to a string literal but
not to a string expression.
(b) where eval() is used validly, ISTM fairly likely that at least some
other parts of the page will be either better than average or rare valid
examples.
Suggest eval(...) usually, but not always, bad
href="javascript:somefunction()" - wouldn't appear in HTML written
by the informed/experienced, so
can be stated as bad.
Has it *no* proper use?
Failing to degrade to a viable
web page (for any reason including
the absence of script support) - easily objectively tested and
certainly bad.
Counter-example - my page holidays.htm. Originally, I wrote it in pure
HTML; but that expanded and needed annual tiresome updating, which I
decline to do. Other than its viable links, the page is of negligible
value without javascript. Of course, "viable" is subjective; the
scriptless page is a valid page.
If Notes-length, the document might, in regard to assumptions, observe
that a document *designed* for a limited audience may nevertheless be
visible more widely; it should not be over-criticised for not being
entirely successful for the widest audience. Consider, perhaps, a page
expertly written by the RNIB for a non-sighted audience (I know the RNID
[D!=B] has an expert); it might not work well in MSIE<latest>.
Note also that code copied, for example from a FAQ, is not a good guide
to the quality of original code on the same page; and vice versa.
Note that the conditions which should apply to the design of
"commercial" sites, especially those used to implement some sort of
purchase agreement, do not necessarily apply equally to other types of
site, such as academic, technical, or vanity sites.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
On Tue, 21 Sep 2004 12:00:53 +0100, Dr John Stockton wrote: JRS: In article <iv********************@giganews.com>, dated Mon, 20
Sep 2004 23:26:21, seen in news:comp.lang.javascript, jmm-list-gn <jmm-
li***********@sohnen-moe.com> posted :Dr John Stockton wrote:
Another one is spelling/grammar errors, at least in the case of those
who seem to be writing in there native language <G>.
Er. "There" should be "their".
Yes. The <G> was to show that I did it on purpose, having noted that
the previous poster had done it (for reasons unknown) ..in the first
paragraph
* Aha! I could not quite figure what you meant either,
but I decided long ago that language is for communication,
and that I would stress over my use of it, only if the person
to whom I was communicating did not understand me.
..that I had quoted. PKUATBT.
I *prefer* hanging at the back, the atmosphere is more relaxed,
and it means you usually miss the rain of poison-darts from
the natives during ambushes.
So their! :-P
--
Andrew Thompson http://www.PhySci.org/codes/ Web & IT Help http://www.PhySci.org/ Open-source software suite http://www.1point1C.org/ Science & Technology http://www.lensescapes.com/ Images that escape the mundane
In article <1x******************************@40tude.net>, Andrew
Thompson <Se********@www.invalid> writes
<snip> Whereas '==true' contrasts to the 'solid script doing stupid things'
by being the (slightly) inept way of doing things which may be
quite sensible.
I would tend to consider it an indication the author's knowledge
could not be trusted. I think I'll count votes on this one in the end..
<snip>
Some good programmers in other languages think that the '== true' style
makes things clearer and easier to proof-read.
So, on its own it says nothing about the code but if there are other
horrors then it adds to the horror.
John
--
John Harris
In article <1n*****************************@40tude.net>, Andrew Thompson
<Se********@www.invalid> writes On Mon, 20 Sep 2004 16:49:54 +0100, Dr John Stockton wrote:
<snip> Use of 24*60*60*1000 and vice versa, rather than 864e5 or 86400000;
There's a well known rule that you must never, ever, ask the user to
calculate something the computer can calculate. This also applies to
programmers. 24*60*60*1000 is easy to understand, easy to proof-read,
and unlikely to be mis-calculated. In addition it will sometimes provoke
the programmer into remembering that some days aren't 24 hours long and
that some minutes aren't 60 seconds long, which is good.
What is bad is when 24*60*60*1000 appears more than once in the same js
or html file.
<snip>I am not quite convinced that an ..approximate
date is unacceptable in a lot of the many (seemingly
quite trivial) situations in which it is used.
<snip>
What is bad for people picking up the code is where there is no comment
saying it's an approximation. Unfortunately, a beginner is unlikely to
know how to check this :-(
John
--
John Harris
JRS: In article <1n*****************************@40tude.net>, dated
Tue, 21 Sep 2004 11:12:22, seen in news:comp.lang.javascript, Andrew
Thompson <Se********@www.invalid> posted : Use of 24*60*60*1000 and vice versa, rather than 864e5 or 86400000; use
of that number in a manner which will fail across Summer Time changes,
or away from GMT.
Richard also expressed that such rough-shod dealing
with dates was bad form, but..
If I wanted to know the dividend of a share that matures
Feb. 1st 2005, I would want it accurate to the cent.
If preparing data in advance for checking up on your accounts, yes. If
deciding whether the dividend would allow you to buy a new piece of
furniture, probably not.
OTOH, if one of my relatives had a page that reported their
kid was '108 days old' I would shrug and reply, "..whatever,
get back to me when it stops drooling".
I am not quite convinced that an ..approximate
date is unacceptable in a lot of the many (seemingly
quite trivial) situations in which it is used.
Error in a calculation in which correctness is not difficult is not of
itself unreasonable; but it casts a shadow over the estimated quality of
the rest of the code. A rough calculation accompanied by
"approximately", visible on the page or in comment, is probably a *good*
sign, unless the exact calculation is really easy.
Perhaps my perception of most date scripts being used
for trivial ends is quite incorrect? How much of it
is going on behind the scenes that is not immediately
apparent to the web-surfer?
Who knows? But if something for trivial ends is worth doing, it is
worth doing right, where that is not difficult.
Code which is being presented for others to copy should be exactly
right, since the author does not know what it may be used for. For age
in days (of one born at 00:00:00) :
alert(Math.floor((new Date() - new Date("2004/01/09"))/864e5) +
" days")
is bad; but
alert(Math.floor((new Date() - new Date("2004/01/09"))/864e5) +
" days, approximately")
is good.
alert(Math.floor((new Date() - new Date("09/01/2004"))/864e5) +
" days")
is very bad indeed, though worse is possible.
***
There is an ambiguity in the initial article of the thread, which
suggests that : most people get their JS off web sites, which is
entirely logical.
Aside : I deprecate that abbreviation, but point
out that for myself I *always* use "JRS"
(unless J or S alone serves in context).
Does "web sites" mean web sites in general, or web sites that claim in
some way to be FAQs or tutorials? Are we referring to copying code that
is offered in order that it may be copied, or code that is present
merely to be executed?
Some FAQ sites are basically reliable; others are mere copies of all the
code that the owner can get (a fairly well-known site has without
permission copied some of my code, and done so badly). Some non-FAQ
sites are reliable (W3's, I guess, for example); others are not (HMGs',
I guess).
FAQ sites should be of moderately consistent quality; less so for
"collect anything" and multi-author ones.
But sites intended only to be executed may be of very varying quality; a
page may contain code copied from our FAQ itself, some from a bad
"compendium" site, and some written by the page author. Therefore, the
quality of one part of a page or site may be a poor guide to the quality
of other parts.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3 Turnpike 4 ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
>>From time to time I get requests to have JSLINT ignore beloved-but-faulty coding patterns. There is code that runs correctly
but fails JSLINT because it is sloppy in some way. All code is improved
by conforming to JSLINT.
There are few sloppy coding practices that are as dangerous
as taking well-tested code and modifying it to remove a "faulty"
coding pattern.
Bad code is not made good by ignoring its defects. "It seems to work" is
way too low a standard, especially in a runtime environment as variable
and deficient as web browsers.
Even if we accept the statement that all code is improved by
conforming to your tool, that doesn't mean that code that doesn't
conform should be blindly and automatically labeled as "bad".
Code which can be improved is sub-good. Can we agree on that?
Many of the rules that JSLINT enforces are intended to prevent
confusion on the part of future readers. Proper documentation
is an alternative to conformity. The fact that your tool cannot
detect proper documentation should not rule it out.
Bad code is not made good by commenting.
I would not ban the comma operator in all cases. Unfortunately,
it would be difficult for your tool to detect only the cases
that are likely to be confusing. The following, while not best
practice, should not cause an entire script to be rejected as
bad code:
for(i=1,j=0;j<alpha.length;i++,j++)
Uppercase HTML tags are not a sign of bad code. Out of date,
perhaps, but not to be automatically flagged as a bad example.
JSLINT has an option to ignore HTML case.
Labels of which you disapprove are not necessarily a sign of
bad code. I've known people to use labels where most of us
would use comments, to flag special blocks of code.
The labels are not used in the code. It's a harmless quirk.
Using labels that match variable names should not automatically
be rejected. You need to actually look at the code and apply
judgment to decide if the usage is potentially dangerous.
These are reckless practices that are never seen in good code.
There are probably more examples. These are just from my memory
of having read the description of JSLINT. The bottom line is
that LINT-like tools are very handy for the developer to use to
identify code that may be confusing, but the tool lacks judgment
to decide whether each case is actually dangerous code.
Code which is confusing is dangerous. http://www.crockford.com/javascript/lint.html This thread has been closed and replies have been disabled. Please start a new discussion. |
