RE: Browser search API

I really appreciate Mitar's desire to not hijack the browser's native UI, and instead intercept it and supply it with more helpful information. That seems definitely better than preventDefault()ing the normal search UI.
________________________________________
From: Mitar <mmitar@gmail.com>
Sent: Monday, December 02, 2013 14:48
To: Mounir Lamouri
Cc: public-webapps@w3.org
Subject: Re: Browser search API

Hi!

On Mon, Dec 2, 2013 at 3:42 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> I am not sure that telling the webpage what the user is currently trying
> to search is a great idea.

Firefox and Safari are already doing that. When user searches, you can
get what he or she is searching for with window.getSelection(). Chrome
does not provide that. But the issue is that you do not know when the
search started. You could poll or you could try to detect unusual
change in scroll position, but all that is ugly.

What I am proposing is a standardized interface to that.

And there are real use cases. For example, go to some long document in
Google Docs and invoke browser search by going through menu (Edit ->
Find or something similar). You will see that it does not work except
for the current document page. It does not find pages which are
further down the document, because they have not yet been rendered. If
you press ctrl-f, Google Docs intercepts this and provides you with
their own search interface which does work across whole document. This
is a bit
hackish in my opinion because it would be better that you would be
able to use known interface (especially important on mobile devices
where you are not pressing ctrl-f, and some custom interface might not
be as well integrated as native one - for example, native one could
provide voice search for free (as no time needed to implement it)).
And that it would work across whole document. Google Docs is just an
example, any dynamic and rich document viewer has this issue, Mozilla
pdf.js for example as well.

> However, if a webpage wants its own "find in
> page" UI I guess a simple solution would be to do something similar to
> the Forms Validation UI: a 'findinpage' event could be fired on the
> document when the user initiates a find in page and the page would be
> able to call .preventDefault() on the event in order to show its own UI.

This would be one option, but I would prefer that user can still
continue to use browsers interface because this might be better
integrated with the device, like on mobile devices search is often
just an entry in the menu which opens possibly specialized search
interface for that particular mobile device.


Mitar

> It could look like:
> window.document.addEventListener('findinpage', function(e) {
>   e.preventDefault();
>   var find = createFindInPageUI();
>   find.focus();
> });
>
> --
> Mounir
>
> On Sat, Nov 30, 2013, at 15:40, Mitar wrote:
>> Hi!
>>
>> Is there already any proposal for browser search API for searching
>> over displayed web pages? So that a webapp could know when user is
>> searching with a browser interface. I am imagining something where
>> browser would send an event with search string content whenever user
>> would modify search pattern. Because searching over the page is part
>> of the trusted UI, webapp should not have a way to interfere or set
>> search string content, but webapp should still know when searching is
>> happening.
>>
>> This would be really useful for assuring search works as expected for
>> webapps which work with rich and special content. For example, Google
>> Docs would not have to hijack search shortcut to provide their own
>> search. And it would still work when user starts searching by enabling
>> it through browser menu entry and not through keyboard shortcut.
>>
>> Another example is Mozilla pdf.js, a canvas based PDF rendering
>> library for the web. Because all content is rendered as canvas,
>> searching is a really unsatisfying experience. Their current approach
>> is same as Google Docs, they hijack search keyboard shortcut to
>> display their own search. And again, this makes users be confused if
>> they start searching through browser menu.
>>
>> Not to mention that users using mobile devices probably never start
>> searching with keyboard shortcut.
>>
>> So, is there a plan to standardize something like that? A simple event
>> which would be send every time user change string he or she is
>> searching for, or an empty string if search was cleared or closed.
>> Where should I turn to to propose such a standard?
>>
>>
>> Mitar
>>
>> --
>> http://mitar.tnode.com/
>> https://twitter.com/mitar_m
>>
>>



--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Received on Monday, 2 December 2013 20:03:26 UTC