- From: Mitar <mmitar@gmail.com>
- Date: Mon, 2 Dec 2013 11:48:13 -0800
- To: Mounir Lamouri <mounir@lamouri.fr>
- Cc: public-webapps@w3.org
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 19:48:40 UTC