The pixel has always been the smallest unit in screen-based design. Because it’s been indivisible, it is the concrete unit of measurement among screen-based designers. The phrase “a pixel is a pixel is a pixel” has been adopted to help print designers not used to fixed-screen density understand the concept. Because of this consistency, web designers have adopted pixels over points and other units to build websites.
Now that hardware is changing and pixel densities are growing, pixels are struggling to find relevance as the stable unit they once were. Browser zooming is one thing and has been covered on QuirksMode. But what is a pixel on high resolution devices today? Why does the 640px — 960px iPhone 4 claim to be 320px — 480px in the browser? The truth is that there are two different definitions of pixels: they can be the smallest unit a screen can support (a hardware pixel) or a pixel can be based on an optically consistent unit called a “reference pixel.”
The hardware pixel#section2
Most of us are familiar with the hardware pixel. It’s the smallest point a screen can physically display and is usually comprised of red, green, and blue sub-pixels. Light from these three sub-pixels is mixed to create the colors we see. Because the hardware pixel relates to a physical element on a screen it cannot be stretched, skewed, or subdivided. These properties make the hardware pixel like the atom: the unit of design on which we build everything.
The reference pixel and splitting atoms#section3
Things are changing for the pixel. The w3c currently defines the reference pixel as the standard for all pixel-based measurements. Now, instead of every pixel-based measurement being based on a hardware pixel it is based on an optical reference unit that might be twice the size of a hardware pixel. This new pixel should look exactly the same in all viewing situations. The beauty of using a reference pixel is that it takes proximity to a screen into account. When using a phone that you held close, a reference pixel will be smaller on the screen than a projection you view from a distance. If the viewer holds their phone up so it is side-by-side with the projection, the pixel sizes should look identical no matter the resolution or pixel density the devices have. When implemented properly, this new standard will provide unprecedented stability across all designs on all platforms no matter the pixel density or viewing distance.
Reference pixels are amazing, but now we have two conflicting definitions. Android devices have a new unit, called the “density independent pixel” or “dip,” which developers can use to distinguish the number of optical pixels an item spans. This allows developers to use hardware pixels for crisp graphics and patterns by using px or the new relative definition of a pixel for text sizing and consistent proportion across devices by using dip. Splitting the definition of a pixel into two units is great for Android but the web has to deal with years of pixel based designs across all kinds of devices. It would be wonderful if web developers had these units as well, but without shifting the current definition of a pixel entirely, the pixel-based web would break. Imagine if the iPhone 4 told a website it was actually 640px; text would render at half size, such that without zooming, that website would be nearly impossible to read. For all those mobile sites that disable zooming it would be impossible to use.
Fig. 1: Standard pixel sizes on the Galaxy Tab and Kindle Fire.
We also don’t know what each device considers a pixel and this is a problem. For example, the original Galaxy Tab and the Kindle Fire have the exact same screen size and resolution; but pixels on the Tab, which adjust for the reference pixel, are measured at 1.5 times that of the Fire, which uses hardware pixels. It is impossible to develop for new devices without having one to test on because the only specs released speak in terms of hardware pixels. A developer might look up information on these two devices and think that if the screens are the same and they both use the Webkit rendering engine their website will look the same. Sadly this is not the case; as far as a website is concerned, the Galaxy Tab is 400px — 683px and the Kindle Fire is 600px — 1024px.
Identifying break points and moving forward#section4
It’s safe to say there is a problem with pixels. But we can use media queries to identify the inconsistencies and adjust accordingly. We can use the device-pixel-ratio media query to identify devices with scaled pixels. We can combine that with dimensions to identify types of devices with some amount of accuracy. The iPhone 4 has a device-pixel-ratio of two, so it measures pixels as twice the size of a hardware pixel. Many Android devices have a device-pixel-ratio of 1.5, so things are scaled at one-and-a-half times larger than the hardware pixel. Currently this needs to be prefixed, but you can use this query to start identifying scaled devices.
Specificity is key when identifying classes of devices, but be careful: never be quite so specific as to single out a single device and attempt to target that in case other devices have the same problem. Taking a look at the original Galaxy Tab and devices like it, a device-pixel-ratio of 1.5 will only get us part-way there. Most Android phones today also have this device-pixel-ratio and conflicts there can lead to other problems. Querying the device-width at both orientations will tell us that this is larger than a phone, but not as large as other tablets that may come out in the future. We can use device-width to identify the screen, unlike width and height which only query the viewport. Using the device dimensions, we can gain much better insight into the hardware being used:
@media screen and (device-pixel-ratio: 1.5)
and (device-width: 683px)
and (orientation: landscape),
screen and (device-pixel-ratio: 1.5)
and (device-width: 400px)
and (orientation: portrait)Note that device-pixel-ratio needs to be vendor prefixed to work, so adding -webkit- and -o- will make it work in Webkit and Opera browsers.
Now let’s look at devices like the Kindle Fire, which has the exact same hardware resolution as the Tab, and uses hardware-based pixels. Dealing with devices like this are more difficult because they’re more likely to conflict with netbooks and other larger screens as well as the iPad with a similar resolution. Using the media queries orientation and max-device-height will highlight the devices we need. Devices usually give a height less than the actual device-height so to avoid 1024 x 768 tablets identifying those under 600 pixels tall will avoid those. Now we’re looking at tablet devices which have fairly consistent resolutions and sizes:
@media screen and (device-pixel-ratio: 1)
and (device-width: 1024px)
and (max-device-height: 600px)
and (orientation: landscape),
screen and (device-pixel-ratio: 1)
and (device-width: 600px)
and (max-device-height: 1024px)
and (orientation: portrait)
Fig. 2: Normalized pixels on the Galaxy Tab and Kindle Fire.
Using ems instead of pixels will give you a lot of control over how your site can scale—and not just on type—on everything that had a pixel-based value before. Now, all you need to do is change the font-size value on the html element. Switching the Kindle Fire to look like the Galaxy Tab is just a matter of multiplying the base size by 3/2 (1.5) on the Kindle Fire’s media query. If you wish to use hardware-based pixels on the Galaxy Tab, multiply its base size by 2/3 (.666667). Because everything is based on ems, your site will scale relative to base font-size. Check out the full example in this Gist. Changing it depending on the context can improve consistency across platforms.
Managing multiple pixel definitions can be tricky. The pixel is the most basic unit and this shift to the optical pixel will cause some strange things to happen. Device makers are doing a fairly good job at identifying these issues and solving them so we don’t have to, but something is always going to slip through the cracks or contain inconsistencies. Fortunately we have tools to identify and overcome these obstacles as long as we remain aware of this shift.
I remember in the late 90’s being at a seminar where someone spoke about measurements for monitors. It was suggested that the mm should be ‘layered’. In other words, devices should have a mechanism that translates their pixels to mm. At the time it was thought this should be done in hardware, but as I understand it, the reference pixel is exactly that. They just named it differently which makes it more complex than needed. Why would you want to define lengths in a virtual dimension when you could just as easily do it in mm? In other words, I do not understand why the -already existent- mm has not been used for this technology?
My question (not directed at Scott as much as the general web standards community): Why bother referring to reference pixels as pixels at all? There’s no reason we have to hijack a term that has a relatively clear definition otherwise. Now would be a perfect time to coin a better term.
For the sake of conversation, let’s say we instead refer to reference pixels as _specks_. If nothing else, it’d be easier to explain the concept of a _pixel-to-speck_ ratio than it would be to explain a _physical-pixel-to-reference-pixel_ ratio.
@Yuvalik
Yes, the definitions do seem overly complex and confusing. The web deals with a lot of legacy code on both the browser and the HTML/CSS sides and I assume this is the reason why a new unit wasn’t created.
However the W3C definition of a pixel, even though it is full of trigonometry, offers a unique and wonderfully consistant unit across all kinds of devices. Unlike millimeters or inches a pixel consistently scales relative to the assumed viewing distance. An accurate pixel will appear the same size no matter if it is projected on a 50ft screen or held up close on a mobile phone. Millimeters will remain the same physical size on both devices causing them to be almost invisible when projected onto a viewport.
…not really. The reference pixel was first described in CSS 1 in 1996: http://www.w3.org/TR/CSS1/#length-units
Would this method be any different than using something like <meta name=”viewport” content=”initial-scale=1.0, width=device-width” /> outlined here https://developer.mozilla.org/en/Mobile/Viewport_meta_tag ?
@Nick Fitzsimons
Thanks for pointing that out Nick. It always amazes me how forward thinking the W3C is. Few user agents have altered their pixel sizes from hardware pixel sizes until recently though.
“If the pixel density of the output device is very different from that of a typical computer display, the UA should rescale pixel values.”
@Dan Ciupuliga
Hi Dan, that method is used to properly scale and zoom the viewport. It does not indicate what the pixel ratio is on devices. Theoretically you could change the “initial-scale” value on different devices depending on what zoom you prefer. This code is HTML so you would not be able to use CSS media queries to change the value.
Gotcha. Thanks for clarifying.
If the intent is to have full control over actual device pixels to then scale things, at least on Android you can also add target-densitydpi=device-dpi to a viewport meta. this turns off the built-in dpi bias you get, even when width=device-width. unfortunately, iOS doesn’t support this (yet?).
[and yes, full disclosure first: I work for Opera] in terms of having to add the above meta to the HTML, rather than being able to use CSS MQs: that’s exactly why I personally think the “CSS Device Adaptation”:http://www.w3.org/TR/css-device-adapt/ spec would be cool to have across browsers…but for now, it’s only supported in Opera Mobile (and possibly Opera Mini, but I’d have to double-check).
Great tip Patrick, thanks. The real issue is with device makers inconsistently implementing pixels and compensating for those inconsistencies. The media queries outlined in this device adaptation spec look incredibly useful for identifying problem areas provided the values returned are accurate.
This is yet another example of an absurd way to manage a “new” feature, it maybe true that with higher density images there’s a need to render things differently on screen but it’s completely absurd to leave the managing of such conversions to the developer, how insane is to pretend that we device a conversion for every device out there:
@media screen and (-webkit-device-pixel-ratio: 1)
and (device-width: 1024px)
and (max-device-height: 600px)
and (orientation: landscape)
and add that statement for every combination of renderer/resolution/pixel ratio/ orientation?
are you serious? that is plainly absurd, this should have been created as a new unit so you can start defining your designs in – let’s call it – “dips” “specks” or whatever (as long as it’s not called pixels) and it’s the device who should make the calculations, not the developer, actually it shouldn’t be too hard for the rendering engines to calculate accurate equivalences with legacy (meaning current) designs defined in pixels, given the device actually “knows” for sure the conversion ratio, size and resolution of it’s own screen this is really the kind of thing that vendors should agree beforehand not everyone making their own interpretation and leave ridiculous ways for the developers to cope.
Have we learned nothing from the ’90s ’00s browser wars, sometimes it seems as if with every change or new hype we have to reinvent the web from scratch.
@baaxee
While I disagree with your choice of words, yes, we shouldn’t be dealing with the problem in the first place. According to the spec, the Kindle and devices like it use the wrong measure for pixels in any kind of normal use case. It should not be the developers responsibility to fix their mistake.
Unfortunately there are a lot of devices doing it wrong and not much knowledge as to what is to spec and what isn’t or how to overcome these inconsistencies. Before I got these devices to test on I wrongfully assumed they would be the same, only to find a huge problem when testing.
I agree with “Patrick”:http://www.alistapart.com/comments/a-pixel-identity-crisis//#9 that if the intent is to get full control over pixel size, target-densitydpi=device-dpi achieves what you’re aiming for, and is way less complicated.
That said, I want to point out that Firefox and Opera also support device-pixel-ratio. Would it be possible to add -o-device-pixel-ratio and -moz-device-pixel-ratio to your code examples (and maybe even a generic fallback). Note that Opera only supports fractions as values, so 1.5 should be written as 3/2.
Disclaimer: I work for Opera.
Thanks Patrick, I will get these added to the article.
Maybe I don’t understand, but how does target-densitydpi=device-dpi help if the values passed down to the browser are not accurate and how can custom offsets be defined per device to adjust for those inconsistencies? I will play with it some more.
Also, I love how Opera uses fractions instead of decimals. The math is way easier to manage 🙂
basically, with that extra directive in the meta (or the equivalent using the CSS viewport stuff in Opera) you “zero out” any device-specific bias. combined with width=device-width, you’re forcing the browser to set its viewport pixels to match the device pixels. this value is then also used when doing mediaqueries etc (the same way that width=device-width is the common mantra used for every RWD site using MQs…basically, it’s an extension that also nullifies the zoom, which otherwise would still be affecting your calculations). after that, you have the raw device pixels to play with and make decisions on. it may not be helpful in terms of getting consistent font sizing, but it at least allows you control over the inconsistent zoom factors (this should also affect user-set zoom in android browsers, but haven’t tested this yet).
see the ‘Going one level deeper — dealing with high-DPI screens’ part of Andreas’ “An introduction to meta viewport and @viewport”:http://dev.opera.com/articles/view/an-introduction-to-meta-viewport-and-viewport/ for a quick overview of this dpi bias stuff…
From my experience creating CSS that is optimised for a wide number of mobile browsers (and habitually tested on 30-40 devices + 3-4 additional non-native browsers over 4-5 platforms) I suspect that what you’re suggesting may either not work as well as you think, or may in cases make things worse for users.
Mobile browsers do vary in default em size but if you normalize/reset the font to 1em you can very easily build an experience that is by and large consistent and legible as intended. Although certain browsers/OEMs have been known to set a default font size that is smaller or larger than the norm, this is less and less of a problem.
While device-pixel-ratio may seem like a useful query-able value, it only represents a portion of the overall user experience. Users now have a great deal of control over both viewport and font size. “The latest version of Android”:http://stephanierieger.com/the-trouble-with-ice-cream-sandwich/ offers three different ways to zoom the layout (thereby resetting the viewport and triggering any media queries that match to the new value) as well as a setting that completely resets the default font size to whatever the user wants. And as devices range from 150 to 300 dpi, the actual size the user will see will be an aggregate of a) the browser’s font settings b) the zoom level/viewport size and c) the dpi.
Attempting to control all this using precise values derived from the pixel-ratio may appear successful when tested on a small subset of device, but the success of the technique when mapped against 1000s of devices will still be dependent on the user, browser and OEM (who ultimately sets default sizes and implements/interprets spec) doing exactly what you want/expect them to do. This is unlikely to happen and as you also cannot test on all devices (and devise edge case adaptations where needed), these extra steps may ultimately prove less successful than simply creating a more nimble design, while in parallel starting to reset client expectations regarding the value of a reliance on pixels measurements going forward.
Thanks for commenting stephrieger,
The intent is to identify problem areas and adjust for them specifically. Many 7″ tablets have problems and this is intended to identify what those are and how to compensate. “Usability studies show”:http://www.useit.com/alertbox/kindle-fire-usability.html that these devices being sold in the millions have issues when it comes to pixel scaling.
However the queries are specific enough and will simply be ignored on most devices. If a user decides to change the zoom level and viewport size then the site will use those settings instead of the normalized values. Most vendors get it right and overriding everything just doesn’t make sense.
Hi Scott,
Totally in agreement regarding the issues on certain 7″ tablets and i’m familiar with Jakob’s recent research. The 7″ format is a tricky one. We tend to think of these devices more as large phones than tablets and it’s a shame Amazon didn’t carefully consider their choice of viewport setting. The Galaxy Tab viewport is much more approachable.
The thing is that based on media queries alone, it’s going to be very hard (possibly impossible) to target those adaptations to only those specific devices that need them. In the past (and occasionally still today), we implemented occasional tweaks such as these through user agent-based identification of specific browsers (or sometimes browser-sub versions…).
While this was an imperfect solution (white-lists always are), it at least delivered the tweaks to only the devices that needed them. And as this was also typically accomplished server-side, the 90% of devices that didn’t need the tweaks never received them to begin with (thereby also minimising the risk of false positives…i.e. tweaks being applied to browsers that were absolutely fine..thereby causing a problem rather than solving one).
Scott, thanks for the detailed information. I appreciate knowing a little more about how devices are interpreting our code.
The question I have is this: How bad is the problem? Is it a case where some devices will have a less-than-perfect display, but still fall within the range of acceptable? Or could it be more like the case of the iPhone 4 that you mentioned, where a site rendered in device pixels would be totally unusable?
I think we’ve all come to accept the mantra that our sites don’t need to look the same in every browser. My first inclination is to file this problem away in the same bucket.
I’d like to assume (for now) that most developers won’t take the time to make specific fixes like this, which means that device users would get used to whatever implementation they’ve got. (Kindle Fire users will get used to sites appearing at a certain relative size, and so forth.) If the display is really bad, devices with poor display settings would take a hit in sales, and the message would get back to those vendors very quickly that they need to fix something.
I guess what it boils down to is that I’d like to put the onus on device manufacturers to render my site in a rational way if I’ve written solid, standards-based code.
Are there certain device fixes that you’d suggest for any and all web sites, or would you say this technique is more applicable in very specific cases?
Nathan,
This is a question that can be asked about any number of things in web development and can be followed up with a number of other questions. How much traffic to you expect to be getting from devices like the Nook and Kindle Fire? Are you targeting mobile? Looking to the future, where can you expect your traffic to come from?
I work for an e-reading company so these devices mean a lot to me and the Kindle Fire is selling in the millions. Implementation was easy for me as well. I use Sass and could quickly change the units to ems “with little effort”:https://github.com/scottkellum/Seasons/commit/5ae21ea6db0cb00fe8a3d5ef8392a3b30f9b948c#diff-2 . Once you are using ems the code required to scale your site now is incredibly small. All you do is change the font-size of the HTML tag and you can easily scale everything up and down by changing one value.
This may not be something you want to re-write your site in ems for, but it is at least an argument to exclusively use relative units on the next site you build.
It seems like a lot of this complexity could be avoided with
<meta name=”viewport” content=”width=640″ />
Suddenly all devices treat your pixels as the exact same percentage of the screen width. Isn’t this all we want?
Scott, definitely this technique will become a standard. Making websites that adapt perfectly to every device and situation is growingly challenging. I just finished a couple of responsive websites and got to say that my bills are going to grow a lot for this.
As I said, this techinque will become mandatory, but will also add a lot of work, especially when editing a complex website’s css to second customer’s requests. The days of pre-settled website costs are over.
Ryan,
This can cause problems on smaller devices where you may want to viewport to equal the device width. On phones, everything would shrink down to fit the viewport and on larger screens things would need to scale up. However, if you are targeting devices on the server side this can be a great solution that will even override the users scale settings. Sending something to a user that is that rigid can cause plenty of usability issues though, so be careful if that is the path you take.
fornace,
Hopefully it doesn’t add too much to your development time. This is really an argument to use relative units like em, rem, and percent instead of px, in, pt and so on. If you are finding yourself going back to make core adjustments to your CSS later in a projects development I recommend using a CSS precompiler like Sass.
In my point of view websites are built in the present to facilitate the future. Take ALA for example, with a design that has lasted for quite a few years it is facilitating game changing articles like responsive design. While it does not implement these new ways of thinking it does its job wonderfully. There is no point in killing yourself keeping legacy sites current, instead build it the best you can the first time around. I am trying to keep a normalization list up to date here: https://github.com/scottkellum/pixel-normalization. It should be a matter of copy/paste to keep up to date.
Hm, ok, so I follow, but unfortunately I don’t have multiple devices to fully grasp and experiment with. So I guess my question is, how important is its application, and when/how do we apply it now?
I feel like responsive web design addresses a similar issue, accounting for different devices, except now this accounts for two devices, same screen size, different rendering. As a web designer, if I’m making my website responsive, and font size isn’t critical to layout or other structural issues, do I need to worry about this?
I feel like this is fine tuning that could be practical/helpful/important in certain circumstances, such as trying to get super small subtext and still making it readable across all devices, but for the most part, isn’t essentail to usability.
And, if it is important, can I cut and paste that gist and go about my way, or do I need to worry about more?
Very interesting topic, and thanks for laying it out!
Cheers!
Think about the last time you went to footlocker (or another shoe store). You see a pair of kicks you really like the look of, everything about them screams your personality so you ask the store clerk for a 9 to try on. When you get them, your right foot is snug but you can barely get the left one in at all before your toes hit the end.
You try the 10 only to find that it’s like trying to walk in two small rowing boats.
See the problem with shoe manufacturers is that they all interpreted a size 9 differently. The actual size itself is altered based on the contour of the shoe, the density of the soul, the stitching and so on. If that wasn’t enough of a headache, a US size 9 is actually a UK size 8 and a European 42!
Suddenly exactly the same product has 3 different measurement methods to be based upon along with the manufacturer’s interpretation of each of those fundamental measuring concepts.
Buying shoes is exactly the same as working with html/css layouts. We all have shoes on our feet today though, so we must have found a size and pair that suited us personally.
Pick the style, the materials and the measurement that suits with you and try them on, wear them to the club or kick back and watch TV in them, ultimately it really doesn’t matter how they got on your feet just that you feel comfortable in them.
son0fhobs,
I try to avoid absolutes, especially in the web design space. There are cases for and against almost every technique. This is more of an argument to use relative units like em and rem instead of absolutes like px and pt. As long as your layouts are defined in relative terms alterations are easy.
It is more important to normalize for responsive and fluid layouts that fit to the screen. Fixed layouts are always zoomed differently on touch devices anyways so they don’t need to really worry about this. Tablets are rapidly increasing in popularity and 7″ tablets are one of the fastest growing areas while having some of the biggest issues with pixel scaling. “Usability studies show”:http://www.useit.com/alertbox/kindle-fire-usability.html that there are some major issues on these devices, the Nook suffers from them as well although the native UI is better designed for touch input. Because of these issues I have converted my frameworks to use this technique and have taken the time to refactor some older projects to use ems for pixel scaling. That said, I work on digital publications for the web so the kindle/nook market is a bigger deal for me than most people.
Yes, as long as you are using relative units everywhere you can cut and paste the gist and go about your way 🙂
I’m glad I’m not the only one who lacks appreciation for needlessly making coding more complex. I begin to long for the application of non-complicated standards, as Web Standards did for websites. But it is what it is.
I think the move to relative units like em is inevitable.
Too many screen sizes, too many resolution settings.
I don’t normally do web design – these days usually I work with web fonts. But when it comes time to put demo pages together, I realize more and more that no matter what I do, I’ve got invisible “partners” who are going to come along after I’m finished and secretly alter what I’ve done.
Device manufacturers, the OS, users – they all have just as much say in my design as I do. The difficulty is accepting this and making it work as an advantage, not a liability. It’s a big mental adjustment. A complete change in paradigm. It’s been coming for awhile, and now it’s arrived full blown with the proliferation of mobile devices. Until recently, there was still some semblance to the fixed media of print which has dominated for 500 years. But that’s all gone now. I don’t agree with the notion that screen sizes will eventually “boil down” to some reasonable, manageable number.
Some used to argue that it was best to view the CSS as a “suggestion” only. Now, it’s not even a suggestion. Just a beginning, a start – an offer. Nice article, thanks.
I’m really having trouble getting past the opening paragraphs of this article. Yes, the pixel is a unit of measurement. But you fail to specify what is being measured. What is the pixel a unit of? The answer has always been *resolution*, not size.
Consider the content being presented and not the hardware. A digital image that is 640 x 480px has no inherent size; it has only an inherent resolution—which helps us understand its size in quantitative and/or relative terms. (Which leads us to *think* we’re talking about size.)
This issue became crystal clear to me recently while studying bitmap fonts and font-rendering (aliasing, sub-pixel aliasing, anti-aliasing). A bitmap font is one that’s been designed based upon a particular grid; it has no inherent size but its resolution is clearly defined—which gives it very distinct limitations.
This is where pixels and points are worlds apart. Point is a true unit of size, being defined as 1/72 of an inch by modern standards. A point is always a point—in terms of its size—but its resolution is completely ambiguous. Point is a unit of size, without resolution. Pixel is a unit of resolution, without size.
Doug,
There are two definitions of a pixel, one is the hardware pixel or the size of one unit on a physical screen, the other and w3c standard is a relative size based on a reference pixel.
How big is a pixel exactly according to the spec?
??For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees??. ??For reading at arm’s length??, ??1px thus corresponds to about 0??.??26 mm?? (??1/96 inch??).
That probably doesn’t give you a good idea as to how the unit behaves. So imagine looking up at the moon, then bringing your thumb up and covering the moon. Optically your thumb and the moon are the same size, but physically the moon is much larger than your thumb.
When dealing with font hinting and anti-aliasing you are altering how text falls across various hardware pixels, not reference pixels. A bitmap font scaled on some screens to the w3c standard of a pixel might have issues displaying properly. Using the method outlined in the article can work to fix this or using the method “described earlier in the comments”:http://www.alistapart.com/comments/a-pixel-identity-crisis/P10/#13 of using target-densitydpi=device-dpi might help with bitmap fonts.
Scott,
I think it’s important that at least one of your definitions acknowledges content—not just the hardware or a W3C standard.
Fundamentally, pixels are descriptive of a grid-based or bitmap-style visual representation. The size of the grid is completely arbitrary. When talking about digital photos, we don’t talk about their physical dimensions, or the size of their pixel units, we talk about the number of pixels they contain. One of my points is that we commonly confuse that number with size. And I think that confusion runs wild in the web design and development world as well. We get used to pixels _seeming_ a certain size, but they were never the size we presumed they were; they were just a quantity—a quantity that helped us assess relative size, dimensional ratio, and the limitations of a particular digital asset.
Unlike a vector object, a bitmap object (whether a photo or a bitmap font) has very specific limitations by virtue of its pixel dimensions. Those dimensions by no means represent the physical size of the object, only the resolution of the object.
Personally, I’d like everyone who reads this to repeat this mantra for one week: “*Pixels are a unit of resolution*, *not size*.”
Doug,
In web design and development pixels are used as a unit of measure, not to describe content. Changing the resolution of a photo in the context of web design will change it’s size, not it’s refinement. This is because CSS is a presentation language that is usually used to describe elements on a screen with it’s own resolution. Because the resolution of screens are set, pixels of images and bitmaps are displayed at a 1:1 default ratio to that of the device making the unit of measure on the screen significant. Within this context, pixels are a unit of size that describe resolution, but not a unit of resolution. If we were discussing digital photography without the context of presentation formats then yes, pixels would be a unit of resolution, not size.
I think Doug’s posts are helpful. Scott, the beginning of your response: “in web design and development pixels are used as a unit of measure” – I understand the point you’re making, but isn’t this exactly the problem? The “reference pixel” is an appropriate next step, but like others have said, the name isn’t great. How about lexip? I actually think its better to mentally abandon the whole idea of designing based on a little square unit. RWD gets us close. But there is still that default font size measured in pesky pixels. The last step is to define font size without pixels and be done with them. What if we could just directly define an em as a percentage of the viewing window? For example, we redefine em slightly as the area (not just length) that a capital M fits inside of, then define how big an em is in our documents, like 1/7500 of the area of the window. Essentially we would define our own “pixel.” I understand something similar is happening in the article when you change the base font size. But I like the idea of defining all sizes according to the screen real-estate, including the actual em.
See, the very fact the W3C has tried to ascribe a standard size to a pixel (or create a concept called a “reference pixel”) is indicative that the pixel has no inherent size. It’s ever-changing.
Yes, it’s a unit of measure—but of quantity, not size. I call this quantity “resolution” (you may call it “refinement”?) because it’s intimately connected to the level of detail that can be rendered by a grid-based representation. For example, a 4×4 pixel grid cannot render the detail that a 400×400 pixel grid can; it doesn’t have enough resolution.
Content is everything. It’s what designers and front-end developers work with. To any CSS designer:
*If you’re using pixels to “size” content that is _not_ a bitmap*—*such as a font, or an HTML element*—*reconsider what it is you’re really doing*.
You’re saying to the browser, “Please map this to a grid of [this many] pixels”. In other words, you’re limiting or commiting that content to a particular grid-based resolution—in effect, asking the browser to treat it as a bitmap. Yes, you’ll get a relative size from this type of declaration—by tethering it to the other bitmap elements on the page—but there should be no expectation of an absolute size.
This is very different from using a unit like points. With points, you’re making an explicit statement of size only, with absolutely no commitment to a particular resolution.
Sorry if I’m repeating myself here. And my apologies if we’re using different terms. To me, this understanding of the pixel _simplifies_ things greatly, in a way that adds clarity instead of complexity.
Thanks for the responses!
I would love it if the W3C adhered to this mantra and agree with *kylew* above that a new unit would be wonderful. Having pixels that don’t describe resolution is confusing and a new unit would be nice. However facts are facts which aren’t up for debate and the W3C has actually defined a pixel like this for a long time. Changing it now would cause a lot of problems.
Yes, I totally agree it isn’t the best solution but this is the problem and I proposed a solution in my article. The solution involves abandoning pixels and moving to ems or other relative units.
I read most of the commets but not all so sorry if this has already been mentioned and I missed it.
As you mentioned device-pixel-ratio is currently only supported within webkit and opera, I thought its worth mentioning that -o-device-pixel-ratio uses fractions rather than decimals like webkit.
-webkit-device-pixel-ratio : 1.5
will be become
-o-device-pixel-ratio : 3/2
I like what you guys tend to be up too. This sort of clever work and reporting! Keep up the terrific works guys I’ve included you guys to blogroll.
“Web Design Company”:http://www.sminfosoft.com
“Technology News”:http://update-technologynews.blogspot.in/
i am waiting for the iphone 5.
Interested article and very useful information in it.
Haven’t read through the entire comments, but just wondering why you used -device-pixel-ratio which needs to be prefixed rather than ‘resolution’ in your media queries? Seems to me you could be more accurate and less tied to specific device definitions by using resolution.
Also… to me your MQ for targeting the Kindle and the Tab are great in terms of a useful exercise, but are amazingly impractical for real-world development. It just shouldn’t be that hard.
Scott, Thanks for a good article.
But what does this sentence mean:”Devices usually give a height less than the actual device-height so to avoid 1024 x 768 tablets identifying those under 600 pixels tall will avoid those.”?
It’s not just grammatically gonzo, it’s actually totally unclear. I’ve read it over and over and I just don’t get it. Device height isn’t reported correctly? On which devices? Can you document/expand on this? You’re dropping a huge bomb here without any elaboration. I think we’d all be really interested to see a table of actual devices with their actual and media-query-reported dimensions, if such a thing exists.
Also, you make a sweeping (and I believe correct) generalization about how developers probably shouldn’t try to get locked into targeting specific devices, but instead *classes* of devices with different characteristics. But then you go on to specifically target two devices in the most narrow way possible. It’s philosophically “¦ baffling. Even for just these two devices, I’m left at the end of the article wondering which approach I should take to preserve reference pixel scale for typography across all devices. Scale up the Fire or scale down the Tab? I get the relativity of it all, but it would clarify a lot if a single position were taken.
@jameswillweb At the time, this was the most widely available tool at the disposal of developers. Resolution vs device-pixel-ratio is still under some amount of debate from what I have read, although the W3C seems to be settling on resolution. Time will probably provide more and better solutions and resolution is one of them, but the issue of unit discrepancies is a big one. Unfortunately the unit specs are, in my opinion, a mess. This is how I was taming a particularly annoying outliers at the time.
@Mwahaha Sorry for my gramatical mis-steps. I have always struggled with my writing. What that means is that devices rarely report the correct device height in pixels. Instead they report the height minus any browser chrome, so essentially the viewport height. Querying a lower number ensures that those devices are included.
These are just two devices I am using as examples. Many other devices in the 7″ class of tablets are targeted with these queries, like the Nook, Viewsonic viewpad, ACME Android 7″ “¦
@Mwahaha Also I did take a stance on what scale I prefer. I scaled both devices to the equivalent of 1.2. “From what I hear”:https://twitter.com/huafi/status/220941824955654144 , this is around the same scale as the Galaxy Nexus.