RE: Handling Javascript [was Re: New(ish) Test Version Of Betsie

Um... yeah. Javascript is a problem.

The main reasons I made the decision to have Betsie remove all Javascript
are approximately as follows:

Betsie messes around in a very serious way with the HTML in the page. When
Javascript in a page is making assumptions about what else is going to be
there in the page (especially images, and especially image roll-overs), it
fails badly, and an awful lot of Javascript makes precisely those kinds of
assumptions. I haven't managed to work out how to distinguish between such
Javascript and other Javascript that makes no such assumptions and would
therefore work fine in theory under Betsie. Building a Javascript
interpreter into Betsie seems fairly pointless until it is possible to make
that distinction reliably, at which point it may prove to be easier to
simply rely on the user's browser's Javascript interpreter.

Also, in practice, and certainly on the test suite of however many squillion
pages I have tested Betsie on, both on the BBC site and elsewhere, I have
found the general standard of 'found' Javascript to be no higher than the
general standard of 'found' HTML - it's hard enough to find and fix
syntactically correct Javascript after the Betsie HTML mangling, but when
people make mistakes in it anyway it becomes almost impossible - certainly
in a Perl CGI that is already quite large due to the amount of mucking
around with HTML it does. Maybe a CGI written in C/C++ could encapsulate
enough oomph to do the job, but this only introduces other problems
associated with the much smaller pool of people who are going to be happy
with installing such CGI scripts, to say nothing of the sheer magnitude of
the task when you consider how many mutually incompatible versions of
Javascript are out there.

Meanwhile, removing all Javascript solves the problem of Javascript-related
error messages. I did try and retain some Javascript, but all that ended up
happening was that I retained the ablility to ensure a flurry of Javascript
errors on almost every page that contained undeleted Javascript. So, bye bye
Javascript, until we can distinguish between Javascript worth keeping and
Javascript that needs throwing out. Any ideas?

In any case, while there is a problem with pages that rely on Javascript for
key functionality, I don't think it's Betsie's problem, or, indeed, an
appropriate problem for a repair tool. After all, the WAI content guidelines
state quite clearly in point 6.3: "Ensure that pages are usable when
scripts, applets, or other programmatic objects are turned off or not
supported. If this is not possible, provide equivalent information on an
alternative accessible page. [Priority 1]." So relying on Javascript being
present for anything is an accessibility error up there with omitting ALT
attributes in an image. Hence, although Len writes...

> This [checking form data with Javascript] is a reasonable thing to do, to
check data on in the 
> browser before
> sending it to the cgi script.  I've seen this before and my 
> guess is that
> it's a common idiom.

... I'm afraid I don't agree that checking form data with Javascript *is* a
reasonable thing to do. Javascript may be turned off, or may simply not be
present, and then that checking - if it is indeed important - will have to
be done again in the CGI. If it's already being done in the CGI, it doesn't
need to be done in the form. If it doesn't really need to be done at all -
if it doesn't matter whether or not it's being done - why do it at all?

I would point out that 'click here' is also a common idiom.

Cheers etc.,

Wayne

Wayne Myers
Interactive Software Engineer
BBC Digital Media
http://www.bbc.co.uk/education/
0181-752-6116

Received on Wednesday, 2 June 1999 12:50:19 UTC