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.
Regards,
Maciej
