W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: [selectors-api] Why have two identical differently named interfaces?

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 13 Mar 2008 17:18:27 -0700
Cc: liorean <liorean@gmail.com>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <67D10CDC-9FA1-41E1-AE05-B3F86F14E75E@apple.com>
To: Alex Russell <alex@dojotoolkit.org>

On Mar 13, 2008, at 4:53 AM, Alex Russell wrote:

> Hash: SHA1
> On Mar 12, 2008, at 8:46 AM, liorean wrote:
>> On 12/03/2008, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>> I guess I could do the two interfaces, but I'm having a hard time  
>>> seeing
>>> different extensions being made to these two interfaces (as
>> opposed to wholly
>>> new interfaces being invented, as was done here).
>> I can actually imagine one extension that only makes sence on  
>> elements
>> and not on any other nodes - element-rooted instead of
>> subtree-only-but-document-rooted queries. (I don't see any real
>> benefit from such an interface though, but I've seen the idea
>> mentioned on the mailing lists.)
> The benefit here is the (potential) ability to root queries to  
> containing nodes. Nearly every JavaScript library that does CSS  
> selectors handles the equivalent of:
> 	node.querySelectorAll("> .thinger");
> Which currently has no expression via valid CSS 3 selectors. There's  
> no concept of a query being a descendant of a selector root node  
> although the above use-case occurs very frequently in real-world  
> scripts.
> It seems foolish to extend the CSS 3 selectors WD to support a  
> syntax that is simple-selector free, whereas it has use in the DOM- 
> centric APIs.
> Whether this needs to be handled via separate interfaces, I can't  
> say (and don't care).

Maybe the best solution would be to add a :scope pseudo-element which  
is the target of the querySelectorAll call if not called on the  
document. That would allow old-school JS library semantics just by  
prepending ":scope ".

Received on Friday, 14 March 2008 00:19:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC