Anti-Javascript FAQ
This FAQ explains to web site developers why you should stop requiring
JavaScript (also known as ECMAscript and JScript) on your web pages. It
also gives you a number of techniques to get the same effects without
JavaScript. Note that while I am personally opposed to all use of
JavaScript, I understand that JavaScript can do some things that you
can't do with normal HTML. The techniques presented here for removing
JavaScript do allow JavaScript to be used, they just make sure that your
site is accessible to browsers that do not implement JavaScript or have
JavaScript turned off.
Remember, the more accessible your site is, the more potential customers
you have. If Amazon.com can do it, so can you.
This FAQ contains three sections:
If you have any questions that are not answered by this FAQ, or if you
have any comments, please send e-mail to
aahz@pobox.com
Last update: 20 May, 2004
- JavaScript is a security risk
Most of the truly glaring security holes have been fixed, but it still
requires vigilance on the part of site maintainers. If you require
JavaScript and your site gets cracked, your users will blame you.
Rather than re-hashing lots of arguments on this subject, here are some
links that provide this information:
- Javascript is not universal
For starters, JavaScript works differently in browsers that do support
JavaScript: Netscape 3.0 is different enough from Internet Explorer 5.0
that only the simplest JavaScript will work on both. Then you've got
all the new "internet appliances" that don't support JavaScript, web
phones that don't support JavaScript (such as the T-Mobile Sidekick),
and text-only browsers such as Lynx that don't support JavaScript (lots
of blind people use Lynx -- in fact, some people have threatened to sue
sites for non-compliance with the Americans with Disabilities Act (ADA)).
For another take on this issue, see
"This page optimized
for ..." - arguing with customers. It's not about JavaScript in
specific, but about the perils of requiring any form of browser-specific
extensions.
- JavaScript form-validation duplicates coding effort
If you write client-side data-validation code in JavaScript, you'll
still need to write that code on your web server. Otherwise, you're
vulnerable to any hacker or script-kiddie who reverse-engineers your
JavaScript code (remember, the JavaScript is available in plain-text
source on each of your web pages). I personally have many times
reconstructed the output of a piece of JavaScript code to get at a
needed area on a web server. Once you start duplicating your code, you
then have a problem synchronizing the code between what you've got in
JavaScript and what you've got on the web server.
(Some people have told me that they write code in an intermediate
language that generates both client-side and server-side code. It's not
clear to me how reliable that is if a specific browser is not required.)
- What about cookies?
Many of the same general arguments about JavaScript apply to cookies, as
well. Because cookies are pure data and not code they're overall less
likely to cause problems, with one exception: because cookies can be
persistent, if you use them for storing login name and password, you
present a security risk because most people use machines that have no
security (Win95/98 and Macintosh). (Even with OSes that provide
security, such as WinXP and OS X, it's likely that few people will
follow good security practices.) From the developer side, the big
problem with using cookies is that many people use multiple browsers on
multiple machines; if you're going to solve that problem, you might as
well skip cookies in the first place.
Non-persistent session cookies can work fairly well, and most newer
browsers can distinguish between persistent and session cookies.
However, people sticking with older browsers are more likely to just
reject all cookies (and there are good reasons for sticking with older
browsers -- many people prefer the cleaner interface of Netscape 3, for
example). There's also the issue of cross-site cookies (particularly
ads) violating privacy; again, newer browsers provide methods for
dealing with this, but it's still usually easier to completely turn off
cookies.
Cookies are probably the lesser evil for maintaining session IDs at
least. Putting session IDs in the URL can be made secure, but it's
somewhat more cumbersome, and it looks ugly. In the end, though, with
the misuse of cookies to date, many people will still reject them.
For starters, it's a lot easier if you thoroughly familiarize yourself
with the standard HTML tags. My favorite reference is the
Bare Bones Guide
to HTML, which is available at
http://www.werbach.com/barebones/index.html.
- Don't use
javascript: URLs
Using a straight http: URL will allow any browser to access
the link. If you want to use JavaScript for browsers that have
JavaScript enabled, use the onMouseOver and
onClick attributes of the
<a href> tag.
- Forms
Many people code HTML forms that almost work without JavaScript, but
fail because they don't include an HTML submit button:
<input type="submit">
- How do I create popup windows?
Use the target="_blank" attribute of the
<a href> tag.
Overall, though, I recommend against using target; if
someone is not using JavaScript, zie probably will not want popup
windows.
- How do I perform redirects?
Don't use window.location;
instead, use an HTTP redirect or
<meta http-equiv="Refresh">
Here's a simple example that demonstrates how one can still use
JavaScript while making the site accessible to people with JavaScript
turned off:
- wrong:
<a href="javascript:window.open(blah)">
- right:
<a href="foo.html" target="_blank" onClick="window.open(blah);
return false">
These are mostly sites that I have personally used to purchase products
(some of which are local to the San Francisco Bay Area);
sites that are suggested by other people are marked with "??". Sites
that I particularly like are marked with "!". Some of these sites have
some (or many) links that use JavaScript, but the basic site functions
can all be accessed with
Lynx, a text-only browser that
does not support JavaScript. Some of these sites also work with cookies
disabled.
Some sites don't work with Lynx but do work with a couple of other
text-only browsers:
Links (can be compiled with
crude JavaScript support) and
w3m.
Some of these sites have been notorious for poor privacy policies in the
past, but I'm not addressing that issue here.
Copyright 2001, 2002, 2003, 2004, 2006 by Aahz
(aahz@pobox.com)
Comments welcome
Several people have contributed information and comments, but Jon Ribbens
(jon(at)unequivocal(dot)co(dot)uk) deserves special mention.
Return to Aahz's home page