Hacker News new | past | comments | ask | show | jobs | submit login
16 pixels For Body Copy. Anything Less Is A Costly Mistake (smashingmagazine.com)
386 points by m1nes on Oct 7, 2011 | hide | past | web | favorite | 142 comments

This is an important issue to consider, but talking about "pixels" alone doesn't get us far in this context.

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.

> For another thing, these days pixel densities can vary by at least a factor of 3 between devices.

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.


Yes, CSS has an unhelpful definition of pixels, which AFAICS is almost universally ignored. No doubt it was well-intentioned, but in the real world, pixels have fixed sizes and display devices do not have infinite resolutions. The difference between professional quality web design and an amateurish mess can be as simple as paying attention to the real pixel grid that your beautiful vector icon/font/whatever will be drawn on and shifting/hinting/whatever accordingly.

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.

> which AFAICS is almost universally ignored.

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.

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

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.

> What they're doing is implementing approximations

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
and the reference pixel is defined as:

  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.
See http://www.w3.org/TR/CSS2/syndata.html#length-units

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.

Yes, the official W3C recommendation changed to CSS2.1 earlier this year, and they did effectively redefine a CSS pixel at that stage. I'm not sure this did more than swap one problem for another, though: as I read the (current) wording, we shouldn't get fractional physical pixels any more and basic arithmetic still works on pixel lengths, but now you can only scale up by a factor of 2x, 3x, etc.

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.

Yeah, I agree that saying "use 16px font-size" without mentioning at least the font family is completely useless.

I agree completely! When I started using my 27" Apple Cinema Display I was in heaven, except for having to squint to see stuff. The monitor is really great but it has a insane resolution that tends to make text much smaller.

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

I agree completely with this article. As I've gotten older (now 43) I have had more and more trouble reading web sites. In fact, I've noticed lately that I don't even try on some sites that have "small" fonts, I just close the tab. There are some sites that I really like and I generally depend on my browser to help me out. Chrome has a good habit of remembering my page zoom on a particular site so I don't even notice the font problem on subsequent visits.

Another solution is a custom style sheet. Opera has had that capability forever, since about 2001. I use Opera for most browsing, with a custom style sheet to force all text to a certain font and style. This varies by device: Calibri 12pt is the most readable at work where I sit close to the screen on a smallish monitor, while Verdana 12pt works better on my home desktop and laptop screens. My stylesheet also forces text color to black-on-white, very useful for some forum sites that seem to like the scary gothic gray-on-dark look.

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.

+1 for Opera. It is the only web browser I can get to obey my own style sheet.

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.

You can also define a "minimum font size" in your browser options. This trick really changed my life. Sadly, the rendering can turn ugly on websites with a poor and/or overly complex design (e.g.: facebook.com).

I used 18px minimum in Safari for a long time and I'm just 25. If a site breaks, you can just hit cmd+'+' to zoom it up, which will usually fix the layout.

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. :(

I'm 23 and I zoom in on plenty of sites.

The worst is when zooming breaks the layout causing some of the text to be located outside the viewport. I can't think of a specific example right now but it has happened to me a few times and it's infuriating.

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

Get glasses!

I have contacts that correct my vision to just about 20/20. Maybe I just have higher than average DPI screens, but most sites (hn included especially) are simply too small for me to sit at a comfortable distance and read comfortably. I don't know where the rest of you eagles come from.

Agreed. Eyesight doesn't get better as you get older, it only gets worse. Why strain your eyes trying not to "look old"? Your eyes should be relaxed when you read.

+1, I'm 53 and will soon start using reading glasses. I find myself hitting Ctrl-+ a few times on a lot of Web pages. I run many 'commercial' sites through the readability bookmarklet to calm them down.

I'm a big fan of the Readability bookmarklet (readability.com/bookmarklets), which lets you set the page's font, size, colors, etc. As a bonus, it nukes most of the clutter such as ads and sidebars.

This is nice, but if you want consistency, and you browse alot, you have to use a different solution. Unless you are quite patient.

You can always cut and paste instead.

I'm 41 and have been experimenting with different contacts prescriptions for a couple of years to try to put this off, but I just got my first pair of reading glasses yesterday.

I'm with you; I had great vision until i hit my forties and now at 45, I'm squinting more and more. With the aging baby boomers I'm surprised there isn't an uprising of discontent over this issue.

For boomers it's the tip of the iceberg of technology complaints.

25, moderate myopia and astigmatism (thanks Mom and Dad, respectively), fully corrected with glasses, I zoom in constantly. Including on HN!

Same here only a decade on your age.

I've been zooming since Netscape.

No privacy in the office for me sadly.

HN is unreadable for me without a little fine tuning.

On the surface the statements seems to make sense and the arguments are well put across, but unless someone actually A/B tests it and proves that it makes a difference to readership, or conversions (or whatever your goal is) then it's currently just unsubstantiated theory.

5 points of karma says null result, but I'll have at least one anecdotal data point for you in a few days.

Awesome. I'd be interested to see results. Email me if you get any data your happy to share (details in my profile).

Thanks. Please post results to HN, we'd love to see 'em!

One little known tip that I've been using for years to reduce bounce rates is to increase the text size by a few pixels.

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.

>I guess the older the audience, the more pronounced the effect. //

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

Literally a guess. I've worked with very few sites that target older consumers, so my data points are limited, but in one of these the bounce rate dropped by more than 20% (home decor industry).

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.

I find myself zooming nearly 80% of the sites I visit now, including Google Docs. And I'm always a little bummed that Google's Spreadsheets give me this warning:

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

Same here; since Chrome remembers your zoom settings per-domain, I sometimes forget which sites I'm viewing zoomed versus in the default sizes, so when I use a fresh browser or a different computer it comes as a surprise how unreadable some of my frequently visited sites are (HN being one).

Working closely with designers and observing client requests over the past decade or so, I've seen another pattern that also leads to the "small type" problem: Client requests to get as much above the fold as possible. Granted, the majority of the projects I've worked on in the past four or five years have been very large organizations. When client committees make decisions, it's much harder to teach them or even steer them in the right direction.

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:


I think if you need to shrink things to fit it above the fold, it's time to reconsider what you're putting there. I've never had trouble fitting everything important comfortably above the fold, but I'm only working with my own projects.

I absolutely agree. I also agree with the theory that you should teach, coach and influence your clients with what your team has learned over the course of your career.

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)

I'm 37 and I zoom almost every website I use - I also like to be distant enough from the screen. I also very often use ctrl+A to have white text on blue background (I know, most designers will hate me at this point - but keep in mind that I usually sit in front of a screen 12 hours a day, 10 hours a day on weekends...).

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.

Here's a userstyle for you:


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

Seriously consider an alternative. Tweak your browser to your liking. You can always break out into a different browser, if you want to see the site the way the author intended.

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.

Thanks for the suggestion, but I prefer to give the designers at least a chance to impress me ;)

I'm all for it. I zoom 70% of websites I visit, and I'm only 20 and don't have particularly bad sight -- I'm able to read unzoomed websites, but it's too wearisome.

Most web sites break down when fonts are upscaled. Sad but true. I configured my mother's firefox to do that, it works, but most of the web doesn't look good.

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

You can use NoSquint to upscale entire pages globally (much like Firefox's built-in per-site zoom). It doesn't mess up layout like font-only scaling, though it can do that too, if you want.

The problem with scaling the entire layout is that you end up with a lot of horizontal scrolling, in a lot of cases, which is more annoying than a semi-broken layout.

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

Then you learn most mobile sites disable user scrolling, because of a bug on iOS that causes non-standard zoom levels to cause text to wrap off the screen when changing orientation. So if you did this and your site isn't readable on someones device, they can't even fix it.

Thanks, I was wondering why so many sites are broken on WebOS.

>Most web sites break down when fonts are upscaled.

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.

Another nice solution with Chrome and Opera is to set a default zoom. Up it to about 140%, and it will scale the page without breaking it.

"At age 40, only half the light gets through to the retina as it did at age 20."

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.

Is there a reference for this? The link on the site only goes to another site that makes the claim. I'm very close to 40 and haven't noticed this... though perhaps the brain compensates for it.

I didn't verify it. I can tell you anecdotally that when I was 39.9 I didn't notice any issues, the change started very soon after 40. Mainly just the typical "my arms are too short" syndrome, I can still see like an eagle further than 2 feet in front of me. However, lately I've noticed in low light I have a harder time than I used to.

Interestingly the browser defaults have changed over time.

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.

I think I need to put together a form email, or possibly a webpage to link to, to send to web designers who pontificate about web design and reaching your audience---on a webpage that doesn't fit in my window AND has disabled my scrollbar. Meaning I literally cannot read it without sending it off to Readability or otherwise adjusting my browsing setup.

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

Opera has a nice fit to width toggle.

Am I missing something? The physical size of a 16px font will surely vary based on resolution and screen size.

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

Note that the author means "fonts/sizes that are 16 pixels tall" NOT "16 point fonts" (which is what you get when you pick 16 in MS Word or whatever).

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

* for common pixel densities.

He means "for the most common monitor DPIs", duh.

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

Can we get over specifying text size by pixels already? You don't know what DPI monitor I will have when I look at your pages.

What’s the alternative? I know of no PPI-aware way of specifying font size.

Display PostScript - circa 1987 (thanks, Steve Jobs).

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.

It’s a valuable goal but just that. A goal. It’s necessary to be pragmatic in the meantime. No point in dreaming.

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

I understand the difference between pragmatism and dreaming.

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.

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

CSS3 media queries can help with this:


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.

Unfortunately we can't.

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.

Now, if we could provide bitmap assets that could be zoomed in the same way

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

Yes, you could provide multiple bitmaps in a website now, but in a convoluted way (with some custom javascript checking for resize events etc). In the icons case, it happens automatically.

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.

Sure... I didn't say that it would happen automatically, just that it could be done. Everything done on the web is convoluted.

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.

My bad, I meant resize as in zoom-in out (Ctrl +-) of the page in general, not the $(window).resize().

I generally agree with his argument, but I don't appreciate the way some of the examples were framed. They were a bit misleading.

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.

If you ask a variety of people how readable they find a typical web site, you'll receive almost uniform responses that many (or most) pages are difficult to read. Font size is a factor but there are many more factors, which I outline here:


and suggest solutions for web design here:


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:


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:


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.

Or, better yet, don't set the font sizes or font faces on your web site. I picked defaults that work for me. Don't override them.

The biggest failing I see this is argument is hierarchy. Sure, 16 point Georgia looks sexy as hell. If you have a text heavy website with little navigation, I'd definately recommend it. But in real world design situations, it's a mess. Even the Information Architects site looks flat. There's no easy way to guide the eyes because everything is ultra readable. There's no structure. It's an idealistic shortcut to readability.

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.

> Information Architects site looks flat

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

I installed the https://addons.mozilla.org/en-US/firefox/addon/stylish/ addon for firefox and have set news.yc to use the following stylesheet:

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

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

        font-size: 16px !important;
        padding: 0.5em !important;

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

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

        font-size: 1em !important;

        font-size: 16px !important;

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

This is a great one site solution, but it get's a bit tedious personalising each and every site individually.

Interesting, but at that size of font used on that webpage I read at half speed and I'm 37. For the hacker news site I can read a full line in 3 focus movements. It's much easier to switch focus to the right than to find the next row in text. Not convinced but YMMV.

> I can read a full line in 3 focus movements

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

I've trained specifically on this by reading thick books of prose like Ulysses,Dhalgren,Gravitys Rainbow etc. where the context is more important than the specific meaning of a sentence, the goal is to try to read faster than I can think, and then parse the information when I have more context. It's also possible to read too fast for any comprehension at all, and then slow down a little and take advantage of speed-blindedness - you'll read faster than you did before.

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.


My own reading of Joyce is mediated through Paddy's Irish, Schubert (Winterreise), and Traviata (Bloom's solo). Music preferably from acoustic recordings.

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

For what it's wortjh, I used to be able to read small fonts comfortably when I was 37. Not that I'm 44, I can't. I read Hacker News with Ctrl-+, and I'm happy that Chrome remembers my zoom setting between visits, or I probably wouldn't have visited very often.

I love that feature from Chrome too. I zoom about 80% of the sites I visit now, and I love how Chrome remembers that preference for some of my most frequented sites.

Yep, when the eyesight starts to go down it goes pretty quick. I expect to be hit any day. Still at monaco 9pt.

I feel the presentation and line breaking has a lot more to do with that than the point size.

I agree. The font size displayed was simply too large to read comfortably, whereas HN is very easy to read. Nothing to see here...

How old are you?

I have been reading HN zoomed for quite a while now. I also code with larger than the default fonts because it's less wear on my eyes and I'm not 40 yet. I agree with what's being said but it would be helpful to show some study or research or A/B testing.

Some interesting facts in the article, however, saying a font is hard to read because it's too small is a bit of a loose statement. Font family, color, line-height and width (anything over 500px wide is a strain) all contribute to the readability of text. So a pink font at 16px stretching the full width of the screen (let's say 1400px) with default line-height might be easier to read if it were 13px, dark grey, 450px wide with 20px line-height.

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.

Does this equate to setting the base font size to 1em in CSS?

Yes, unless (if I'm not mistaken) the user has changed their default font size.

Maybe I'm just different, but I like smaller font sizes. It makes it easier to take in more text quicker and do it with less scrolling. I am 26 though. I'll probably change that opinion when I'm 40. I think having the browser zoomed out one level looks best to me on some sites.

I'm 41 and I've not changed my mind yet. But I guess I've been lucky with my eyesight so far.

I'm also 41, and I've recently had to take my glasses (for near-sightedness) off for anything at reading distance.

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.

He gives some interesting data points, but ultimately fails to prove the headline that "anything less is a costly mistake". In order to do that, he'd have to take a sample of websites and show a correlation between copy size and profitability.

Personally I'm a fan of bigger font sizes. Interesting though that Facebook actually reduced their body copy down to 11px, and apparently they are doing pretty well ;)

Definitely also just had mentioned the same thing before reading this. But do you think that they should increase their size? I often tend to look closer to read posts and also just followed their font sizes in a similar project =\

Does the median Facebook user have younger eyes than the rest of the web?

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

I'm 24 and I still even zoom NYT (though that may be just so that the article fills my view.)

Facebook also has a lot more elements (basically, images) to deal with than an average website with significant lengths of (narrative) body text.

I think facebook has more going for it than the fontsize.

I thought the article was impossible to read at 16 px - just not enough density - too few words per line and too few lines per screen to read comfortably. I'm 46.

Seconded, and I'm 26.

Each to their own.

Why "16 pixels"? Wouldn't scaling fonts based in cm/inch make more sense to be resolution independent, especially important on mobile devices?

Many mobile devices ignore these units - to my annoyance - in favour of the "reference pixel" as defined in CSS. http://www.w3.org/TR/CSS2/syndata.html#length-units

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

Yes it's sad how in software development, the most straightforward ways to do something (just specify cm) are usually broken. It's always exception built on exception, different per platform, different per browser.

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

Yeah, I set my paragraph font size to 100%, which Chrome tells me is 14px at normal zoom level. Maybe I should bump it up to 115%.

While it makes sense to use a resolution-independent scaling, keep in mind that mobile should have a smaller font size in inches than a full screen, akin to the font size in a book. I certainly don't use my phone with arm outstretched.

I agree! Have been doing this on my sites for a while now. Another thing to note is that when the font size is small, the number of words that fit into one line increases. It's easier to read lines with less words (which is why newspapers use columns of short width) and using larger fonts in the same horizontal space achieves that.

Just checked. I read HN zoomed twice.

I zoom most of the sites I read mostly due to the number of characters per line. When it is greater than 120-140, I can't focus on the line I'm reading.

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

Re: fixed size layouts, I don't get this. You might be able to zoom these on the iphone, and scroll around the page easily with your finger. But I find fixed sized layouts can be a pain. Preferring fluid. Because at least I can resize the browser window - to get a good line length etc. It's annoying if you do zoom in and the text flows out the side of the browser. I don't enjoy side scrolling.

Why px and not pt? I thought fonts are traditionally done in pts.

Ironically, Smashing Magazine itself is not set in 12px…

16px you mean?

The rest of the site is 12px — only this article had a body copy size of 16px.

Yeah, that page is using a custom css.

See this for example, (at 12px)


I don't know how well it works for sites that are effectively applications, but I wholeheartedly agree when it comes to blogs, articles, and essays.

I am not as old as 40, still. My wikipedia, forbes are all zoomed up. I settled on 16/Serif at-least for personal sites and blog.

Do you think that we need to see changes in current social networks using 12-14 pixels for their body copy?

It's just as easy to hit [ CTRL + ] as it is to hit backspace. If you are worried about your users' ability or knowledge, then you can simply include a link that says "adjust text size up / down" and let them click that to get the desired effect. Browsers allow users to customize the font for a reason. It's impossible to claim a default size that everyone is going to like.

It gets pretty tedious, when you are doing this for 80% of the sites you are visiting.

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.

Just as most users don't know about Ctrl+, most users wouldn't know what "adjust text size up / down" meant either. My 60 year old father uses the Internet a lot, but he wouldn't be able to identify your use of the word 'text' with the words he reads on a website. Up or down to him would mean scrolling.

That's interesting. How else would one describe the words that you read on a website? It's text. Or copy. But text is probably more universally understood.

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

Oh please yes. cough Posterous

Just confirmed I use hacker news @ 298% zoom. Impressive :) Wondering what you all utilize?

Is there a way to use javascript to detect how far zoomed in most of your readers are?

This is what I always think whenever I visit John Gruber's blog (daringfireball.net).

Does anyone use this rule for setting their text editor's text size for programming?

pixels? Pixels are not a standard size, they vary across screens/devices. 16 pixels is anything from too tiny to read to giant.

Too large; didn't read


stopped reading when he started comparing pixel measurements with printed books.

Did anybody else have trouble understanding what "body copy" means? I know such things as "body font size" or so...

Body copy is a commonly used term.

Thanks. Seems to be common in typography, not so common in the HTML world. Guess where I'm coming from...

It's been a common phrase to describe generated textual content on an HTML page for a while now.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact