W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > April to June 2002

Re: Functional Request for DOM

From: Jill Thomas <jill@ionsystems.com>
Date: Wed, 03 Apr 2002 14:04:00 -0600
Message-ID: <3CAB602F.5447CDA1@ionsystems.com>
To: "'w3c-wai-ua@w3.org'" <w3c-wai-ua@w3.org>
As discussed in the teleconference on March 28th I am enclosing a list of the
functional requirements ION Systems has using the DOM:

1. A guarantee that the DOM, once obtained, is valid. Using certain user agents,
a node may
actually be the child of two parents. This is the result of invalid HTML, but
from our perspective that makes no difference as it is impossible to work with
the invalid DOM.
If a DOM is invalid as a result of incorrect input, then we need a way to
discover the errors so that the user can be presented a warning. If this were
implemented, HTML authors might actually be informed that their sites were
invalid and might have some incentive to fix them.

2. A consistent method for determining DOM completion. It is possible, using
certain user
agents, to obtain a pointer to a DOM that is not complete. It would be nice if
we could reliably determine partial completion so that the entire DOM would not
have to be constructed before our software started.

3. Access to the text of the document via a consistent interface.

4. Access to the attributes, in order, of each element via a consistent
interface.

5. Access to the parent tags, in order, of each element via a consistent
interface.

6. A C++ binding. Java and Javascript are great, but they don't make the cut for
many performance critical or mass distributed applications. ION would be curious
to know how many realistic projects are under construction in each language.

As an aside here is what we don't need:
A tree structure. The fact that DOM is a tree might be a significant limitation
to its architecture. Users do not see the document as a tree, they see it as a
list. Having the DOM as a tree makes creation of a valid object from invalid
input more difficult  and also makes it harder to render. This may be an off the
wall suggestion, but included it anyway because our primary problem with DOM is
getting one that is broken, and we don't see the world of HTML suddenly changing
and presenting us with nothing but valid documents. A simpler design that was
correct more often would be better.


Pat Brannan and Jill Thomas


ION Systems, Inc.
jill@ionsystems.com
636-937-9094     Fax 636-937-1828
107 Mississippi Ave., Crystal City, MO 63019
                *****
www.ionsystems.com     Your Bridge To Usability
www.galaxylibrary.com  Where Electronic And Print Worlds Converge
                *****
eMonocle (tm) an XML viewer for simultaneous use by sighted, low vision and, in
the near future, blind readers.
Web Eyes (tm) a web plug-in facilitating compliance with Section 508 and
accessibility to any web page for low-vision users.
Received on Wednesday, 3 April 2002 15:03:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:51:07 GMT