- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Sun, 8 Jul 2001 16:35:10 +0100 (BST)
- To: w3c-wai-ig@w3.org
> 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