Beautiful Lines
Update: This was written just before the iPhone 4 came out, with Apple's new 326 ppi display. With screens that vary from 75 to 326 ppi (and no doubt, beyond), this stuff matters now. Go and make your sites resolution independent. If you don't care about the critique of a designer's blog, scroll to the bottom to learn how to make your site look amazing on all these very shiny new devices.
Typography on the web is ugly. Ragged-right is an abomination, a carry-over from when text rendering was done by Netscape Navigator on 486s with 16 MBs of RAM. Oliver Reichenstein writes at length about how Wired Magazine's typography looks terrible on the iPad, but his own design blog has some not-so-subtle typographic issues. I'm going to quote Oliver by way of a screen shot:
Oliver's lines are between 80 and 90 characters long, 50% longer than what he recommends here. While he has clear paragraph breaks, it's actually impossible to usably increase the font size on his site since everything is done with relative scales — a larger font means that the left gutter grows like a tumor, pushing the text off the right edge of the canvas, while the text container grows, too keeping the line lengths extra long.
More problematically, the iA blog doesn't adapt to devices with different pixel densities. They have an iPhone-specific stylesheet, but that only looks good for the portrait orientation — flip to landscape, and words-per-inch drops to about one or two. On the iPad, Apple's reasonably smart scaling saves them, but the margins are horrific:
It's a little hard (but easier than it should be) to tell that the visual effect of the text running up against the iPad's right bezel is incredibly distracting, and unnecessary given all that white space to the left. Never mind the fact that the font size is too big on the iPad in landscape mode, and actually a little too small in portrait.
I don't mean to harp on iA or Oliver — text across the web looks roughly like the visual art equivalent of MS Paint. Hell, this blog is using a fixed-width layout that looks terrible on low-resolution screens without the saving grace of content zoom. The iA site is better than most, but the work of Knuth and Bringhurst and so many others isn't being honoured.
We can do better.
It's not hard. The tools we have available to us today are amazing. HTML rendering engines are wicked fast, support letter-spacing and word-spacing and all forms of justification and hyphenation and drop caps and indents, oh my! In the past year, we've finally gained the ability to render custom fonts across browsers, basically bringing typography on the web up to LaTeX or Microsoft Word standards. Ahem.
A simple extraction of some of the work I've been doing with rePublish, here's an unobtrusive approach to presenting properly sized text for any reading device that might happen upon your carefully written text. Don't worry about your layout; Any approach is fine, whether fluid or fixed, grid or not. It's the job of this approach to work around your constraints, making your text more readable and lovely.
First, if you're not already, drop everything and size all your text in ems. Your text should be 1.0 em, everything else in ems as appropriate.
* { font-size: 1.0em }
h1 { font-size: 1.5em }
small { font-size: 0.75em }
The strategy from here is to determine how big the text needs to be (at 1.0 em) in order to fill a given text with a desired number of characters. In the "olden days", this was done with rulers and text sizing charts. In the modern era, we're going to do exactly the same thing, except that we'll build our text sizing chart every time we want to display text.
To do this, we take a string that will give us the average number of characters per pixel. A lower-case alphabet will do, but a closer approximation takes the letter frequency into account: "aaaaaaaabbcccddddeeeeeeeeeeeeeffgghhhhhhiiiiiiijkllllmmnnnnnnnooooooooppqrrrrrrsssssstttttttttuuuvwxyyz". Next, we'll measure how many pixels wide that string is in the default font size:
var sizer = document.createElement('p');
sizer.style.cssText = 'margin: 0;
padding: 0;
color: transparent;
background-color: transparent;
position: absolute;';
var letters = 'aaaaaaaabbccc
ddddeeeeeeeeeeeee
ffgghhhhhhiiiiiiijkllll
mmnnnnnnnooooooooppq
rrrrrrssssssttttttttt
uuuvwxyyz';
sizer.textContent = letters;
document.body.appendChild(sizer);
var characterWidth = sizer.offsetWidth / letters.length;
The characterWidth variable is an approximate measure of the per-character width in pixels for the default font size.
Next, we need to know how much horizontal space we need to fill. Get out your rulers, and let's start measuring! The specifics here will vary for every design, but the approach is always the same. First, find the space in which the main body text lives and get its width in pixels:
var contentWidth = document.getElementById('content').offsetWidth;
Now we can find out how many characters long our lines are by dividing contentWidth by characterWidth to obtain actualMeasure. Dividing that by our ideal number of characters per line gives us the relative factor by which we need to scale the default font size. For example, if our target is 66 characters per line, but the current font size produces 85 characters per line, then we need to scale up the font size by 85/66 or 129%.
In order to do the last step, we obtain the current body font size like so:
var measuredFontSize = parseFloat(
document.defaultView.
getComputedStyle(document.body, null).
getPropertyValue('font-size').
replace('px', '') );
And putting it all together, we find our desired base font size with the following formula: desiredFontSize = measuredFontSize x actualMeasure / targetMeasure. Armed with that knowledge, we can circle back around and update the base font size:
var actualMeasure = contentWidth / characterWidth;
var targetMeasure = 66;
document.body.style.fontSize =
(measuredFontSize *
actualMeasure / targetMeasure) +
"px";
That's it! No matter what device your visitors are using, they'll have an easy time reading your carefully written text. Add hyphenation using the unobtrusive (and fast) Hyphenator.js, turn on justification, and you're publishing texts that have the same careful and consistent rendering exhibited by virtually every paper book published today.
To round out the approach, it's absolutely possible and desirable to set maximum and minimum font sizes. Large, high density displays may produce oversized fonts if the content area is flexible, and constrained devices will favour very small fonts. For small displays, this is enough since displaying less text on a small display just makes sense.
For larger displays, displaying smaller-than-ideal text will leave more white space or leave more characters per line, which may or may not be acceptable. If it isn't, there are a number of options; moving to columns might be a good one — this is what newspapers do, to good effect. A 30" high pixel density screen isn't that far off a broad-sheet newspaper, and a series of columns is a far more appealing idea than a website that forces me to scroll down to continue reading a tower of text.
The simpler option would be to use relative sizes for the content container, sizing in ems rather than pixels, and guaranteeing that your content can reach the ideal number of characters per line. For this to work, you need to key the font size off the available pixels or the device's native resolution, rather than the area into which you're sizing text. This blog uses a fixed pixel design, and I'm not currently in a position to rework the design at the moment, but this latter approach is the one that I'd use in the future, and is in effect the technique I use in rePublish to ensure that the text is properly sized regardless of device resolution.
The code to do all this is posted here: https://gist.github.com/428898/e882078f10a06e55fa905a89a6ae65f30331746a
To use it in your site, just paste it into script tags in your template and call it from your onload handler.
I'm releasing it into the public domain, so please modify to suit and share with anyone and everyone. If you create a plugin for jQuery or any other JavaScript framework, please leave a comment here so others can find it.
posted by Blaine at
5:49 PM
17 Comments:
Nice try.
1. Line width: Please read the whole paragraph to the end: "If you increase the reading distance (which is often the case with the iPad, since you happen to hold it on your lap and not with bent arms) you either have to increase the font size or the line width." Monitors are even further away than iPad, so yes, on the screen you can go over Bringhurst's 75 character limit. For context: This was to prove that 33 characters is clearly not enough at iPad's reading distance, not that 50 is the iron rule.
2. iPad Optimization: No, our site is not optimized for iPad. Just chill and wait until we're ready.
If you want to criticize us on web typography you have to try much harder. :-)
Why Oliverno use definite article when talk about iPad? Is iPad person?
Oliver:
1. I know 50 isn't an iron rule, and I would agree with you that longer lines than 50 are ideal for screens and so on. I tend to sit only marginally further from my laptop screen than I would an iPad or a physical book, so I'm not sure that a jump from 50 to 80+ on screens is called for. If it is, there's a lot of evidence that needs to be collected — my own experience is that lines on the web are often uncomfortably long.
2. The whole point of the post is that you shouldn't be optimizing for iPads. Or iPhones. Or iPhone 4Gs. Or Nexus Ones. Or 30" 90 ppi screens, or 30" 300 ppi screens. You should be optimizing for reading experience, and you should be using the best techniques available to do so. Using em-based sizing has long been understood, but always driven by pixel sizing at some level under the covers. In order to build resolution independent designs, we're going to have to come up with resolution independent approaches. I've presented one here, and I'd love to hear your ideas — an iPad-specific CSS file isn't making me excited, though.
just an fyi, as of this comment posting your gist link is broken :)
Anonymous: thanks, fixed!
The public domain sounds like a good idea, but there are actually issues with it in many European countries where it doesn't actually exist, as the author of SQLite found out:
http://www.youtube.com/watch?v=giAMt8Tj-84#t=28m30s
You may want to think about using one of the more liberal traditional license (MIT, ISC, two-clause BSD):
http://en.wikipedia.org/wiki/MIT_License
http://en.wikipedia.org/wiki/ISC_license
http://en.wikipedia.org/wiki/BSD_licenses
hmm, your gist is still broken
David: I think I had tucked away somewhere in the back of my head. For such a small (and easily reproducible) snippet, it's so sad to have to deal with licensing at all.
choonkeat: Thanks; it looks like a bug with github, as the previous URL works sometimes, but not others (!).
> 1. I know 50 isn't an iron rule, and I would agree with you that longer lines than 50 are ideal
> for screens and so on. I tend to sit only marginal?ly fur?ther from my lap?top screen than I
> would an iPad or a phys?i?cal book, so I'm not sure that a jump from 50 to 80+ on screens is
> called for. If it is, there's a lot of ev?i?dence that needs to be col?lect?ed — my own ex?pe?ri?ence is
> that lines on the web are often un?com?fort?ably long.
ok, my count shows character lengths for those lines of 95, 89, 90, 97, and 51, respectively.
so your own blog here is not a good example of what you say that you are trying to show...
oh, and those character-counts don't include the question-marks that are littering your text.
they are the price that your readers have to pay if they want to copy out your text to remix it.
perhaps you will recognize that they have all been introduced by your desire for hyphenation.
was it worth it? i don't think so. especially since they mess up browser _search_ capabilities...
as to whether they screw up your text in the search-engines, i just don't care. but you might.
got a whole lot of people talking about these things about which they know not quite enough...
-bowerbird
Bowerbird: I said that my own blog is a bad example because I'm using a pixel-based layout. I should fix it, and will as soon as I get a chance. In the meantime, the technique works well for the eBook reader, and the line lengths on my blog are better than they were before I applied the change (the reason for the long lines is because I've set a maximum pixel font size).
As for the hyphenation, feel free to file a bug report with your browser vendor. They're handling text incorrectly. For places where it really matters, there are approaches to ensure that cut and paste works properly in the absence of well-designed text handling in the browser. I'll leave it as an excercise to the (snarky) reader.
> Bower bird: I said that my own blog is a bad ex am ple
ok, good, so we agree on that... :+)
> As for the hy phen ation, feel free to
> file a bug re port with your brows er ven dor.
you _are_ optimistic, aren't you? :+)
> They're handling text in cor rect ly.
do you know any browsers that
do _not_ "handle it incorrectly"?
> For places where it re al ly mat ters
wouldn't that be _everywhere?_
if not, why not?
> there are ap proach es to en sure that
> cut and paste works prop er ly in the
> ab sence of well-de signed text han dling
> in the brows er. I'll leave it as an ex cer cise
> to the (snarky) read er.
considering that nobody gets this right,
i'd think you'd do better to explain it...
oh, and, for the most part, you and i agree.
it's just that i think that you will need to
walk the walk if you're gonna talk the talk.
and recognize that there are tradeoffs here,
and lay them out on the table for evaluation.
-bowerbird
Bowerbird: Absolutely, thanks! It's a new and exciting area, and there are going to be hiccups along the way. This approach is really meant as just a first step, and the hyphenation is just one [optional] part. Hyphenation aside, I'd love to hear more thoughts on the resolution-independent text scaling; I think that's the really important bit.
As far as hyphenation goes, I don't feel like I'm being so optimistic there — we're seeing an amazing rate of progress in browser development at the moment, and the cut-and-paste thing is very clearly a bug (if you want the entities, go to the page source). I'm already being fairly conservative in that I don't expect browser developers to implement hyphenation themselves just yet, even though CSS is clearly where this belongs (not in a javascript library).
Do you not think it a little subjective to suggest ragged right is awful? Personally, I didn't read any further in the article because your justified text was excruciatingly slow to read. Don't pretend the web is a novel or newspaper - that's what justified text is for. However, each to their own.
Have to agree with Ronan here - while this site is easy and pleasant to read, it's large and needs lots of scrolling. Not to my (personal) taste, frankly - I'm a speed reader in any case, and find it easier to scan text in smaller type sizes in reasonably sizeable paragraphs. I honestly don't believe there's a "one approach fits all" solution - but I do think sensible web designers should be experimenting all the time, ideally seeking as much user feedback as often as possible.
I too agree with Ronan. Justified text looks good from a distance when you're not actually reading - but to me that's just it...it 'looks' good, it doesn't read well.
I've actually never understood it, do you do it when you write something by hand? Just because the computer is smart enough to compute spacing and rearrange words on the fly doesn't mean we should let it.
I however, am NOT a designer/writer/or anything of the sort...but I am one of the readers. :)
To answer bowerbird's question, yes, I do know a browser that renders it correctly. I inserted a soft hyphen in the first paragraph, and was quite pleased to see how I could still search the text. http://img23.imageshack.us/img23/9495/capturemw.png
I am to lazy to test it on any other browser, though.
Re licensing question that arose:
You could always copy SF editor Jim Baen's idea. He once found a cute code trick to get around a limitation back in the days of GW-BASIC, and he released it with a copyright statement which read (roughly):
"All users are hereby granted all rights to this code on a non-exclusive basis. In fact, the only reason this code is copyrighted at all is to prevent someone else from copyrighting it and thereby restricting its distribution."
IIRC, the code was published with this in one of Pournelle's columns in the old BYTE magazine, way back in the day.
Post a Comment
Subscribe to Post Comments [Atom]
Links to this post:
Create a Link
<< Home