W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2010

[whatwg] input type="location" proposals

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 15 Nov 2010 22:22:48 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1011152148110.26618@ps20323.dreamhostps.com>
On Tue, 10 Aug 2010, Diogo Resende wrote:
> On Mon, 2010-08-09 at 23:45 +0000, Ian Hickson wrote:
> > On Fri, 18 Jun 2010, Eitan Adler wrote:
> > >
> > > Two separate use cases
> > >
> > > 1) For entry of locations into something like Google Maps or 
> > > MapQuest. In this case the form should look as it does now (a text 
> > > box) but browsers would be able to assist you in entering locations 
> > > like it can for for emails.
> > >
> > > 2) For entry of Lat/Long coordinates which can be entered either 
> > > manually or with some kind of map like interface.
> > > 
> > > These are two separate proposals and I both could co-exist one as 
> > > type="location" and the other as type="gps"
> > 
> > Could you give some examples of sites that would use this, and 
> > examples of how they're working around the lack of this feature 
> > currently?
> 
> Any CRM with clients/suppliers/partners/people might want to define a 
> GPS location for a building/office/destination. Currently they usually 
> use a text input.

Do you have any examples? I looked around but couldn't find any. 
Everything I saw either accepted much more than just lat/long coordinates 
(e.g. Google Maps-like UIs) or used a drop-down <select> (to pick the 
building from a known list). Maybe I'm misunderstanding the use case.


> > On Sun, 20 Jun 2010, Eitan Adler wrote:
> > >
> > > For type="gps" I was thinking something like the following:
> > >
> > > 1) type="gps" results in a (double?) text box which takes a latitude
> > > and a longitude
> > >
> > > 2a) there is some css option that tells the text box to act like a map instead.
> > >
> > > 2b) If the css option is on there is also some method of requesting a 
> > > "map source" this source could be any existing map provider
> > > 
> > > Then again now that I think about it some more I don't see this working 
> > > out too well.
> > 
> > Does this solve a problem that two type=number controls wouldn't solve?
> 
> type=url and type=email are here for what? We could all use type=text
> for everything.

type=url and type=email solve the client-side syntax checking problem; in 
both cases, the pattern="" attribute wouldn't be sufficient.


> > On Fri, 25 Jun 2010, Ashley Sheridan wrote:
> > > 
> > > I think it's quite a fringe case. What about things that are more 
> > > used:
> > > 
> > > * type=number - a browser could aid input with some sort of spinner
> > >
> > > * type=price - a browser could use the locale to select a monetary 
> > > format, or at least display the amount in the locale format 
> > > specified by the document itself
> > > 
> > > These are just a couple that I think would potentially be more 
> > > useful than type=location, as I see their use quite a lot. The price 
> > > one is probably more reserved to CMS's and auction sites, but these 
> > > are fairly common enough in use I feel. Number could be used for a 
> > > whole plethora of cases, such as a quantity amount in a shopping 
> > > cart, an age field in a form, or anything else where you might need 
> > > a number that wouldn't necessarily be sensible to use a type=range 
> > > for.
> > 
> > Well we have type=number. I don't know that type=price would be _that_ 
> > useful; mostly prices are output, not input.
> 
> An invoice app would want price input for products or for specific 
> invoice adjustments.

But wouldn't type=number handle that case already?

We can in the future add a "format" attribute to let you specify where the 
currency symbol goes and so on, e.g. <input type=number value=1.99 
format="$%06.2f"> to get output like "$002.99" or format="%.3f CRED" to 
get output like "2.990 CRED".


On Tue, 10 Aug 2010, Diogo Resende wrote:
> Tab wrote:
> > Does a type=location offer any similar benefits over a pair of 
> > type=number inputs?
> 
> Yes, of course. Instead of a numeric keyboard (I never saw one on my 
> iphone), I could just point my current location, or select a location 
> nearby using a map or so.

In practice, maps are a really complicated thing to offer. I think it 
might be best for now to leave this up to the Bing Maps Platform, the 
Google Maps API, and so forth, than to require that browser vendors become 
experts in mapping UI.


On Tue, 10 Aug 2010, Tab Atkins Jr. wrote:
> 
> I do like the idea of being able to automatically input your current 
> location (geolocation without having to touch javascript!).

At this point it's probably best to see how the API is used before we add 
declarative alternatives. In particular, I've never seen anyone use this 
API to prime a form control; normally it's all about locating spots on 
maps and stuff like that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 15 November 2010 14:22:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:28 UTC