- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Mon, 20 Jan 2003 09:07:56 +0000 (GMT)
- 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 about; - 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