W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: Any update on telcon times?

From: Robin Berjon <robin.berjon@expway.fr>
Date: Mon, 24 Apr 2006 20:22:29 +0200
Message-Id: <EEE95AF2-9646-4527-AE63-34FC1114D0D5@expway.fr>
Cc: Web APIs WG <public-webapi@w3.org>
To: Bjoern Hoehrmann <derhoermi@gmx.net>

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

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