For ideal typography, web designers need to know as much as possible about each user’s reading environment. That may seem obvious, but the act of specifying web typography is currently like ordering slices of pizza without knowing how large the slices are or what toppings they are covered with.
If someone asked me how many slices of pizza I wanted for lunch, I would probably say it depends on how large the slices are. Then—even if they told me that each slice was one eighth of a whole pie, or that they themselves were ordering two slices, or even that the slices were coming from Joe’s Pizza—any answer I might give would still be based on relative knowledge and inexact assumptions.
Such is the current situation with the physical presentation of responsive typography on the web. The information at a designer’s disposal for responsive design is virtually nonexistent outside the realm of software. Very little knowledge about the physical presentation of content is available to inform the design. The media query features of today can only relay a very fragmented view of the content’s actual presentation, and related terms from CSS are confusing if not downright misleading.
The immeasurable pachyderm#section2
Among all the physical qualities of web typography, the elephant in the room is the issue of size. I’m not talking about em or rem or “reference pixels” ¹ or even device pixels. I’m talking about real, actual, physical, bona fide, measurable, size!
It’s ridiculous that we can send robots to Mars yet it’s still virtually impossible to render a glyph on a web page and say with confidence: “If you measure this glyph on your screen with a ruler, it will be exactly 10 millimeters wide.” Although actual physical size isn’t always the most important factor in web design, in some cases it is critical. For example, consider content for partially-sighted or low-vision readers: the ability to tweak designs according to physical sizes would enable designers to make conscious design decisions with much more sensitivity to how the type is actually being seen. And even where physical sizing is secondary to relative sizing, why shouldn’t we nevertheless be able to factor in physical size when establishing the relationships between different elements?
Physical considerations ≠ print design#section3
I don’t believe web typography should be a screen-based imitation of print typography. One of the greatest benefits of web typography, and web design in general, is that it is flexible, adaptable, fluidly adjustable, without being locked into any one specific configuration. However(!), that doesn’t mean web designers should be forced to design without any means to address the issues of physical presentation. On the contrary, responsive design will not reach its full potential until it allows the ability to respond to the very important physical variables of digital media.
Please pardon the cliché, but when it comes to typography, on screens or otherwise, size matters. Physical size affects optical issues that change how the eye and brain process typographic images. Not surprisingly, typographers and typeface designers have been compensating for optical size-related issues as far back as Gutenberg.
You can’t expect a paragraph of type with the same relative line-height, column width, letter-spacing, and glyph proportions to function just as well on two different displays that have the same number of pixels but completely different physical sizes. It’s great that designers can adjust proportions between typographic elements if the canvas varies in relative size, but any such compensation is still based on guesswork and assumptions about the physical size of that canvas. When people disagree about the size or spacing of type on a website, there’s a very good chance that their opinions are based on completely different physical manifestations of the same content, even if their software and settings are identical.
Resolute resolution, absolute absolution#section4
One of the most crucial factors in the size equation is resolution. And when I say resolution, I don’t just mean “how many pixels is this?”, or even “how many device pixels is this?”, but also “how large are these pixels?”
This is very different from the W3C’s “resolution” media feature in the current draft of the Media Queries Level 4 spec. You will note that the spec refers to resolution in terms of “CSS ‘inches’”—the quotes around “inches” are theirs, implying that they are not actually inches at all.
For an example of why physical resolution matters, imagine you are rendering text on a digital billboard with a physical resolution of one pixel per inch (1 PPI). Now imagine you are rendering the same text on a 200 PPI mobile device display. Even if you knew the actual number of device pixels that would be used to render your type (which itself is difficult to do with confidence these days), you would want to treat the two compositions very differently, both in terms of the typeface as well as typographic layout. The billboard type would likely require less space between letters. The letterforms themselves would benefit from narrower proportions, and could endure a higher ratio between thick and thin strokes. The type might even require different colors to optimize contrast at that size. These are all basics of typography and typeface design.
Unfortunately, in the current landscape of media query features, there is no way to know the difference between 16 device pixels on a crude LED billboard and 16 device pixels on a high-density mobile display. Heck, there isn’t even a reliable way to know if your type is 16 device pixels at all, regardless of how large the pixels are!
Pixels still rule, for better or worse#section5
I know what some em-based enthusiasts might be thinking: “But you shouldn’t be specifying type sizes in pixel units to start with! All type sizes should be spec’d abstractly in relation to each other or a base font size!” However, in the current world of web typography, no matter what unit of measure you use to spec your onscreen type sizes—em, rem, px, pt, in, %, vh, or whatever else—at the end of the line, your specification is being mapped to pixels. Even if you leave the base size of your document to the defaults and specify everything else with em, there is still a base size which all other sizes will ultimately refer to, and it is defined in pixels.
This is because, currently, the only unit of measure that can be rendered onscreen by any operating system with absolute confidence is the lowly pixel. Until we have media query features that allow us to spec for situations like:
@media (physical-resolution: 1device-pixels-per-physical-inch) { … }
or:
@media (device-width: 10physical-centimeters) { … }
… any compensation for physical size is based entirely on rough guesses about the devices our content will be presented on.²
It’s a complete fallacy that the official CSS spec allows so-called “absolute” units of measure like inches, points, and centimeters to be mapped to anything but actual physical units. Ironically, previous versions of CSS treated these things as you would hope and expect, but a change was made “because too much existing content relies on the assumption of 96dpi, and breaking that assumption breaks the content.” Call me idealistic if you will, but I am more of the mind that a spec should be written based on what is best for the future, not to cater to things that were made in the past.³
Getting physical#section6
Any ability to leverage physical variables for web design will require a joint effort by several groups:
- Device manufacturers will need to provide APIs that can inform the operating system—and, by extension, web browsers and web designers—of the actual physical properties of the hardware being used to present content to the user. Some device APIs are already beginning to show up in the world, but there is a long way to go before functionality and adoption are anywhere near dependable.
- Standards organizations—the W3C in particular—will need to establish specifications for how to reference physical properties when formatting content. They will need to update (or at least augment) their existing “absolute” units of measure to be more meaningful, so they are more than just multipliers of sizeless pixels.
- Software manufacturers will need to implement support for new specs relating to physical media features. Browsers are the most obvious software that will need to implement support, but the biggest challenge might be in getting native support for device APIs in operating system software.
- Type manufacturers and type services will need to provide more diverse ranges of typefaces that have been optimized for a variety of physical properties. Ideally, many of the needed variations could even be provided on the fly using a broader approach to the ideas of font hinting.
- Web designers and developers, last but not least, will need to build their sites to respond to physical properties, leveraging all variables to the benefit of their users.
Size and resolution are just the tip of the iceberg of physical variables that could be considered when improving web typography. Things like viewing distance, ambient light, display luminance, contrast ratio, black levels, etc., etc., could all be factored in to improve the reading experience. Even the ability to know some variables within the realm of software, like the user’s rendering engine or the presence of subpixel positioning, would go a long way toward helping web typographers design a better reading experience.
In the meantime, I’d love to see more of the players mentioned above start to at least experiment with what’s possible when physical features can be specified, detected, and factored into responsive designs in structured, meaningful, and predictable ways. Until we can do that, we’re all just ordering pizza without knowing exactly what will end up on our plate.
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!
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 …
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.
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.
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.
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.
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.
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.
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.
There are media queries for screen DPI.
http://www.broken-links.com/2012/07/13/using-media-queries-to-test-device-resolution/
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.
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.
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.
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.
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 🙂
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.
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)
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?
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.
Thesis
Both tablet and smartphone, respectively Samsung Galaxy Tab 10.1 (resolution 768×1024 px, pixel density 149 ppi) and Samsung Galaxy S2 (resolution 480×800 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?
Assumptions:
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: http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density#Samsung