W3C home > Mailing lists > Public > public-device-apis@w3.org > May 2012

Re: [proximity] extensions to navigator object

From: Doug Turner <dougt@mozilla.com>
Date: Sun, 20 May 2012 11:11:54 -0700 (PDT)
To: Marcos Caceres <w3c@marcosc.com>
Cc: public-device-apis@w3.org
Message-ID: <497343805.1329454.1337537514535.JavaMail.root@mozilla.com>
Hi Marcos,

I am confused.  What spec are you referencing?

The two specs that I am following are:

http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html
http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/userproximity.html


I think many of these issues you bought up were issues that we already discussed.


These two specs met your last 5 issues.


----- Original Message -----
From: "Marcos Caceres" <w3c@marcosc.com>
To: public-device-apis@w3.org
Sent: Sunday, May 20, 2012 4:14:21 AM
Subject: [proximity] extensions to navigator object

Hi,
I think the following extension to the Navigator interface might not be 
ideal:

partial interface Navigator {
readonly attribute DOMString proximitystate;
[TreatNonCallableAsNull]
attribute Function? onproximitystatechange;
};

1. Firstly, it does not follow the convention already established by 
Geolocation (and Battery API!): which uses an attribute that namespaces 
the API properly through an object.

2. Secondly, the interface above pollutes the Navigator object and sets 
a bad precedence for future sensors that might have multiple attributes 
(and would cause people to ask why the convention used with Battery and 
Geolocation were not followed). Other sensor might introduce even more 
attributes and handler types, which would make Navigator a real mess to 
look at. With correct namespacing, we cut down on the clutter by at 
least 50%.

3. Thirdly, it makes the interface slightly more annoying to use, 
because you need to log around "window.navigator.<sensornameProperty>" 
everywhere in your code.

4. Fourthly, "onproximitystatechange" is just way too long IMO.

I propose the following instead:

partial interface Navigator {
readonly attribute DeviceProximity proximity;
};

interface DeviceProximity : EventTarget {
readonly attribute Boolean near;
[TreatNonCallableAsNull]
attribute ProximityChange? onchange;
};
calllback ProximityChange = void(DeviceProximityEvent e)

And the event we listen for is just "change" instead of the really long 
"proximitystatechange".

Then, JS code looks like this:

if(navigator.deviceProximity){
var sensor = navigator.deviceProximity;
if(sensor.near){
//do awesome stuff….
}
sensor.onchange = function(e){
//oh yeah, I can handle that!
}
sensor.addEventListerner("change", function(e){ … } )
}

So, the above issues are addressed as follows:

1. We follow Geolocation's and Battery's lead by having a real object 
for proximity.
2. We reduce polluting Navigator with more stuff than we need to.
3. We make the interface easier to alias (and keep all its bits together).
4. We reduce "proximitystatechange" to just "change" (which follows 
conventions already used in HTML, like 'load', 'click', etc.).
5. We get an overall simpler, hopefully more friendly, API.

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au
Received on Sunday, 20 May 2012 18:12:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 20 May 2012 18:12:27 GMT