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

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

From: Alex Russell <alex@dojotoolkit.org>
Date: Thu, 13 Mar 2008 14:13:06 -0700
Cc: "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <55558685-1197-4C16-9AA6-1F7709FE26B3@dojotoolkit.org>
To: liorean <liorean@gmail.com>

Hash: SHA1

So just to clarify:

Your expectation is that the querySelectorAll API will be wrapped by  
JavaScript libraries for the foreseeable future?

As a JS library author, it was my sincerest hope that I could get out  
of this particular pool.


On Mar 13, 2008, at 6:04 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).
>> On Mar 12, 2008, at 8:46 AM, liorean wrote:
>>> 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.)
> On 13/03/2008, Alex Russell <alex@dojotoolkit.org> wrote:
>> 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.
> Yes, but that use case has a trivial solution in document-rooted
> context: determine the ID or if not present generate an ID for the
> current node, query for a document-rooted "#ID > .thinger" and then if
> you had to generate an ID, remove it.
> In the context of HTML5 scoped style elements I did have an idea that
> could be subverted for this case as well. The idae was basically a
> ::scope-root pseudo-element that encompassed the downwards sibling
> tree of the scoped style element. This pseudo-element could be equally
> useful in the Selectors API.
> (I think I first mentioned it in
> <uri:http://lists.w3.org/Archives/Public/public-html/2007Jun/ 
> 0069.html>.
> The threading is sadly slightly broken in the archives though (usualy
> suspect is Outlook), so it's hard to follow the entire discussion.)
>> 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.
> Or in scoped style elements in HTML5... I still think explicit is
> better than implicit though, with the added benefit that it will not
> require changes to the basic algorithms of current selectors
> implementations.
> -- 
> David "liorean" Andersson

- --
Alex Russell
alex@sitepen.com  A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Version: GnuPG v1.4.2 (Darwin)

Received on Thursday, 13 March 2008 21:13:50 UTC

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