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

[Nils Dagsson Moskopp]

David Young  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  element or something similar as I understand.

I think mixing of text and meta-text often creates problems.


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann

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

[David Young]

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

[Nils Dagsson Moskopp]

Mitar  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

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

[Mitar]

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  wrote:
> On Wed, 29 Oct 2014, Peter Kasting wrote:
>> On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson  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

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

[Ian Hickson]

On Wed, 29 Oct 2014, Peter Kasting wrote:
> On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson  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.   `._.-(,_..'--(,_..'`-.;.'

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

[Robert O'Callahan]

On Thu, Oct 30, 2014 at 9:15 AM, Peter Kasting  wrote:

> 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.  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

[Peter Kasting]

On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson  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.  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

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'