W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2003

Re: to js or not to js?

From: David Woolley <david@djwhome.demon.co.uk>
Date: Mon, 20 Jan 2003 09:07:56 +0000 (GMT)
Message-Id: <200301200907.h0K97u905157@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org

> I don't think developers should take the blame if you get a lot of js errors 
> because you either use a browser that doesn't fully support javascript or you 
> start limiting the support.

Firstly, Javascript is not a very well defined term.  As used popularly
it tends to include:

- the ECMAScript scripting language and some core classes for things
  like string handling - note that this can easily be substituted with,
  say, VBScript, albeit that that is only supported by one browser
  family, and cannot be called Javascript then, even though it shares
  all of the rest of the following, which is what we are really talking

- a document object model, which can be subdivided into:

  * parts defined by W3C (DOM1 and DOM2);

  * parts only standardised by common support in browsers (DOM0);

  * parts proprietory to particular browsers;

- a browser object model (covering automation features of the browser);

- operating system object model features, typically accessed by browser
  object model features.

Of these, you can only really rely on DOM0 being present, although it is
unclear as to where the boundary between DOM0 and the browser's proprietory
model lies.  Browser models, although heavily used in commercial web design,
are not subject to any official standards.  Modern browsers (IE5 and NS6)
implement the W3C DOMs, but authors still author for IE using proprietory
features that can be simulated using DOM1 and DOM2, and may even do that
for IE and use the official ones for NS6+!

That covers apparent omissions that are really the result of a lack of
clear understanding as to what the popular use of the term "Javascript"
really means.  (Most questions asked about Javascript are really about
browser object models, and sometimes document object models, which are
language independent.)

The reasons for deliberately disabling features are basically:

- abuse of those features to try and wrench control from the user -
  popups are the most obvious ones here, and most of the examples here
  where basically variations on anti-popup measures;

- security and privacy.

Authors have only themselves to blame if people start taking counter-
measures to their design excesses.  They ought to respect people's
security concerns.

Although I'm not sure whether this tactic works for selectively disabled
object model features, the best way of checking for support is not to
sniff the browser type, but to use code that probes for the actual features,
you want to use.  One way relies on the fact that the various methods
are associated with objects and you write code that asks the type of
any name subordinate to an object.
Received on Monday, 20 January 2003 06:20:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:13 UTC