In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
|Commentor||Comment||Working Group decision||Commentor reply|
<firstname.lastname@example.org> (archived comment)
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
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
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.
|After much conversation and review of existing implementations, we resolved not to add a nodelist to Element Traversal, but to create a separate spec to add that and similar features. Commentor was satisfied:
<email@example.com> (archived comment)
The Element Traversal WD define childElementCount on the Element interface.
Personally I see little use for such property by itself.
It would make much more sense to have childElements (similar to childNodes
on Node), and therefore we could use childElements.length to get the same
value as childElementCount. childElements would also be a live NodeList.
Most use cases for Element only transversal require looping NodeLists, and
if the author still has to filter nodes from these NodeLists by their
nodeType, then that beats the entire purpouse of this specification.
|No change made.
<firstname.lastname@example.org> (archived comment)
the ElementTraversal interface is bound to readonly attributes in
ecmascript, whereas it is bound to methods in java.
it would be more convenient if it was bound to methods in ecmascript either.
i can think of two arguments for this :
- the bindings will be more consistent (so that you don't have
"getChildElementCount" and "childElementCount" representing the same
|Question answered to commentor's satisfaction:
Anne van Kesteren
<email@example.com> (archived comment)
Some comments on
* As mentioned on IRC, node types should probably be capitalized. E.g.
Text instead of text.
* It's not clear from the introduction why we need childElementCount.
Having both linked list and array like traversing for the DOM is already
slightly unclear to me, but childElementCount seems to provide neither.
* I don't understand why 1.1 is marked as informative and section 1. is
* 2. talks about implementing methods where you mean attributes.
* In 2. ElementTraversal is not marked up.
* I don't understand "A User Agent may implement similar interfaces in
other specifications, but such implementation is not required for
conformance to this specification, if the User Agent is designed for a
minimal code footprint." I suggest dropping this sentence.
* It's not clear to me how "For the purpose of ElementTraversal, an entity
reference node which represents an element must be treated as an element
node." works. Does this mean that an EntityReference node also implements
this interface? I suggest dropping this sentence or stating that this
interface assumes that all entities are normalized away or something. (We
should really get rid of syntactic sugar in the DOM in due course...)
* "Accessing this attribute of an element must return a reference to the
first child node of that element which is of nodeType 1, as an Element
object." I don't think ", as an Element object." makes much sense in this
sentence. (Likewise for similar sentences.)
* I don't think the IDL should be in the appendix. It's a useful overview
of what the draft defines. I would also like to see pointers from the IDL
bits to their definitions. As we've done in the XMLHttpRequest
|New wording hopefully satisfies both commentors:
<firstname.lastname@example.org> (archived comment)
Dear Web API WG,
Element Traversal Spec uses "attribute" word at ECMAScript Language Biding.
> This read-only attribute is of type Element.
But it is prefered to use "property" rather than "attribute" in
ECMAScript world. Other DOM Specs use "property" at ECMAScript
Language Binding (ex. DOM Level 1, ...).
The biding should be something like below:
This read-only property is of type Element.
This read-only property is of type Number.
|Spec changed in response to comment:
<email@example.com> (archived comment)
Some quick comments on the Element Traversal Last Call Working Draft.
These attributes must be read only, but this is only stated in the
bindings. Shouldn't there be something about this in Section 2?
2.5: typo: "must +be+ counted"
3.2: Is window.innerWidth in any spec? As far as I know, no, so is it
good to use it?
3.2: The way the position is computed is wrong. It should either be:
var eachWidth = window.innerWidth / (elCount + 1);
var eachWidth = window.innerWidth / elCount;
if the intention is to leave a space between the window margin and the
var nextPos = 0;
var nextPos = eachWidth/2;
if the intention is to leave no space. Also, perhaps the width should
also be set?
childEl.style.setProperty( 'width', eachWidth + 'px', '' );
B: typo: "Element has -the- all the attributes"
B: Shouldn't the "In a User Agent..." text be placed outside the "code"
div? In its current position it looks bad all bold, and it also causes:
"...has the attributes defined below.
The Element object has the following attributes:"