[whatwg] New feature: better integration with browser find interface

[Mitar]

Hi!

I would like to present to WHATWG the issue of integration of browser
find interface with rich content web applications. Currently there is
no way a rich or dynamic content web application can improve user
experience when user is using browser's find interface to search or
navigate on the page. There is no standard defined for integration or
standard on how browser should implement find interface.

This open many issues and different web apps are trying to address the
issue in different (but unsatisfactory) ways. Some examples include:

Google Docs. If you open a long document in Google Docs not whole
document is rendered immediately so DOM does not contain whole
document. If you try to search using a keyboard shortcut, Google Docs
intercepts ctrl-f keystroke and opens its own find interface. But if
you invoke find through browser menu you get browser's original find
interface which does not really work and does not find anything on
page not yet rendered. The workaround of intercepting a ctrl-f
keystroke also has a side effect of not being nicely integrated with
user browser chrome and while it works it might prevent features to
which user is otherwise used to (for example, "highlight all" feature
in Google Chrome). Additionally, intercepting ctrl-f keystroke is not
something which works on mobile devices.

Mozilla pdf.js HTML5 PDF library and viewer
(http://mozilla.github.io/pdf.js/web/viewer.html). Same issue as
Google Docs. Rendering whole PDF would consume too much resources so
only pages visible to the user are added to DOM. Browser thus cannot
find content on pages not visible. Have same workaround of
intercepting a ctrl-f keystroke.

ACE code editor. Same story. Intercepts ctrl-f to be able to search in
the content of the editor with regex and other more powerful features.
ACE code editor is used in many other sites, like GitHub for editing
files on-site. Because ACE editor is often integrated into website
with other content intercepting ctrl-f does not necessary work
correctly: you would want to search both content outside the editor
and content inside the editor.

Overall I have identified the following issues:

- styling of how matched text looks, and how highlighted text looks
(when user selects to "highlight all" matches in UAs that support
that) - some browsers reuse selection style (Firefox), some browsers
have special style you cannot style with CSS (Chrome)
- telling to the web application that search is being in progress and
what is being searched for
- telling UA that it should retry the search because content has been
changed/rendered/modified

The last is important because for web application which dynamically
render the content, after search has already find matches on the page,
if content is changed, browsers do not retry the search. This is the
most evident with browsers which allow "highlight all" feature, like
Google Chrome.

I have opened initial discussion on the topic on public-webapps mailing list:

http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/thread.html#msg640

The discussion which followed contains some ideas how to address the
issues mentioned above. One simple proposal was to just trigger a
canceable event when search is invoked so that web application can
take over.

What others think?


Mitar

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