W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2014

Re: Geolocation Errata and Updated Working Draft

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 15 Jul 2014 11:43:06 +0200
Message-ID: <1405417386.3542.108.camel@cumulustier>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: Michael van Ouwerkerk <mvanouwerkerk@google.com>, "Mandyam, Giridhar" <mandyam@quicinc.com>, public-geolocation <public-geolocation@w3.org>
Le mardi 15 juillet 2014 à 19:10 +1000, Mounir Lamouri a écrit :
> WebIDL says:
> """
> The [NoInterfaceObject] extended attribute should not be used on
> interfaces that are not solely used as supplemental interfaces, unless
> there are clear Web compatibility reasons for doing so. Specification
> authors who wish to use this feature are strongly advised to discuss
> this on the public-script-coord@w3.org mailing list before proceeding.
> """
> http://heycam.github.io/webidl/#NoInterfaceObject
> 
> I guess Geolocation is violating this, right?

This was at least partially brought up on public-script-coord:
        The other thing that came up was that generally [NoInterfaceObject] should
        be removed unless there is a good reason to have it. For example "The
        Geolocation interface should not have [NoInterfaceObject]."
        
        This part makes less sense to me. What are the reasons for exposing an
        object like this in the global namespace? It seems to have little use, but
        perhaps for feature detection
http://lists.w3.org/Archives/Public/public-script-coord/2014JanMar/0158.html

But the ensuing thread was mostly about "partial" vs "implements", not
much about whether the [NoInterfaceObject] advice applied to the Geo
interfaces.

My perspective is that Position and Coordinates would be dictionaries
(and thus, not exposed in the global namespace) if dictionaries were
allowed as attribute values; but I'm happy to bring this back to
public-script-coord if you think that would be useful.

>  Obviously, if those
> interfaces had to be exposed, you would want to prefix them with
> Geolocation (ie. GeolocationPosition, GeolocationCoordinates,
> GeolocationPositionError).

Makes sense, indeed. I guess I would be interested in perspectives from
implementors point of views.

Dom
Received on Tuesday, 15 July 2014 09:43:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:08 UTC