[whatwg] input type="location" proposals

[Tab Atkins Jr.]

On Tue, Aug 10, 2010 at 2:53 AM, Diogo Resende <dresende at thinkdigital.pt> wrote:
>> 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.

Those both offer validation, and in devices that can expose specialty
keyboards (such as phones), they can offer a slightly different
keyboard for entering data into those (one that makes :, /, and @
easier to type, for example).  Thus these are both more powerful than
type=text.

Does a type=location offer any similar benefits over a pair of
type=number inputs?


>> 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.

Once again, though, what benefit can you gain from type=price over
using type=number for this?  I don't recall ever seeing an app that
allowed you to enter a price in multiple currencies; I've only seen
apps that have several price inputs, one for each currency (this can't
be replaced by an <input type=price>, as it means something quite
different), and currency converters, which need more information than
the browser can provide to be useful in the first place.

~TJ