- From: Jonas Sicking <sicking@bigfoot.com>
- Date: Fri, 9 Nov 2001 16:05:12 +0100
- To: <www-dom@w3.org>
Jesse McCarthy wrote: > Neil Laurance <neil_laurance@yahoo.co.uk> wrote on 11/9/01 6:39:04 AM: > >Jesse, > >I think you can rely on Navigator and Explorer to follow DOM, since they are > >both involved in its conception. A bit of example code should illustrate how to > >use the DOM API in NS, and IE: > > > >var myDocument = window.document; // Document object > > >I hope this explains how to use DOM. Apologies for any bugs or bad practices ;) > > > >Cheers, Neil > > The problem with that, Neil, is that, as a couple of individuals have been good > enough to explain to me, there is nothing in the DOM specification that > indicates what the name of the object representing the 'Document' object will > be -- it could be anything. So, as I understand it, Netscape and Microsoft can > both release browsers that are 100% DOM compliant but _do not_ provide access > to the 'Document' object with the same object name. There is no guarantee that > the 'Document' object will be exposed as 'window.document'. E.g. Netscape > could release a browser that exposes the 'Document' object as 'document' and > Microsoft could expose the same object as 'Microsoft'. If my understanding of > the situation is correct, then you can see the dilemma. The problem isn't that trivial. The DOM standard simply can't specify a "name for the 'Document' object" for several reasons. First of all there can be more then one Document object and you obviously can't call them all 'document'. Second, should all languages that want to support DOM have to implement a global object called 'document', I certainly don't want any new global objects in my C++ code? Third, what would "document" be in an environment outside a browser, for example in my server-component doing XSLT transformations? I could go on, but I think you see the problem. The answer to your problem is that it's not the *DOM* standards job to specify how to get hold of your initial Document object, but some *other* standards job. For example the JavaScript "standard" (I'm not going into a discussion if JavaScript is a standard or not or what a standard is or why Microsoft is or isn't the evil empire) could specify that there is a global EcmaScript object of class Document called "document" that represents the Document object currently show in the browser window. Or better yet, a BrowserEnvironment standard could specify that there is a global object called "document" that represents a Document object in whatever language is used, and the DOM bindings for that language defines how to use that object. However this is outside the scope of the DOM standard. A BrowserEnvironment standard should perhaps not be outside the scope of the W3C, and actually something that I would think is a very good idea. But again, it's outside the DOM standard and therefore outside the scope of this mailing-list Thanks for your attention. / Jonas Sicking
Received on Friday, 9 November 2001 10:00:33 UTC