Subject: Fwd: Implementing HTMLDocument on all Documents (detailed review of the DOM) - msg#00069

Previous Message by Date: (click to view message preview)

Re: Official results of memeber-only vote on Selectors API name combos

Hi Charles & everyone, Charles McCathieNevile wrote: On Thu, 16 Aug 2007 19:56:59 +0200, Travis Leithead <travil@xxxxxxxxxxxxxxxxxxxxx> wrote: Recently, a member-only vote was held to attempt (yet-again) to resolve general complaining, grumbling, etc., about the latest API names chosen for the Selectors API spec I suppose a vote was the only fair and equitable thing to do. Well, it seemed the last best hope to stop going around this forever. I suppose this thread is now open to hear what the standardistas think, but personally, I'd like to just put the voted name in, and get this spec done ;) Indeed. As chair, this is a formal announcement that the decision of the group is to use the name querySelector, and publish the last call draft with that name. (This gives the public a chance to raise any objection that they think will convince the group to open this debate and go round *AGAIN* - as W3C process requires - but means that within the group the issue is until then considered resolved by vote). A small comment on the decision about the naming. Just to be 100% clear: this comment is not meant be an objection, indeed the last thing I want is to delay one more time the publication. However as I didn't participate in the pool (partly because I was away, but also because I didn't want to break a possible consensus) let me re-iterate my opinion on this. In terms of API you have to design them not only with the "standartitas" or "web gurus" in mind, but for a world of developers which includes: - people that use DOM APIs in other languages than JavaScript (DOM API are for example part of the Java platform) - people that do not have English as native language And at least for those two categories (that I'm part of) it seems to me a getElementsBySelector() method would have been clearer than the other options. Thanks for listening! -- Christophe

Next Message by Date: click to view message preview

Re: Implementing HTMLDocument on all Documents (detailed review of the DOM)

On 21/08/07, Simon Pieters <simonp@xxxxxxxxx> wrote: > We'd rather have the members of HTMLDocument that are useful for all types > of documents to be moved to the Document interface. This would probably be: > > * location > * URL (also present in SVGDocument) > * domain (also present in SVGDocument) > * referrer (also present in SVGDocument) > * cookie > * lastModified > * getElementsByClassName > * innerHTML > * activeElement > * hasFocus > * getSelection How about document.title? > Furthermore, it might make sense to move the following members from > HTMLElement to the Element interface: > > * getElementsByClassName Does this make sense on Element? I mean, the class attribute and it's semantics are HTML/XHTML specific. -- David "liorean" Andersson

Previous Message by Thread: click to view message preview

Official results of memeber-only vote on Selectors API name combos

Recently, a member-only vote was held to attempt (yet-again) to resolve general complaining, grumbling, etc., about the latest API names chosen for the Selectors API spec. I suppose a vote was the only fair and equitable thing to do. The race was pretty close, given the total votes, and a new name candidate rose to the top. I suppose this thread is now open to hear what the standardistas think, but personally, I’d like to just put the voted name in, and get this spec done ;)   Summary   Choice All responders                 Don't mind Don't want Ranked 1 Ranked 2 Ranked 3 Ranked 4 Ranked 5 Ranked 6 Single return value: selectElement() 2 2 2 5     3   List of return values: selectAllElements()                 Single return value: selectorQuery() 4   1   2 4 2 1 List of return values: selectorQueryAll()                 Single return value: selectorQueryOne() 3 1       2 2 6 List of return values: selectorQuery()                 Single return value: querySelector() 4   2 1 3 4     List of return values: querySelectorAll()                 Single return value: matchSelector() 4 2   2 2 1 2 1 List of return values: matchSelectorAll()                 Single return value: getElementBySelector() 2 3 6 2       1 List of return values: getElementListBySelector()                   Multiplier 3 7 1 2 3 4 5 6 Scores Totals selectElement()/selectAllElements() 6 14 2 10 0 0 15 0 47 selectorQuery()/selectorQueryAll() 12 0 1 0 6 16 10 6 51 selectorQueryOne()/selectorQuery() 9 7 0 0 0 8 10 36 70 querySelector()/querySelectorAll() 12 0 2 2 9 16 0 0 41 matchSelector()/matchSelectorAll() 12 14 0 4 6 4 10 6 56 getElementBySelector()/getElementListBySelector() 6 21 6 4 0 0 0 6 43 Stack ranking by vote: Rank Votes querySelector()/querySelectorAll() 1 41 getElementBySelector()/getElementListBySelector() 2 43 selectElement()/selectAllElements() 3 47 selectorQuery()/selectorQueryAll() 4 51 matchSelector()/matchSelectorAll() 5 56 selectorQueryOne()/selectorQuery() 6 70   So, querySelector/querySelectorAll it is. Now I’ll certainly have to learn to spell ‘query’ correctly...   Thanks to Lachlan for correcting my previously erroneous math.   -Travis MSIE

Next Message by Thread: click to view message preview

Re: Fwd: Implementing HTMLDocument on all Documents (detailed review of the DOM)

* Charles McCathieNevile wrote: >This is from the HTML group, but my first impression is that Simon is >right. Unfortunately my other first impression is that nobody is currently >really working on the relevant specs - is that true? As far as the Web API Working Group is concerned, Simon would be asking for new specifications to be produced, and in that sense you are right. As for the specific issue: >We're not happy with implementing the HTMLDocument interface on all >Document objects. It will affect all other types of documents and the >naming of their members in the future, and any additions to HTMLDocument >in the future becomes risky because it might break non-HTML documents. The same is true for any interface that Document objects implement, like those in the DOM Events or DOM Traversal specifications. While I could readily agree that implementing HTMLDocument on all Document objects might not be a good idea, I have a hard time seeing how: >We'd rather have the members of HTMLDocument that are useful for all types >of documents to be moved to the Document interface. This would probably be: would be any kind of improvement. You would have to explain why they need to be on Document rather than on a DocumentWithUsefulStuff inter- face. Clearly adding them to Document would make implementers who do not and do not plan to implement HTMLDocument anywhere at all unhappy (important reasons being that they are poorly designed and depend on not particularily common features like interactivity). -- Björn Höhrmann · mailto:bjoern@xxxxxxxxxxxx · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/