john robert boynton: Typography

Mon, 26 May 2003 02:22:49 GMT

Further adventures of .... For those of you just tuning in, licentious radio's NO JUSTIFICATION in HTML campaign is sweeping the web. Why? Because justifying text without hyphenation typically leaves uneven. gaping holes between words, where a single, small space should be. Even though the right edge is nicely even, the gaping holes and running rivers (a hole at about the same place in several lines) make reading difficult. If you intend for people to read the text on your website, making it harder to read than normal is a bad idea. Of course we can't say X without pondering the opposite of X. When could you justify text? Newspapers get away with it because of hyphenation and narrow columns. We postulate that with sufficiently narrow columns, the eye doesn't scan along the line as much, so irregular and large spaces between words wouldn't be such a big problem. Not content to leave well-enough alone, we had to hack. Putting soft hyphens () in text is easy. Modern browsers will at least ignore the  -- we thought. Sigh. There's no end to the blundering of browsers. (We're complaining, not accusing. Browsers are hard and making browsers fast was harder, and all of this would have been fixed long since had the development pace kept up.) WinIE 4+ will use  to hyphenate. Mozilla ignores them gracefully. Alas, MacIE 5x (on one Mac with OS X, anyway) displays a U with some queer accent for every . Not content to leave bad enough alone, we hacked onward: write a script in Javascript to go through and remove the soft hyphen characters. (We had thought Javascript was finally stable enough to be useful....) Alas. Our simple-minded hack freaked MacIE out completely -- throwing margins off and twisting the font-family. (Why in the world didn't they test this?) Reluctantly, we abandon the concept. (The coolest bit was we got to align headings to the right. You don't get to do that every day.) Fact is, WinIE's hyphenation was pretty bad -- not hyphenating often enough -- and our view is that hyphens should hang -- be placed just beyond the right margin -- which WinIE doesn't do. This design had very short lines... we might try again in a design where the lines are a more normal length and the server is smart enough only to give s to WinIE browsers.

Wed, 21 May 2003 05:09:00 GMT

Just for the anti-zeldman record: the latest addition to the local stylesheet for Zeldman's primarycontent is "color: black". Oh. Nice, readable, black text.

Sat, 03 May 2003 17:59:49 GMT

Random Rant on the font tag.... Putting a font tag in every freaking table cell was pretty silly. On the other hand, it worked. "Worked" in the sense of letting users pick the default text size, and reliably scaling the text size from there across platforms. The fact that some designers picked the typically unreadable "font size=1" for body text was not the fault of the font tag. CSS has a way to do essentially the same thing, but Microsoft broke it by picking different relative sizes than the rest of the world. That is, the CSS equivalent of size=2 is one step different on Windows IE than on most other browsers. Then there's a Windows IE bug for sizing text with em units in CSS -- some users will see .9em as unreadably small. I'm sure Billionaire Bill's heart breaks when he hears about these bugs that make it vastly more difficult to create websites that look OK on both Windows IE and other browsers.

Fri, 25 Apr 2003 00:03:35 GMT

A Conversation With Marty Neumeier [meet-the-makers.com]. Marty Neumeier was the editor of Critique, a quarterly magazine about "graphic design thinking". Critique was great. I miss Critique almost as much as I miss prosperity. Since Critique folded, when I'm near a magazine rack, I just sigh and turn away.

Thu, 13 Feb 2003 16:17:51 GMT

What to click. I watch movies on DVD sometimes. I have this 19-inch monitor. The clickable areas are *tiny*. They're hard to find. Just make stuff clickable, darn it. With stylesheets and a bit of automation, we can do better than we've done so far. Say your homepage has headlines and one or two paragraph summaries or leads. The headline should be clickable, sure. But why not the text of the paragraphs? First, you don't want the text underlined, and you don't want the same *loud* hover indication. We can do that with stylesheets. Second, you don't want non-CSS browsers to have the whole paragraph underlined (because it's so much harder to read underlined text). So you have to be able to send *different* html to CSS and non-CSS browsers. You have to automate, and you have to have some server-side browser-sniffing. (Or easy client-side opt-in.) Third, you can't nest links. If the paragraph contains a link itself, that would require special handling. But *that's* OK, since you already have to automate. Just end the paragraph link before the link in the text, and start another link after. The specific link in the text should be obvious when you hover, so customers know that they're getting the right link when they click. As ol' Jakob says, most customers spend most of their time at other sites, so not everyone will make use of a feature like this. Some people may even get confused by it, though they're more likely to wonder why other websites don't work like this, rather than why your's does. But some people will be helped, and that's what we're here for, right?

Tue, 11 Feb 2003 23:15:51 GMT

Silly zeldman.com hacking update.... For no *very* good reason, I want the secondarynav on the right. float: right, right? But the latest style tweaks switched to absolute positioning. position:absolute trumps float:right in Mozilla. (At a glance, that seems to be the way the spec is written, too.) To over-ride the absolute positioning, my userContent.css looks like this:

#primarycontent {margin-left: 0px !important;}

#secondarynav {position: static !important;}

#secondarynav {float: right !important}

In principle, this is a silly business. But it's maybe the way of the future, so I indulge. The only bad thing is that I usually have five or ten browser windows open, and every time I tweak the user stylesheet I have to close them all and restart Mozilla. But if I do that once a week, it doesn't seem too bad. I was only driven to this stylesheet hacking back when Zeldman was justifying his text. At licentious radio, we brook no justification of html text.

Tue, 11 Feb 2003 20:10:48 GMT

Greg Palast has updated and re-published his book. He'll be at Kepler's on February 27. Palast digs up dirt on the Bush people, which is published in newspapers in England, but black-holed by the Republican-owned media here. Greg's interview with Buzzflash goes into some of the gory details: Bush is blackmailing Blair to support the war. Poppy Bush himself set up the Iraqi nuclear weapons program in the 80s, with $7 billion from the Saudis. Greg is also the only known/suspected victim of licentious radio's campaign to stop justification of text on the web. We're not taking credit for it, but we *did* email a suggestion that it would be easier to read his articles if they weren't justified. And today, the articles aren't justified. For now, we'll spare you the anti-justification manifestoing. But mark your calendar for Greg at Kepler's.

Sun, 09 Feb 2003 16:58:09 GMT

Update: This post was fundamentally wrong. You *can* use a transitional DTD without being thrown into quirks mode. You just have to know *which* way to specify the DTD. *Without* a URL, you get quirks-mode. You can get standards mode, or Mozilla/Gecko's 'nearly-standards' mode, by choosing the right DTD declaration. You just have to know. Here's the Mozilla/Gecko behavior [mozilla.org]. Cost of DTD hijacking.... (Choosing quirks mode based on transitional dtd considered costly.) We have this problem of a gazillion web pages that were tailored to now-old browsers that were definitely quirky about rendering. "Quirky" being partly a euphemism for "non-standard".... A browser that does things *right* will suddenly gag on these old pages (render them ugly). So you might want the new browser to be able to render an old-fashioned page the way the old-fashioned browser rendered it. But how will the browser know to use quirks mode, not standards mode? You use the DTD, was the answer. The DTD had (practically) never been used for anything, so why not? I'm glad *I* didn't have to make a decision like that. For me, I would have been glad if a transitional DTD let me make pages that would work pretty well in non-CSS browsers, *without* enforcing old bugs (etc.) when someone uses a new browser to look at the page. The example is you might want to use bgcolor, link, and vlink in the body tag, and even the despised but functional font tag. But if you use a transitional DTD, Mozilla duplicates various nasty 1997-era bugs. So now if I want to use transitional tags, I've got to do all the work-arounds that we hated before. In order to avoid the old bugs, you have to give up usability for old browsers. Here's an example.... You put a div around the "content" part of the page, and style based on the div. Everything within the div looks fine, until you have some tabular data -- in a table. Because you use a transitional DTD -- in Mozilla and other browsers -- the text in the table cells doesn't get the styling of the div. That's not necessarily so bad, because you can style the contents of the table cells. But with the cascading nature of CSS, if a browser comes along that *doesn't* support quirks mode, the styles could be applied twice: .9em times .9em. So don't use ems, right? Ouch. I have a different perspective on this than some. I don't care if old pages look bad in new browsers. People who want their websites to look pretty can update their pages, from my perspective. I would rather that it be easy to make new pages that follow standards with a bit of a nod to downward compatibility. Like I say, I'm glad *I* didn't have to make these decisions, because I would have leaned the other way.

Sun, 09 Feb 2003 14:41:11 GMT

Interesting claim on the Opera/MSN story.... They suggest MSN tweaked a stylesheet to work better with Opera 6. When Opera 7 came out, the tweaked stylesheet broke the layout, because of changes in the browser. I haven't tested this, but it sounds plausible (slashdot comment). First, make your browser follow the standards. Second, when browser-sniffing, be aware that new versions will come out eventually, and the new versions will be specifically *different* than the current version. So limit your targeting to known versions. When Opera 7 comes out, give it some generic stylesheet until you take the time to figure out what you need to do to support it.

Sun, 09 Feb 2003 14:12:33 GMT

I guess that makes it official, then. I am the Anti-zeldman [google.com]. (ha ha)

Mon, 03 Feb 2003 04:07:46 GMT

More zeldman.com hacking. (The original hack, by the way, was overriding text-align: justify. We *hate* justified, unhyphenated text -- because it is harder to read with the gaping whitespaces in the lines. We wouldn't have bothered with today's hack if we hadn't been pushed over the edge by the justified text.) Being old-fashioned, I have a *narrow* browser window. So narrow, that when the zeldman.com content column is on the right, the lines of text go right off my window. They're harder to read that way. Shall I scroll over, every time I look at the page? Shall I change the width of my browser window to suit zeldman.com's layout? userContent.css to the rescue! For me -- on gnu linux -- the file is at: ~/.mozilla/default/bictshp6.slt/chrome/userContent.css I added the following lines: #primarycontent {margin-left: 0px !important; margin-right: 150px !important} #secondarynav {float: right !important} The float: right puts the navigation on the right side, overriding the website's stylesheet. One problem with the user stylesheet for Mozilla is that you have to exit the browser completely before changes take affect. Since I usually have several windows open, I don't like closing them all, and opening them all again. Plus, I'm lazy. I mention this to explain that I don't think !important is necessary for any of them, and the margin-right setting is probably unnecessary. But what I've got there now works, and it's time for bed. Another option would be to make the secondarynav display: none. That would prevent the waste of screen real estate. I hardly ever use the navigation, and when I do, I could just use a different browser. Good news, though. Zeldman stopped justifying the text. My previous hack is no longer necessary. The bad news is that it points out the potential for user stylesheets to go out of date, and accumulate junk. Update: I more or less failed in my laziness. I had to restart the browser again, anyway, and so I fixed some of the above.

Sun, 02 Feb 2003 20:06:27 GMT

HTML and the various related technologies have been a nightmare to work with, for several reasons. Unfortunately, one of the reasons is that numerous seemingly inappropriate decisions have been made by the standards committees. Sometimes you wonder if *anybody* there has a clue. Consider line-height. In real-world type, we think of "leading", which was extra lead inserted *under* a line of text. People have been putting characters on paper for thousands of years. We do it like this for a reason. The CSS specification says half of the extra line-height should be added *above* the line of text. The flaw is that you can't align the top of the text of two columns that have different line-height settings. Is this a big deal? How often can you just work around it, after all? It's just that one seemingly clueless decision subtracts value from the web, and forces *all* designers to work around it. Just get the decisions right the first time. Leading and half-leading [w3.org]: User agents center glyphs vertically in an inline box, adding half-leading on the top and bottom. For example, if a piece of text is '12pt' high and the 'line-height' value is '14pt', 2pts of extra space should be added: 1pt above and 1pt below the letters. You can search back throught the email archives to find that the committee was given the appropriate feedback: "This is going to cause massive confusion with people who come from the dtp-world or traditional typography. I like to think of leading as added space after the line. I've never seen it referred to as space above and below the line. Its counter-intuitive." But there's no hint of why they did this to us in the first place. Netscape tried to make up for it, by the way, by *dropping* the half-leading above and below paragraphs. Totally crazed. There's a work-around. Say column one has line-height: 1, and column two has line-height: 1.5. In the div for column one, set padding-top: .25em. Of course it gets more complicated from there... when the first lines have different font sizes, for example. Pretty soon you're back to specifying everything in pixels. Another seemingly fundamental feature.... Ideally, the length of lines in a web page is allowed to adjust somewhat for different browser window widths. Commonly in "liquid" layouts, the text column width can range from very narrow to very wide. At the extremes, the amound of line-height that is appropriate is very different. Short lines, no extra line spacing is needed; long lines may need a lot. So why not let designers specify a *range* for line-height? At <= 10 ems, line-height is one. At >= 30 ems line-height is 1.5. Interpolate for other lengths.

Sun, 02 Feb 2003 03:02:23 GMT

How to escape pixel-based measures for onscreen type.... Specifying type in pixels is almost meaningless, since the actual *size* varies so dramatically among your customers. A font-size of 13 pixels can seem quite large on some monitors, but unreadably small on other monitors. Specifying type in an actual measure -- points, inches, millimeters, etc. -- would give you a consistent size across all monitors -- if monitors knew the actual size of their pixels. In fact, there's even more good news, because this approach lets your customers *fudge* for their eyesight. The monitor could actually be set for 96 pixels per inch, but a human could adjust the setting to 120 pixels per inch to make up for poor eyesight. More pixels per inch could give you better quality type, because more pixels would go into each character. (120 pixels per inch might not be enough to be helpful for 10 point text, alas.) That takes care of the type. What about the graphics? First, with better type controls, we won't need as many images for navigation and such. Second, we'll be able to use line-art instead of bitmaps. And third, we propose that browsers should incorporate quality bitmap scaling. Where you *do* use a photograph, for example, size it at 120 dpi, and let the browser scale it down to 96 dpi if needed. Browsers can already do this, but they don't necessarily do it well. In fact, before long, browsers will be able to tell the server what dpi they are using. Then you'll be able to store several sizes on the server, and deliver the best one for each browser. There are some problems. At low resolutions, a choice of a size in points might not map evenly to an actual pixel size, so the browser would have to round. Current screen resolutions are so low that the shape and color of text can vary dramatically from one pixel size to the next. Verdana is prettier and much easier to read at 11 pixels than at 13 pixels -- regardless of the actual size of 13 pixels. You could also lose the benefit of hinting, I believe.

Sat, 01 Feb 2003 15:37:56 GMT

From John Hudson of tiro.com: "I suppose it is inevitable that eventually all web designers will have 200 dpi monitors and will finally realise that specifying type size in pixels was a bad idea. In the meantime, the early adopters will go blind trying to read blogs on their 133+ dpi screens. Being blind, they will find it more difficult to find someone to reproduce with, and so the early adopter gene will gradually be removed from the gene pool. This will leave only late adopters, thereby causing a massive recession in the computer and software industry and slowing the pace of new development to a crawl. People just don't consider the consequences of their design decisions!" This was a comment at typographi.ca, which is kind of a small-group weblog. If you think that's amusing, don't miss licentious radio's: The hundred millionth monkey: "Once upon a time all the web monkeys used tiny type on their web pages. Most used font size=2. The artistic and the long-winded used font size=1. The forward-thinking, standards-compliant web monkeys used stylesheets: font-size: 11px."

Thu, 30 Jan 2003 18:36:08 GMT

Ouch. Searching Yahoo-Google for "bad typography websites" (without the quotes) today returned *this* page as the first item in the results. Is Google insinuating that we are the worst website about typography? That we have the worst typography of any website? That we're the best website with bad typography? That we have *naughty* typography? We think we've just been insulted by a search algorithm....

Wed, 29 Jan 2003 17:26:55 GMT

I watched Enemy at the Gates the other day. The titles were awesome. They found a typeface that looks Russian Avante-garde-ish. Way better than flipping the R and N. And then they played with angles like Lissitsky, Tschichold, and the gang. I sure hope whoever did that was having fun. Just kidding. I've got plenty of food.

Sun, 26 Jan 2003 19:39:00 GMT

We -- infamously -- showed how to use your "user" stylesheet to undo zeldman.com's justification of body text. A new wrinkle is to add a unique class or id to your web pages as a "hook" to allow frequent visitors to override your styles. For example: <body id="licentious-radio"> in my webpages would allow you to override my styles without affecting other websites: body#licentious-radio p {text-align: justify; font-family: verdana; font-size: 11px} (Don't try this quite yet. We haven't updated our templates.) This is a fine cooperative-hack. But it just rubs your nose in the obvious design flaw: you should be able to specify user styles by domain and url, the way we can specify cookies. I'm not, of course, suggesting that a large percentage of browser users will ever learn CSS syntax and memorize the jumble of features and property names. But browsers *could* give us an easy interface to tweak the display of sites we use frequently. For example, many websites set font sizes that are uncomfortably small for many users. Some browsers let a user "zoom" a web page. I'm suggesting the browser let you easily add user styles for that website so that the user sees readably-sized text on every page on every visit, with only one command.

Thu, 23 Jan 2003 15:07:02 GMT

For page layouts of books, there is a common worship of the Golden Section, which yields tiny inner/back margins. That's lovely and practical with a small number of large pages with a high-quality binding. But in cheaply bound paperbacks, the Golden Section makes the book harder to read, and practically requires you to stress the binding beyond the limits of most glue. Consider the example of Bringhurst's The Elements of Typographic Style. The glue is pretty good, but if you don't fold the binding open, the lines of text curve dramatically. Josef Mueller-Brockman in "Grid Systems/Raster Systeme" devotes some examples and two sentences to the topic: "In voluminous books the pages become curved when the book is open. The wide back margins are intended to prevent the lines of text becoming difficult to read because of this convexity." If you want to play Golden Section, why not Golden Section what the *reader* sees when holding the book? That's very different from what you draw on a single flat sheet of paper.

Thu, 23 Jan 2003 14:41:16 GMT

There was a lot of fuss when wired.com switched to stylesheets for page layout. The front page I go to is back to tables: http://www.wired.com/news/nc_index.html The articles seem to be formatted with tables. (The lines of text are *too* long! I keep my browser windows *narrow* -- so narrow that a line of text that wraps to the window is reasonably readable. So I can just read the "print" version. I don't understand what they think anybody else is going to do. Maybe you're supposed to buy the magazine....) The regular front page is still stylesheet layout, though: http://www.wired.com/

Fri, 10 Jan 2003 03:30:53 GMT

Web browsers should incorporate acceptable bitmap image scaling capabilities. For example, a 240 pixel-wide image might be two inches for some users, but more than three inches for others. With good scaling, you could tell the browser to display the image as two inches wide, and it would be the same size even where monitors have different settings. As we've mentioned before, this would allow people with poor eyesight to cheat -- tell their browsers to scale up the size of text and images. For example, if there were actually 96 pixels per inch, a user could tell the browser to act as if there are 150 pixels per inch -- making text and images 50% larger. Current displays are such low resolution that any measure could wind up being rounded off to the nearest pixel. In the long run, the solution is higher resolution screens. This is likely to take a *long* time, because we are rushing so fast to LCD monitors that have even worse resolution than our CRTs. But five or ten years from now, things should improve.... It's still a good idea to let web browsers scale images well.

Thu, 09 Jan 2003 19:15:13 GMT

Another note on the impossibility of typography for the screen.... In print, we use italics to emphasize. On the screen -- because so few pixels go into each character -- italicized text (at common sizes) is much harder to read that regular text. The illegibility factor actually *de-emphasizes* italicized text. Not what you want. Then we have the option of making text bold. But at typical sizes, the strokes in a letter are either one pixel wide for regular, or two pixels wide for bold. This is *too* much emphasis. You would only do this if you want to keep people from reading the words that aren't in bold. What can you do? 1) Write such short chunks of text that none of this matters. Many weblog items are only a paragraph, for example. 2) Give up on writing to be read! Revel in headlines, lists, links, and bold. 3) Cheat. Use color for emphasis. How about dark gray body text and black for emphasis? Lots of problems with this approach -- many people will want to click on differently-colored text. 4) Use slightly larger than normal text, so there are enough pixels to make italics legible. Fortunately, people *do* read online. The best thing is probably just to avoid using a lot of extra emphasis that would interrupt the text.

Wed, 08 Jan 2003 20:08:26 GMT

Underlining links was a *seriously* primitive choice for html. Underlining reduces readability, even if it adds emphasis. So your eye is attracted to the spot, but the text is difficult to read. CSS provides more options. Try: border-bottom: 1px; text-decoration: none. That also lets you get away from coloring the link text. You might want to add emphasis to a link by coloring it, but a lot of times there's no need. You can leave the text color alone, and just color the bottom border. If you add pretty good line-height to make your text more readable, then you can afford a little padding, so there's some whitespace between the bottom of descenders ("gpqy") and the border. If you choose a border color that is lighter than the text, you probably have less need of extra padding. If you're worried that the border by itself doesn't add enough emphasis, try making it two pixels. I've been playing with this for a couple of days. Today I ran across this site, with a pleasant gray background, and a darker gray border for links.

Wed, 08 Jan 2003 19:51:07 GMT

One of the worst CSS tricks: set body text-align: center, and then a width for the content div. Anyone whose browser window isn't as wide as your div won't be able to see the whole page, won't even be able to scroll to read the part hidden *to the left* of the viewable area. (In Mozilla, at least.) Don't *do* this!

Sat, 04 Jan 2003 18:59:34 GMT

Wonderfully warm days around San Francisco! Yesterday I tromped around downtown SF again. Out of the wind, you wouldn't need a jacket. The excitement of the day was buying "Grid Systems / Raster Systeme" by Josef Mueller-Brockman.

Fri, 03 Jan 2003 15:45:42 GMT

My favorite bit from Emil Ruder's Typographie so far is that it's all done with illusions: A horizontal line *looks* longer than a vertical line of the same actual length. A perfect square *looks* as if it's wider than it is tall. A horizontal line looks "thicker" than if it were vertical. Etc.