- From: Doug Schepers <doug@schepers.cc>
- Date: Tue, 06 Feb 2007 19:34:54 -0500
- To: Web API public <public-webapi@w3.org>
Hi, Anne- Anne van Kesteren wrote: > > Given the input from Björn I suppose there's no real need for a method > that returns a single element node (assuming implementations make that > optimization). It might be worthwhile to add an informative note to the spec describing this optimization to implementors, with a small use case or example. That way, someone who wasn't following this discussion would still know about it and could choose to build it in, and those content authors who read the spec could spread the use of it. > Given that, I propose we rename .getAll() to > .getElementsBySelector() and drop .get() (on both Document and Element). Just to be clear, .getElementsBySelector() would still work on both Document and Element, right? > One advantage is that it's consistent with the naming people already use > for custom written functions that have this functionality. In theory > it's also not harder to type than .getElementsByTagName(). The only > thing that makes it differ from the other getElementsBy* method(s) is > that it doesn't return a live NodeList. I don't see that as a major > problem. Nor do I, but you could add yet another note in there emphasizing this. > If there are no strong objections I'll implement this in the specification. Sounds good. Thanks, Anne. Finally, an anecdote. When I talked to one of my co-workers about this functionality, he asked if it would let you get and element by id at the element scope rather than the document scope; I told him it would, but asked why that was a strong use case for him. He replied that he frequently has multiple elements with the same id in the same document, and sometimes wanted to get a particular one, not just the first one. This is a smart, competent guy with good programming skills, but he didn't know that an id needed to be unique within a document. I suspect that he is only one of many, and that with this method, the misuse of id would become even more widespread. To combat this, I'd like to see an explanatory note that reiterates the restrictions on the use of id (a sort of Best-Practice comment, essentially). Regards- -Doug
Received on Wednesday, 7 February 2007 00:35:14 UTC