- From: Johnny Stenback <jst@w3c.jstenback.com>
- Date: Wed, 14 Apr 2004 10:53:03 -0700
- To: Robin Berjon <robin.berjon@expway.fr>
- Cc: www-dom@w3.org
Why not simply make this new "tiny" API provide a specialized implementation of a TreeWalker (http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/traversal.html#TreeWalker) that will work consistently regardless of whether the underlying DOM contains text nodes or not. That way you wouldn't introduce new DOM attributes/methods that give you nothing that doesn't already exist, and in fact, what you're going for would be doable w/o any changes to the DOM, what so ever. I personally don't think that extending the already heavy weight core element classes with yet more attributes/methods is a good idea, when it seems like it's completely avoidable. Robin Berjon wrote: > > 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, > -- jst
Received on Wednesday, 14 April 2004 13:53:32 UTC