W3C home > Mailing lists > Public > public-webapi@w3.org > May 2007

Comments on element traversal specification...

From: Ray Whitmer <ray@jhax.net>
Date: Tue, 22 May 2007 18:39:28 -0600
Message-ID: <20070522183928.6yb645y2o4kw8cgk@webmail.xmission.com>
To: public-webapi@w3.org

I just saw an element traversal API draft, which is a good, powerful  
idea that is quite close to the helper functions I write every time I  
use DOM for serious work.

My main comment: I could not use unless it does not do something  
reasonable with skipped intervening content, which it could do with  
little disruption.

For my purposes, if the application is processing element content, it  
needs to raise an error if non-whitespace text is found.  If it is  
processing mixed content, it needs to pass the skipped content back to  
the caller. I cannot think of the case where non-whitespace text  
should ever be silently ignored.

Fortunately, it is fairly easy to handle, for example, through an  
optional argument, as follows:

If no argument is specified (for element content), then non-whitespace  
intervening text (between the sibling/parent and the next/previous  
child) would cause an error.  If the argument is specified (for mixed  
content), the argument is a parent node (such as a DocumentFragment)  
and all intervening non-element nodes (between the sibling/parent and  
the next/previous/first/last sibling) are just copied to the specified  
node (appended as children, never an error) so the caller can examine  
or do with them what he will.

The optional argument would be added to each navigation call of the  
API, can be implemented quite easily, and makes the functions more  
universal. It can be optimized well in implementations and does not  
make the functions more difficult to use. The calls are the same  
(without optional argument) for element content (and errors for  
non-white-space are automatic).  Anyone who wants to ignore or collect  
intervening content can specify the second argument.

If you have considered and rejected this, consider my comment another  
voice for this. If there is a simpler answer, by all means. If not, I  
guess I would not find the specification useful for most of my  
applications, but you probably have other cases in mind where it would  
be useful.

With respect to other issues: it would be nice to have both Java and  
ECMAScript bindings, and I think you should not provide a child list  
attribute in this API (waste of effort). If anyone insists on a better  
list, make a Java iteratable or a real non-live array, not a  
non-standard live list interface (like DOM V1), but who really needs  
it anyway?  Not me.


Ray Whitmer
Received on Wednesday, 23 May 2007 00:39:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC