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

19 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. 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.
  3. 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”);
    var w = div.clientWidth / 10,
        h = div.clientHeight / 10;

    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.
  4. 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.
  5. 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.
  6. One question - how does this play with viewing distances?

    I have two 1920x1080 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 1920x1080 pixels on the 24” display, but I can only see around 1280x720 pixels on the 50” display at my normal viewing distance. If I move closer, I can see all 1920x1080 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.
  7. There are media queries for screen DPI.

    Copy & paste the code below to embed this comment.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Have you tried using viewport units for your font sizes?
    Set a sensible fallback, and you can use it everywhere, like so
    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.
  14. I’m glad this article and 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 toss that into your Visual Studio and run it. It’s based off of this article 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:

    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.
  15. After writing below post in my text editor, I found this article and many answers to my problem in it as well as in comments, but anyway, I decided to put it here as a contribution to the topic.

    I’ve started work on some RWD website and I got confused.

    In many articles on font sizes in RWD I could find in Internet [like link or link or other] I see logical statement:

    “For smaller devices you should decrease font size a little bit to obtain similar perceived, legible font size, due to the fact of holding device closer to eyes.”.

    Sounds reasonable, but it doesn’t work exactly in the way I would expect. I’m not sure if I don’t understand something here or don’t see some obviousness or maybe I’m right and the problem is real.

    For further reading you may want to follow this post with illustration of problem:

    Preceived Font Size Issue Illustration

    To dispel my concerns I’ve created simple html: Font Size test, but I only got more confused.

    In my example, I’ve created 3 elements:

    • 3em heading [48px]
    • 48px bitmap square
    • 1em paragraph text [16px]

    I’ve created also version with non-relative text sizes: Font Size test 2, but results are the same.


    Both tablet and smartphone, respectively Samsung Galaxy Tab 10.1 (resolution 768x1024 px, pixel density 149 ppi) and Samsung Galaxy S2 (resolution 480x800 px, pixel density 217 ppi) change sizes of every website element with little consistency.


    Experiment: First step

    I took screenshots from both mobile devices and pasted them to my monitor. It has 94 ppi, I measured it by drawing in Photoshop exactly 1000 px long line, put a ruler on it, it had 10,62 inches, so 1000/10,62 = ~94.

    Screenshots show, that every element on my test website has different size in px, and also different proportions to each other!

    Results are the following.

    On tablet:

    • 48 px bitmap square shrunk to 39 px,
    • 48 px heading to 36 px,
    • 16 px paragraph text increased to 19 px.
    • all proportions between elements have changed!

    On smartphone:

    • 48 px bitmap square shrunk to 23 px,
    • 48 px heading to 25 px,
    • 16 px paragraph text increased to 20 px.
    • all proportions between elements have changed!


    Experiment: Second step

    In second step I scaled tablet and smartphone screenshots to simulate their real-life dimensions. I calculated scale by proportions between pixel densities. For example, I scaled down smartphone screenshot to 43%, because 94/217 = 0,43.

    It fits almost perfectly if I literally put my devices on monitor.


    Experiment: Third step

    In a third step, I took a picture of all three devices screens holding them from the eye thereabouts respectively:

    • monitor: 70 cm
    • tablet: 50 cm
    • smartphone: 35 cm

    Step 3 shows that main statement read in articles mentioned at the beginning of this post is true only in regards to paragraph text. On all devices it has similar perceived font size.

    Bitmap square and heading are much smaller although they keep similar proportion to each other.


    Further calculations: How devices could calculate perceived font sizes?

    Theoretically, in order to achieve exactly the same perceived font size it could be calculated like this, from proportions:

    Perceived Font Size Formula

    And it seems to be fairly OK with my experiment. I’ll check this with my paragraph text on smartphone. What size it should be to perceive it the same as on desktop monitor?


    Distance eye - monitor is 70 cm.
    Distance eye - smartphone is 35 cm.
    Monitor pixel density is 94 px/inch.
    Smartphone pixel density is 217 px/inch.
    Paragraph font size on monitor is 16 px.

    16 [px] * 35 [cm] / 70 [cm] *217 [px/inch] / 94 [px/inch] = 18,46 px

    Target font size of paragraph text on smartphone should be: ~18,5 px, which is quite accurate. Of course, this font size changes when smartphone or desktop changes distance to the eye.


    Conclusion and final questions

    I can imagine mobile device browsers during rendering fonts take into consideration pixel densities of devices and assume some distances from the eye.

    My questions are:

    • why they don’t do the same with all rendered elements (in my example bitmap square resize is completely incomprehensible for me)?
    • why they don’t render proportions between element properly?
    • how to design RWD then? ;) Is there a way other to design / test / amend / test / amend / test…?

    Additionally, it seems that decreasing font size for smaller devices is not always definitely true. In fact, some websites do increase it. Example: link (more on link)

    Pixel densities reference:


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