Re: The DOM is not a model, it is a library!

----- Original Message -----
From: Kasper Peeters <K.Peeters@damtp.cam.ac.uk>
To: DOM Mailing List <www-dom@w3.org>
Sent: Thursday, October 07, 1999 12:00 PM
Subject: Re: The DOM is not a model, it is a library!


>
> Just my 0.02, but the DOM `standard' is IMHO of very little use if
> anyone can restrict it at will by using hasFeature(). If one wants a
> javascript program to run on all DOM implementations, and some of them
> have NodeLists while others don't, the program will have to work with
> NodeIterators anyway.

I agree that it would be best all around if everyone implemented every
interface and method in the spec.  This position is traditionally what the
DOM working group, and standards bodies in general, have strongly advocated.
For the domain of Web browsers running JavaScript applications, I
*completely* agree. But one main point that has come out in this thread
seems to be that WITHIN DIFFERENT DOMAINS of DOM implementers and users,
different sets of features are more and less relevant.  For example, if (for
the sake of argument) supporting live NodeLists doubled the size of typical
DOM implementations, for domains (like cell phone software) where the
footprint of the libary is critical, implementers would have good reasons to
not implement this feature, and users would get used to not having it.

I submit that the DOM can still be useful if anyone can use hasFeature() to
define a subset of features that they support that is presumed to be useful
FOR THEIR TARGET DOMAIN.  Now people define subsets more or less on their
own, with no mechanism for sub-communities to define common subsets of the
API or to query to see if the subset they need is supported.  I can
*imagine* that we could tweak Level 2 to allow this, assuming anyone thinks
its useful.

Mike Champion

Received on Thursday, 7 October 1999 12:56:14 UTC