W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: window.find already exists

From: Tim Down <timdown@gmail.com>
Date: Mon, 21 Nov 2011 17:03:59 +0000
Message-ID: <CAOYSAj0Wv_Ad7gw-BWweYMaQR5w_hjmt8gzEtY06AQMKxJZ5zA@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Simon Pieters <simonp@opera.com>, public-webapps@w3.org
window.find() covers a use case not easily replicated by other APIs:
searching within the page for text that crosses node boundaries. There
was a thread on the WHATWG mailing list about this:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-July/032588.html

Tim

On 21 November 2011 16:29, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Nov 21, 2011 at 8:28 AM, Simon Pieters <simonp@opera.com> wrote:
>> There's discussion about introducing find and findAll as an alternative to
>> querySelector[All]. However, window.find exists already in Firefox and
>> WebKit, and is for in-page text search. There's a placeholder for it in the
>> spec.
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#dom-find
>>
>> Are Firefox and WebKit going to drop the old find()? Is there legacy content
>> that feature detects for find() and would break if it changed semantics?
>
> That only interferes if .find() for selectors is defined on window.
> qSA is only defined on Document and Element, though, and I see no
> reason that .find wouldn't be the same.
>
> (Dropping window.find would be fine with me if we could do so, though,
> so it's a good question to ask.)
>
> ~TJ
>
>
Received on Monday, 21 November 2011 17:04:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT