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

Hi, Daniel-

I definitely see your use case and think it would be a valuable 
addition, but I agree with Björn's characterization.

Part of the rationale with not having a nodeList was to make this a very 
lightweight interface, and that was reinforced through comments on this 
list.  I had initially introduced a nodeList in this incarnation of the 
spec, but received negative feedback about it, which is why I did the 
next best thing (from my perspective) in adding 'childElementCount' instead.

Björn is also correct that the Selectors API spec will add that kind of 
discrete itemized access to browsers, so I am reluctant to reintroduce a 
nodeList to Element Traversal.

There are also existing implementations that follow the spec as it is, 
so while that's an unfortunate situation --implementations should really 
only be shipped in production code after the spec is considered stable, 
in CR-- it is contraindicative of so fundamental a change.  It would 
also necessitate another LC period.

However, I am merely the editor, so I leave it to the WG to decide.

On the other hand, if you're satisfied that your desired functionality 
will be otherwise available via the Selectors API or XPath, as Björn 
points out, then you could withdraw your comment.  Please let me know 
your preference.


Bjoern Hoehrmann wrote (on 3/28/08 11:47 AM):
> * 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.
> 
>>    b. you add
>>
>>         Node    item(in unsigned long index);
>>
>>       but that is not really consistent with the existing way of
>>       querying list of nodes.
>>
>>    My very strong preference goes to solution a.
> 
> At the least you would need a different name as this would go on all
> element nodes and you would probably run into name clashes quickly, and
> confuse authors (NodeList.item vs. Element.item for example). However,
> you could also just use XPath, or Selectors, or one of the many other
> methods for this particular case, I don't think this addition is needed.

-- 
Regards-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

Received on Friday, 28 March 2008 16:27:18 UTC