- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Wed, 14 Apr 2004 18:27:56 +0200
- To: www-dom@w3.org
Dear DOM IG, I am writing to you on behalf both of the SVG WG and the JSR-226 Experts Group. As you may know, both our groups are working on a subset of the DOM that would be suitable for implementation on devices supporting SVG Tiny (1.1 and 1.2). The relevant documents can be found at: http://www.w3.org/TR/SVG12/svgudom.html http://jcp.org/aboutJava/communityprocess/review/jsr226/index.html One of the things we believe users must be able to do is to navigate from an element into its children, as would appear natural. However, we have a very strong constraint of minimising the number of interfaces, and of only exposing the strict minimum functionality that needs to be. As such, the only way of accessing textual content is through textContent() -- there are no Text nodes, no more in fact than there are CDATASection, ProcessingInstruction, Attr, etc nodes. We have Node, Document, and Element. We also have a strong constraint that content that works in SVG Tiny must work in SVG Full, which uses the complete DOM. Given the context, the following problem appears: on a Tiny device using childNodes, hasChildNodes(), firstChild, lastChild, previousSibling, and nextSibling will always contain Elements, and elements only. However, the same program running inside a Full implementation will see many more nodes of different types, and given the fact that it can safely expect to only see Elements in Tiny it will very likely blow up badly in Full. There are only three clean ways out of this quandary: - give up entirely on providing access to children. This was seriously considered for a while, but it renders the API far less powerful, to say the least; - insert objects of type Node with no information available on them where non-Element nodes would appear. Not only is the presence of these objects totally useless from the point of view of API users, it also incurs a performance hit that we consider to be intolerable; - add a few fields to the Element interface that provide access to Element children and siblings alone. That is the path we have chosen. The additions to the interface are as follows: interface Element { ... readonly attribute Element firstElementChild; readonly attribute Element lastElementChild; readonly attribute Element nextElementSibling; readonly attribute Element previousElementSibling; ... }; firstElementChild of type Element, readonly The first element child of this element. If there is no such element, this returns null. lastElementChild of type Element, readonly The last element child of this element. If there is no such element, this returns null. nextElementSibling of type Element, readonly The element immediately following this element. If there is no such element, this returns null. previousElementSibling of type Element, readonly The element immediately preceding this element. If there is no such element, this returns null. These are the parts that the mobile subset would use, the full set would also add childElements and hasChildElements() for consistency (perhaps requiring an ElementList interface as well). By a chance side-effect, this addition also eliminates the infamous problem of users trying to access the first element child of an element using firstChild and getting a Text node of white space instead of what they expected. I hear you saying "but why are you changing the DOM Core Element interface when you have your own SVGElement interface with which you can fudge to your heart's content without bothering us?" Well, quite simply because SVG is intended to be a multinamespace environment, and these fields would have to be present not only on SVG elements, but also on elements from foreign namespaces present in the same document. Now, we well understand that there is a problem: the DOM WG turned into a pumpkin and DOM 3 Core went to Rec last week (many kudos by the way, it is an excellent spec). Yes, both the SVG WG and the JSR-226 EG are currently flagellating themselves for not having thought of this previously, but that does nothing to fix the problem: it's very probably impossible to change DOM 3 Core now, or to hope for a DOM 3.1 Core, yet those fields need be on Element, or very close to it. So here is what we propose: the SVG WG would take under its responsibility to create a new Chapter in the DOM 3 spec-suite. That chapter would be called "DOM 3 Element Navigation" (or something similar) and would be available through the "ElementNavigation" feature. Language-neutral DOMs would be able to get at it through the normal feature/casting mechanism, and SVG implementations of the DOM would mandate that all instances of Element support it "natively" (ie with no form of casting). Since the JSR is on a very tight schedule for the end of April, we would appreciate comments you may have on this approach. Thank you very much in advance, -- Robin Berjon
Received on Wednesday, 14 April 2004 12:28:30 UTC