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

Re: Light sensor - strawman proposal

From: Doug Turner <dougt@mozilla.com>
Date: Thu, 12 Jul 2012 09:17:34 -0700 (PDT)
To: Marcos Caceres <marcosscaceres@gmail.com>
Cc: BALAJI NERELLA VENKATARAMANA <nv.balaji@samsung.com>, public-device-apis@w3.org
Message-ID: <1027887394.1160063.1342109854553.JavaMail.root@mozilla.com>

Please see:


We implemented this in Gecko.

----- Original Message -----
From: "Marcos Caceres" <marcosscaceres@gmail.com>
To: public-device-apis@w3.org
Cc: "BALAJI NERELLA VENKATARAMANA" <nv.balaji@samsung.com>
Sent: Thursday, July 12, 2012 8:24:28 AM
Subject: Light sensor - strawman proposal

Balaji and I were wondering if the WG would be interested in standardising access to a device's the light sensor (if it's in scope for the WG … perhaps under the "generic sensor access" part of the charter)?  

<use-case rant>   
Light aware UI use cases are fairly common (and most modern phones, tablets, and laptops include a light sensor). For example, changing contrast of content based on how much light is hitting the phone can be really helpful when looking at content in bright outdoors or dark environments (independent of the phone's own attempts to automatically adjust the brightness, as many phones do today). My car's GPS supports such a feature, for example, where it completely inverts the colours on the screen for "night mode".  

Furthermore, making sure content is be legible while a user is in full sunlight is becoming an increasingly common practice with developers: unfortunately, this currently results in UIs that are ultra bright and "contrasty" by default, instead of having UIs and content more dynamically suited for the lighting condition under which the app is being used.  

Note: we are aware that actually having control over the brightness from within an app through an API would be extremely helpful here also - but we are leaving that out of scope for now as that probably more in scope of the System Applications WG. Use case for that: adjusting the brightness of the phone to create more contrast so that a QR code can be more easily scanned in full sunlight (the iPhone App "EventBrite" does this, for instance).   
</use-case rant>

Here is a straw man proposal for discussion:   

partial interface Navigator {
readonly attribute LightSensor lightSensor;

interface LightSensor : EventTarget {
readonly attribute double? max; //max sensor range
readonly attribute double? lux; //last known value
attribute EventHandler onchange;  

interface LightChangeEvent : Event {
readonly attribute double newLux;
readonly attribute double oldLux;


And in action:
navigator.lightSensor.addEventListener("change", function(e){
if(e.newLux > 32000){
//full sun light! lets make the text a little bigger and darker

//generic handler   
navigator.lightSensor.onchange = function(e){ … };

If this is something the group would want to standardise, Balaji and I would be happy to volunteer to edit the spec and create a test suite.  

Kind regards,

Marcos Caceres
Received on Thursday, 12 July 2012 16:18:06 UTC

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