Re: Javascript is Access Cryptonite.

> 	I am a UNIX user both in my job and at home and
> discovered that I could not use a certain web site at all because
> javascript is used to drive the navigation of the site.  This

This is true for the vast majority (or so it seems) of UK commercial
web sites.  It's also the subject of a current thread on the lynx-dev
mailing list.

> means that any browser that accesses the site must use scripting
> to do even the simplest selection of links and downloading of
> pages.

I think it might be interesting to analyse why sites use scripting.  Reasons
include:

- to implement features that would take time to be standardised and included
  in enough browsers in the field (by allowing one to program the
  browser directly, one can get away with poorly defined semantics,
  amongst other things);

- overriding policy decisions in HTML that contradict with commercial design
  wants (e.g. your Javascript links often popup a window, and often with
  various standard browser buttons disabled, wherease popups are considered
  a bad accessibility feature and disabling buttons shifts control from the
  user to the author).  Other areas were policy might go against wants is
  in bandwidth conservation.

- they want to be different (but being marketing types, they all end up by
  being different in the same way as everyone else is being different - with
  most even blindly copying code without understanding it!);

- client side browser identification (unfortunately the identification
  is usually to select the right scripts, not to handle non-script 
  features) and to allow presentational aspects (e.g. screen size) to
  be "optimised".

I have a feeling that I could write a whole essay on this topic if I had the
time.  However, I suspect there is no way of avoiding scripting without 
giving up any pretence that HTML is more than a language for making IE
display advertisements.
 
> 	Lynx and all its text-oriented relatives do not use
> scripting because the scripting languages are closely tied to
> either Netscape Navigator or Internet Explorer.  If one was going

To some extent IE, and to a large extent NS6, have taken their structure
from the W3C DOM, but the fact remains that scripting creates a barrier
to entry (a desirable characteristic from the point of view of commercial
browser developers) because of the complexity required in a minimal 
browser implementation.

As I've also pointed out in the past, scripting is at the core of most
browser security exploits and the idea of allowing third parties to run
anything so close to a general programming language on your machines ought
to send shivers down the spines of anyone really concerned about computer
security.  (My ISP, one of the ealiest, and one of the largest individual
and small business ISPs in the UK, advises anyone concerned about security
to disable scripting, on their web site.)

> to try to add scripting to lynx or another open-source browser,
> the question would be, "Whose scripting do we go with?" There are

NS6 has decided to go with W3C's object model, but still implement
DOM0 features, i.e. early IE and NS4 object model features, together
with some browser object model features from IE and NS4 (W3C only
standardise document object models, whereas a lot of the popup link
stuff is using browser object models).  Failing to implement some
NS4 proprietory features, whilst identifying itself as Netscape has
caused some sites not to support it.

> both technical issues and, even worse, proprietary issues which

I don't think there are many intellectual property rights problems,
but there is the problem that most proprietory object models are 
not very tightly specified and are likely to do things in the way that
was easiest to implement, not the simplest way of meeting the 
objective.

> hold back what might seem like the obvious solution which would
> be to build a javascript engine and fix this problem.

Most problems are not to do with Javascript, but to do with the
object model.  The object model tends to be fundamental to the the
design of the browser, so a "Javascript" engine would actually be
most of the browser.

> 	We've got two major problems.  We need to find some way
> to have a commodity browser that can work with the javascript

Javascript was invented by people who had no commercial interest
in their being commodity browsers.

> period.  It should technically be possible for modern servers to
> gracefully degrade or modify their output for any browser which has
> scripting turned off or no scripting capability such as lynx and

It's largely possible to make pages that degrade gracefully without
alternative versions, and that is much more desirable from a network
bandwidth point of view.  The problem, in both cases, is that authors need
to make scripting alternatives a high priority.  What normally happens
is marketing say I'd like it to work this way and development look at
the problem, see it can be solved with scripting, but don't explain the
problems that result, as they are not problems that their brief requires
them to solve, so it would be commercially inefficient to do so.

(A look at the contents, or lack thereof, of no-frames sections in web
pages will give you a good idea of how little effort people are prepared
to spend on alternatives - useable no-frames sections are very cheap to
produce, if you have the will - a small amount of explanation and a 
link to the navigation pane - this is not the ideal way but it is
usable.)

> several other browsers.  It should be a piece of cake for modern
> servers to modify their output on the fly if they receive the
> right identification string from a no-script client.

Pages customised for Lynx but emasculated as a result are another
issue that Lynx people object to.  The easy solution tends to be to
class any minority browser as an almost ran and produce a token, lowest
common denominator, solution, and then fail to maintain (cue Kynn on
dynamic versions from a common source - but I don't think that is a
solution without a large will to maintain such versions).

Received on Sunday, 8 July 2001 11:38:37 UTC