Re: [geolocation-sensor] Mark as Discontinued Draft and continue in Geolocation API (#60)

While there is developer demand for the use cases outlined in the "experimental" Geolocation Sensor specification (see how unpleasant when people add "labels" to specs), it is crucial to address some misconceptions about the feasibility and practicality of retrofitting new features into what you deceptively call the "legacy" Geolocation API.

First, the assumption that retrofitting these sought-after features into the Geolocation API has repeatedly proven incorrect. Unlike the "experimental" Geolocation Sensor, the Geolocation specification has been consistently well-maintained and is interoperably implemented by all major browser vendors. This robust maintenance contradicts the notion of it being "legacy" and underscores its viability for evolution.

Second, labeling the Geolocation specification as "legacy" is misguided and deceptive. It is an actively maintained specification with widespread support across all major engines. The validity of the use cases is not in question; however, it is misleading to dismiss the current Geolocation specification when it continues to serve developers and users effectively. Put bluntly: there is nothing "legacy" about it, and, despite baseless claims to the contrary, nothing preventing it from being evolved. 

Moreover, wide review feedback from Mozilla and WebKit has already indicated a lack of support for the "experimental" Geolocation Sensor specification. This feedback led browser vendors to move the actual Geolocation specification from the DAS working group to make it a joint deliverable with WebApps, allowing browser vendors and a wider set of stakeholders than would be possible in DAS to collaborate on it and steer it inclusively. The lack of participation from other implementers in the DAS working group further diminishes the potential for significant input or adoption of the experimental and unimplemented Geolocation Sensor spec. Implementers have consistently advised the DAS group to collaborate with WebApps to improve the existing Geolocation standard rather than pursuing a separate, unsupported and duplicative .

It's also important to consider the W3C TAG's guidance on adding new capabilities, which emphasizes integrating new features with existing functionalities and considering existing usage before introducing new specifications. The current approach with the "experimental" Geolocation Sensor specification appears to violate this principle by not adequately integrating with the well-established and actively maintained Geolocation API (see [W3C TAG Design Principles](https://w3ctag.github.io/design-principles/#new-features)).

Therefore, it is essential to set aside any pettiness and focus on advancing a single specification that is already widely implemented and supported. Claims that the Geolocation specification cannot evolve have been demonstrably and repeatedly shown to be unfounded and without merit.

In conclusion, the W3C community should prioritize practical, well-supported solutions that address developer and user needs without unnecessary fragmentation. By working together on the existing Geolocation standard, we can ensure a smoother, more effective path forward for all stakeholders.


-- 
GitHub Notification of comment by marcoscaceres
Please view or discuss this issue at https://github.com/w3c/geolocation-sensor/issues/60#issuecomment-2128398684 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 24 May 2024 02:51:25 UTC