W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: [Element Traversal LC] access to element by index

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 28 Mar 2008 09:23:46 -0700
Message-ID: <47ED1B92.2070207@sicking.cc>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, "Web APIs WG (public)" <public-webapi@w3.org>

Bjoern Hoehrmann wrote:
> * Daniel Glazman wrote:
>> 1. congrats for this spec, I love it ; I can't count how many times in
>>    page or chrome script I am filtering out nodes that are not element
>>    nodes.
>> 2. the ElementTraversal interface has a |childElementCount| attribute
>>    but misses access to an individual childElement based on its index.
>>    That would be really useful. Two solutions here :
>>    a. you remove the childElementCount attribute in favor of a
>>         readonly attribute NodeList    childElements;
>>       and that NodeList has all we need
> It was the SVG Working Group that originally came up with the interface
> and they, as I understand it, decided against having any NodeList in the
> SVG Tiny 1.2 DOM. They rather introduced the interface to allow imple-
> mentations to discard some nodes like comments and text nodes with only
> white space while keeping compatibility with implementations that keep
> them. I would imagine they would be unhappy with such a change.

I agree with Daniel here. I'm not really following your argument. Are we 
trying to keep compatibility with the SVG spec here? Is the interface as 
designed now 100% compatible with SVG?

If we're not 100% compatible with SVG, why would they oppose an 
improvement like the suggested one?

I don't see how having the suggested interface would affect if you can 
discard other nodes entirely or not, that seems to be more affected by 
the *other* interfaces in the various DOM specs (such as DOM L1 Core).

If we don't provide a way to grab elements by index I don't really see a 
purpose of the childElementCount attribute.

/ Jonas
Received on Friday, 28 March 2008 16:24:26 UTC

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