- From: Mitar <mmitar@gmail.com>
- Date: Sun, 23 Feb 2014 00:52:07 -0800
- To: whatwg@whatwg.org
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
Received on Sunday, 23 February 2014 08:52:33 UTC