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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 10 May 2012 15:19:17 -0700
Message-ID: <CA+c2ei8MmdPS1QHHybSEx_jM2=vGVtDgaegsGa7_2rXdhwAxug@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: "Tran, Dzung D" <dzung.d.tran@intel.com>, Doug Turner <dougt@mozilla.com>, Anssi Kostiainen <anssi.kostiainen@nokia.com>, "public-device-apis@w3.org public-device-apis@w3.org" <public-device-apis@w3.org>
On Wed, May 9, 2012 at 2:16 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> On Wednesday, May 9, 2012 at 10:13 PM, Tran, Dzung D wrote:
>> > So, what I agreed with jonas about was a new event that only fired when there was a transition between near and far. device proximity for something that was more advanced. <insert this new event name here> for something really simple.
>>
>> > Thoughts?
>>
>> What I am afraid of is that browsers going to interpret far versus near differently on the same device. I rather to give the control to the programmer to interpret base on value, min, max.
>
> I'm afraid of the opposite thing. I more trust the people that are closer to the os (or directly interfacing with the hardware) to handle that.

I agree with Marcos here.

My concern is that with an API that exposes the raw data, we also end
up exposing the inconsistencies between different devices/browsers.
The web is notoriously bad at dealing with such inconsistencies.

Say that we only expose .min/.max/.value. This means that in order to
solve one of the most common use-cases of detecting that the user is
holding the device against his/her face the page will have to do
something like:

window.onproximitysensor = function(e) {
  if (e.min == e.value) {
    game.pause();
  }
  else {
    game.unpause();
  }
}

This will work great on low-precision hardware which only returns the
values 0cm or 5cm (I'm told this is common for proximity sensors
today).

However say that 2 years from now hardware vendors start putting in
higher precision proximity sensors which detect distance down to 1mm.
This means that the above code will only pause the game if the user
presses the phone against the sink right where the sensor is.

I know that I often either hold my phone against my ear, which means
that if the proximity sensor is located just above the speaker, the
proximity sensor might end up above my ear and 1-2 cm away from the
skin on my cranium.

So the above code would suddenly start to fail since e.value would be
1.5 and e.min would be 0. This leaves the browser vendor with the
choice of:

1. Expose high precision data and make websites fail to detect that
the user is holding the device against the head.
2. Not expose high precision data.
3. Add a "proximity2sensor" event which contains the high precision data.

None of these solutions are good.

We can certainly evangelize that pages write code like

window.onproximitysensor = function(e) {
  if (e.min == e.value || e.value < 2) {
    game.pause();
  }
  else {
    game.unpause();
  }
}

but evangelizing has traditionally not been very effective.

This is why I think we should expose simple "near"/"far" data,
preferrably through a separate event. I would also add a warning to
the "proximitysensor" event in the specification saying that different
devices will have different .min/.max values as well as different
resolution and if authors want to just detect "near"/"far" the other
event.

/ Jonas
Received on Thursday, 10 May 2012 22:20:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 10 May 2012 22:20:18 GMT