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:

> - 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       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 28 October 2014 18:00:06 UTC