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

Re: [selectors-api] Why no querySelector(All) on DocumentFragments?

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 14 Mar 2008 16:11:57 -0700
Cc: Jonas Sicking <jonas@sicking.cc>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-Id: <4B4A2E1E-6655-4F46-B83E-E3D19B4F0B57@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>


On Mar 14, 2008, at 2:25 PM, Boris Zbarsky wrote:

>
> Jonas Sicking wrote:
>> If we merge DocumentSelector and ElementSelector into simply  
>> NodeSelector we'll more or less automatically get the functions on  
>> DocumentFragments.
>
> Not necessarily.  I'm not advocating that all Nodes be castable to  
> NodeSelector.  Just that whatever nodes querySelector(All) work on  
> are.
>
>> We'd also get it for attribute nodes which might be less desirable.
>
> I don't think it's desirable at all.
>
>> Though we could say that the interface is only required to be  
>> implemented on Documents, Elements and DocumentFragments.
>
> That would be my suggestion, yes.  ;)
>
>> If we could get a :scope pseudo-element that would be an excellent  
>> solution IMHO, and would be great with scoped stylesheets as has  
>> been pointed out elsewhere in the last few days.
>
> Agreed.
>
> That said, is there interest in getting this spec to CR quickly,  
> since it seems some UAs are planning to ship it in the near future  
> even though it's a Working Draft?  Or are said UAs willing to make  
> changes to their implementation after shipping as the spec changes?

UAs are also planning to ship HTML5 features, and that's nowhere near  
CR. For Safari/WebKit we are willing to keep up with changes but we  
hope and assume there wouldn't be gratuitous incompatibilities  
created. For example, extending the interface to DocumentFragment,  
adding :scope, or adding parallel methods for element-rooted queries  
would both be reasonable changes from our point of view. Because this  
API is driven to a large extent by a desire to replace AJAX library  
functionality with more performance native versions, I think it's  
important to make sure we actually satisfy their use cases, and we're  
learning about that from the existing early implementations as JS  
library authors play with them.

The main thing I'd like to see ASAP is a good test suite, and we don't  
need to wait for CR to start building that.

Cheers,
Maciej
Received on Friday, 14 March 2008 23:12:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 March 2008 23:12:36 GMT