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 ? > > 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. -- Mounir
Re: in-page search, was Re: New manifest spec - ready for FPWD?
On Wednesday, December 4, 2013 at 9:17 AM, 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). > * 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 ? > > 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”). > Tracked by: https://github.com/w3c/manifest/issues/90
in-page search, was Re: New manifest spec - ready for FPWD?
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). * 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 ? 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”). -- Marcos Caceres
