[whatwg] Why type="location" was removed

[Ian Hickson]

Some of you may have noticed that type="location" was removed between the
last version that I published on my personal site, and the draft currently
hosted by whatwg.org.

I have attached the comments that led to this removal. I am not qualified
to write new text to address these concerns, but if someone can write text
that solves these problems, I would be happy to reintroduce the feature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

-------- Forwarded text follows --------

location:

> specified as two floating point numbers (an optional negative sign,
> one or more decimal digits, a decimal point, and six more decimal
> digits)

with the above spec for numbers, you could say
 (a plain number with a six-digit fractional part).
At least you used digit this time, not integer ;^)

> The value specifies latitude and longitude, in that order, as
> decimal degrees.  The latitude represents the location north and
> south of the equator as a positive or negative real number,
> respectively, in the range -90.000000 <= &theta; <= 90.000000.  The
> longitude represents the location east and west of the prime
> meridian as a positive or negative real number, respectively, in the
> range -180.000000 < &phi; <= 180.000000.  The longitude and latitude
> values must be specified as decimal degrees and ...

there ain't no such thing as a decimal degree, nor any need to repeat.
You mean the values are specified in decimal and measured in degrees,
but we already said numbers were interpreted in decimal anyway.  But I
despise the wording you have used.

  The two plain numbers are angles, measured in degrees.  The first
  gives latitude, -90 <= &theta; <= 90, measured North from the
  equator; negative values are thus to the South.  The second number
  gives the longitude, -180 < &phi; <= 180, measured East from the
  prime meridian; negative values are thus to the West.

I would also argue that the range for longitude should run from -195
to +195 so that folk living between the international date line and
the prime meridian's opposite can encode a useful detail.

> ... and must be specified to six decimal places.  This allows for
> granularity within a meter of the geographical position.

... (down to about a ninth of a meter, about the size of my hand, in
     fact; and better for longitudes at any latitude but 0.000000) ...

Why is this desirable ?

If my form is asking the user to specify the location of the city
they're in, I don't care about (or want) a granularity better than a
few kilometers.  If the user doesn't have the next generation GPS,
they don't have information better than of order 10 metres.  If the
user is walking round town with a hand-held device, or sat on the bus
with a lap-top, it's just plain silly to give enough precision to
distinguish between my two hands while I'm typing the datum, and have
each of them move by a significant fraction of the granularity.  Hey,
why not throw in three more digits and be able to pin-point a
tardigrade ? (Which, incidentally, is an animal whose mass is less
than the Planck mass.)

Example: NASA have computers that know all about eclipses, so could
put up a form that I can ask to find out when is the next one I've any
chance of seeing.  I may be too lazy to fly to New Zealand, but if
I've got to go to the other end of the fjord to see it, I'm happy.  So
NASA's form only wants to know this to a rather coarse granularity.

Example: I'm in a new town, I've checked into my hotel, I want to know
where there's a good restaurant nearby.  I go to tourist information's
web-site, say where I am and ask for restaurants.  With any luck
they've got some selection criteria aside from location - I can say
"Ethnic-Type: Thai;q=1, Indian;q=.9, Chinese;q=.7" (or its equivalent)
and note how crucial price is to me.  If I want the nearest, I'll
specify my location fairly precisely; if I actually want a nice walk
before and after dinner, I'll specify it coarsely so the search
(optimising over the other constraints at the same time) spreads out
further.

I'd sooner see precision deployed here (and see also my notes, below,
on wanting precision to be able to require enough, as well as forbid
too much).

> Servers should ignore data following a second comma (in other words,
> the data is really a comma separated list, and currently only the
> first two fields are defined). This will allow for future extension
> of this field.

altitude ?
[Resists temptation to recommend this be measured in fathoms.]
name of planet ?

> Clients should only specify coordinates that are accurate to at
> least a few hundred meters.

Why ?  See above under city, movement, ignorance.

> offer a map-based control for coordinate selection

I'm in a boat on the sea.  I know my location roughly.
I'm walking in the hills; ditto.

The map-based control is exactly the thing that I want to use; but let
me judge how blurred to make my selection !

> User agents should not automatically send the user's location
> without the user's consent.

  Warning: submitting this form may empower the people who're after
  you to target their missiles more accurately.  Continue ?

... but seriously, the privacy concern here is another reason why I
*want* to be able to specify an imprecise location.