Re: in-page search, was Re: New manifest spec - ready for FPWD?

On Wed, Dec 4, 2013, at 10:17, Marcos Caceres wrote:
> On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
> > Yes. In-apge Search is something that might also be useful within an app -
> > especially if you can find out it is happening and respond to it
> > intelligently if the app hides things by default.
> The ability to do this is useful, but I wonder if it’s kinda context
> specific. Just some very lose thoughts off the top off my head:
> * no (mobile) native application platform let’s you do this, AFAIK (just
> a fact - not a judgment or a good/bad thing).
> * hardly any mobile browser currently supports this (which sucks, IMO).  

This is supported by Chrome and Firefox on Android I believe.

> * searching in page is not something that is usually shown by default:
> you have to press ctrl-f on most browsers to bring up in-page search.  
> * apps might only want specific runs of text (a group of elements) to be
> searchable… maybe this is a HTML feature <section searchable>?  
> So I guess the option, if we were to support this, would be something
> like “searchable”. Then the UA can work out the best way to present show
> the search box (e.g., long press -> “Search on this screen”).

As mentioned in the bug, I believe it is quite too early to ask
ourselves how to handle that. I think we should focus on the basic
features that would have a wide adoption and keep that kind of features
for later. This is the kind of problems that might or might not exist
later depending on UA UI and developers feedback.


Received on Wednesday, 4 December 2013 11:38:46 UTC