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

Re: [sensors] Device Proximity (was: Device light and proximity sensor)

From: Marcos Caceres <w3c@marcosc.com>
Date: Wed, 9 May 2012 21:32:21 +0100
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Cc: "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <31F8272A142F4514956C83BC45AFB902@marcosc.com>
Hi Anssi,  
Nice work on the spec… some comments…  

On Wednesday, May 9, 2012 at 1:15 PM, Anssi Kostiainen wrote:

> [2] http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

Maybe reword the abstract to:

"This specification defines a means to receive events that correspond to a proximity sensor detecting the presence of a physical object."

Reliance on HTML5's definition of "Function" as a type might be risky. Please see proposal 2 here:     

IMO, this is too precise: "The current proximity is the distance between the hosting device and the nearby object, in centimeters."  

I fear the above is confusing proximity with a distance sensor. If I understand correctly, proximity sensors don't detect distance, but changes in (electro/magnetic) radiation within some distance (which may correspond to the distance of an object to the sensor in a given range). So, I don't think - but I don't honestly know - that it is realistic to predict what the distance in proximity is with a proximity sensor, or if many sensor even support that! - it is only really possible to know just that some object is "far" or "near" based on detecting the strength of radiation bouncing off the target object. If the object is not uniform, or deflects radiation away from the sensor, then the reading will not be accurate (but enough to trigger a threshold!)… think of a stealth bomber deflecting radar :)    

Do the other values (min, max, value) really matter for the use case?: "is object (face, table, thing) close to the phone?" My understanding is that most of these proximity sensors only have a range of about 5cm, so there is little or no practical application/use case for them apart from "on/off" behavior. If I am wrong about the use cases, can someone explain some others? And if there is no other use case apart from knowing if a sensor is "far" or "near", we might be able to do without min, max, value, which could greatly simplify things: you only need a proximityChangedEvent fired when a threshold is reached to know "far" or "near".  

So, if we are talking about the same sensor (the one that switches the screen off when you put the phone close to your face), then it might be good to amend the interface to tell you if it is near or far (as some sensors only report a binary near or far measurement). Something like:

readonly attribute boolean near;  


enum Proximity { "far", "near" };
readonly attribute Proximity proximity;   

Lastly, there does not currently appear to be any normative text saying that the UA must only turn on the proximity sensor upon event registration (would suck if the sensor came on every time I open the browser, as it would just eat battery). Also, it might be good to have a bit of text describing what happens when you switch tabs in a browser (i.e., stop the sensor)… common sense stuff, I know… :)  


Marcos Caceres
Received on Wednesday, 9 May 2012 20:32:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC