On Apr 24, 2006, at 16:56, Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
I personally think ElementTraversal should be replaced by a
.selectSingleNode() method that supports a small XPath subset,
There is a gigantic difference in performance between
selectSingleNode
and firstElementChild. Just parsing alone will take longer time then
just iterating the children and finding the first element.
ElementTraversal in SVG Tiny 1.2 replaces the node traversal
methods in
DOM Core, so as to allow implementations to not store the other node
types, white space text nodes in particular.
That is not the only purpose. It also addresses the rather
fundamental use case of traversing the structure of a document (i.e.
the elements) without resorting to the setup and lesser familiarity
required by DOM Traversal and other such approaches. One large
argument was "make easy things easy". Folks who've had a chance to
experiment with it in pre-release SVG Tiny 1.2 implementations love
it (I know I do). I've grown so used to it that I now pest against
browsers whenever I have to do the same stuff without it. Even Hixie,
who is not exactly partial to SVG's APIs, said "hey that rocks" when
he first saw it ;) [disclaimer: I'm not saying he endorses it, etc.]
Honest, it's simple, and it makes your breath fresh.
The only overhead added by
using selectSingleNode instead is that you have to do some string
comparison to branch to the correct traversal code, there isn't any
more
parsing or XPath code necessary than that.
It's possible, but I don't think that optimising .selectSingleNode()
to key off "preceding-sibling::*[last()]", "following-sibling::*",
etc. is very nice implementation-wise or very user-friendly. Or very
nice for that matter.
What the best solution is naturally depends on what you are trying to
achieve; if you don't care much about ever more traversal methods, and
really do need the performance gains, ElementTraversal might be a good
idea. It isn't clear to me though that this should be the primary con-
cern.
I don't think it needs to go into D3C. I am not too fond of adding
ever more convenience methods to the DOM, but this one is very
convenient as well as adapted to constrained devices (where
performance also matters). It also helps kill what is possibly the
number one user error when navigating the DOM, which to
consider .firstChild, .nextSibling, etc. to be elements.
I'll put the draft up when I find five minutes and that way we can
ask public feedback on the exact details.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
