On Tue, 26 Feb 2008 06:42:49 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote (on 2/25/08 4:25 PM):
* 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've reworded the introduction slightly, in hopes of making it more
clear. I've also added explanatory text to example 3.2, which
demonstrates the use of childElementCount.
Where is the draft located that contains these changes? It seems you
haven't updated the editor's copy which makes it hard for me to revew the
changes.
* 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.
That's an odd request. A better suggestion might be to clarify the
sentence, since I wouldn't have put it in if I didn't think the point
needed to be made.
Most of the functionality of this spec is an optimized subset of DOM2
Traversal & Range, and it is intended that a UA could implement both by
aliasing; however, this isn't required for conformance to this
specification. I hope that clarifies it for you.
It's not a subset at all. Clarification is ok too, but I think the
sentence is a distraction.
* 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.
I put this in as a response to an earlier comment [1]. While I think
it's an edge case, the commenter was satisfied by the response.
That may very well be so, but I don't understand what it's saying.
I'm reluctant to mandate how a UA implements the solution, whether by
implementing this interface on the entity reference node or only on the
expanded resulting DOM, because I don't know how every UA does so. I
don't think it effects interoperability, so I prefer to leave it as is.
Leaving it as does not satisfy me as I think the sentence is unclear.
* "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 agree, but if you care to suggest alternate wording, I'll
consider it.
"Getting this attribute of an element must return the first Element child
node of that element or null if there are no Element child nodes."
* I don't think the IDL should be in the appendix. It's a useful
overview of what the draft defines.
I think this is a stylistic change that doesn't affect the readability
or usefulness of the specification. I prefer to keep it as is, since it
makes more sense to me this way.
It would tell you upfront what the interface is and what members it
introduces and provide pointers to the definitions of those members. I
think that would make the draft more readable.
Since I made only editorial, non-normative changes, I published them in
the upcoming LCWD document, to be published next Monday.
I don't understand why it's not in the editor's draft. Everything what
this group does, including editorial work, is captured in public documents
nowadays.
[1] http://lists.w3.org/Archives/Public/public-webapi/2007Mar/0065.html
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
