W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [selectors-api] Investigating NSResolver Alternatives

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 14 Jul 2008 23:38:17 +0200
Message-ID: <487BC749.8030206@lachy.id.au>
To: Anne van Kesteren <annevk@opera.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>

Anne van Kesteren wrote:
> On Mon, 14 Jul 2008 21:30:18 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> Last I checked, the main envisioned use of the querySelector* APIs was 
>> to speed up existing queries toolkits do.  Might be worth asking them 
>> what they think would be useful.
> http://krijnhoetmer.nl/irc-logs/whatwg/20080709#l-597
> http://api.dojotoolkit.org/jsdoc/dojo/HEAD/dojo.query (It doesn't even 
> do XML unless all names are lowercase.)
> http://www.prototypejs.org/api/utility/dollar-dollar
> I agree that asking them explicitly would be good though, but it seems 
> like so far the need was not compelling enough to implement it. (And 
> libraries generally have gone to extreme lengths to implement other 
> things not natively supported by browsers or not available cross browser.)

Given that IE, Webkit and Opera seem to be in favour of dropping 
NSResolver, if Mozilla will agree, I'm more than happy to do so and 
possibly deferring it till a future version of the spec when we can 
really justify its use cases and find a solution that doesn't suffer 
from so many problems.  If it is dropped, then I'd rather not have an 
implementation ship with support for it, since then it would probably 
need to be specced anyway  Although, maybe it would depend on whether or 
not content relies on it.

Lachlan Hunt - Opera Software
Received on Monday, 14 July 2008 21:39:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC