The contrast ratio is 5.57:1 well above the 4:5:1 requirement. It seems that they're using Adobe Clean Light ( Helvetica Neue Light as a fallback). This must be the source of your readibility problem. Depending on browser/platform font-weight: 300 can be a huge problem.
You hit the nail on the head: The font-weight:300 is killing the readability in Chrome on Windows. When I toggle it off the text becomes readable.
I don't know what this 4:5:1 requirement is, but it also looks better to my eyes with the color:#444 toggled off so I get black text. But it's not as huge a difference as turning off the width.
The "4.5:1 requirement" can be found in the Web Content Accessibility Guidelines (WCAG) 2.0, part of a series of Web accessibility guidelines published by the W3C's Web Accessibility Initiative:
The font is the issue, not so much the color. Light fonts as the bread font are just a bad idea.
Not that it matters even a little bit in this case. It's an irrelevant diversion of the worst kind. It's ignorant and foolish, something for small minds.
Because many people who design webpages aren’t very great when it comes to typography?
It’s just a bad idea to use those light fonts for anything but headlines or other kinds of large type. For the headline that light font is absolutely ok. For the body text it’s just embarrassing (especially since this is from Adobe).
I have to say, though, this blog is written by those at Adobe who develop new standards (for HTML/CSS/JS), so probably very technical people who are more often than not not very knowledgeable about design – that is to say, those involved here do not necessarily have a strong design focus (and neither do they necessarily have to have that).
Maybe the one who decided it has an Apple device with 'retina' screen? I was reading it on an rMBP and the font struck me as very pleasant, hence I couldn't understand the fuss here first. Helvetica Neue Light is quite popular on these newer Apple devices, it's good to know that it is a bad idea though.
The "bread font"... is that a design term? I like it, and it intuitively makes sense. I'm just wondering if that's a common term or if bread is interchangeable with potato, pasta or some other starchy food that fills you up.
I've definitely heard it before, though "body font" seems to be much more prevalent. It's probably a literal translation from a continental Germanic language, e.g. Dutch has "broodtekst" though the word refers to the actual body copy, not the font. German has "Bröttext".
Haha, no, body text is them common English expression. I just translated “Brotschrift” literally to English and somehow convinced myself that it’s an actual English expression.
This is probably due at least in part to the Mac's text rendering, which is considerably thicker than Windows. It's pretty common to find text that is ridiculously thin, mostly on designer's websites. I'm no devotee of Windows or Mac (though I don't own a Mac yet), but it seems pretty clear that the design crowd needs to start at least spinning up a simple Windows (or even Linux - Ubuntu's text rendering is in between OS X's and Windows') VM and make sure that their text is readable on the platforms that nearly everyone uses. Even Android and (I believe, though I wouldn't be surprised if I was wrong) iOS don't render text as thickly as OS X. Failing to optimize for different text renderings and making your text extremely thin alienates both the mobile market and 95% of the PC market.
Also, Chrome has terrible, evil, nasty text rendering in general, at least on Windows. I prefer it to IE10, but the web does look much better in IE, which actually has decent text rendering.
Which device are you using and with what light settings? I've received one report from a user saying that the text on my site is "unreadable" due to the contrast but nobody inside my organization can see what the problem is, so I'm interested in how other people are experiencing such problems.
I'm using a 17" Dell M6500 running Windows 7 and the text is unpleasant to unread in all browsers I have installed (Firefox 18.0.2, Chrome 24.0.1312.57 and even IE 9).
It looks quite a bit better on my external monitor - which is 1600x900 rather than the 1900x1200 of my laptop display.
FWIW, the text looks fantastic on a retina ipad (on safari). It could do with being a bit darker to increase contrast, but still it looked great and was easy to read. So screen resolution seems to make a difference.
Does this algorithm actually make things more readable? Or does it just make them look nicer. Not that there's anything wrong with that but sometimes the two goals clash, like with the text in this article.
And is it me or is the use of a series of single characters rather than a length of actual text a really weird choice?
The typophiles here will surely yell at me for getting the terminology wrong, but my experience is that fonts are heavier on OS X and whenever I see a site with whisper-thin text like the above I suspect it was tested on OS X only.
Edit: removing the font-weight CSS attribute makes the page legible. The issue is that you specified a font-weight under 400 ("normal"), and different font engines snap in different ways.
But I bet that the text you're looking at right now on HN is easier to read than the screenshot. Now consider that people might have dense screens, or sit further away from the screen than you do, or have poor eyesight.
Nah, it’s still too light on OS X with Safari. And on a Retina screen, no less. If this would work anywhere, it would work on that combination of screen, OS and browser. But no, it does not.
I can read it comfortably if I lean in, but I'd rather not. The text here on HN is smaller than your site, and it's perfectly readable from my normal position.
The gray on white is actually ok. Even better would have been black on light gray. Too much contrast is a pain point when reading text with a backlight.
font-weight is indeed the main problem, but regardless I hate this new trend of not making text black. What would a bookmarklet look like to set the body color to black?
The trends to make thin grey text on nearly-gray background are driving me nuts also. I have two global Stylish [0] styles in my Firefox and I toggle them when I need to read something on a page like this:
1) Enable Georgia font instead of the author's favourite thin font:
html body, html div, html span, html p {font-family:Georgia !important;}
2) Make everything black (except links):
html * {color:black !important;}
a {text-decoration:underline !important; color:#00a !important;}
Those are not perfect but they work for me in 95% of the cases.
The first rule is a not a catch-all to not put Georgia in code/pre/textareas etc. `html` is necessary not to affect Firefox's (browser) styling.
The run-time of that particular implementation of the Knuth-Plass algorithm is quadratic in paragraph length, which is too slow for web browsers (which might have to deal with very long paragraphs). However, the algorithm can be implemented to run in O(n) for large n, or O(n log n) with smaller fixed constants. Though you might have some issues with the line breaks made by the browser.
I'm not totally sure, but I think the linear time papers I've read sacrifice some of the aspects of the original Knuth and Plass algorithm. I think some of those are going to be necessary to properly implement the Knuth and Plass algorithm in browser (also, floats are going to be interesting.)
The performance isn't actually that bad, I can perform line breaking in JavaScript on some very large documents, with the only performance bottleneck being DOM node creation (which native implementations won't suffer from.) If necessary the linebreaking could also be done incrementally, with a first first-fit pass and then the Knuth and Plass algorithm.
I could be mistaken, but I'm fairly certain Internet Explorer implements the Knuth and Plass algorithm when using `text-justify: newspaper`. Unfortunately, I can't check because it isn't open source. The output however is pretty much identical to what my JavaScript version generates, so I'm inclined to believe it is the Knuth and Plass algorithm.
As mentioned above, Knuth's algorithms are implemented in many professional typesetting and layout applications. I think the people implementing those applications have great respect for Knuth (and Plass.)
My impression is that the users of those programs are unfamiliar with the algorithms used, so I think it is the latter.
Awesome, thanks! I foolishly forgot to see if there were siblings to my post. (I try and keep a handle on discussions I'm in with the "threads" link.) So, yeah, apologies for missing those posts.
I'm really excited about this. While it is not the Knuth and Plass algorithm, it takes one of the nice features of it and proposes a simple algorithm to implement it. Implementing it should only be a minor adjustment to the text layout algorithms of browser rendering engines, and if implemented correctly it should not cause any reflows, only a repaint.
For subtitles and ledes, or really anything larger than the main body text, I actually prefer the <br/> solution. It's important not only to break in a pleasing shape, but also to break at grammatically-sensible points. So it's better to say:
This is a very legitimate addition to CSS. I bet we will see it in a future release. It makes a lot of sense for headings. I hope it will not get abused for other text blocks (but I am sure it will).
Yeah, I've looked into this in the past. In fact, it was exactly a year ago that I tweeted that Chrome doesn't support hyphenation. Had to double check today to see if it were still true.
In fact, it seems even more important now that they have Chrome on tablets and phones (this was announced one year ago as well, incidentally).
I long for something that would just wrap all big paragaphs of text at 70-ish characters without hacking at element widths (I've tried user stylesheets, scripts... nothing satisfactory). If this were implemented, I imagine it would be easier to do that.
(For example, the first line of the first paragraph of the post renders as 134 characters on my screen. Maybe I am just old, but I find this hard to read.)
I used a user stylesheet that added max-width: 50ex; to <p> and <li> tags for a long while, but found too many sites ended up funny (especially those that mixed <p> and <br>). These days I just make my browser narrow.
The Knuth optimal balancing algorithm is implemented in C in the Gnu Core Utilities program "fmt" -- see http://www.gnu.org/software/coreutils/ -- and is plenty fast enough for a browser to render text.
Yes, the website is ironically displaying text in an inconvenient way for a bunch of users.
But as for the content itself: why not just use left align justify? I understand that justify asymmetrically inserts spacing to apply a balanced center throughout, but is this really an issue? In what context are users so hypersensitive to readability issues that they need the justify spacing to not only balance the entire text but evenly balance each space within the text in reference to one another?
Pardon me for not finding this significant. I just think it's a bit anal when we have a solution already.
The linked article isn't about balancing individual word spaces within justified text, it's about re-wrapping the lines so that the last line isn't markedly shorter than the others, even in the face of changing viewport and font sizes.
Ugh, I really hate newspapers and the like that stretch out words and letters randomly just to have it make a perfect block. Random spacing to meet your criteria of prettiness does not improve readability. This person centers too much is his problem, I think. Just left align, read down the page with every line starting in the same spot, stop when done. Yay. Most web readers don't even read every word anyway, they skim, and you are producing something anti-skimmable by not keeping a nice solid left line where all the text starts wherever possible.
Balancing headlines and the like is complete standard everywhere. Abusing letter spacing has nothing whatsoever to do with it and is generally frowned upon. If you see that someone made a mistake.
You are simply complaining about words and letters being stretched too far. If you pick up a random novel, you'll see that paragraphs are justified, through a variety of devices such as hyphenation, letter spacing, and generally microtypography. Most of the time this is done professionally and you have no idea because you don't notice.
The simplest solution to a similar problem (a single hanging word in a headline) that I've seen is to replace the 'space' between the last two works with an This forces the last two words to stay together as a unit. It can be automated with a simple piece of ECMAScript.
It's not the single word alone in a line. It's a final line that significantly shorter than all the others. You want to strive for text that's mostly ██-shaped, not ▐▀-shaped. Replacing the last space by a non-breaking one just shifts the problem around a bit (and you still have occurrences like “I am” at the end of a sentence – it's not like the final word is always something nice and long like “sightseeing”).
I know I'm pretty late here, so hope you see this. I found this free online version of "designing for the web" to contain an accessible guide to typography and even delves into some of the more technical/nuanced areas
Wouldn't it be easier and give you more editing control to just put text in a <pre> element? Seems like it would be hard to algorithmically determine what will visually look good
InDesign already does this (as does quite a number of other software) and it works remarkably well. There is rarely a situation in which manual adjustment improves the typesetting and the automatic solution i definitely always good enough.
A manual solution is possible but not very practical, as was also mentioned in the article. Especially when the web design is responsive, such manual adjustments are problematic. But HTML is (luckily) also very flexible and neither font size nor the font are guaranteed to be constant, making a manual solution break horribly in e worst case.
CSS desperately needs feature parity with something like InDesign when it comes to typesetting. Adding stuff like this is obvious, something those working with layout programs had at their disposal for a long time.
I do agree that typesetting in CSS is a bit lacking. We haven't really had any significant changes in this area since CSS 1.0 came out (with word-spacing and text-spacing). @font-face is great, but it's more about specifying the font to use instead of specifying the type layout.
It's also nice to see some constructive issues already being raised on the project. Whether or not the current implementation is perfect, it'd be really neat to have this type of functionality implemented in a CSS spec.
That seems even worse because it's slaughtering the wrapability of the text. That would only work on a container of pre-set size, and maybe then only on certain clients. How do you know which font client x will load?
Lovely idea. One might also consider the special case of two centered lines, where many have an aesthetic desire for the first to be longer than the second.
