Summary

  • W3C 于 2008 年 12 月 22 日发布 Geolocation API 首份公开草案，给网页脚本一条请求设备位置的共同路径，并未规定必须由 GPS 或某一种网络信号给出答案。
  • 2013 年 10 月 24 日的推荐标准明确了单次定位、持续更新、精度、缓存与用户明确许可；2016 年第二版对 2013 年文本作了勘误修订。

游客站在路口，手里的纸地图已经转过两圈，河流仍然不肯站到她想象的那一边。网页地图可以直接告诉她最近的电车站在哪里。问题是：它得先知道她在哪里。一个坐标对于找路很有用，对于别的事情也一样有用。这使“给我位置”从普通数据请求变成了需要有人站在柜台前问清楚的动作。

W3C 2008 年 12 月 22 日首份公开草案提出的正是这个柜台。草案让网页脚本通过浏览器取得承载设备的地理位置，举例包括游客在陌生城市寻找附近景点、在地图上标出自身位置。网页拿到的核心信息是经纬度与精度，而不是某个品牌的定位芯片说明书。不同设备可以用各自能用的办法回答同一个问题。

草案列出的来源相当杂：GPS、IP 地址、Wi-Fi、蓝牙、蜂窝网络信号都可能参与估算。接口不替设备指定“唯一正统”的测量方法。对网站而言，这种抽象免去了逐个识别硬件与网络的工作；对读者而言，地图上的蓝点也不该被误读成钉在某一块地砖上的绝对坐标。精度信息本就是答案的一部分，意味着周围还有一圈可能的位置。

请求还有不同节奏。getCurrentPosition()问一次，适合把地图移到附近。watchPosition()接收位置变化，适合跟着路程更新方向；clearWatch()结束跟随。找一家咖啡馆和追着游客走过整座城，不是同一件任务。2009 年 7 月 7 日的最后征求意见草案继续打磨接口与隐私问题。W3C 的出版历史显示，从 2008 年首次公开到 2013 年定稿，中间经历了多年讨论。

2013 年 10 月 24 日的正式推荐标准把交付位置的规则说得很清楚：浏览器不得在没有用户明确许可时把位置发给网站。普通浏览器的许可界面应写出请求方的主机名；跨会话保留的许可必须能够撤销。用户拒绝时，应用收到PERMISSION_DENIED错误。地图可以礼貌发问，浏览器不能把游客的回答当作默认赠品。

网站提出问题时也能表达“多新、多准、等多久”。maximumAge表示可接受多旧的缓存位置；timeout限制取得位置的等待；enableHighAccuracy是希望得到更高精度的提示。高精度可能花更多时间或电力，设备也未必能给出更好的结果。尤其有趣的是，征求用户许可的时间不算进定位超时。一个急着画蓝点的网页，不能因为人多读了几秒问题就宣称定位失败。

返回值带有以米计的accuracy。2013 年文本说，精度数值应对应约 95% 的置信水平。与其在屏幕上画一枚号称绝对准确的大头针，不如让人看到定位有一个范围。标准也明确不保证接口返回设备的实际位置。地图能帮人找到街区，不代表它知道游客现在踩着第几块砖。把估算说成目击，只会把方向带偏。

把坐标交给网站并不等于把此后所有用途一起批准。2013 年文本要求接收方在必要时才请求位置，按提供位置时说明的任务使用，任务结束后处理掉数据，除非用户明确允许保留；未经明确许可也不该再转交。找最近电车站和保存永久行程档案，可能以同一对经纬度开始，却是两份不同的约定。浏览器守的是第一次交付；拿到坐标后的选择归网站负责。

2016 年的第二版推荐标准将 2013 年版本的勘误纳入正文，并未凭空发明另一套地图。由此留下的分工仍然清楚：设备与浏览器决定如何估算，用户决定是否交出，应用决定用一次、持续跟踪还是接受较旧的位置。标准统一的是问法，没有替所有网站写好业务目的。

这就是地理定位接口的历史意义。网页开始能用同一种语法向现实街道发问，同时不能因为会发问就理所当然地得到答复。游客或许还是把纸地图拿反了。至少浏览器学会在替她翻正之前先问一句。