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

Re: Comments on element traversal specification...

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 22 May 2007 22:22:21 -0700
Message-Id: <1CA324F6-3A60-4266-A057-AB6490BF824A@apple.com>
Cc: public-webapi@w3.org
To: Ray Whitmer <ray@jhax.net>

On May 22, 2007, at 5:39 PM, 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.

See Jonas's message for other ways to achieve this.

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

The API is mostly in the form of attributes, not methods, so there's  
nothing to pass an optional argument to. You'd need to add methods or  
new attributes to handle the case you want.

> 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.

You don't want to append them as children, because that would remove  
them from the original document; you could clone them instead, but  
that is expensive performance-wise and does not preserve node  
identity. At this point, we have a pretty narrow range of use cases  
which would be better served with (in my opinion) normal DOM  
traversal plus a way to detect whether a text node contains  
significant content.

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

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