W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2011

Re: List for static properties

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 07 Apr 2011 10:54:58 +0200
To: Suresh Chitturi <schitturi@rim.com>
Cc: public-device-apis@w3.org
Message-ID: <1302166498.6838.176.camel@altostratustier>
Le mercredi 06 avril 2011 à 16:49 -0500, Suresh Chitturi a écrit :
> Here is a list of fairly static and simple properties that would be
> useful to expose (read-only) through device API.
> Output:
> -          Display resolution/size (physical screen width/height, full
> screen resolution, rendering area)

I think most of those can already be discovered using existing DOM
properties, see e.g. http://www.quirksmode.org/mobile/viewports2.html

> Input: 
> -          Touch, non-touch, dual

I wonder if touch-enabled browsers can be detected by checking if the
"ontouchstart" attribute is defined e.g. on the HTML element?

I'm not sure what you mean by "dual" (or what use case detecting such a
state would support).

> -          Keyboard type (Qwerty key board, others)

Is the intent to be able to bind key events based on their physical
locations? Do you have a use case in mind? 
I don't think there is any spec that covers this at the moment.

> Media
> -          Available Audio/Speech codecs
> -          Available Video codecs

Supposedly, this would be useful both for encoding and decoding
capabilities. I could see this being useful in quite a few contexts,

> Camera
> -          Front, back, pixel resolution
Do you have any specific use case in mind for these data?

> Storage
> -          Total capacity, available 

There has been discussions around Quota management for the filesystems
API, which I think would be the right way to approach this.

> The idea would be come up with a vocabulary for these properties and
> define two methods:
> boolean hasProperty(String property);
> String getProperty(String)

This would be one solution, but I think a proposal that would better
integrate with existing objects and interfaces would likely get more
traction. I think we should look carefully at each proposed dataset, see
how useful/important it is to give access to it, and refrain from using
a generic framework unless/until it clearly proves to be the best

Received on Thursday, 7 April 2011 08:55:18 UTC

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