W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2015

Re: [whatwg] New feature: better integration with browser find interface

From: Mitar <mmitar@gmail.com>
Date: Mon, 22 Jun 2015 23:57:46 -0700
Message-ID: <CAKLmikNYmMmPfGL9hypdTC4oLWH+UGaQr6YhRE7k2ZazEU7VtA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg List <whatwg@whatwg.org>, Robert O'Callahan <robert@ocallahan.org>, Peter Kasting <pkasting@google.com>
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 <ian@hixie.ch> wrote:
> On Wed, 29 Oct 2014, Peter Kasting wrote:
>> On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson <ian@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 "find"s 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
Received on Tuesday, 23 June 2015 06:58:21 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:33 UTC