- From: David Young <dyoung@pobox.com>
- Date: Tue, 23 Jun 2015 11:36:01 -0500
- To: whatwg@lists.whatwg.org
On Mon, Jun 22, 2015 at 11:57:46PM -0700, Mitar wrote: > Hi! > > Followup to this proposal. So after more than half year browsers still > have issues searching in dynamic apps. Google Docs can still only > intercept ctrl-f, but for people who uses menu search then does not > work. It's funny you should mention this, because just last night I was cursing Wikipedia as I tried to search within a page on my iPhone. Wikipedia's default, outline view for mobile makes in-page search ineffective. One way to fix this is for "infinite scrolls" and other pages that load content "on demand" to provide methods for the client to ask the server to search/send the on-demand content. > On the other hand, sometimes it is useful to not allow search to be > intercepted. For example, I tend to use browser search for menu in > Google Docs to search over comments sidebar, while I use ctrl-f to > search the document content. But this cannot really be expected to be > clear to users or intuitive. A better integration of such apps with > browsers is necessary. I'm not sure I'm picturing the right scenario. It sounds like you want sometimes to limit your search to the comments sidebar, and sometimes to search the document. The search override in Docs is incomplete (it overrides the keychord, not the search method), and a happy side-effect is that initiating a search by different modes (menu, ctrl-f) searches different page content. Is that right? If the web platform provided "search within selection," that would be a consistent and learnable way for users to limit their searches. Dave -- David Young dyoung@pobox.com Urbana, IL (217) 721-9981
Received on Tuesday, 23 June 2015 16:36:30 UTC