Comments on A Pixel Identity Crisis

45 Reader Comments

Back to the Article
  1. 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?

    Copy & paste the code below to embed this comment.
  2. 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.

    Copy & paste the code below to embed this comment.
  3. ...not really. The reference pixel was first described in CSS 1 in 1996:

    Copy & paste the code below to embed this comment.
  4. Would this method be any different than using something like <meta name=“viewport” content=“initial-scale=1.0, width=device-width” /> outlined here ?

    Copy & paste the code below to embed this comment.
  5. Gotcha. Thanks for clarifying.

    Copy & paste the code below to embed this comment.
  6. 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”: 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).

    Copy & paste the code below to embed this comment.
  7. 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.

    Copy & paste the code below to embed this comment.
  8. I agree with “Patrick”: 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.

    Copy & paste the code below to embed this comment.
  9. 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”: for a quick overview of this dpi bias stuff…

    Copy & paste the code below to embed this comment.
  10. 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”: 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.

    Copy & paste the code below to embed this comment.
  11. 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).

    Copy & paste the code below to embed this comment.
  12. 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?

    Copy & paste the code below to embed this comment.
  13. 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?

    Copy & paste the code below to embed this comment.
  14. 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.

    Copy & paste the code below to embed this comment.
  15. 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!


    Copy & paste the code below to embed this comment.
  16. 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.

    Copy & paste the code below to embed this comment.
  17. 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.

    Copy & paste the code below to embed this comment.
  18. 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.

    Copy & paste the code below to embed this comment.
  19. 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.

    Copy & paste the code below to embed this comment.
  20. 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*.”

    Copy & paste the code below to embed this comment.
  21. 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.

    Copy & paste the code below to embed this comment.
  22. 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 4x4 pixel grid cannot render the detail that a 400x400 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!

    Copy & paste the code below to embed this comment.
  23. 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

    Copy & paste the code below to embed this comment.
  24. 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”:
    “Technology News”:

    Copy & paste the code below to embed this comment.
  25. i am waiting for the iphone 5.

    Copy & paste the code below to embed this comment.
  26. Interested article and very useful information in it.

    Copy & paste the code below to embed this comment.
  27. 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.

    Copy & paste the code below to embed this comment.
  28. 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.

    Copy & paste the code below to embed this comment.
  29. Sorry, commenting is closed on this article.