Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Responsive Web Design With Physical Units

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 Link

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) > {



@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) Link

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 Link

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 Link

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 Link

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 Link

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 Link

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.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


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.

  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

      Deborah Michaliszyn

      July 25, 2013 12:29 pm

      yoi, fun…WURFL. I left that alone about 15 years ago.

    • 3

      Hei hei Jason.

      > Unfortunately, a lot of devices report incorrect dpi.
      How exactly do you query the device’s dpi in the first place?


  2. 4

    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.

    • 5

      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.)

    • 6

      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.

  3. 7

    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…)

  4. 8

    Sérgio Lopes

    March 21, 2013 9:12 am

    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):

    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:

    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.

    • 9

      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.

      • 10

        Sérgio Lopes

        March 22, 2013 7:17 am

        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.

  5. 11

    james Deering

    March 21, 2013 10:21 am

    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.

    • 12

      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.

    • 13

      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.

  6. 14

    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.

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

    Very interesting article though. Thanks for putting it together.

  7. 15

    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!

    • 16

      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.

  8. 17

    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:

    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.

    • 18

      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.

    • 19

      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!

  9. 20

    Vedran Milic

    March 21, 2013 6:43 am

    Great, and informative article. Thanks.

  10. 21

    Lucas Menant

    March 21, 2013 6:46 am

    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 ?

    • 22

      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.

      • 23

        Consider the very large screens you see on TV crime/action shows, where they are working with a very large (feet) touch screen, but are standing close enough that they can’t see the whole screen.

        Or consider Terry Pratchet: When asked why he had 6 monitors in a 3 x 2 array on his desk, he replied, “Not enough room for 8.”

        I use 3 monitors with a combined width of 5300 pixels / 50 inches.

        I’m working on making my site responsive. I started from a good place. My initial CSS was entirely liquid layout, using em spaces and percents, with the occasional pixel unit used for borders, margins and padding. It was good enough that I could read my site on an iPhone 4, (just barely) although actually hitting a link with my finger was tricky. So far I’m making good progress dividing into two layouts based on a single break point.

        In design we have to consider:

        * Where is the user looking from: For this perspective (pun, ouch) the critical ratio is viewing distance / physical pixel size. For monitors we typically are viewing them from between 1 and 2 diagonals away. For a phone we are looking at them from several times that. While I have 3 monitors, I only look at one at a time. 2000 pixels wide is about all I can handle at once.

        If I get further away, I can’t make out pixels, and so in practice, I use a lower resolution.

        The iPhone typifies the problem. The iPhone 4 has a 4+ inch screen, a nominal pixel size of 640 x 960. The iPhone 6+ is nominally 1240 x 2200 — very close in pixels to my monitor. But I can’t hold an iPhone 6 close enough to my eyes to take advantage of that resolution. My hands keep bumping my nose.

        The second issue concerns touch screens. Fingers are blunt objects, and also are not transparent. We need a reasonable target for a finger to hit. My iPhone 4’s keyboard is right at the edge of that target. Consider: An iPhone 4 and some mythical tablet with the same pixel dimensions. A page that is *really* hard to use on the phone is easy to use on the tablet. The screen is larger, but so are the pixels. But our fingers now take up fewer pixels.

        Overall, I think you are correct: We have a bit of a mess to sort through.


        Base website: 2 col disiplay, 20% side navigation, 80% content.
        Below 800 px wide, both nav and content divs are 100%. It will take me another day to make it usable.

    • 24

      Stephen Cronin

      March 21, 2013 8:31 am

      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.

  11. 25

    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?

  12. 26

    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. 27

    John Hatherly

    March 21, 2013 8:57 am

    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. 28

    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.

    • 29

      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. 30

    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. 31

    Here is something to help:

    link: “” calculator of DPI.
    o/ lol o

  17. 32

    Tarun Bhadauriya

    March 23, 2013 7:03 am

    Great article. Thanks.

  18. 33

    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.

    • 34

      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!

  19. 35

    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. 36

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


↑ Back to top