473,883 Members | 1,601 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Top warning signs of bad code?

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_Spe culative_For_Di scussion_OK?'>
1 <SCRIPT LANGUAGE='JavaS cript'> // last millenium, or another reality?
2 if (navigator.user Agent.indexOf(" IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascrip t:somefunction( )"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write( "<p>Importa nt 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
Jul 23 '05 #1
109 5986
*Andrew Thompson* wrote in comp.lang.javas cript:
[snip]
<FAQENTRY class='more_Spe culative_For_Di scussion_OK?'>
1 <SCRIPT LANGUAGE='JavaS cript'> // last millenium, or another reality?
2 if (navigator.user Agent.indexOf(" IE")) // #FAQ4_26
3 eval(); // #FAQ4_40 (usually)
4 if (..==true) // !understanding boolean.
5 <a href="javascrip t:somefunction( )"> // #FAQ4_24
6 <NOSCRIPT> // If missing, the script does not degrade gracefully.
7 document.write( "<p>Importa nt 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.getEle mentById("myId" ).style.color = "#ff3333"; // Not
testing for methods and properties before using them
9. document.myForm Name.myTextInpu tName.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/
Jul 23 '05 #2
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
Jul 23 '05 #3
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_Spe culative_For_Di scussion_OK?'>
1 <SCRIPT LANGUAGE='JavaS cript'> // last millenium, or
another reality?
<SCRIPT LANGUAGE='JavaS cript1.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.user Agent.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="javascrip t: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>Importa nt content.."); // delivering
content.
Yes, but:-

if(featureX && document.write) {
document.write( '<input type="button" onclick="useFea tureX()">');
}

- 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.
Jul 23 '05 #4
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
Jul 23 '05 #5
On Mon, 20 Sep 2004 00:37:59 GMT, Andrew Urquhart wrote:
8. document.getEle mentById("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.myForm Name.myTextInpu tName.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
Jul 23 '05 #6
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
significant ly 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.javas cript FAQ - http://jibbering.com/faq
Jul 23 '05 #7
On Mon, 20 Sep 2004 02:27:15 +0100, Richard Cornford wrote:
Andrew Thompson wrote: ...
1 <SCRIPT LANGUAGE='JavaS cript'> // last millenium, or
another reality?


<SCRIPT LANGUAGE='JavaS cript1.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='javas cript'
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="javascrip t: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>Importa nt content.."); // delivering
content.


Yes, but:-

if(featureX && document.write) {
document.write( '<input type="button" onclick="useFea tureX()">');
}

- 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>Importa nt 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
Jul 23 '05 #8
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='JavaS cript'> // 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="javascrip t: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
Jul 23 '05 #9
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='JavaS cript'> // 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="javascrip t: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
Jul 23 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.