- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Wed, 04 Dec 2013 22:38:19 +1100
- To: Marcos Caceres <w3c@marcosc.com>, Charles McCathie Nevile <chaals@yandex-team.ru>
- Cc: Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>, Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>, "Kostiainen, Anssi" <anssi.kostiainen@intel.com>, Web and Mobile IG <public-web-mobile@w3.org>
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. -- Mounir
Received on Wednesday, 4 December 2013 11:38:52 UTC