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

Re: ElementTraversal spec draft

From: Doug Schepers <doug@schepers.cc>
Date: Tue, 03 Apr 2007 12:00:08 -0400
Message-ID: <46127A08.2080200@schepers.cc>
To: web API <public-webapi@w3.org>

Hi, Bjoern-

I don't think that your solutions address the use case I was pushing 
for.  I will present my counterargument, but just for the sake of moving 
the spec along, I will most likely drop this feature unless I get 
indication of support otherwise.

Bjoern Hoehrmann wrote:
> * Charles McCathieNevile wrote:
>> @@issue: should we add a childElements attribute
>> that returns a list of elements?
> 
> No! You can easily do this with
> 
>   for (child = element.firstElementChild;
>        child;
>        child = child.nextElementSibling)
>     array.push(child);
> 
>   for (var i = 0; i < array.length; ++i)
>     ...

That forces the author to use a 2-pass solution at JS speeds, rather 
than at compiled-code speed (and footprint).


> I do not see why you would do that though. Further, you can about as
> easily do this using DOM XPath, XPath selectNodes, the CSS Query API,
> DOM Level 2 Traversal, you can in fact just use Core like
> 
>   for (var i = 0; i < element.childNodes.length; ++i)
>     if (element.childNodes[i].nodeType == 1)
>       ...
> 
> well you would really use
> 
>   for (child = element.firstChild;
>        child;
>        child = child.nextSibling)
>     if (child.nodeType == 1)
>       ...
> 
> Counting is trivially implemented on top of these, or you can just
> use XPath "count(*)". 

In what browser?


> I understand a primary concern why SVG Tiny 1.2
> did not have many of the DOM Core features is because the NodeList
> interface was regarded as expensive. And having childNodes live and
> childElements not live would add considerable confusion. No need for
> an alias for element.selectNodes("*") and element.cssQuery("*").

I doubt that smaller devices will implement those interfaces.  We'll see.


> As a comment on the draft, you have to define how the method behave
> in case of unexpanded entity references and entity replacement markup.
> I've explained this in a little bit more detail on www-svg at some
> point.

As discussed on IRC, I'll post my suggested handling of this situation 
in the next draft.  I'd appreciate further feedback then.

Regards-
-Doug
Received on Tuesday, 3 April 2007 16:01:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT