- From: Robin Berjon <robin.berjon@expway.fr>
- Date: Mon, 24 Apr 2006 20:22:29 +0200
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Web APIs WG <public-webapi@w3.org>
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/
Received on Monday, 24 April 2006 18:22:10 UTC