The Hardware Pixel Community Group Launched

With your support, the The Hardware Pixel Community Group has been launched:
  http://www.w3.org/community/hardware-pixels/

This group was originally proposed on 2014-12-05
by Joseph Orbegoso Pea. The following people supported its
creation: 
      Joseph Orbegoso Pea
      Micael Batista
      Jonathan Jeon
      Oleg Yarin
      Gadi Cohen
  
To join the group, please use:
 http://www.w3.org/community/hardware-pixels/join

Please note that supporting a group is different from joining
a group. Supporters must also enroll if they wish to participate.

--------------------
A group for people who love pixels!


This group is in support of exposing device pixel densities to web
developers and letting web developers have the ability to use 'hardware
pixels' instead of 'CSS pixels' on demand. Native developers have this
affordance, why can't we? Hardware pixels! We want hardware pixels!


## What we want ##


We want metrics! The hardware pixel density of a screen can live in the
window.screen object as window.screen.pixelDensity, for example. The
value would be the average of the vertical pixel density and the
horizontal pixel density of the screen (in hardware pixels per unit). 
Vertical and horizontal pixel densities of the screen can be exposed in
window.screen.verticalPixelDensity and
window.screen.horizontalPixelDensity. Yes, the vertical and horizontal
values don't always have a ratio of 1 across devices. Pixel Aspect
Ratios are important for developers and designers that truly care about
device-independence.


## How can it be done? ##


Easy. The EDID data in modern screens tells us the width and height of a
display in millimeters, the native resolution of the screen, and other
interesting information. This info allows us to calculate a screen's
hardware pixel density in pixels per millimeter with floating point
precision. Exposing these values in window.screen is even more trivial.


## Why do we want these values? ##


In this modern day, developers are moving towards device-independent
development more than ever before. By exposing physical characteristics
of a screen (when supported by the screen (just like how OpenGL is
exposed through WebGL when supported by a device)) web developers will
be able to make device-independent decisions on their development
process. 


Currently, the lack of these metrics means that a web app can only look
*almost* the same across devices, but not necessarily *exactly* as
intended. We're engineers; *almost* is not enough. For example, suppose
I want to make a push menu that is *always* 1 physical inch wide. This
is currently not possible because inches in the web are "CSS inches",
not physical inches. CSS units like centimeters, millimeters, and inches
are currently unreliable across devices.


You might think "why not just create a div element that is 1 cm wide,
then get it's width in pixels and that's how many pixels per cm you
have". Sure, that works, but those are *CSS* pixels per *CSS*
centimeter. On top of that, not all operating systems operate at the
same dpi, and to make matters worse not all devices have a
devicePixelRatio of 1 (mines 2 by default in Mac OS X Yosemite). So the
value that you'll get from this technique, if you adopt it right now,
vary a *whole lot* across devices. We can't say with any confidence that
something being displayed on various screens on multiple devices is 1
physical inch wide.


Giving us these screen metrics will not only help us, it will help the
future generation of developers because not only will exposing these
screen metrics based on EDID info (when supported by the screen) get us
closer to device-independent development more often, it will also
promote the use of the EDID standard by screen manufacturers so that the
next generation can benefit even more from the exposed screen metrics.


## Pixel Freedom for All! May the pixel be with you! ##
--------------------

Thank you,

W3C Community Development Team

Received on Friday, 3 July 2015 13:33:25 UTC