For one thing, different fonts have different design characteristics. In particular, the x-height of one sensible body font at a nominal 16px could easily be 50% more than the x-height of another. Sadly, while CSS lets us specify a stack of fonts to try, it doesn't yet let us specify a different size to go with each one so we can achieve a similar optical result. (CSS3's font-size-adjust might be intended to help here, but seems overcomplicated and underpowered to me.)

For another thing, these days pixel densities can vary by at least a factor of 3 between devices. The latest iThings sometimes do better than the 300dpi that used to the be benchmark for a laser printer. For a classic CRT or cheap and cheerful TFT, something more like 96dpi is common. At least you can detect this to some extent in CSS, because the new devices with very high densities also tend to support media queries so you can present larger text (in pixel terms) and higher resolution graphics accordingly.

If we're going to improve the way we present text (and graphics) on the web for people whose vision isn't perfect, it's going to take a much more flexible styling system for the web and probably a lot more real world experience of what works and what doesn't as well. As much as I respect people taking a stand on behalf of those who can't see as well as some, I'm not sure advocating a fairly arbitrary 16px guideline is helping.

It pains me to point this out, but the solution to this particular problem is that CSS has redefined what "pixel" means, or rather, they've made "px" stand for something slightly different. Specifically, the "px" specifier now is a scaled length unit, and corresponds to whatever length subtends the same arc in a user's field-of-view as would a single pixel on a typical desktop display at about two feet away. So technically, in order to know how many pixels a px is, you need to know the resolution of the display, the size of the display, and the distance from it that the user will be sitting.

(Argh)

Given that CSS also recognises length units such as pt, which make far more sense if you really want to specify a physical size for something like a font, distorting the meaning of "pixel" doesn't seem very useful. It's a little like idealised fluid layouts, which quickly gave way to the practical benefits of more controlled layouts and more recently to responsive designs that are specifically tailored to the strengths and weaknesses of different browsing environments. Good design often requires an element of precision, which you simply can't specify if browsers keep moving the goalposts.

Safari on iPhone uses that definition (that's the whole "resolution doubling" thing, in a nutshell).

Gecko uses that definition, including on mobile devices.

In fact, that definition is almost universally _used_ in cases where it matters (i.e. high-dpi displays).

> Given that CSS also recognises length units such as pt

Which are nowadays defined in terms of CSS px, because otherwise sites break. So 1pt == 1.3333px in CSS in most modern browsers.

That's my point, though: no-one is really implementing CSS-px. What they're doing is implementing approximations, like doubling everything up on a high-dpi screen because the pixel pitch is roughly twice what you get on a typical desktop monitor, which is close enough to be workable.

If browsers implemented CSS-px as specified, then on all the monitors in front of me, the text on most pages I have open right now would look the same size in Firefox, and not noticeably smaller on some monitors than others. Also, all those beautiful, crisp n-pixel borders on mobile-friendly sites would look terrible (because they would be rendered with different degrees of fuzziness due to the antialiasing on different mobile devices) and everyone's photographs on Facebook would be blurry. Of course, that's a silly idea, and no browser actually does it (other than when zooming).

Most of the major mobile browsers (possibly all by now) support restricting the viewport and zoom so you can match your site to real, physical screen properties instead of whatever virtual viewport size they pretend to have by default. IME, a fairly high proportion of mobile-specific and responsive pages now start by switching this on. No-one's going to change this functionality any time soon, because vast numbers of mobile-optimised sites would immediately break. Fortunately, that means we can go into real-physical-dimensions modes and then use media queries to select an appropriate layout (including text sizes) for smaller, high-dpi devices as part of a design, without sacrificing precision in cases where the time and money is there to work on the fine details for best results on that kind of device.

The definition of CSS-px (for low-res devices, which includes all the mobile stuff so far; high-res in this context is print) is:

  it is recommended that the pixel unit refer to the whole
  number of device pixels that best approximates the
  reference pixel

  the visual angle of one pixel on a device with a pixel
  density of 96dpi and a distance from the reader of an
  arm's length.

So the whole point is to approximate the reference pixel by doubling your device pixels (or tripling, or whatever).

I think you may be thinking of a different definition of CSS pixel that used to exist a number of years ago (when "px" and reference pixels were the same thing). That definition is no longer in the spec, and hasn't been in a while. And that's precisely because of the antialiasing issues you mention.

Given that the point we're debating here is the merits of setting a minimum 16px body text size, that would mean the next alternative was 32 physical pixels on a display of roughly 200dpi resolution. While that might be useful, you could still find that depending on the physical properties of your devices, 16px text needed to render at say 24 physical pixels to look the same size to the reader.

When you've got that kind of uncertainty to work with, I stand by my earlier comments that an arbitrary 16px size without reference to either the specific font or the physical properties of the device isn't a particularly useful guideline. The design considerations for devices with such different physical properties are too complicated to dismiss with a simple scale factor.

BTW: Different fonts do work better at different sizes, and the article specifically mentions that fact.

There won't be any magic bullet solution. Specifying text size in terms of pixels gives you tiny words on super high resolution iDevices or even modern laptop screens. Specifying size as an absolute via points or inches/cm doesn't work for users lacking the visual acuity to see that size. Specifying size relative to a user-settable device default only works for users savvy enough to find that setting. What we've got now is a mixmash of the above, where devices treat an absolutely-specified size as a baseline to scale from via zoom controls.

But hey, web font scaling is still twelve parsecs better than the original option of going out to buy the large print edition of whatever you want to read.

I also use my own style sheet, with my own choice of font. I use a slightly modified version of one of the w3c core styles.

In Firefox, I just set a my own font, a minimal font size of 16px, and my own link, background and foreground colours.

The web to me is just plain ugly outside my browsers.

I am now on Chrome which zooms uniformly and when HackerNews comments are just barely readable, the 'reply' links seem to be twice their size, when in Safari they were the same (minimum) size. Neither approach is pretty. :(

(There are workarounds but they shouldn't be necessary.)

You can always cut and paste instead.

I've been zooming since Netscape.

No privacy in the office for me sadly.

HN is unreadable for me without a little fine tuning.

I've successfully reduced the bounce rates on a few sites with that hack alone. On others it made little difference. I guess the older the audience, the more pronounced the effect.

Was this a tested hypothesis or is it literally a guess?

Unlike more recent experimentations, I did not conduct a formal AB/multivariate test, but the font size had been the only internal change at the time. Also, I have no idea whether these lower bounce rates translated into higher revenue.

Also, all of the sites mentioned above were female-oriented.

"Your browser's current zoom setting is not fully supported. Please reset to default zoom."

I'm seeing a growing number of comments here that read like "I can..." or "I prefer..." The article clearly states this is a decision arrived at by considering the end-user. It's all relative; all sites don't need to be that way. You should be user-testing every project with your target market anyways, and if you were and it was a problem you'd hear about it. I know I have, many times.

Another great article on this subject is one "Relative Readability" by Wilson Miner:

http://www.wilsonminer.com/posts/2008/oct/20/relative-readab...

The clients I mentioned are organizations with thousands of employees, and (at the very least) dozens of very large departments. Their decisions are always made by committees made up by representatives from these departments, and they all want equal or more attention. You just can't teach clients like that and stay within a tasteful budget. All you can do is creatively mitigate.

It's not all bad, though. It's just another puzzle to solve, only this time the solution isn't in code.

(Sorry for straying so far off topic from the original article)

Last thing, I just hate sites that use facebook comments - eg techcrunch - because fonts don't scale there. As a matter of fact, I never read comments on those websites.

http://userstyles.org/styles/54719/ctrl-plus-text-resizing-f...

This fixes Ctrl+Plus on LinkedIn as well as sites using Facebook comments.

I use my own style sheet with opera, and customise firefox flipping between the two, and occasionally breaking out into chrome.

I also find the terminal more readable than the browser, so have made my browser look like the terminal - I even use a monospaced font. Because that is what I'm comfortable with.

W3m and Elinks are actually really nice to use, readability wise.

Funny to read your highlight method, I use that when away from my computer.

Which is sad. My eyes aren't very good too and they prefer bigger fonts. In fact, most people have vision problems those days.

Of course, that all depends on how much you need to zoom in. For me, that's about 6x.

Funnily enough, the top bar in the article page broke at that scale, pushing "Directory" down.

Personally, I had to downscale it twice (not sure to what %) to be able to read comfortably.

Well, at least now I know why I'm constantly having to turn the fucking lights on when reading something on paper - that seemed like a new development. I'm 42.

When we used to use 640x480 and 800x600 monitors, the browser defaults - for something like a h1 took up most of the screen. That's half the reason designers (before the advent of CSS) didn't use semantic markup. They'd just use bold to mark up a heading at the body text size. We had pixel images used for text in navigation at 10px. With something like 12px for body text (and tables for layouts.)

There were also radical inconsistencies between the browsers, with their text size rendering defaults.

I'm also pretty sure that the 16px default font size was a late edition. Either way a bit of history would help the article.

Plus, as many have pointed out, the fact that 16px appears differently depending on screen resolution, distance from the display is an important point that should have been stated.

The article may have been better arguing that making a website more readable is better for users and sustained readership.

This fault is honestly an order of magnitude more common among webpages that are specifically discussing user-oriented design. Argh.

So claims such as '16px is the same as most books' are clearly nonsense.

The difference in terminology is subtle to look at, but huge in practice.

The problem is: due to the need to mix and align with bitmap graphics, web design is most convenient when specifying font sizes in pixels (except for simple pages, like HN and such, fluid designs cannot cover most cases in a mainstream enough fashion).

So, given that, he had to mention a specific pixel setting. But he took into account most common DPIs. For the majority of users they do not vary that much, around 100-120 dpi.

(Btw, have you read the article? He is aware of that, and he even gives examples of 16px in different DPI screens).

I know there isn't a good current alternative in the web world, but shouldn't it be a goal to not have to specify pixels anymore? Obviously mobile browsers already largely ignore/change pixel font sizes.

(If you didn’t notice, we are talking about the web here.)

In the short term, that pragmatism should include web devs not trying to lay everything out pixel-perfect so it breaks if the user hits "zoom". The diversity of screen sizes and browsers and DPIs is greater than it has ever been, and will only increase.

That may be true, but beyond a certain point, it doesn't matter.

In terms of physical size, it makes sense to have a single-column layout for small devices, where layout techniques like using multiple columns are never going to be very useful no matter how high the resolution gets. You might prioritise some content more highly and reduce or eliminate less valuable material to go with this. It also makes sense to allow for layouts that do have wider areas and/or multiple columns if the content can benefit and the display medium can support it. I doubt anyone is going to want to render most web pages with dozens of columns any time soon, though, no matter what physical size a screen might reach. Most content isn't going to benefit from that, because the human eye and brain can only take in so much at once anyway. So the big question here is how many discrete layouts are useful in practice, with a whole load of secondary questions about the balance between showing more content at once vs. allowing user interaction to navigate content in different ways.

In terms of resolution, the consideration is different, but there is still a general case. At low resolutions, it is worth having specific, pixel-perfect designs. At somewhat higher resolutions, it is worth having different pixel-perfect designs, to give sharper results at a similar physical size. Sometimes it is best if pixel-based designs don't try to copy all the detail of the "true" designs as they get smaller, but present simpler, cleaner versions of the same basic idea instead. At some point, your resolution gets high enough that scaling vectors representing the "true" designs by default and using techniques like antialiasing and font hinting becomes a viable alternative. Somewhere beyond that, vectors alone would be sufficient, as the eye isn't powerful enough to see any more detail anyway. The big questions are where on this scale you change from one pixel-perfect format to another, and how many such formats you produce before you switch to using scalable vectors.

In the real world, of course, these two ideas interact at times, and there is a cost/benefit trade-off as well. Perhaps you would prefer to have three sizes of pixel-perfect versions of all your custom graphics plus a vector, but in reality you might have only one or two and accept that content will appear at significantly different physical sizes on different devices. Perhaps you would like to have a responsive design with four different layouts, but in reality a mobile-friendly version and a regular site will do. You'll still be able to cater well to many different devices with only a small number of combinations if they are well thought-out, though.

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

A realistic strategy today is to assume a typical desktop monitor by default, since not all popular desktop browsers implement media queries to a useful extent. Then you can add specific CSS sections for hardware with very different parameters, such as screens on mobile devices. Usually being both newer and more in need, mobile OSes and the browsers running on them typically support media queries better, so while not always ideal, this approach works fairly well in practice.

Maybe for copy text it's ok, but not for other page elements, ones that we want to align in a specific way to bitmap images, no.

The page-zoom style resizing is our best bet --it's the "resolution independent" way to have your pixels and eat them too.

Now, if we could provide bitmap assets that could be zoomed in the same way, instead of just showing bigger but more pixelated (as we can in application icons in OS X), we would be done.

The most common way (used for icons) is to provide multiple bitmaps and load the right one depending on screen DPI. You can do this on your site too.

And there's of course vector graphics (SVG), if you don't mind some extra processing on the client for rendering...

As for SVG, client rendering time would be insignificant for most case (for a desktop machine at least, they have CPU to spare). But currently used IE version (> 6) for one don't support SVG. And the main problem are bitmap assets such as photographs. Those cannot be done as vectors.

Btw: why would you have to watch resize events? Changing the size of the browser window (even rotating the screen/phone) doesn't change the DPI.

Specifically the paragraph where he inserts smaller fonts into the middle of his paragraph, hoping to shock you with the difference in size.

Here is a screenshot of that paragraph with the body text actually set to 16px: http://i.imgur.com/mcdNI.png

10px is still tiny, but 14px doesn't appear nearly so 'weaksauce' any more.

As I said, I DO like larger font sizes and think he has a good point. But misleading comparisons like this bug me and I felt I had to set it straight.

http://www.filterjoe.com/2009/03/25/filters-for-reading-on-t...

and suggest solutions for web design here:

http://www.filterjoe.com/2009/03/23/site-design-for-reading/

A main theme of my site is how to read without distraction on the web. As has come up a number of times on Hacker News, the tools readable and readability are a terrific way to reformat web pages in order to make them more readable:

http://www.filterjoe.com/2011/04/11/web-page-reformatting-se...

One last trick is to arrange a high pixel density monitor vertically and place it far away from your eyes. You can calculate the distance needed to attain the equivalent of a retina display:

http://www.filterjoe.com/2011/02/26/the-best-monitor-setup-t...

Whether this makes a difference in terms of readership, conversions, etc. I have no idea. But the proliferation of tools in the past few years to help people read web content suggests that a lot of web users are struggling with reading web pages.

For me, the most pleasurable reading experience I can think of is Instapaper on an iPad. What's the default size on that? I could be wrong, but I doubt it's anything larger than 14-16.

Besides, is it really a "costly mistake"? Is Facebook is failure because the text is small? Is Apple's website is design disaster? Both sites (and many more) feature a mix of large and small text with modest sized body. They're navigation is thought out and structured.

The 16 pixels argument encourages the opposite of that.

Incidentally, that makes it perfect for, you know, reading. Are your books too flat?

While we're at it (and I still find their layout beautiful): "Good branding is not pretty; it’s bold, sweet and simple" - http://www.informationarchitects.jp/en/ugly-ugly-coca-cola-m...

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("news.ycombinator.com") {

    .title{
        font-size: 16px !important;
        padding: 0.5em !important;
    }

    .subtext{
         font-size: .8em !important;
         padding-left: 0.5em !important;
    }

    .comment {
         font-size: 16px !important;
    }

    .comhead{
        font-size: 1em !important;
    }

    .pagetop{
        font-size: 16px !important;
    }

I mixed px and em as I tried different settings, but just stopped when I found something I liked.

I doubt it:

The distance the eye moves in each saccade (or short rapid movement) is between 1 and 20 characters with the average being 7–9 characters. Thus, the most impressive fact about fixations (the point at which a saccade jumps to) and saccades is that there is considerable variability not only between readers, but for the same person reading a single passage of text. - [1]

I'm not saying you're wrong, but that would put you at the extreme end of the bell curve; it's more likely you're not aware how much your eye is moving.

1: http://en.wikipedia.org/wiki/Eye_movement_in_reading

One thing that slows down a reader is focusing on individual words. Try instead to focus between two words, and use secondary focus to pick out the words next to it without re-focusing.

http://www.speedreadingtechniques101.com/meta-guiding

Seriously, is there a distinction to be made between reading for facts/information (skim, scan, locate, focus) and reading as art (micro scale language and music in the voice, macro scale navigation of the plot)?

Does this distinction translate onto the Web? Is there a literary role for hypertext (pace Mark Bernstein)?

The article doesn't target a specific type of site. Article sites or news sites rely on readability far more than startups. The article seems to suggest that you NEED copy to guide users. This statement is incorrect. You can guide users with whitespace, color, images, buttons, hover states etc.

If you have a startup landing page with lots of copy on it, regardless of font-size...you've already failed.

But I still prefer the smallest fonts on my e-reader, and relatively small fonts on my iPad and laptop computer.

While I don't mind larger fonts at 16px, I'm not willing to make that tradeoff for improved readability vs. not having to scroll as much.

A counterpoint: NYTimes.com sets their article paragraph font size at 1.5em (with a roughly equal line height).

Crazy-speak IMO, and I suspect I'm not the only one... perhaps someone in the standards community could explain the rationale.

I guess to do it correctly you'd have to write javascript to reliably detect the DPI on all platforms/browsers (as far as possible, if not make some educated guess) then adapt your text sizes to that :(

So I can certainly understand 'just choose 16px and be done with it'.

And that is by the way another reason I love fixed size layouts: you can zoom them however you like.

See this for example, (at 12px)

http://www.smashingmagazine.com/2011/10/05/smashing-coffee-m...

Also on slower hardware - zooming is a drag, and it can be slow.

The browsers do allow for customisaton, and I think this is probably the easiest thing for an end user. I use a minimal font size of 16px, and that works for me. But it does break some sites - Facebook's layout has been broken over the last month like this for example. Which is fine if you kind of understand the reason for it, but could confuse other users. Just as some navigation breaks, think of horizontal nav, that falls onto another line when the text size increases - I'm thinking hover states, and drop down menus.

If he were reading a magazine and you said "do you find the text to be too small", you think he might turn to you and say "what do you mean by text, I'm reading a magazine here, there is no text."