Skip to toolbar

Community & Business Groups

The Hardware Pixel Community Group

closed on 2019-08-13

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! ##

Group's public email, repo and wiki activity over time

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

No Reports Yet Published

Learn more about publishing.

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

Call for Participation in The Hardware Pixel Community Group

The The Hardware Pixel Community Group has been launched:


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! ##


In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. 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. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group in social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at site-comments@w3.org

Thank you,
W3C Community Development Team