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

Re: Comments on element traversal specification...

From: Doug Schepers <doug.schepers@vectoreal.com>
Date: Wed, 23 May 2007 01:32:47 -0400
Message-ID: <4653D1FF.7080208@vectoreal.com>
To: public-webapi@w3.org

Hi, Ray-

Thanks for your feedback.

Ray Whitmer wrote:
> 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.

It doesn't seem to me that what you are looking for is in scope for 
ElementTraversal.  The whole point of ElementTraversal is that it 
ignores all non-element content.  This is most useful for languages such 
as SVG where most content is not "markup" per se (that is, where 
elements are themselves the content, and are not primarily used to 
encapsulated text content).  Of course, there are uses in HTML as well, 
where most elements are in fact marking up text content (for example, it 
might be used to walk a collection of <li> elements, while ignoring any 
whitespace or comments between them).

As Jonas points out, you can use ElementTraversal in combination with 
the Node interface (myElem.nextElementSibling != myElem.nextSibling) to 
achieve more flexible results.

It's worth noting that this interface is specified on the Element 
object, not on the Node object, so it cannot be called from a text node 
in any case.

> With respect to other issues: it would be nice to have both Java and 
> ECMAScript bindings, 

The most recent version of the spec has both 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.

In response to feedback, the ChildElementList has indeed been removed. 
Instead, a childElementCount attribute (an unsigned long) provides the 
most crucial functionality of ChildElementList while reducing the 
implementation overhead.

Received on Wednesday, 23 May 2007 05:33:01 UTC

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