I'm all about readable fonts, though mikeyanderson is going a bit overboard in the too big direction.
He's also committing the fatal sin of mixing ems (for his h1 title font size) and px (for his h1 line height). The result is overlapping characters: http://i.imgur.com/tEplJmv.png
I've griped on HN (and elsewhere) more than once about small fonts, low contrast (http://www.contrastrebellion.com/ can't get enough good words from me), and the reading-friendly tools such as Readability.com (despite some recent updates I'm not entirely happy with), InstaPaper, Pocket, etc. The latter are a great way to avoid this pain with minimal effort, and "read now" bookmarklets make this pretty near instant for most users. The styles presented by any of these services would do well as a default for virtually all content-rich sites.
I also have become all but obsessive in restyling sites whose CSS fails me. Which is to say, most of them (including Hacker News: http://stylebot.me/styles/2945). Using the Stylebot Chrome plugin, I've created, as of this writing, 819 stylesheets (some applied to multiple sites, some the same basic "unstyled.css" sometimes lightly modified). I think I've reached the point where I can make some fairly definitive statements, at least as far as UI/UX goes:
⚫ Use ems. Do not use px (graphics positioning excepted). NEVER mix ems and px.
⚫ Provide a high contrast between foreground and background. No, you're not limited to black on white (though it's a safe choice). Brad Frost's website illustrates a styled but very clear example (and it's what he does): http://bradfrostweb.com/ (It's also a beautifully fluid site).
⚫ While we're talking about contrast: take your "but black on white is too much contrast" talk and bin it. The guidance for brown type on an off-white page is for paper. Which is a reflective medium. Screens are, almost always, emissive. Which is to say, they have a maximum brightness, a much lower native contrast ratio than paper, and their display properties get markedly worse as ambient light levels increase. Most displays have a brightness/contrast control which can reduce the maximum brightness, and on many devices this is either automatic or easily accessed by the user (Fn+PgUp/PgDn on my Thinkpad, Macs have similar controls). However they cannot be pushed over their maximums, and in many cases, that's going to be insufficient to read your tiny low-contrast font. In my experience, any text at #333 or lighter is already too light.
⚫ Single-column designs are almost always preferable to multi-column. With an adaptive width, this will frequently address the needs of both desktop and mobile users with very few additional adaptations.
⚫ Respect your user's font choices. There are two classes of user: those who've selected font sizes to address their reading comfort and/or visual needs, and those who have no idea or clue. By forcing a specification on them, you're frustrating both. Using relative sizes "medium", "smaller", "larger" is a better bet.
⚫ Break the zoom button and you may not die, but your page is dead to me.
⚫ Don't include iframes with their own stylesheets. These cannot be overridden by the user. And yes, I'm talking to you, Amazon. Given the visual discomfort these elements present, I've simply set them to "display: none".
⚫ Don't explicitly scale HTML elements (p, a, li, tr, td, ol, ul, dt, dd, blockquote, pre). Style classes or IDs instead. One of my quick-and-dirty fixes is to apply an "important!" inherit property to each of these elments. CSS hackers will know about reset.css stylesheets, these can be useful to users as well.
⚫ Don't push your text to the edge of the screen. Another style I apply to virtually all sites is a "padding: 0 2em 2em 2em;" to the main text block. Generally padding at the top isn't necessary, but keeping the text from running straight into the gutter greatly improves readability.
⚫ It's hard to go wrong with a 45-55em max-width, auto width, and auto left and right margins.
⚫ Put some fucking padding and/or margins around images and other inline elements. 0.5 - 1em at a minimum.
⚫ CSS columns (a trick I picked up recently here on HN) are a good way for presenting your navigation / sidebar elements. Not supported in all browsers (what is), but the good ones do. You can see them used in the article below.
⚫ And if I sound fucking grumpy, it's because I am fucking grumpy. My first response to opening your goddamned webpage shouldn't be "fuck it, do I really want to spend time fixing this?" Because usually the answer is "no."
I recently posted to reddit with several specific examples of sites converted from multi-column to single-column:
I agree with 95% of what you said, the main exception is using em for styles. If you are designing for the screen, pixels are your medium and you should be aware of them. If you are using any graphics elements you will need to use px anyhow and then you are mixing - which I agree is bad. Ems can have unexpected consequences as well. For one, because it is a measure relative to the size of the capital M, sizes can change when the parent font-family changes (moving from a proportional to monospace font, for example.) Also, it is relative (like %) so if you wrote a CSS rule like this (you shouldn't, but it is to illustrate an point)
div {font-size: .5em; }
And you have this HTML
<div><div>Hello</div></div>
The actual size of "Hello" would be .25em. If you want a font to have a font-size of, say, 14px on screen, then set it as that and you'll have less worries about it changing unexpectedly if the font of its parent changes. I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.
I know this is not orthodox, but I've been doing front-end dev for 12 years and I promise this practice has saved me from a lot of hassles.
To be clear: about 80% of what I know about CSS I've learned in the past 9 months or so, despite having dabbled in HTML since the late 1990s -- I've long hand-tooled my own HTML for my personal websites and many discussions which allowed HTML markup. And I'm coming at this almost completely from the user experience perspective. To be more specific, my user experience. I respect your experience, but the practices I've seen in live code are ... simply infuriating.
If you are designing for the screen, pixels are your medium and you should be aware of them.
Pixels are an aspect of your medium. Not all pixels are created equal: they're not the same size, brightness, or color. Screens have hugely varying numbers of pixels, and can be resized pretty much at whim. Used to be you could rely on having at least 80 columns of text visible, with handheld devices, that's rarely a safe bet (reading the comp.risks digest, with its fixed-format presentation became all but impossible). I'd argue that ems and percents should be your principle units.
Where I use px it's for image padding (though I'm switching to ems for that), and border widths (though again, ems might actually make more sense, I'm just used to specifying 1-8px borders ...).
My point is that, for content, that is, text, your measurement should principally be about text. Your ems font sizing point has merits (well, except for your use of 14px for your font size), but you've got plenty of alternatives: smaller, medium, larger. Or absolute sizes: (though I'd suggest avoiding these): xx-small, x-small, small, medium, large, x-large, xxlarge. And realizing that '0.5em' is really saying "scale this to about 50% of normal text with" pretty much obviates your complaint that the typical character isn't 1em in width. Or, if you want a fixed relationship, percentages. I usually set my header tags at 150, 140, 130, 120, 115, 110, though I may bump that up (200% or 300% for major heads) or down (5% or smaller steps). And I'll often set these differently for header, article, aside, and footer elements (larger, normal, smaller, and smaller, typically).
Example of using ems for height and spacing is the drop caps on both my subreddit and Dreamwidth styles.
My focus on single-column layouts for text content (note that I actually like the multi-column mode for navigation and promotional elements -- when in sufficiently wide-screen displays) means that pixel-perfect placement is rarely an issue. I've also taken to styling navigation lists as "display: inline" or "display: inline-block" elements, several instances on the examples screenshotted at reddit, specifying inline-block gives you access to the :first-letter pseudo-element which you can see in the reddit menus on my personal subreddit http://www.reddit.com/r/dredmorbius. The inline styling means that you don't really have to worry about the width of the internal options -- they space themselves out appropriately.
And my use of margins plus padding means that you get both a fluid text box and a minimum guaranteed margin. 2em is tight but workable. This also means that you can set your default font for containers, say:
Setting a font size for the body (I actually usually set this smaller than my preferred reading font: 12pt for body, 15pt for the article, and possibly others for the header, aside, and footer elements (rarely below 10pt). This lets me set the overall page bounding in the #container segment (margins and padding), without skewing the overall widths of the other page elements, and preserving the option of individually scaling fonts and line heights within them. And if my padding widths are slightly off between header, article, aside, and footer, really, it's no big deal. The medium is inherently variable.
As an example of where things go haywire with px-specific stylings, Google+ uses a really complex bit of HTML to render its post and comment scores. It includes independently placed "+", tens, ones, and rating button elements. And if you're not using precisely the font sizes Google assumes, the characters are horribly mis-aligned and clipped. I've had to fix this multiple times as G+ changed its classnames (some completely asinine CSS minifier/obfuscator they use). See here:
I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.
Good practice there.
I swear to fucking god I'll shoot the next HTML monkey I lay my hands on who uses px for line heights, or fucks with letter spacing. It may just be with a squirt gun, but I'll shoot 'em.
The other factor to consider is that you also have access to the @media selectors which can key off of display size. I make use of this on my Dreamwidth blog, http://dredmorbius.dreamwidth.org/ The Kosmic Kat logo is a background image of the #header block which actually includes all of the top-of-page elements, not just the title segement. Given LiveJournal's HTML template, in order to accommodate both wide and narrow screen placements, I had to find a transition point at which the logo moves above the title text, and the right margin for the blog and post titles is removed. It's not a totally elegant solution, but it works sufficiently for me: I get my little branding element, and the text doesn't get horribly mangled.
I used to use Readability to deal with problematic web sites, but I switched to Clearly after encountering a number of web sites that Readability had problems with (not rendering all the content). I didn't know about Readability's feature of exporting a page as ePub. I may have to give readability another try.
My primary use case, though, is in organizing content I find online related to a research project -- the ability to tag, star, and archive content is particularly useful. Though I do wish the management and search tools were more powerful.
Followup just to note: UI/UX considerations (which I'm addressing) may not translate into conversions or other performance metrics of the site. But ... well, that's not really my problem. And if your site is sufficiently poorly designed, I'll be going elsewhere anyway.
I'll also note that numerous of these problems have been encountered specifically with commerce sites (several, Target specifically comes to mine, broke zoom).
Now, of course, if your goal is (and/or business model depends on) having frustrated, clueless users on your site you can invert all my recommendations and do peachy.
He's also committing the fatal sin of mixing ems (for his h1 title font size) and px (for his h1 line height). The result is overlapping characters: http://i.imgur.com/tEplJmv.png
I've griped on HN (and elsewhere) more than once about small fonts, low contrast (http://www.contrastrebellion.com/ can't get enough good words from me), and the reading-friendly tools such as Readability.com (despite some recent updates I'm not entirely happy with), InstaPaper, Pocket, etc. The latter are a great way to avoid this pain with minimal effort, and "read now" bookmarklets make this pretty near instant for most users. The styles presented by any of these services would do well as a default for virtually all content-rich sites.
I also have become all but obsessive in restyling sites whose CSS fails me. Which is to say, most of them (including Hacker News: http://stylebot.me/styles/2945). Using the Stylebot Chrome plugin, I've created, as of this writing, 819 stylesheets (some applied to multiple sites, some the same basic "unstyled.css" sometimes lightly modified). I think I've reached the point where I can make some fairly definitive statements, at least as far as UI/UX goes:
⚫ Use ems. Do not use px (graphics positioning excepted). NEVER mix ems and px.
⚫ Provide a high contrast between foreground and background. No, you're not limited to black on white (though it's a safe choice). Brad Frost's website illustrates a styled but very clear example (and it's what he does): http://bradfrostweb.com/ (It's also a beautifully fluid site).
⚫ While we're talking about contrast: take your "but black on white is too much contrast" talk and bin it. The guidance for brown type on an off-white page is for paper. Which is a reflective medium. Screens are, almost always, emissive. Which is to say, they have a maximum brightness, a much lower native contrast ratio than paper, and their display properties get markedly worse as ambient light levels increase. Most displays have a brightness/contrast control which can reduce the maximum brightness, and on many devices this is either automatic or easily accessed by the user (Fn+PgUp/PgDn on my Thinkpad, Macs have similar controls). However they cannot be pushed over their maximums, and in many cases, that's going to be insufficient to read your tiny low-contrast font. In my experience, any text at #333 or lighter is already too light.
⚫ Single-column designs are almost always preferable to multi-column. With an adaptive width, this will frequently address the needs of both desktop and mobile users with very few additional adaptations.
⚫ Respect your user's font choices. There are two classes of user: those who've selected font sizes to address their reading comfort and/or visual needs, and those who have no idea or clue. By forcing a specification on them, you're frustrating both. Using relative sizes "medium", "smaller", "larger" is a better bet.
⚫ Break the zoom button and you may not die, but your page is dead to me.
⚫ Don't include iframes with their own stylesheets. These cannot be overridden by the user. And yes, I'm talking to you, Amazon. Given the visual discomfort these elements present, I've simply set them to "display: none".
⚫ Don't explicitly scale HTML elements (p, a, li, tr, td, ol, ul, dt, dd, blockquote, pre). Style classes or IDs instead. One of my quick-and-dirty fixes is to apply an "important!" inherit property to each of these elments. CSS hackers will know about reset.css stylesheets, these can be useful to users as well.
⚫ Don't push your text to the edge of the screen. Another style I apply to virtually all sites is a "padding: 0 2em 2em 2em;" to the main text block. Generally padding at the top isn't necessary, but keeping the text from running straight into the gutter greatly improves readability.
⚫ It's hard to go wrong with a 45-55em max-width, auto width, and auto left and right margins.
⚫ Put some fucking padding and/or margins around images and other inline elements. 0.5 - 1em at a minimum.
⚫ CSS columns (a trick I picked up recently here on HN) are a good way for presenting your navigation / sidebar elements. Not supported in all browsers (what is), but the good ones do. You can see them used in the article below.
⚫ And if I sound fucking grumpy, it's because I am fucking grumpy. My first response to opening your goddamned webpage shouldn't be "fuck it, do I really want to spend time fixing this?" Because usually the answer is "no."
I recently posted to reddit with several specific examples of sites converted from multi-column to single-column:
http://www.reddit.com/r/webdev/comments/1tm4ox/user_site_res...