Responsive Web Design With Physical Units

Advertisement

This post should be titled “Getting Ahead of Yourself.” “…By a Few Years,” actually. Here’s the deal: at the time I’m writing this, early 2013, there’s no way to accurately design for the Web using physical units, nor will there be for a very long time. But there is a way to design while knowing the physical characteristics of the device — or, at least, there will be in the very near future.

Mobile devices
Different devices can have a similar screen resolution, yet entirely different physical factors. iPad (1st generation) has the diagonal size of 9.7″, the resolution 1024 × 768 and 132 ppi. Kindle Keyboard 3G has the diagonal size of 6″, also the resolution 768 × 1024, yet 212 ppi. Image source: kodomut1.

It’s called the “resolution media query”, and it’s been in the specification for media queries for some time. However, while it has been in the spec, that doesn’t mean anyone has actually implemented it yet. Fortunately, WebKit is leading the way2 and pushing for this feature to be implemented. So, how will we use this nifty little feature, exactly? Here’s how.

The Thin Line Between Queries

First off, I posit that there will be only one use case for a resolution-only media query. Something along the lines of

@media (min-resolution: 250dpi) {

}

has, at this time, only one good use: swapping out low- for high-resolution images. I’ve tried imagining other uses and, as far as I can tell, there just aren’t any. But resolution is not what we, as Web designers, are truly interested in. Since we are designing for humans, shouldn’t we be thinking about the physical side of human data consumption and designing using this kind of a metric? And in a perfect world we could simply say width: 1in and have a one-inch wide element, regardless of the device. Unfortunately, we live in a digital world in which the physical and digital pixels are not the same. We need something to bridge the gap. That something is the resolution media query.

Good. Now that that’s out of the way, let me show you how this one little piece of code can make so much difference that your head will promptly explode. (I take no responsibility for actual blown heads as a result of this post.)

Let’s compare two media-query declarations:

@media (min-resolution: 341dpi) and (min-width: 767px) > {

}

and

@media (max-resolution: 131dpi) and (min-width: 767px) > {

}

At first glance, this doesn’t seem like much of a separation, right? Wrong. The numbers I’ve used are specific to the HTC Windows Phone 8X (the first snippet) and the iPad 2 (the second snippet). By using the resolution query, one can basically separate physically small devices from large devices.

As it currently stands, a query that looks like @media (min-width: 767px){ } will affect both the HTC and the iPad, with no other possibility of separation, because both have a resolution that is 768 pixels wide. In fact, the iPad has a lower resolution, at 1024 × 768, whereas the HTC is 1280 × 768. In case you haven’t realized yet, the problem with all of this is that the iPad is a 10-inch device, while the HTC is a 4.3-inch one. That’s less than half the physical size!

By using the resolution media query together with a width query, we can distinguish between physically small and large devices to adjust design elements and layouts accordingly. While, as mentioned above, screen resolution isn’t really what we are interested in since we use logical breakpoints in responsive design3, it is useful to know whether a site is being displayed on a small or a large physical display — e.g. to increase font size or rearrange design elements in the layout. But where do we draw the line between small and large? Quite simply, we can’t. Each of us has to draw the line, possibly on a project-by-project basis, between “This is a small device” and “This is a large device.” As far as ballpark numbers go, I’ve done a few calculations and have developed a theorem that should give you a clearer idea of how this works more or less.

The Physical Size Inquiry Non-Exhaustive Theorem (PSINET)

Here’s the theory: In a combined query, if the ratio between the smaller of the width and height and the resolution, called a PSINET score, is higher than 5, then the result falls in the category of a physically large device. If the resulting number is lower than 5, then it is a physically small device. Devices that score very close to 5 are considered to be medium-sized, close to the physical size of an A4 sheet of paper (21 × 29.7 cm).

Here’s a non-exhaustive list of devices to test the formula above. I’ve listed each device’s score according to the formula, along with its diagonal size, resolution and density, and PSINET score.

Physically Large Devices

Device name Diagonal size (inches) Resolution PPI PSINET score
Apple iMac 27 2560 × 1440 109 13.00
Sony Vaio F 16.4 1920 × 1080 134 8.05
Apple MacBook Pro RD 13 2560 × 1600 227 7.04

Physically Small Devices

Device name Diagonal size (inches) Resolution PPI PSINET score
Sony PSP 4.3 480 × 272 128 3.75
Kindle Keyboard 3G 6 768 × 1024 212 3.62
Kindle Fire 7 1024 × 600 169 3.55
Samsung Galaxy S 4 480 × 800 160 3.00
Samsung Galaxy NoteII 5.5 720 × 1280 267 2.69
Samsung Galaxy S IV 5 1080 × 1920 441 2.62
HTC Butterfly 5 1080 × 1920 441 2.62
Samsung Galaxy Grand I9082 5 480 × 800 187 2.56
Palm Pre 3.1 480 × 320 186 2.5
Sony Xperia Z 5 1920 × 1080 443 2.43
Samsung Galaxy SIII 4.8 720 × 1280 306 2.35
LG Nexus 4 E960 4.7 768 × 1280 318 2.41
Nokia Lumia 920 4.5 1280 × 768 332 2.31
HTC One 4.7 1080 × 1920 469 2.30
HTC One X 4.7 720 × 1280 312 2.30
HTC Desire HD 4.3 480 × 800 217 2.21
BlackBerry Q10 3.1 720 × 720 328 2.19
BlackBerry Z10 4.2 768 × 1280 355 2.16
Motorola Droid X 4.3 854 × 480 228 2.10
Sony Ericsson S 4.3 720 × 1280 342 2.10
Motorola RAZR i XT890 4.3 540 × 960 256 2.10
iPhone 5 4 640 × 1136 326 1.96
Apple iPod Touch 3.5 960 × 640 326 1.96
Nokia Lumia 620 3.8 480 × 800 246 1.95
HTC Wildfire 3.2 240 × 320 125 1.92
Nokia Lumia 710 3.7 800 × 480 252 1.90
Motorola Defy 3.7 854 × 480 265 1.81
LG Optimus One 3.2 320 × 480 180 1.77
Nokia N96 2.8 240 × 320 143 1.67
Sony Ericsson W810i 1.9 176 × 220 148 1.18

Medium-Sized Devices

Device name Diagonal size (inches) Resolution PPI PSINET score
Apple iPad (1 & 2) 9.7 1024 × 768 132 5.81
Apple iPad (3rd Gen) 9.7 2048 × 1536 264 5.81
Amazon Kindle DX 9.7 824 × 1200 150 5.49
Acer Iconia Tab A500 10.1 800 × 1280 149 5.36
Samsung Galaxy Tab 10.1 1280 × 800 149 5.36
Motorola Xoom 10.1 1280 × 800 149 5.36
Asus Transformer Pad Infinity 10.1 1920 × 1200 224 5.35
Microsoft Surface 10.1 1366 × 768 148 5.18
Asus VivoTab RT TF600T 10.1 1366 × 768 155 4.95
iPad Mini 7.9 768 × 1024 162 4.74
Amazon Kindle Fire HD 8.9 1920 × 1200 254 4.72

Is this method of determining device size foolproof? Hardly — that’s why it’s a theorem. It’s based on solid reasoning and empirical evidence and has come about by using the scientific method, but it is not a rule, law or axiom. Take it with a pinch of salt (or, better yet, a truckload of NaCl) and refine it. It is a theorem, a proposition, to be remembered in the future when the resolution media query and our work with it become a mainstay of the Web.

Breaking the Theorem

Like any self-respecting follower of the scientific method, I’ve tried to break my own theorem. Thus, I imagined a freak of a device, 2 inches long and 20 inches wide, putting its diagonal size at 20.09 inches, with a 240 × 40 pixel display, yielding a resolution of just 11.94 PPI. It gets a PSINET score of 2.01, which puts it well into the small device category, even though it’s almost half a meter long. The reason is simple: it’s that 2-inch-wide dimension. Because the PSINET score ignores the longer of the device’s physical width and height, the greater the difference between those two dimensions, the less accurate the PSINET score will be. Sure, this beast of a device is unlikely to ever become reality, but it’s worth understanding the reasons why it would break the theorem.

Device name Diagonal size (inches) Resolution PPI PSINET score
ThinLong 20.09 24 × 240 11.94 2.01

Real-World Applications

Apart from the obvious visual changes and tweaks mentioned above, there are other ways to use the resolution media query.

Enter Enquire.js4. For those of you who haven’t heard of it, it’s a very nice JavaScript library that helps you execute particular scripts on matching media queries.

We could use Enquire.js or even just window.matchMedia5, which is a native JavaScript method, to differentiate between mobile, tablet and computer users much more reliably than by using width queries alone. Here’s a not-very-polite example using Enquire.js:

enquire.register("screen and max-resolution: 150dpi and max-width: 300px", function() {
    alert('My, what a small screen you have there, Grandma!')
});

Combining media query types with CSS and using a resolution-aware JavaScript library is just the right formula to give us real future-proof control over what I call the “physical Web.” Imagine being able to view a priceless sculpture located in a museum halfway across the Earth on a 1:1 ratio on any device, or shopping for an engagement ring online and seeing exactly how big that 24-carat diamond is. The real-world applications, pun intended, are nearly endless.

In our world of responsive Web design, we’d very much like to provide the best experience to users, whatever their device. In light of the sans-resolution media query above, that task becomes less of a challenge and more a windmill fight. Assigning blame is pointless, because none of us can do anything to change the current ecosystem of devices. Manufacturers will continue to put out devices with resolutions and pixel densities that they’ve pulled out of their butts, and that’s fine — that’s their business. Staying on top of the situation by providing us designers with the tools we need (but can’t easily build ourselves) to create the best user experience possible is the job of browser makers, and I salute the good people at WebKit for spearheading the implementation of the resolution media query.

(al)

Footnotes

  1. 1 http://www.flickr.com/photos/kodomut/5154254605/sizes/m/in/photostream/
  2. 2 https://www.webkit.org/blog/2194/last-week-in-webkit-resolution-media-queries-and-timeouts-for-xhr/
  3. 3 http://www.smashingmagazine.com/2013/03/01/logical-breakpoints-responsive-design/
  4. 4 http://wicky.nillia.ms/enquire.js/
  5. 5 https://developer.mozilla.org/en-US/docs/DOM/window.matchMedia

↑ Back to topShare on Twitter

Art director, focused on eCommerce design and development and a fan of flat skeumorphism. Sometimes blogger, novice speaker, creator of the HTML5 Starter Pack, Adobe Certified Expert in Photoshop and member of the now defunct Smashing Network.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Jason Featheringham

    March 21, 2013 6:41 am

    Amazing post! We are currently tackling this conundrum as well to determine “tablet” vs “mobile.” Unfortunately, a lot of devices report incorrect dpi.

    In the interim, we are experimenting with the WURFL database, using the stored physical dimensions to create classes on the “html” tag.

  2. 4

    It’s a great idea indeed – in the end, as we’re talking future anyway: why not cut the javascript and make a pure css framework based on this?

    This might get complicated, mathwise – but wouldnt it be possible to simply determine different base font sizes based on the width/height & resolution of the screen to achieve a consistent px-to-mm conversion table via media queries and use them througout the stylesheet by applying REM units to size things?

    I mean it’s probably bonkers, and would need a huge load of queries to be halfway accurate, but it could work I think… and it would be simply amazing to be able to design things knowing that, for example, 1rem = 1mm on the device.

    (or, taking a bit further, straightway be able to use pc & pt measurements for web AND print on the same project…)

  3. 5

    I think you didn’t get the resolution media query right. When the spec says DPI, dots-per-inch, it’s talking about CSS inches and not physical inches (the browser can’t even know the screen physical size):

    http://www.w3.org/TR/css3-mediaqueries/#resolution0

    One CSS inch is always 96px. This means that (min-resolution: 192dpi) is equal (min-resolution: 2dppx). A retina Apple device will always report 192dpi, not the physical one. There is no way to get the real screen size on the web. More on MDN:

    https://developer.mozilla.org/en-US/docs/CSS/resolution

    BTW, you say WebKit is leading, but they are actually the last browser to support the resolution media query. Firefox, Opera and Internet Explorer already have support.

    • 6

      You’re quite right about the 96dpi problem. But here’s the thing: this post, as mentioned right at the beginning of it, is from the future. Yes, we currently live in a world in which all browsers report 96dpi regardless of device or actual pixel density, but the fault there lies with browser makers.
      The fact that WebKit have implemented the resolution media query is a hint, if you will, of things to come. Nevermind the fact that the W3C are being utter boxheads and saying that the web should keep being 96dpi because it would break existing content (what a load of bull). The guys and gals at WebKit and not just them have realized that we cannot move forward without going into the physicality of web capable devices.
      So, yeah, your comment is very much valid. For today’s world. But that’s not what this post is about. It’s a glimpse into the (hopefully) near future.

      • 7

        I see your point. I just want to make clear that the resolution media query (and min-resolution/max-resolution) is not what you want. They report CSS inches and this fact is in the spec (it isn’t a browser fault, it’s the official way). Since the web never breaks compatibility, this media query will never return physical DPI.

        But I understand you’re talking about a hypothetic future feature. So I think it’s better you call it a “min-physical-resolution”, hoping that it’s added to the spec in the future. Just don’t use the currently “min-resolution” because it isn’t what you mean and it’ll never be. Avoid making people confused.

  4. 8

    Why don’t you just design for the ATSC standard display size of a 16 by 9 aspect ratio and be done with it? You’re spending way… too much time on creating a solution to a problem that doesn’t exist.

    • 9

      I agree actually. The evolution of higher PPI on all the different sized devices being manufactured will actually make your head explode. I’ve recently started using 16×9 as my primary ratio, and usually start at the highest resolution and DPI possible. Usually 300 since it’s print ready. So pretty much, everything that is produced must first be print standard, as well as uploaded to the file database in full format. At that point, I rely on javascript to generate down-samples of the images to other resolutions and DPI for retina displays as well as caching them. It works the server CPU hard for a few minutes, but the end result is beautiful.

      A few scripts I’ve found are retina.js, Adaptive Images (New Nine makes a WP version), and BJ Lazy Load (WordPress) to help generate cached images at specific breakpoints.

      This has helped set a standard for aspect ratios, and formats. I’ve added a few formats to the list: Movie Poster, Panoramic, Post Card, Portrait, 4×3, 16×9 (1920×1080, 1280×720 and further down to 320px width for small mobile devices.)

      This has also lead me to completely avoid using the wordpress thumbnail cropping completely, but using manual cropping for each image incase it needs a proper format cropped.

    • 10

      Jason Featheringham

      May 18, 2014 10:52 am

      16:9 as a future design methodology is complete bunk. The only reason it is somewhat reliable now is because manufacturers are copying the Television ratio. Videos fit nicely in a 16:9 screen right now, but movies, for example, are moving beyond that skew. TV will soon follow, and devices won’t be far behind.

      Furthermore, video may not always be the medium we idolize or copy.

      Think beyond media.

  5. 11

    When I read this: “Sure, this beast of a device is unlikely to ever become reality…” , I immediately though of Apple’s recent(?) patent for the slap-bracelet style watch, which alluded to a very long, very narrow, flexible screen.

    http://www.patentlyapple.com/patently-apple/2013/02/talk-about-timing-apples-wristwatch-patent-arrives.html

    So… maybe not those exact dimensions, but in the same category for sure.

    Very interesting article though. Thanks for putting it together.

  6. 12

    Marc-André Boivin

    March 21, 2013 1:20 pm

    While i find this reflexion really interesting, i’m still thinking about some issues. There would be many design differences between an interactive wall where the user must touch the wall, and a really big TV screen that he will watch from 6 feet. For example, the buttons size would be very different, don’t you think?

    But anyway, i was not aware of the resolution media query and i find your theorem a good place to start. Keep up the good work!

    • 13

      You’re absolutely right.

      I also missed that point when checking out ways to design in physical sizes last year.

      If we as web developers got the possibility to do adjust our layouts depending on real physical size (or to design in physical sizes), we have to know the distance to the user as well.

  7. 14

    So PSINET = (height or width in pixels) / (resolution in pixels per inch) , right?

    That formula reduces to PSINET = inches.

    So PSINET score appears to be a very fancy way of saying “this big” in inches. (My 27″ iMac screen is 13″ tall, just like your table says, but from now on I will say “my iMac has 13 PSINETs” — way cooler.)

    Those of you interested in physical units might be interested in this:
    http://smus.com/physical-units/

    Also, as someone who recently completed an adaptive project, I recommend using clientWidth and clientHeight to get “device size”. These values don’t represent the number of pixels on the physical screen, but rather the number of pixels of “space available”, if a “pixel” is basically the size of a traditional pixel (regular computer screen pixel before Retina days).

    So if clientWidth is 320, that’s a phone. if it’s 4xx, that’s a big phone, 700 is a tablet in portrait, etc… (naturally you look at both clientHeight and clientWidth to get device orientation).

    In CSS you can use min- or max-width. Those media queries compare to a value that is almost always the same as clientWidth.

    It’s easy, it works on 95% of devices, and while it won’t give you real-world units you do have to ask yourself why you would really want that in the first place.

    • 15

      I like the way you think, Oliver! Your technique with using clientWidth is the next best thing right now, but I still think using actual physical measurements is a more natural way of designing for humans. We’ve been thinking in pixel so long, it’s like we’ve forgotten that the natural way of doing things is by measuring actual distances. You wouldn’t ask someone how many pixels tall he or she is, right? As far as real world applications, I touched on that in the second to last paragraph of the post.

    • 16

      Oliver, are you talking about the regular stack of min-width media-queries to get to a usually correct design for most devices in existence right now? Or are you touching on something more than that with clientWidth? I don’t see how your example differs from the standard device-agnostic mq’s we already use.

      If there is a difference, please explain how it works because I’m looking for something like that!

      My problem is basically what is addressed in this article – the best example being the full HD phone that will display my responsive website the same way as a decently sized desktop monitor – except that due to the screen-size the user once again will have to pinch and zoom to be able to read the content.

      Are you saying there’s a way around that?

      Thanks in advance!

  8. 17

    Great, and informative article. Thanks.

  9. 18

    This is interesting but I think you’re not looking far enough… What about the distance between the viewer and the screen ? Think about a screen in your glasses in comparison to a tv screen. This will have to handled to get the right design don’t you think ?

    • 19

      While the ergonomics of data consumption is outside the scope of this post, I understand your view and have, in fact, taken it into consideration. Whether we like it or not, there’s a generally accepted comfortable reading distance and while you’ll most likely find various values assigned to it, it will always be somewhere around 2x-3x times the diagonal of the device on which we’re reading. I highly doubt we’ll ever be in a position to be reading something 10 inches in diagonal from across the room.
      Taking this into consideration, calculating a PSINET Score still makes sense. If you’re finding users who prefer to read your content on 6 foot diagonal TVs, you’re very likely to get a PSINET Score higher than 10 for that user niche. And then, of course, adjust design accordingly.

    • 20

      I’d assume that the bigger the device is physically the further the user is looking at it from. I wouldn’t say this holds up 100%, but comparing a TV to a desktop to a phone, which are in order from biggest to smallest, id say they are also in order from the distance users typically view them at.

  10. 21

    It’s gives us a lot to think about or at least a lot to keep up with in terms of knowing the size/res of up coming devices! lol

    What is your suggestion for handling images in different size stages?

  11. 22

    Get rid of css and it replace with standardized super strict layout specific javaScript. That would cause HTML to be data specific with no layout trickery injected ( I’m looking at you div-ites and navigation elements ). Articles about responsive design would become a thing of the past along with css3 and html5. Those are both broken answers to the problem.

    You could use variables like device width, device resolution, and relate elements based on properties that you set yourself.

    I know saying css sucks is not going to go over well here, and that this kind of standardization would never happen.

    • 23

      And what, pray, do you gain by pushing the problem into a different language space? It’s still the same problem, and you still need to rely on what the device chooses to report. JSSS was alive and well and living in Netscape Navigator 15 years ago, and it was no more a good solution to the problem then than it would be now. (Oh, by the way, if your HTML is not currently “data specific with no layout trickery injected”, you’ve been doing it wrong. Or worse, you’ve been supporting IE6.)

    • 24

      I believe you tried to learn html and css and failed everytime in it. Guess what, even my ten year old nephew can make websites and you can’t. Pity.

  12. 25

    Lucas beat me to it… the viewing distance does impact on the design. A smart watch and smart glasses could have the exact same size screen and PPI, but their visual impact is dramatically different.

    Similarly with a phone, tablet, tv & desktop; all four devices are likely to be viewed at from different distances.

  13. 26

    Very interesting post. thank you for adding to the RWD conversion. In response to viewing distance: I think it would be possible to add an addendum to your theorum defining a relationship between resolution, physical screen size (large, medium, small, “thin-long”) and suggested viewing distance. I’d imagine a theoretical “thin-long” viewing distance wouldn’t be far off from a small screen. And yes, thank you Webkit… thank you. Oh, and dig your love for the scientific method.

  14. 27

    What this means is that web design is in turmoil right now, there is no standard, everyone struggling to come up with the next trade-off solution to screen dimension and resolution problems we are facing. I say, we designers need to triple our salaries since we are in for a long roller coaster ride.

    • 28

      I agree, it’s not the prettiest solution, but in lieu of an actual physical query, we’re forced to work with what we have. I’d like to say it’s the first time we have to do it, but we all know that’s not true. Remember the old way of doing what a placeholder attribute does now? How about rounded corners in IE7? PNGs in IE6? The list could go on and on. Sure, PSINET seems a bit strange at first, detecting physical characteristics by inferring them from known parameters, but soon as you know it, someone will decide there should be a spec to address it and in 10 years we’ll all be laughing about it. It’s a process, I guess, and one that has driven frontend web development forward for the past 15 years.

  15. 29

    There is a slight inconsistency between the “BREAKING THE THEOREM” paragraph text and the following table. The ThinLong resolution of 40 × 240 (text) as opposed to 24 × 240 (table). The PSINET score for 40 × 240 would be 3.35.

  16. 30

    Here is something to help:

    link: “http://members.ping.de/~sven/dpi.html” calculator of DPI.
    o/ lol o

  17. 31

    I can’t quite believe that you actually want to use inches for this purpose.
    Inches are a non-standard legacy unit, originally defined as the size of King Henry’s thumb*, that are nowadays only used in the United States and Great Britain.

    If you really want to go with physical measures in CSS, why not use the internationally accepted (and also well-known amongst the English-speaking folk) metric units?

    [*] Today, it is defined as 25.4 millimeters or 2.54 centimeters.

    • 32

      Oh, you little troll! Of course most people, myself included, would use the metric system. I could never, for the life of me, get used to thinking in feet and inches. The fact that I used inches in the post is only because the post is written in, well, English. Naturally, I mentioned units most familiar to people in English speaking countries: inches. That and the fact that most device manufacturers size their creations’ diagonal sizes in inches.
      But, hey, at least you mentioned the conversion rate between inches and mm/cm. Someone might remember that for future reference, so thanks for your comment!

  18. 33

    Tarun Bhadauriya

    March 23, 2013 7:03 am

    Great article. Thanks.

  19. 34

    With the exception of choosing higher-resolution images, it seems to me that media queries based on ems would be more beneficial than media queries based on DPI+pixel-width (-height). Regardless of the screen density and width (or height or ratio), if we’re using a meta viewport width=device-width and use em-based media queries, then the ems automatically address how much space we have to work with. What am I missing here?

  20. 35

    Great Article, I am very much familiar with media queries.

  21. 36

    Your PSINET score for the Sony PSP is wrong. You’ve used the larger of the two width and height dimensions for your calculation. Just a head’s up. Fascinating stuff.

  22. 37

    Excellent article. The resolutions are key. I am definitely going to give this a try.

    -Erik Karkheck

  23. 38

    Henk C. Meerhof

    March 29, 2013 3:12 am

    Here we go again. This exact problem has been my issue since screen design.
    In history no screen was even outputting tho real world measurements.

    What ever the Virtual measurements are, at some time you have to put information into a system by photographic camera, scanner, imaging program, etc. This alone is generating many challenges and discussions (and miss believe)

    Later on we want to get this info out a again. And I second them before that we finally change ti the SI-system. So if I draw a vector image with a line 10 mm long, I want it to show 10 mm of line on every device. No matter what resolution, no matter what physical size of the screen.

    The only thing remaining will be viewing distance. he design project will specify if it is for a hand held device or not.

    What I don’t understand is this the screen is a physical part of the device, so I can measure 10 mm on the screen with a ruler! This points to the solution, if the screen is attached to a device, we have to instruct the device with information about the screen in place. Simple calibrate the measurement of the screen. Now if we say a line is 10 mm its will be 10 mm.

    Now to pixel related information, as the calibration define a measurement in mm’s you can easy tag an image to be shown at , say 30 mm wide. Yes if this was a very low res image it will show its pixels. This is an effect we all have seen a long tome ago, solutions are similar.

    PS. I did not read all posts.

    Henk C. Meerhof

  24. 39

    Thank You for the Awesome Post. there is becoming a fine line between tablet size and mobile size… and this will help define that, at least a little for us.

    Thanks

  25. 40

    hi, your are right Responsive Web Design can only be possible With best Physical Units. Today web design of a website is very important to increase traffic for it. I want to say thanks for this good information and hope in future i will get more and more like this.

  26. 41

    Bernardo Antunes

    April 1, 2013 1:45 am

    Hej,

    Nice article. I believe that you will like a proof of concept that I created last year about real units, where I show a working webpage that can calculate real units and that at the same time is responsive.
    Real units are the only way that designers will be able to present their design as it was designed and not an approximation.
    You can see it working and explained here:
    http://asdesigned.bernardoantunes.com
    And please, tell me what you thought about it. ;)

  27. 42

    Aren’t PPI (Pixels Per Inch) and DPI (Dots Per Inch) completely different?

  28. 43

    I think I am missing something…
    The manufacturer knows the size of the screen and the PPI, right? So why does the manufacturer not embed that information in a bios-thingy? If I know the PPI and the width and/or height of a screen then it would be a very simple matter to display anything true to size?

    • 44

      Yes, display manufacturers encode physical display width and height details in the EDID (I guess you could call it a “bios-thingy”) and native applications can read this information and calculate the PPI by dividing resolution by physical distance. I honestly don’t know why browser vendors don’t make this info available through a Web API.

  29. 45

    Thanks Radu.

    Very useful stuff! We also published a blog post, it’s about the basics of responsive development and has some great tips in: http://brightbyte.co.uk/responsive-development-the-basics/.

    Thanks Again.

  30. 46

    Good job, i´ve been explaining and evangelizing in my corp., very few understand what it entails.
    I hope that all of this will become an standard.

  31. 47

    Hi

    I am working on a responsive website but there is a problem in it. If anyone can help then it will be grt.
    http://wordpressboon.com/bon/
    See the above site, if you see this in ipad landscape version then the footer is leaving some gap at bottom, how can we fix this /?

  32. 48

    Woooww!!, Pretty updated report with the sizes of almost any device!!. I love it!. I also found very helpfull this link that I do not see in this Post or any comments:

    freakzion.com/index.php/The-Blog-February-2013/mobile-screen-sizes.html

  33. 49

    Great thought exercise. I really like the concept and approach, plus the table gives me new insights into setting better thought out breakpoints as an interim solution.

    Two ideas to consider for expansion on the concept, taking into account the comments about distance from the screen.
    1) Base the calculation on the short side dimension instead of the diagonal as it would give a more precise measure of acceptable pixel density and solves the apple wristband example. This removes the variation among screens having different aspect ratios.

    2) I think grouping devices on their ergonomics might give more insights. One commenter pointed out that optimum viewing distance for TVs is in proportion to the diagonal and this is all to preserve an optimum viewing angle in degrees for the optimum immersive experience. That works for detached screens from desktop to wall mounted where the optimum viewing distance is greater than arms length. Grouping 2 is the interactive display, where because the screen is hand-held or being touched, the optimum viewing distance is a bent-arm’s length. This even applies to the interactive video wall in the use case where you need to be close enough to touch it, regardless of it’s size. Because the primary determinant of position is holding the device comfortably, the viewing angle is no longer the dominant factor. Left isolated is the glasses mounted screen because through the use of a lens it simulates a distant screen. For these, the TV/monitor approach works.

    Applying this distinction, I think you will find that there is a very consistent recalculated PSINET score for Group 1 as manufactures realize that packing more pixels than the viewer can perceive from the optimum viewing distance into a screen is unnecessary cost.

    As for group 2, they are not at the optimum viewing angle and so pinch and zoom are the solutions to simulate the detail they could see on a detached optimized monitor positioned at the same viewing distance. All devices in this group would have the same bent-arm viewing distance. The lowest PSINET scores would identify devices that are furthest from optimum for that distance – that the lack of resolution becomes apparent in perceptible jaggies, but they also consume far less bandwidth.

    Appreciate the thought exercise – it gave me a new perspective on designing for the small viewport as regardless of screen size/res, the text has to remain readable at the bent arm length viewing distance and that is best measured in mm or points. It also supports dropping resetting body font to 62.5% or any other override because the manufacturer of these devices is presetting the default em to what is optimum to display the smallest easily readable system font for that device’s ergonomics. Instead use rem to calculate fonts relative to that built-in calibrated font sizing to get a look that translates well from device to device using the manufacturer’s determination of optimum for their native screens and apps. Then using a content-out approach for setting columns in ems to preserve measure, this approaches a very device-agnostic design where CSS media breakpoints are used to adapt layout (column positioning) to fit screen geometry while retaining readability.

  34. 50

    Deborah Michaliszyn

    July 25, 2013 9:38 am

    Hi,
    I have read this halfway, but the question arises to me, why can’t use percentages on the fonts, but allow 100% for p, so that the end user decides the font they want on their device, and all my site does is scale to fit without interrupting the design.

  35. 51

    I’m glad this article and http://alistapart.com/column/responsive-typography-is-a-physical-discipline exist. There are innumerable use cases for web sites & web applications with awareness of a client’s physical monitor size. One thing that kind of annoys me is the arguments that some people (like on a few StackOverflow posts) have AGAINST this kind of awareness. And as a result, there’s a lot of circulating nonsense out there as to why knowing about physical units is bad or impossible to implement:

    1. A whole boatload of UI designers that have been forced to learn 4x over about device screen layout independence (WPF/Android/iOS/CSS) and as a result they think designing anything using real life coordinates on a client’s screen is evil. They also seem to assume anyone simply expressing interest in such a metric is not as educated as them in the fine art of UI design. There are actually a lot of cool things you can do with availability of such information… I just don’t get why people are so hostile towards this.

    2. There’s big lie spread around everywhere that “The OS simply CANNOT KNOW ABOUT THE PHYSICAL SCREEN” this is absolute bogus. Utter garbage. I wish someone had a loud enough loudspeaker to correct this. I made a simple program which demonstrates that EDID data is accessible even on Windows XP https://github.com/amannm/NativeDeviceMetrics/blob/master/WindowsDeviceMetrics/WindowsDeviceMetrics/main.cpp toss that into your Visual Studio and run it. It’s based off of this article http://ofekshilon.com/2011/11/13/reading-monitor-physical-dimensions-or-getting-the-edid-the-right-way/ which outlines a bunch of additional strategies. I’m sure Linux and OSX have a similar native API that lets you read these EDID blocks. There are NO TECHNOLOGICAL HURDLES preventing a native program like a browser to access EDID information and make a subset of it available through a Web API.

    3. People who want their apps to have physical display awareness ALWAYS seem to phrase their problem statement incorrectly. They often encapsulate the issue inside of the whole “Hey, my DPI isn’t 96 ! This needs to be fixed!” and the response is almost always some people giving a long history of the definition of DPI and Microsoft and OSX and W3C and blah blah blah. End result is no action, for example: https://bugs.webkit.org/show_bug.cgi?id=11644

    People with these problems need to stop conflating their need to access physical display attributes with this whole DPI rubbish that’s all mixed up in Media Queries and Meta Viewport and devicePixelRatio. That whole area is a mess. The only way to get what we want is to not even mention any of that other stuff because its much harder to convince people to change something rather than to add something new.

    Can we just get some window.physicalXDPI and window.physicalYDPI attributes or something?

  36. 52

    Hi,
    I am webdesigner from India. I can make your site responsive. Please reply to this mail if you are interested. Thanks.

    Cheers,
    Hariharakumar

  37. 53

    Just to tell you that this web site provide a copy of your article without attribution ( #Shame ) :

    http://designwebsiteblog.com/mobile/responsive/responsive-web-site-design-with-physical-units.html

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top