Responsive Typography is a Physical Discipline, But Your Computer Doesn’t Know It (Yet)

by Nick Sherman

18 Reader Comments

Back to the Column
  1. Well said, Nick, and such an articulate explanation of my own thoughts that I have struggled to define. We all must encourage those that define the technology we use to embrace this challenge. We must also be patient, as we know these changes take time and will, in the future, be refined to a point of usefulness. This also demonstrates why it is so important for all of us to remain current with the status of technology and technique. Just when you might think our skills and technique have matured – surprise – we gotta read up to keep up! Thanks for a terrific article, Nick!

    Copy & paste the code below to embed this comment.
  2. Eddie — I agree that patience is a virtue with these things, and I definitely don’t want to make it seem like such changes will be quick or easy. I just want to make sure we don’t all get too comfortable with how things currently are, or even how they are shaping up to be, without taking a step back to think about the bigger picture. Now if we only knew how big that picture actually was …

    Copy & paste the code below to embed this comment.
  3. PPI (aka, DPI) is a complicated issue. Most desktop and laptop displays already provide EDID as an API for accessing their PPI; however, Microsoft largely ignores it in Windows, instead choosing to use a default of 96. Apple does basically the same outside of their retina displays, but instead uses an even more appalling 72 PPI. The Linux landscape is even more complicated, with most distros attempting to imitate the look of Windows.

    It’s possible to set the correct PPI in all three operating systems, but almost no users do so. The result is that outside of a few OS aware exceptions (retina displays) the higher the PPI of the users display, the smaller text will render.

    Complicating the issue even further, many of todays displays don’t have square pixels, resulting in slightly different horizontal and vertical PPI values (often by only a single pixel). For the two big OS providers, this is particularly problematic, since their platforms only allow one PPI value for both horizontal and vertical rendering. Which means fonts render with an ever so slight skew. Thanks to X11, Linux is capable of handling horizontal and vertical PPI values that differ, but only for applications that use the modern font configuration, terminal applications and the like that still use the legacy configuration are still stuck with the same problems as those in the Microsoft and Apple worlds.

    The sad truth is that until the OS vendors decide to set the correct PPI, browser vendors don’t have very many good options on the table, if any at all. And since setting the correct PPI would cause a noticeable difference which some users might complain about, it’s unlikely that any of the OS venders will change their implementations anytime soon.

    Copy & paste the code below to embed this comment.
  4. Austin — Thanks for the insight. Now I’m quickly falling down a rabbit hole of researching EDID and DisplayID (EDID’s apparent successor). In the cases where the user can set the actual PPI, will specifying CSS sizes in “absolute” units, like inches, actually produce the expected result in any OS/browser environments?

    As with many things related to web standards, it seems to be a bit of a chicken & egg situation, where the W3C doesn’t have a spec for actual size because OS vendors don’t set the actual size and so on. I’d be curious to hear your opinion about what you think is the most realistic next step that will do the most for shifting things in the right direction. I have my own opinions but it’s always great to hear from someone with another perspective.

    There are of course all kinds of other variables I didn’t even get to touch on in the article, like what to do with projected images where the resolution isn’t as easily knowable, or non-rectangular pixels that might operate under different rules. Those kinds of things seemed a bit less relevant given the current state of things though.

    Copy & paste the code below to embed this comment.
  5. On a small note, because most of the article makes quite a lot of sense, we can determine “how big is this pixel” already, it’s just not a single function call. If you truly care about physical dimension, you use something like this:

    var div = document.createElement(“div”);
    div.setAttribute(“style”,“position:absolute; top:0; left;0; width:10cm; height:10cm;opacity:0”);
    document.body.appendChild(div);
    var w = div.clientWidth / 10,
        h = div.clientHeight / 10;
    document.body.removeChild(div);

    and now we know the size of a pixel. In FF, Chrome, Opera and even IE 10, these all report 37.8 for my screen right now, for instance. If I want a page with type based on physical dimensions, I’d inject something similar to this (with a few more lines to ensure .removeChild doesn’t resolve before computerStyle kicks in – yay optimised JS+DOM) and know the physical size of a pixel, and consequently how big I want to set type.

    Copy & paste the code below to embed this comment.
  6. I think this is overthinking things a little. All CSS needs is a “anally retentive” mode, or “hobgoblin” mode. You flick that on, and suddenly everything makes sense: px are pixels, cm are centimeters, pts are points. Switch it off, and you’re in the rabbit hole of the w3c assuming you’re mentally disabled and re-rigging everything as per the new rules.

    As for EDID/DisplayID, It’s almost always worked for me. I think in the late 90s and early 2000s it used to have issues and the prevailing wisdom has been to not trust it, and that kind of behaviour has been ingrained. Perhaps we have a hobgoblin mode in the browser, too, so the user can specify that they’ve checked all this and you really seriously can trust that they know how to hold a fork.

    Copy & paste the code below to embed this comment.
  7. Mike — Perhaps I’m missing something, but if your JS+DOM method is indeed reporting a resolution as 37.8 pixels per centimeter, that is the same as 96 pixels per inch. I’m guessing that’s not the actual physical pixel density of your display, but just corresponds to the situation that Austin described. Have you tried rendering a 1 inch square using your method and measuring it on the screen with a ruler?

    Sunny — Whenever I ponder how to get past this unfortunate mindset of “but if we change things to work the way they should, all our old documents will look weird”, I usually end up thinking about something similar to the “hobgoblin mode” you mentioned.

    Another idea I’ve considered is that if there was some way to declare which version of the spec your CSS code was meant to work with, we could theoretically change the CSS specs as dramatically as we want from version to version. So you can say “this CSS was written according to the CSS spec version 5.0”, and then the browser could treat your pixels as they are spelled out in CSS 5.0, even if it is a completely different method than how pixels are treated in CSS 4.0.

    Copy & paste the code below to embed this comment.
  8. I guess you are quite right about the whole problem. You definatly can see where this is going, when you look at Apples Retina Displays, that pretends to have half the resolution that it actually has, so all the absolute pixel values in websites still make sense. But increase the „simulated resolution“ of your retina display and nothing makes any sense. A pixel is neither a pixel nor four pixel. Something inbetween. How tall are 10 Pixel? No idea.

    I also think this will end in unimaginable chaos if we can’t get the browser to tell us, the physical size of the display in relation to its resolution, or the ppi. Everything else will end up in always making body text about 16 to 18 pixels, hopping it won’t get to small or to big on any display. And I guess this will really hurt the progress of webdesign. How am I supposed to to make a side note in a small font size, if everything below 14 pixels bears the risk of becoming unreadable small.

    I once took the time to put together a list, of how many Points a font with a certain pixel size is on certain common Displays. For example:

    18 pixel font
    MacBook Pro Retina@1024 = 16,5pt
    MacBook Pro Retina = 12,4pt
    iMac = 11,9pt
    MacBook Pro Retina@1920 = 8,8pt
    Samsung Galaxy SIII = 4,2pt

    12 pixel font
    MacBook Pro Retina@1024 = 11,0pt
    MacBook Pro Retina = 8,3pt
    iMac = 7,9pt
    MacBook Pro Retina@1920 = 5,9pt
    Samsung Galaxy SIII = 2,8pt

    While this seems quite interesting, the only valuable information you can get out of this, is that you have no chance at all to get things right. If you set your resolution to 1024 a 12pixel font is way bigger, than a 16pixel font the same display with a resolution of 1920.  8,3pt seems fine, 5,9pt would be quite small even in print. This doesn’t even take into account that most displays have a much lower resolution than acutal print.

    Copy & paste the code below to embed this comment.
  9. One question – how does this play with viewing distances?

    I have two 1920×1080 computer displays near me that I view on a regular basis, one 24”, one 50”. I sit about 20” away from the 24” display, but I never get closer to the 50” display than around 120”.

    Thus, pixels on the 50” display are smaller perceptually (despite being physically bigger) than on my 24” display – a test with a checkerboard pattern shows that I can see all 1920×1080 pixels on the 24” display, but I can only see around 1280×720 pixels on the 50” display at my normal viewing distance. If I move closer, I can see all 1920×1080 pixels, but that involves climbing on furniture.

    Note that printed media doesn’t have this problem – in general, printed media is easy to move closer if the type is too small. It’s video displays that have the problem, because they tend to be awkward to move.

    Edit to add: Really, what you want to know is two things; the size of a pixel in arc-seconds, and the size of the display in arc-seconds. CSS px (defined as the visual equivalent of 1/96th of an inch at arm’s length) are a reasonable alternative to arc-seconds here (as they’re just a funny way to count sizes in arc-seconds, just as inches are a funny way to count sizes in millimetres), and I wouldn’t therefore argue against wanting to know the viewport size in px, to allow you to pull tricks like removing the sidebar if it’s going to take over the layout.

    Copy & paste the code below to embed this comment.
  10. There are media queries for screen DPI.

    http://www.broken-links.com/2012/07/13/using-media-queries-to-test-device-resolution/

    Copy & paste the code below to embed this comment.
  11. This question completely mis-understand the digital medium. Consider this example; text rendered at 1 inch in height on my laptop screen; totally legible. Text rendered at 1 inch in height on a JumboTron at a basketball game; stupid. There is no use case for being able to force something to render at an exact dimension. Beyond that, as is clearly illustrated in examples with projectors, it’s simply impossible. I often work with live shows, where there is a projector duplicating what is on my laptop screen. The two render at the same resolution, but are NEVER the same physical size, nor should they be.

    Copy & paste the code below to embed this comment.
  12. Simon — Viewing distance is a whole other can of worms. I considered addressing it in this piece, but decided to leave it for the sake of sanity. The ideal situation would be that viewing distances could be explicitly factored in, but obviously that’s a bit optimistic at the moment. There are also instances where one single viewing distance isn’t as relevant because there are many people viewing from many distances/angles. In such cases, knowing the real-world specifics of how big the display is will at least get you a rough idea of the situation.

    I agree that knowing sizes in arc-seconds (or even estimated arc-seconds) is helpful, but in order to do that, I don’t think we should eliminate the ability to address actual device pixels. That is essentially what CSS “reference” pixels do.

    myfreeweb — Yes, I am aware of such media queries. The problem with them, and the point of my whole article, is that they don’t actually correspond to actual physical resolution.

    Josiah — I think you are misunderstanding my argument. It is less about making things the same across the board and more about making them different in appropriate and informed ways. There are indeed ways to know the size/distance of a projected image, but that is less of what I’m focusing on here.

    For a more relevant example, consider the iPad and the iPad Mini. Both of them have the same resolution as far as a website can tell, but a website will render at completely different sizes between the two. Of course the viewing distances might be different, but it is not at all unreasonable to want to modify the design to better suit each device. Even if the apparent size (in arcminutes) is the same between the two when you factor in viewing distance, that doesn’t mean the same design will work just as well for both cases. For instance, I would probably want smaller margins on the iPad Mini than on the full-sized iPad. This example is even on the relatively subtle side of the spectrum. Resolution differences are much more vast between other kinds of devices, as Marcus demonstrated in his comment above.

    Copy & paste the code below to embed this comment.
  13. Great points Nick (pun sorta intended). I have always thought representing a “correct” physical size is a fundamental component of good typography, digital or not. It’s actually quite surprising that this topic isn’t discussed more.

    Copy & paste the code below to embed this comment.
  14. I don’t think real resolution media queries are necessary. I agree with Josiah, it’s all about the viewing distance.

    Nick, you talked about iPad vs iPad mini. I don’t think we should adapt to these differences. They’re the same pixel size for a reason: the user will buy the one that better fits its case and the perfect viewing distance for her.

    The Samsung Galaxy S3 and Samsung Galaxy Note 2 have the exact same issue: they have the same resolution but different physical sizes. The user chooses the best device and use it accordingly. If she buys a Note2 it’s because she wants everything to be big; if you adjust your design according to physical display size, you’ll frustrate this user.

    I believe we, as developers, should program thinking about pixels. And let device manufacturers set the ideal physical size according to the viewing distance intended. And let the user choose the device that better fit her use case.

    Copy & paste the code below to embed this comment.
  15. I agree with Sunny – this is over-thinking things a little.

    The web works best as a flexible, fluid medium. The decisions we make as designers are best-practise based approximates as to what will work for a given user/demographic/device. Aim for the middle and let the user customise their experience from there. Good enough?

    The problem is less about designers inability to accurately gauge size, density, viewing distance etc, and more that the user’s reading experience is inconsistent across apps, websites, etc, through lack of sensible defaults or control over font settings.

    Oh well, let’s muddle on :-)

    Copy & paste the code below to embed this comment.
  16. I completely agree with the author and I’ve been considering this for quite some time now, we can only hope os/browser makers work in this direction for the future!

    Sérgio and Alan:
    It’s actually not that simple, if designers are unable to know how the final output will look in terms of sizing, the medium is very hard to evolve. Design (and typography) is about creating the best possible experience for the end user. We have to consider what kind of situation your most important user might be using your service.

    That means we have to consider things such as actual screen size and from that information work with what would be the most optimal reading distance. If we can predict these things we would be able to successfully create something entirely new that doesn’t break as soon as the user switches medium. OR it might not even be something entirely new, but something that just works perfectly without any hiccups.

    If web design was all about finding the best average solution and then let the OS/Browser makers decide what would be the best sizes and reading conditions, why not stop designing all together? We could do just as well with unstyled web pages and let everything depend on browser defaults (and hope that the browser defaults are getting a bit more mindful about these things in the future)! Okay I might be over over-exaggerating a bit, but you get the point. It all comes down to what design really is and why design is important in the first place.

    Copy & paste the code below to embed this comment.
  17. Have you tried using viewport units for your font sizes?
    Set a sensible fallback, and you can use it everywhere, like so
    h2{font-size:24px;font-size:4vw}
    then the font is always in proportion to the screen size (for all browsers that understand it)

    Copy & paste the code below to embed this comment.
  18. I’m glad this article and http://mobile.smashingmagazine.com/2013/03/21/responsive-web-design-with-physical-units/ 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?

    Copy & paste the code below to embed this comment.