Re: skeleton Geolocation API

On Fri, Jun 27, 2008 at 6:24 PM, Erik Wilde <dret@berkeley.edu> wrote:
> because this is what i am interested in, i think it is not a good idea to
> have a location API that only focuses on spatial data. if the UA makes a
> "location fix", the user should have the option to say "at home", and there
> is not spatial information for that. i believe that the future of the mobile
> web will depend of this kind of more human-centered application design.
>
> on the other hand, i am sure that are many web app developers who simply
> want to get their hands on that nice GPS data and that's all they want from
> an API. which is why i think it's important to have use cases and
> requirements, and to use this as a starting point to develop a location
> concept.

The main use cases that caused Google to propose this spec are (and
have been) listed in the draft (near the bottom):

http://dev.w3.org/geo/api/spec-source.html

They all revolve around having web apps be able to discover the user's
lat/lon. The only use case I've hear suggested for the location URI
idea is that users should be able to manually specify their location.

This is not a use case I expect we'd be interested in addressing in
Gears. It is already well-solved in web applications. It's actually
better than location URIs, since users can enter their location in
natural language.

The only thing I can see that moving it into the UA would buy is
having it remembered across apps. If that is the goal, I'd suggest a
far simpler solution: just standardize on a name for the input box to
type location information into. Most browsers these days support form
autofill and that concept can be extended to autofill location as well
(this probably already occurs with fields called "address" for
example). At the very most, just define a new <input type="location">
that renders as a textbox with an autofill dropdown containing
previously entered values. No new URI scheme required!

- a

Received on Sunday, 29 June 2008 20:27:22 UTC