- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 28 Oct 2014 17:59:36 +0000 (UTC)
- To: Mitar <mmitar@gmail.com>
- Cc: whatwg@whatwg.org
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 28 October 2014 18:00:06 UTC