Re: Browser search API

Hi!

On Wed, Dec 4, 2013 at 6:25 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> So, it's not clear to me why the inability to search in unloaded pages
> will be fixed by intercepting the system find in page unless let the UA
> doing the search but then it is no longer clear why you want to know
> that a search is actually happening. (This said, if the text is not
> loaded, it is not clear how the UA would be more able to search unloaded
> content.)

My idea is that when page intercepts a search it can search for it in
internal (not rendered) structure, or make a request to the server,
and get information where does this search match in the document and
then render only those parts so that UA can find it.

But I agree, that requires some more changes. For example, currently
it is not really possible to style how found elements are highlighted.
And it is not possible for page to say to UA to retry searching
because the document has modified. I believe that for full solution
this parts should be implemented as well. Because they would be useful
for other cases. So:

- styling of how matched text looks, and how highlighted text looks
(when user selects to highlight all matches in UAs that support that)
- telling to the webapp 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

I agree that another approach would be to be able for webapp to take
over search completely, but I am trying to imagine a less "all or
nothing" approach. But, I do not really care about any of those
options if there will be some option available.

> I agree with the native UI issue but wouldn't the page still need a way
> to tell the UA that it wants to perform the search itself?

So in the idea I envisioned (which might not be the best and it comes
mostly from what is currently available) is that webapp does not try
to perform the search itself, but it prepares content so that UA finds
relevant parts.

For example, webapp could render low-fidelity text for whole document
so that approximate positions are successfully found in whole
document, but then render high-fidelity contet only for displayed
viewport region. The issue with this approach currently is that when
you render high-fidelity content browser does not retry the search.
And that you do not know should you render this high-fidelity text
content because you do not know if search is in progress.

> In that case, the idiomatic way to do that is to cancel an event.

This is what people currently do for when they cancel ctrl-f key
combination. But you can still invoke original search interface
through menu.

The issue with this approach (besides that it does not work in all
cases) is that user might want not to search only the document
content, but other things around it as well. For example, in Google
Docs, you might want to search over comments content. And not just
document content.

> But I feel like I am missing something here. How do people use window.getSelection()?

window.getSelection() is not really part of any search API. It seems
some browsers reuse text selection code path and this is why it gets
exposed through it. But this is not standardized and is more meant
that you use it when you want to know what has been selected by the
user, not searched.


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Received on Wednesday, 4 December 2013 15:08:49 UTC