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
