W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] Specification of window.find()

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 29 Jun 2012 20:46:27 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Rick Waldron <waldron.rick@gmail.com>, Tim Down <timdown@gmail.com>
Message-ID: <Pine.LNX.4.64.1206292043330.30734@ps20323.dreamhostps.com>
Cc: whatwg@whatwg.org, benjamin.poulain@nokia.com, Aryeh Gregor <Simetrical+w3c@gmail.com>
On Wed, 15 Feb 2012, Tab Atkins Jr. wrote:
> On Wed, Feb 15, 2012 at 11:26 AM, Ian Hickson <ian@hixie.ch> wrote:
> > So I guess we have to make a decision for the platform here.
> >
> > Do we want:
> >
> >  - To spec window.find() in all its historical glory, and have it
> >   implemented everywhere?
> >
> >  - To spec a subset of window.find() that just does the use case described
> >   above, namely to destructively change the selection to a matching part
> >   of the DOM so that it can be manipulated by script?
> >
> >  - To spec a new API that just returns matching ranges and then allows
> >   those ranges to be manipulated like the selection can be today?
> >
> >  - To encourage authors to write a library that does this for them, and
> >   not bother to provide a dedicated API at all?
> >
> > Which would implementations that don't do the full window.find() today be
> > willing to do?
> 
> As far as I know, we (google) would prefer to do nothing with 
> window.find(), so we can use it for the Selectors API.  No opinion on 
> whether the functionality is useful under another name.

On Wed, 15 Feb 2012, Rick Waldron wrote:
>
> +1 to TJ's mention of find for use in the Selector API:
> 
> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html

On Thu, 16 Feb 2012, Tim Down wrote:
> 
> For what it's worth as author of a small library currently working on 
> implementing something like this feature, I have no love for 
> window.find(), even if it were consistently implemented in browsers. I 
> would prefer the use case I described to be met by a different API, 
> which would ideally provide node-independent text-based 
> creation/mutation of Ranges, with features similar to those provided by 
> Microsoft's TextRange.

Given the lack of interest in the feature, I have removed it from the spec 
and recommend to implementors that they drop support for the API.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 29 June 2012 20:46:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC