Jonas Sicking wrote:
Jean-Yves Bitterlich wrote:
A few alternatives were proposed here, referred below as
(i) 'attribute NodeList childElements',
(ii) 'Node item(index)' and
(iii) xpath .querySelector.
I personally like (iii) because it is powerful (or is it just queries
that are
Hopefully, not too late to bring some more 'Elements' (at least our
opinion) to this thread and spec.
As some of you already know, we have brought JSR-280 [1] (parts of which
is DOM related and refer to the ElementTraversal (draft) specification)
to a Final Release back in October 2007.
Jean-Yves Bitterlich wrote:
A few alternatives were proposed here, referred below as
(i) 'attribute NodeList childElements',
(ii) 'Node item(index)' and
(iii) xpath .querySelector.
I personally like (iii) because it is powerful (or is it just queries
that are powerful?), however it
Hi, Bjoern-
Bjoern Hoehrmann wrote (on 4/3/08 6:30 PM):
* Simon Pieters wrote:
The result of (2) probably also means that there's both childElementCount
and childElements.length to do the same.
If the SVG Working Group wants the count but not the NodeList, you end
up with that either way.
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
I'm not following this argument at all. Neither would content that uses
.globalStorage, .forms, .querySelector or anything else that's not in
the SVG Tiny spec.
We're trying to make a new API here, of course content that uses that
API isn't
On Thu, 03 Apr 2008 19:04:55 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Ah, thanks, that does explain the issue.
Though I think that if we want the web to have a .childElements NodeList
available then we have two options:
1. Add it to the ElementTraversal spec and have SVG Tiny say that
* Simon Pieters wrote:
The result of (2) probably also means that there's both childElementCount
and childElements.length to do the same.
If the SVG Working Group wants the count but not the NodeList, you end
up with that either way. This might be a good time to talk to them.
--
Björn
If we're not 100% compatible with SVG, why would they oppose an
improvement like the suggested one?
Content that uses childElements[...] would not function correctly
in SVG Tiny 1.2 implementations for no particularily good reason.
I'm not following this argument at all. Neither would
Daniel Glazman wrote:
I'm actually not sure. How often do authors want to get the third
child without knowing anything more about it than that it's an
element? Iterating through the kids (by means of ET or '.childNodes')
gives you much more context information (what type of element it is,
On Apr 2, 2008, at 00:48, Boris Zbarsky wrote:
OK. So item() would be available on Element after casting it to
NodeList in those implementations. I guess you're saying that the
cast would not longer be unambiguous if there were multiple
NodeLists that might make sense? So childElements
Bjoern Hoehrmann wrote:
It would be easier to define that, if the argument starts with a non-
white space combinator, it is prefixed with a selector that selects the
element node it is called on and only that node. That would give you
myFooElement.querySelectorAll(*)[3]
Urgh, to say the
Henri Sivonen wrote:
On Apr 2, 2008, at 12:44, Jonas Sicking wrote:
And to what end? To use indexing instead of list-style iteration.
Exactly. Something that I would imagine is quite commonly done. Note
that we're not just talking iterating over a full DOM tree, we're also
talking about
On Apr 2, 2008, at 12:44, Jonas Sicking wrote:
And to what end? To use indexing instead of list-style iteration.
Exactly. Something that I would imagine is quite commonly done. Note
that we're not just talking iterating over a full DOM tree, we're
also talking about navigating around in a
Jonas Sicking wrote:
Bjoern Hoehrmann wrote:
We could also standardize the popular .getChildrenByTagName() method,
that would give the similar
myFooElement.getChildrenByTagName(*)[3]
This seems like an excellent idea. To do in addition to the
ElementTraversal spec.
I understand from
On Apr 2, 2008, at 13:20, Jonas Sicking wrote:
Henri Sivonen wrote:
On Apr 2, 2008, at 12:44, Jonas Sicking wrote:
And to what end? To use indexing instead of list-style iteration.
Exactly. Something that I would imagine is quite commonly done.
Note that we're not just talking iterating
Daniel Glazman wrote:
Jonas Sicking wrote:
Bjoern Hoehrmann wrote:
We could also standardize the popular .getChildrenByTagName() method,
that would give the similar
myFooElement.getChildrenByTagName(*)[3]
This seems like an excellent idea. To do in addition to the
ElementTraversal
Jonas Sicking wrote:
But I was serious about thinking that adding the function seems like a
good idea. It's currently much too painful to navigate around in the DOM
so it's something we should try to fix.
Agreed.
/Daniel
On Apr 2, 2008, at 15:09, Jonas Sicking wrote:
It can be a pain to add IDs to *all* the nodes you ever access. A
pattern i've seen a lot is to have small repeating sections in a
page, and then navigating within that repeated section.
That makes sense.
That said, I don't think there's a
On Apr 2, 2008, at 16:21, Henri Sivonen wrote:
It was a problem for me when I tried to walk the HTML5 spec in
Firefox 1.5 using iterative traversal with firstChild/nextSibling/
parentNode. Firefox 1.5 performed a *lot* worse than the then-
current versions of Opera and Safari. And the spec
On Apr 2, 2008, at 16:50, Henri Sivonen wrote:
if (next = current.firstChild) {
current = next;
continue;
}
break;
Please disregard that break;. (Left-over from a switch that was
obscuring the main point of the algorithm.)
--
Henri Sivonen
[EMAIL PROTECTED]
On Apr 2, 2008, at 2:44 AM, Jonas Sicking wrote:
Henri Sivonen wrote:
On Apr 2, 2008, at 00:48, Boris Zbarsky wrote:
OK. So item() would be available on Element after casting it to
NodeList in those implementations. I guess you're saying that the
cast would not longer be unambiguous
Henri Sivonen wrote:
I'm not claiming it would be awfully hard, but it does change the impact
of Element Traversal from adding four or five methods on an existing
class (mere code footprint; super-simple)
That depends on what performance characteristics callers expect or UAs want to
Henri Sivonen wrote:
Allowing app code to index into platform
structures that are most commonly forward-iterated seems like an
anti-pattern in terms of what implementation constraints are placed if
the impression that the app developer gets is that indexing has the
performance properties of
On Apr 1, 2008, at 17:36, Henri Sivonen wrote:
I think using
var e = p.firstElementChild;
while (e != null) {
...
e = e.nextElementChild
}
to iterate over child elements is a cleaner idiom than introducing
an index that isn't used for random access but only for forward
iteration.
Even
Henri Sivonen wrote:
How often do people pick a single child by index (with a number know a
priori) instead of iterating over children and testing each one for an
interesting trait?
Let me turn the problem differently : NodeList and NamedNodeMap are the
normal answers when we query a list
Hi, Henri-
Henri Sivonen wrote (on 4/1/08 10:36 AM):
c. just remove the childElementCount attribute
It seems to me that checking if an element has *any* element children is
going to be the most common use case for childElementCount and that can
be checked by checking if firstElementChild
On Apr 1, 2008, at 18:41, Daniel Glazman wrote:
Henri Sivonen wrote:
How often do people pick a single child by index (with a number
know a priori) instead of iterating over children and testing each
one for an interesting trait?
Let me turn the problem differently : NodeList and
Henri Sivonen wrote:
The childNodes feature seems to have caused a lot of
complexity in DOM implementations
Really? What sort? I'm only familiar with the Gecko implementation here, but I
don't see it causing extra complexity there...
The Selectors API, for example, returns comatose
On Apr 1, 2008, at 23:27, Boris Zbarsky wrote:
Henri Sivonen wrote:
The childNodes feature seems to have caused a lot of complexity in
DOM implementations
Really? What sort? I'm only familiar with the Gecko implementation
here, but I don't see it causing extra complexity there...
In
On Apr 2, 2008, at 00:30, Boris Zbarsky wrote:
Really? You mean document.body.item(5) does the same thing as
document.body.childNodes.item(5)? And that this is common? I
must have missed it
I mean that the getter implementation for childNodes is roughly
return this;.
This pattern is
On Apr 2, 2008, at 00:45, Henri Sivonen wrote:
Yes, getChildNodes() is available
Doh. item() is available...
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
Hi,
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
* 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
Bjoern Hoehrmann wrote:
b. you add
Nodeitem(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
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
* Jonas Sicking wrote:
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?
The element count attribute is new, other than that I am not aware
of differences.
If
Ok, guys, let's see it that way : we have one given element and we
want to find its 3rd element child. Very simple and common query,
right ?
1. using my proposal :
myFooElement.childElements.item(3);
2. using Selectors API :
myFooElement.querySelector(*:nth-child(3)) does NOT work
Hi, Daniel-
Daniel Glazman wrote (on 3/28/08 12:55 PM):
Ok, guys, let's see it that way : we have one given element and we
want to find its 3rd element child. Very simple and common query,
right ?
I'm actually not sure. How often do authors want to get the third child
without knowing
Doug Schepers wrote:
Speaking as an author of many SVG Webapps and a contributor to several
SVG script libs, knowing the number of child elements is a really common
need; index-based access is less needed, and can be effected by other
means.
I would just like to point out, from my
I'm actually not sure. How often do authors want to get the third child
without knowing anything more about it than that it's an element?
Iterating through the kids (by means of ET or '.childNodes') gives you
much more context information (what type of element it is, what it's
bbox is,
Doug Schepers wrote:
Since Selectors API is meant to be a more comprehensive API than Element
Traversal, I would expect it to be able to deal with this more general
use case Daniel mentions, and personally would prefer to increase the
comprehensive functionality of that spec over Element
* Daniel Glazman wrote:
3. using XPath :
document.evaluate('*[3]', myFooElement, null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null).snapshotItem(3);
I was thinking of .selectSingleNode(*[3]) which is not part
of the DOM Level 3 XPath Note but
Hi, Boris-
Boris Zbarsky wrote (on 3/28/08 1:41 PM):
Doug Schepers wrote:
Speaking as an author of many SVG Webapps and a contributor to
several SVG script libs, knowing the number of child elements is a
really common need; index-based access is less needed, and can be
effected by other
Doug Schepers wrote:
The question is, can we revisit it in light of existing implementations
in JSR-280 and in deployed code in mobile devices? At the very least,
we would have to leave 'childElementCount', and add an additional
nodeList (be it static or live). At that point, yes, it does
44 matches
Mail list logo
