RFD: How To Recognize Bad Javascript Code

(Request for Discussion)

I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

I'm open for comments about it.

Have I missed the mark on a point or two?
Have I overlooked something?
Is my basic goal flawed? Is code bad in so many different ways that I
should just pack up shop and forget this?

Or did I do a smashing bang-up job that will keep the new coders away from
the horrors of most online examples and finally end c.l.j's favorite
hobby?(*)



(*) Saying "That's junk! Don't do that!"

On Tue, 01 Jan 2008 05:28:51 -0500, Jeremy J Starcher wrote:

(Request for Discussion)

I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

And it would really help if I included

<URL: http://www.mopedepot.com/jjs/HowToRe...criptCode.html >

On Jan 1, 6:37 pm, Jeremy J Starcher <r3... (AT) yahoo (DOT) spam.me.not.com>
wrote:

On Tue, 01 Jan 2008 05:28:51 -0500, Jeremy J Starcher wrote:
(Request for Discussion)

I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

For the language="javascript" issue you recommended:
<script type="text/javascript"></script>

Personally I'd recommend just using:
<script></script>

Partly because "text/javascript" is an invalid MIME type, it should be
"application/javascript". But "application/javascript" is invalid
HTML, it MUST be "text/javascript". So best to avoid it altogether and
save keystrokes/bytes.

slebetman wrote:

On Jan 1, 6:37 pm, Jeremy J Starcher <r3... (AT) yahoo (DOT) spam.me.not.com
wrote:
On Tue, 01 Jan 2008 05:28:51 -0500, Jeremy J Starcher wrote:
(Request for Discussion)
I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

For the language="javascript" issue you recommended:
script type="text/javascript"></script

Which is correct.

Personally I'd recommend just using:
script></script

So you would recommend invalid markup.

http://validator.w3.org/

Partly because "text/javascript" is an invalid MIME type,

It isn't.

it should be "application/javascript".

It shouldn't.

But "application/javascript" is invalid HTML,

It isn't.

it MUST be "text/javascript".

It needs not to.

So best to avoid it altogether and save keystrokes/bytes.

You are completely wrong:

http://pointedears.de/scripts/test/mime-types/

BTW, we discussed this only a few days ago. Please read before you post.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

slebetman wrote:
<snip>

For the language="javascript" issue you recommended:
script type="text/javascript"></script

Personally I'd recommend just using:
script></script

Which could never be valid (x)HTML mark-up as the TYPE attribute is
required by the pertinent validity rules.

Partly because "text/javascript" is an invalid MIME type,

It is not an "invalid" MIME type. It was a fictional MIME type up until
2006, and then it became an inappropriately labelled "obsolete" MIME
type (inappropriate because it does not make sense to declare something
as obsolete until it is practical to not use it).

it should be "application/javascript".

And it probably will be "application/javascript" at some point in the
relatively distant future when "text/javascript" actually becomes
obsolete.

But "application/javascript" is invalid HTML,

No it is not. The values for the TYPE attribute are externally
referenced from the (x)HTML specifications in a way that implies that
any current MIME type would be valid (and mark-up validators don't check
those external references anyway).

it MUST be "text/javascript".

There certainly is no "MUST" about it. The formulation
TYPE="text/javascript" is used because it is the valid mark-up that has
been observed to be universally successful (or non-problematic). The
odds are that that universal effectiveness results from
"text/javascript" being used as an example value in the HTML
specification, regardless of the fact that at the time there was no MIME
type for javascript.

So best to avoid it altogether and
save keystrokes/bytes.

So it comes down to an appeal to idleness? There may be valid reasons
for abandoning mark-up validity but idleness does not seem like
sufficient reason in itself. (Especially is it is actually being too
idle to write (or go out and find) a macro that will insert the entire
script tag as a result of one action, or use some other similar editor
facility.)

Richard.

On Tue, 01 Jan 2008 05:14:23 -0800, slebetman wrote:

Personally I'd recommend just using:
script></script

Partly because "text/javascript" is an invalid MIME type, it should be
"application/javascript". But "application/javascript" is invalid
HTML, it MUST be "text/javascript". So best to avoid it altogether and
save keystrokes/bytes.

I had forgotten about "application/javascript" I saw that discussion a
few days ago and made a mental note. Since my mental notes are written in
the sea-shore at low tide -- I forgot.

It is my understanding that this mime type is actually recognized by
anything in the world and has been rushed into service without a valid
reason for the rush.

We hang onto "text/javascript" because pretty much everything supports it
and it still works. Not only works, but works better than its proposed
replacement.

Jeremy J Starcher wrote:

I've put together a guide that I hope will help novice coders avoid the
same hair pulling that I went through.

I'm open for comments about it.

Have I missed the mark on a point or two?
Have I overlooked something?

Plenty.

1. "Depreciated script tag usage"

a. The word you were looking for is _deprecated_, not "depreciated".

b. The term you were looking for is `script' _element_, not "tag".
Elements consist of tags (start tag, close tag) and content:

http://www.w3.org/TR/REC-html40/intr...t.html#h-3.2.1

c. Your example `script' elements are empty where they should have
content. At least that should be indicated in some way.

d. "JavaScript1.2" actually means something in NN4; ask Google.
I have never seen anyone using "JavaScript1.3", though.

2. 'Using "href:javascript"'

Using the pseudo-protocol javascript in the href is never valid. Not
only is such code not valid HTML, [...]

Wrong. The value of the `href' attribute is of type URI. If
`javascript:' syntax would be written as an URI, it would certainly
be valid there. One point of recommending against `javascript:'
there is that

it cannot provide a fallback to browsers not running Javascript.

There are other points that I have also mentioned in my FAQ notes last
year. There are also exceptions to be made in special cases.

3. "Excessive use document.write"

should read "Excessive use *of* document.write()".

A recommendation for a viable alternative is missing. Consider this:

<script type="text/javascript">
if (NN4 || IE4)
{
document.write(
new Array(
'<ul>',
' <li><a href="Search.html">Search<\/a><\/li>',
' <li><a href="Order.html">Order<\/a><\/li>');
' <li><a href="Help.html">Help<\/a><\/li>');
'<\/ul>'
).join("")
);
}
</script>

4. 'Not ending lines in a semi-colon ";"'

The argument in favor of the trailing `;' is flawed in two regards:
a) not every line should be ended with a semicolon but every *statement*;
b) minifiers should not be used. See previous discussions.

5. "Use of eval"

Using eval to parse JSON works well. While there are some security
concerns, they can be easily addressed.

There are two other uses where using eval() is considered appropriate.
One is making arbitrary computations with user input, the other is
hiding code from script engines that consider it to be syntactically
invalid because they do not support the corresponding language feature.

A reasoning for the statement that the security concerns could be
easily addressed is missing.

6. "Browser sniffing"

You describe the goal of that -- "to tell which browser the code is
running on" to be "good", and I don't agree. Web developers should
avoid writing for a specific user agent.

7. "Web pages that do not include a DOCTYPE and/or do not validate"

Internet Explorer provides a way to identify itself that does not
interfer with other browsers. Some web developers use this to work
around bugs in IE's handling of style sheets or to import
compability code. Other web developers regard this is an evil crutch.

The argument against Conditional Comments is not sound, at least not
for IE-specific workarounds. CCs are valid SGML markup.

Is my basic goal flawed?

I don't think so. I think it would make a fine addition to the FAQ after
careful evaluation.

Is code bad in so many different ways

You can bet on that.

that I should just pack up shop and forget this?

No, it's a good start.

Or did I do a smashing bang-up job that will keep the new coders away from
the horrors of most online examples and finally end c.l.j's favorite
hobby?(*)

Hardly.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

On Tue, 01 Jan 2008 18:01:51 +0100, Thomas 'PointedEars' Lahn wrote:

Jeremy J Starcher wrote:
Have I missed the mark on a point or two?
Have I overlooked something?

Plenty.

1. "Depreciated script tag usage"

a. The word you were looking for is _deprecated_, not "depreciated".

Absolutely correct. Thought I spell-checked everything. I'll fix that.

b. The term you were looking for is `script' _element_, not "tag".
Elements consist of tags (start tag, close tag) and content:

http://www.w3.org/TR/REC-html40/intr...t.html#h-3.2.1

Once again correct. I've let myself get a bit sloppy in speech.

c. Your example `script' elements are empty where they should have
content. At least that should be indicated in some way.

Hadn't thought of that, but it makes sense.

d. "JavaScript1.2" actually means something in NN4; ask Google.
I have never seen anyone using "JavaScript1.3", though.

I didn't know if that was backwards compatible to browsers today or not.
If memory serves me correctly, it changes some of the array methods.

2. 'Using "href:javascript"'

| Using the pseudo-protocol javascript in the href is never valid. Not
| only is such code not valid HTML, [...]

Wrong. The value of the `href' attribute is of type URI. If
`javascript:' syntax would be written as an URI, it would certainly
be valid there. One point of recommending against `javascript:'
there is that

| it cannot provide a fallback to browsers not running Javascript.

There are other points that I have also mentioned in my FAQ notes last
year. There are also exceptions to be made in special cases.

Hmmm... This point has me thinking now. I'll have to ponder the best way
to phrase the URI issue. "Valid, but not recommended" perhaps.

I'll try and find your FAQ notes. If you are feeling generous I'll take a
donated URL to it.

3. "Excessive use document.write"

should read "Excessive use *of* document.write()".

Agreed, once again. Bad proofreading on my part again.

A recommendation for a viable alternative is missing. Consider this:

script type="text/javascript"
if (NN4 || IE4)
{
document.write(
new Array(
'<ul>',
' <li><a href="Search.html">Search<\/a><\/li>',
' <li><a href="Order.html">Order<\/a><\/li>');
' <li><a href="Help.html">Help<\/a><\/li>');
'<\/ul>'
).join("")
);
}
/script

I'll agree that is better than the table design, but I was trying to
indicate that using Javascript for putting a navigation bar on the screen
shouldn't be done. Augmenting one would be OK.

Perhaps a different example would be better. Using Javascript to show a
print button or something.

4. 'Not ending lines in a semi-colon ";"'

The argument in favor of the trailing `;' is flawed in two regards:
a) not every line should be ended with a semicolon but every *statement*;

I code in C. I know that. Somewhere it got lost between brain and
keyboard. Maybe I've been using "one statement per line" scripting
languages too much.

b) minifiers should not be used. See previous discussions.

I knew that was going to come up. I'm tempted to yank that whole section
out, except that style-wise I -really- like having the semicolon there.
Code without it grates on me.

5. "Use of eval"

| Using eval to parse JSON works well. While there are some security
| concerns, they can be easily addressed.

There are two other uses where using eval() is considered appropriate.
One is making arbitrary computations with user input,

Yes, I should mention that. While I've only seen it used for "trivial"
calculator applications, I suppose it would be the basis for an Javascript
spreadsheet or something.

the other is
hiding code from script engines that consider it to be syntactically
invalid because they do not support the corresponding language feature.

Oh.. there is an idea. That is the second new thought you've tossed into
my head here. I'm picturing one code branch that runs slowly with a dozen
checks to assert all values are within range and a second code branch
using try/catch. The try/catch is faster when available.

Is that the kind of thing you mean?

A reasoning for the statement that the security concerns could be
easily addressed is missing.

I'll toss in this link: <URL: http://www.json.org/json2.js > In my
reading, I haven't heard of anyone finding holes in it.

6. "Browser sniffing"

You describe the goal of that -- "to tell which browser the code is
running on" to be "good", and I don't agree. Web developers should
avoid writing for a specific user agent.

Poor wording on my part. No, its not good. Recognizing that all the
world is not IE and that differences exist *is* good.

7. "Web pages that do not include a DOCTYPE and/or do not validate"

| Internet Explorer provides a way to identify itself that does not
| interfer with other browsers. Some web developers use this to work
| around bugs in IE's handling of style sheets or to import
| compability code. Other web developers regard this is an evil crutch.

The argument against Conditional Comments is not sound, at least not
for IE-specific workarounds. CCs are valid SGML markup.

I agree. I worked very hard on my wording to remain as neutral as
possible, I'll have to find a way to phrase "Other web developers regard
this is an evil crutch -- but they are wrong" a little more gently.

PointedEars

Thank you for your advice. There are a handful of people whom I had hoped
would take time to respond because I recognize their knowledge and skill
greatly exceeded my own. You are one of them.

Not to say others aren't welcome to respond. Other beginners, no doubt,
have their own lessons we can learn from.

I'll try to update that page later on today, after I've had a chance to
think about some of the things mentioned so far.

In article <pan.2008.01.01.17.58.59.532824 (AT) yahoo (DOT) spam.me.not.com>, Jeremy J Starcher <r3jjs (AT) yahoo (DOT) spam.me.not.com> wrote:

On Tue, 01 Jan 2008 18:01:51 +0100, Thomas 'PointedEars' Lahn wrote:

Jeremy J Starcher wrote:
Have I missed the mark on a point or two?
Have I overlooked something?

Plenty.

1. "Depreciated script tag usage"

a. The word you were looking for is _deprecated_, not "depreciated".

Absolutely correct. Thought I spell-checked everything. I'll fix that.

"Depreciated" *is* correctly spelled. It's just not the right word. :-)

--
Regards,
Doug Miller (alphageek at milmac dot com)

It's time to throw all their damned tea in the harbor again.

Thomas 'PointedEars' Lahn posted :

[snip]

1. "Depreciated script tag usage"

a. The word you were looking for is _deprecated_, not "depreciated".

Well, if we're being anal, Thomas, "_deprecated_" is not a word.
"deprecated" is, though.

b. The term you were looking for is `script' _element_, not "tag".
Elements consist of tags (start tag, close tag) and content:

http://www.w3.org/TR/REC-html40/intr...t.html#h-3.2.1

Funny thing is, I looked that page up and down buddy, and I didn't see
anything about a script _element_ anywhere. Maybe your underscore is broken.

c. Your example `script' elements are empty where they should have
content. At least that should be indicated in some way.

Pretty sure that's already been under discussion regarding the type
attribute. Please read before you post, as you like to say.

One point of recommending against `javascript:'
there is that

| it cannot provide a fallback to browsers not running Javascript.

There are other points that I have also mentioned in my FAQ notes last
year. There are also exceptions to be made in special cases.

You know what would be even more helpful? A link or even a hint about
where your big ole FAQ is for those of us not arrogant enough to read
your mind.

3. "Excessive use document.write"

should read "Excessive use *of* document.write()".

Are you a programmer or an English teacher? Oh, you're both! That would
explain a whole bunch.

A recommendation for a viable alternative is missing.

Like the link to your FAQ, Mr. Kettle?


[snip]

Or did I do a smashing bang-up job that will keep the new coders away from
the horrors of most online examples and finally end c.l.j's favorite
hobby?(*)

Hardly.

This, right here, this is why people get irritated with you, I think.
Maybe you just like being a pompous arrogant , I dunno, but most other
people don't care for it. You lack that internal filter that says "don't
say that, that's what a pontificating, unmitigated ass would say"

~A!