This document:Public document·View comments·Disposition of Comments·
Nearby:Web Applications Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-1985 LC-1986 LC-1987 LC-1988 LC-1989 LC-1990
There are 6 comments (sorted by their types, and the section they are about).
hi, the ElementTraversal interface is bound to readonly attributes in ecmascript, whereas it is bound to methods in java. why? 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 binding) - i can make a quick implementation in javascript
Hi. 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. Thank you.
Some comments on http://dev.w3.org/2006/webapi/ElementTraversal/publish/ElementTraversal.html below * 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 not. * 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 specification.
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 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. Best, </Daniel>
Dear Web API WG, Element Traversal Spec uses "attribute" word at ECMAScript Language Biding[1]. > firstElementChild > 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[2], ...). The biding should be something like below: firstElementChild This read-only property is of type Element. ... childElementCount This read-only property is of type Number. Regards 1: http://www.w3.org/TR/2008/WD-ElementTraversal-20080303/#ecmascript-bindings 2: http://www.w3.org/TR/REC-DOM-Level-1/ecma-script-language-binding.html
Hello, 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); instead of var eachWidth = window.innerWidth / elCount; if the intention is to leave a space between the window margin and the elements, or: var nextPos = 0; instead of 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: B: Repetition: "...has the attributes defined below. The Element object has the following attributes:" Thanks,
Add a comment.