Re: Browser search API

Hi!

OK. You are maybe right, it would be easier just to get an event when
user invokes a search (through key combination or menu or whatever)
and then leave to webpage to deal with that. Probably it is possible
to reimplement search with combination of ranges and extraction of
text on the page.

So OK, how can one proceed to get such event standardized. ;-)


Mitar

On Thu, Dec 5, 2013 at 7:31 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On Thu, Dec 5, 2013, at 2:08, Mitar wrote:
>> 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 think styling the search highlights, if not already doable, could be
> nice.
>
> Though, my feeling is that such an API might try to support too many UC
> and at some point one of them will be styling the search field. I think
> allowing the content to take full control of the search in page might be
> the best solution for the content and the UA: simple and efficient. It
> might be a lot of work to re-implement a search UI but libraries could
> help with that if needed (we will agree that pages that try to imitate
> the search field are not simple pages usually).
>
> --
> Mounir



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

Received on Thursday, 5 December 2013 21:39:14 UTC