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

Reply via email to