Re: [whatwg] New feature: better integration with browser find interface
David Young dyo...@pobox.com writes: 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. Infinite scroll is the halting problem outsourced to Layer Eight. As the user, you never know how much content will come, until it actually ends. This problem can not be solved – except for not using infinite scroll. 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. The “web platform” does not do that, browsers do that. The browser I use (conkeror) can already limit commands to specific elements or DOM nodes. For example, prefixing a “c” (copy) command with “* i” limits it to images, prefixing it with “* *” limits it to DOM nodes. The sidebar could be an aside element or something similar as I understand. I think mixing of text and meta-text often creates problems. Greetings, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New feature: better integration with browser find interface
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 dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] New feature: better integration with browser find interface
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. 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. Mitar On Thu, Oct 30, 2014 at 11:40 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 29 Oct 2014, Peter Kasting wrote: On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson i...@hixie.ch wrote: - 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. This is just a bug in the browsers. If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. How large? On Thu, 30 Oct 2014, Robert O'Callahan wrote: It seems possible to me: 1) You can do it lazily, during idle time (though some apps don't have any) 2) You can do it incrementally 3) You can start with the visible part of the page You can also use a rate-limitting and back-off strategy -- only update find every second or so at most, and if the user hasn't interacted with the page, do it even less often. There's no reason to do it every nanosecond as the page is modified. Having said that, it would be complex enough I don't know if it would ever be worth implementing. In its most basic implementation, where you only do it every few seconds and only if the user has interacted with the page recently, it seems relatively simple, especially if you don't bother with the incremental aspects. As someone who deals in large pages and searches in those pages a lot, I find the lack of dynamic find-in-page to be a regular nuissance, FWIW. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- http://mitar.tnode.com/ https://twitter.com/mitar_m
Re: [whatwg] New feature: better integration with browser find interface
Mitar mmi...@gmail.com writes: 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. 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. To speak to the contrary: I think that “better integration” is extremely harmful, as long as it violates user expectations. I use the keyboard a lot (my hands hurt when I browse with a mouse) and I absolutely hate it when websites intercept keypresses that the browser UI already uses. Some sites – e.g. GitHub – I can navigate only without JavaScript. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] New feature: better integration with browser find interface
On Wed, 29 Oct 2014, Peter Kasting wrote: On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson i...@hixie.ch wrote: - 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. This is just a bug in the browsers. If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. How large? On Thu, 30 Oct 2014, Robert O'Callahan wrote: It seems possible to me: 1) You can do it lazily, during idle time (though some apps don't have any) 2) You can do it incrementally 3) You can start with the visible part of the page You can also use a rate-limitting and back-off strategy -- only update find every second or so at most, and if the user hasn't interacted with the page, do it even less often. There's no reason to do it every nanosecond as the page is modified. Having said that, it would be complex enough I don't know if it would ever be worth implementing. In its most basic implementation, where you only do it every few seconds and only if the user has interacted with the page recently, it seems relatively simple, especially if you don't bother with the incremental aspects. As someone who deals in large pages and searches in those pages a lot, I find the lack of dynamic find-in-page to be a regular nuissance, FWIW. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] New feature: better integration with browser find interface
On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson i...@hixie.ch wrote: - 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. This is just a bug in the browsers. If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. Is there an implementation idea I'm missing for how browsers could fix this bug in a performant way? Otherwise I can't see us doing what it seems like you want. PK
Re: [whatwg] New feature: better integration with browser find interface
On Thu, Oct 30, 2014 at 9:15 AM, Peter Kasting pkast...@google.com wrote: If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. Is there an implementation idea I'm missing for how browsers could fix this bug in a performant way? Otherwise I can't see us doing what it seems like you want. It seems possible to me: 1) You can do it lazily, during idle time (though some apps don't have any) 2) You can do it incrementally 3) You can start with the visible part of the page Having said that, it would be complex enough I don't know if it would ever be worth implementing. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] New feature: better integration with browser find interface
On Sun, 23 Feb 2014, Mitar wrote: If you open a long document in Google Docs not whole document is rendered immediately so DOM does not contain whole document. 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. [...] Mozilla pdf.js HTML5 PDF library [...] 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. [...other similar use cases...] - 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) The various use cases you gave didn't seem to be derived from this need. How much of a need is this? - telling to the web application that search is being in progress and what is being searched for That does seem to be something that is necessary. I've filed a bug to track it: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27186 - 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. This is just a bug in the browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] New feature: better integration with browser find interface
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
