Stuff & Nonsense Home

Where you’ll find designer, author and speaker Andy Clarke. The bastard.

Blogging And All That Malarkey

Lead Pipe

Would you be surprised if you heard me grumble about CSS3 and web typography *?

Probably not.

Fine web typography is almost always about readability, particularly the readability of long passages of text. Typefaces that have been designed specifically for on-screen reading (as opposed to print) go some way to making type more readable, but designers can make even the most readable screen fonts difficult to read and, conversely, you can make type set in faces that have not been designed for on-screen reading more readable.

There are several factors that affect readability; your choice of a serif over a sans-serif and the distinctiveness of the typeface you choose, the measure (line length), how you justify your type and the spacing between lines.

Leading

Leading (‘ledding’) (or line-height in CSS if you prefer) is, unsurprisingly, the space between lines of type.

It is perfectly acceptable to decrease leading if your chosen typeface has a smaller x-height, but when you set the line-height too tight, you darken the optical grey of your type and the ascenders (strokes that rise above the x-height) and descenders (strokes that fall below the baseline) merge to form a denser and less readable mass of type.

A small amount of additional lead often makes blocks of type more readable, but when you open the leading to much, you force a reader’s eye to make bigger jumps between the end of one line and the beginning of the next.

Again, there are several factors that should influence your choice of leading amount for body text.

x-height

x-height is the size of a typeface demonstrated by its lowercase x, as x is the only letter that stretches to all four corners of character space, disregarding of course letters with ascenders that extend above the mean line and descenders that fall below the baseline. (More on x-height at Wikipedia)

The x-height of a typeface has a big impact on its readability as it influences our perception of the size of that typeface, more so than the height of ascenders and descenders. Even when you set the same size on several typefaces (for example: 36px), those typefaces may appear to be different sizes.

x-height, together with differences in a typeface’s weight and character width, affects it’s apparent size, the darkness of it’s typographic ‘colour’ and therefore the amount of leading (line-height) that you should set between lines to maximize the readability of your type. As a general rule if the typeface you choose has a smaller x-height and a lighter weight, you should decrease line-height. When the typeface has a larger x-height and a heavier weight, you should increase line-height.

Here comes the grumble you’ve been waiting for…

The problem with CSS

Imagine this scenario.

For your design you want to use Calibri, a typeface with a smaller x-height and darker, denser optical grey. Of course for people who do not have Calibri installed on their system, you'll no doubt offer a more commonly found alternative, perhaps Verdana along with it’s larger x-height followed by the ubiquitous Arial with an x-height that is different again. Your resulting CSS font-stack would look like this:

body {
font-family : Calibri, Verdana, Arial, sans-serif; }

Most CSS frameworks that include a typography component and most everyone I know add a line-height declaration, wrapping up several font properties including size, line-height and family into one shorthand declaration:

font: 14px/20px "Helvetica Neue", Helvetica, Arial, sans-serif; /* 24ways */
font: 0.8125em Verdana, sans-serif; line-height: 1; /* A List Apart */
font: 11px/1.5em "Lucida Grande", Verdana, Arial, Helvetica, serif; /* Mark Boulton */

And there’s the problem with CSS, right there. Different typefaces, even common ones, that have been designed with different x-heights, need different amounts of line-height. Calibri less than Verdana and different again to Arial or Helvetica. But CSS does not provide the facility to specify a varying line-height if a font in the stack is not installed, as it retains the same set line-height value for all typefaces specified in the font-stack.

Specifying the font-stack in a different way,

body {
font : 12px/1.5 Arial;
font : 12px/1.8 Verdana;
font : 12px/1.3 Calibri; }

doesn’t help.

When Calibri is not installed or is disabled, a browser displays the typeface from it’s own browser (‘default’) stylesheet rather than falling back to the previously specified Verdana or following that, Arial. However it does continue to display the last specified line-height value, regardless of whether it’s accompanying font-family is available.

CSS3 will not help resolve this

When you have a few extra minutes to spare, take a look through the CSS3 Text Module. It was last updated over two years ago. While the CSS Working Group has proposed important additions, some, such as text-shadow that have already been implemented in the browsers I care about, there is nothing proposed to address the issue linking line-height to font availability. This is an oversight I hope that with the right encouragement and help they will rectify — and soon.

What are your options today? Perhaps a Javascript solution such as FontAvailable that can test for font availability. If you’re handy with the jQuery, you could then append a class based on the result:

.calibri { font : 12px/1.3 Calibri; }
.verdana { font : 12px/1.8 Verdana; }

and so on.

Of course you could choose to get around the issue of font non-availability altogether and utilise @font-face for even the most common of typefaces, it’s an approach I’m currently contemplating but one that brings about it’s own set of challenges.

Yeah, yeah Andy…

All you ever do is…

complain.

Leave your comment

Andrew Ingram

May 6 2009 @ 10:20am #

Excellent thoughts, you’ve managed to eloquently explain some of the issues I have with CSS.

I think that we were so excited to have something to champion (web standards) that we forgot to notice its glaring flaws before the technology became too embedded.

I really do hope that the authors of these standards pay attention to these kinds of posts rather than simply dismissing them as examples of insignificant edge cases, unfortunately I’m quite skeptical. Too many reasonable complaints and requests have been shot down on the grounds of not being worth the additional complexity.

Just enabling the full expression of typography on the web and doing nothing else would be a huge boost for the presentation of the web.

André Luís

May 6 2009 @ 10:25am #

Andy, this is scary. I was just talking about this very same issue with a colleague earlier today.

You’re spot on. And my reaction was exactly the same as yours… “css3 won’t help!”.

I’d go even further.

Tracking (aka letter-spacing) is also a property I’d like to be able to set on a typeface-by-typeface basis. Not all of them are designed equal, like you said, and that includes badly kerned typefaces that needs a minor tweak (the closest we can manage, I guess, is by adjusting a different tracking value).

So, maybe what we need is a way to specify line-height, letter-spacing, word-spacing, font-weight (*specially* font-weight!!), font-style for each typeface. And they’d only get applied if that typeface is available.

What do you think?

elliottcable

May 6 2009 @ 10:27am #

Small typo: s/more so that the/more so than the/. Feel free to delete this comment after you fix it (-:

elliottcable

May 6 2009 @ 10:29am #

Two more bugs: it says HTML allowed, but as demonstrated above, it’s not … and your captcha isn’t “above” the field, but to the right. — Ed says: OK, OK, I get it.

Jeff Croft

May 6 2009 @ 10:30am #

This problem is yet more evidence of the fact that CSS was put together, in very large part, by engineers, and not designers. It’s my experience that the folks behind CSS are *still* not really listening to designers when it comes to CSS wishlists and the like. It’s bummer, and one we have very little control over. Also, given the relatively long measure and reversed out text, I’d say the textarea I’m currently typing in needs a little more lead. ;)

— Ed says: Consider it done my friend.

elliottcable

May 6 2009 @ 10:32am #

On another note: I have an imperfect solution to this (and other related problems), in that I pre‐render a block of text far out of the user’s viewport, and compare it to known values to determine if the correct typeface is installed. It’s an ad‐hoc font‐stack implementation that allows me to do whatever I want based on the fallback sequence of the typefaces.

Anyway, far more annoying than any of this is when I can’t use the typeface I want at all — much less make it look just so — because some retarded browser doesn’t support `@font-face`. Srsly, much more important than any of this is that browsers get around to properly supporting typeface embedding.

Jeff Croft

May 6 2009 @ 10:40am #

> Srsly, much more important than any of this is that browsers get around to properly supporting typeface embedding.

It’s a good point. Proper support for @font-face across all major browsers, as well as cooperation from font foundries, would effectively make this issue moot.

Martin Bavio

May 6 2009 @ 01:41pm #

Very good post. I guess that until folks doing css specs start listening designeers (and as Jeff Croft wrotes, that is *still* not happening), we will have to solve the problem in our own ways. How? IMO, js

jQuery is the solution for now, easy and really fast. It´s a hack, I know, but it works.

Tim Brown

May 6 2009 @ 02:38pm #

Great point, Andy. I wonder if some FontAvailable-powered, dynamically written CSS might yield the same certainty as specifying type via @font-face.

Of course, you’d need a bunch of conditional statements (if Baskerville, line-height = 1.618; if Georgia, line-height = 1.7; etc.).

Tim Brown

May 6 2009 @ 02:40pm #

Whoops. Meant to link that up. FontAvailable (jQuery).

Matt Wilcox

May 6 2009 @ 06:57pm #

CSS has fair few holes that are obvious if you’re a designer. As Jeff Croft points out, it’s because the CSS group is a bunch of engineers with nary a designer among them. I’ve ranted ‘till I’m blue in the face about this very thing, as have many others, yourself and Jeff included. Never makes a scrap of difference. Which is why I’ve not blogged anything CSS related this year. What’s the point? No one with any power over the spec is listening. And those that do hear our protests just put their fingers in their ears and scream “lalala, I know best! You don’t need it, you’re just a designer”.

It’ll be nice when the whole font-embed issue is solved and makes this problem redundant. I imagine font-embed will get fixed far sooner than correcting an inherent problem with CSS. As usual. Shiny new things get priority over fixing broken implementations (here’s another pet peeve: background-position has to re-set X and Y. Which is bloody annoying when all you want is X - like, oh i don’t know, for _hover states_).

Andy moan away. I’ve largely stopped bitching about CSS’s problems in despair of them ever getting fixed. The W3C’s so ineffective as to be actively a problem. They’re in my way. Roll on browser vendors taking control out of the W3C’s hands: a-la -webkit-transition etc.

Matt Wilcox

May 6 2009 @ 07:06pm #

Oh, another basic problem with the font handling: Calibri and the new MS font family have smaller x-heights, which makes them optically smaller. When a font substitution occurs, say to verdana or helvetica, those fonts look too large for the design, despite getting the same font size. It’s not just a line-height issue, it’s an entire scale issue. It looks bad because we still can’t size by x-height rather than character height.

There’s this: https://developer.mozilla.org/En/CSS/Font-size-adjust

but as far as I’m aware IE, as usual, doesn’t do it. And therefore we can’t rely on it, and therefore we can’t really use it.

Matt Wilcox

May 6 2009 @ 07:10pm #

Last reply.

font-size-adjust WAS in CSS2. Then got ejected in CSS 2.1. By engineers.

Says it all. http://dbaron.org/log/20080613-firefox3-css#font-size-adjust

Ben

May 6 2009 @ 07:53pm #

This is exactly the reason I wrote my jQuery plugin - to allow for minor stylesheet alterations based on available font-stacks.

http://www.beseku.com/weblog/2009/04/22/detecting-installed-fonts-with-jquery/

Florent V.

May 6 2009 @ 08:38pm #

Hello,

First, as mentioned, font-size-adjust solves some of the mentioned problems. It’s not in CSS 2.1 mostly because there was no sign of it getting implemented in the short or even medium term. CSS 2.1 removed a lot of such unimplemented properties, which then divide in two groups:

- the ones that were badly designed (removed);
- the good ones (pushed to CSS3).

Font-size-adjust was pushed to CSS3.

Re: the W3C processes and the impression they don’t listen to designers,

1. The last time i heard the W3C CSS WG’s co-chair Daniel Glazman speak publicly, he insisted that they needed input from designers. And asked for such input.

2. What group of designers, or recognized experts, submitted propositions to the CSS WG using the appropriate communication means (the WG’s list, for instance)? Posts on designer blogs will most probably be ignored because… well, you have to submit your input, not put it on your blog and hope that someone from the WG will read it, submit it to the WG, defend it, etc.

3. Is the input that some designers submit (if any) organized, with propositions and arguments? “It’s broken, i wish we had this instead” is something, but it’s not much.

4. The W3C working groups tend to listen to a) organized groups and b) recognized experts. Since they’re mostly engineers, they may not know perfectly well who is a recognized webdesign expert. So the solution is: organized groups.

You know what to do: work with several people, create a proposal, submit it.

Clinton Montague

May 6 2009 @ 08:43pm #

The jQuery FontAvailable plugin is really useful - I like the class injection idea. I’m currently setting up a project using the plugin to track the availability of many fonts across different user groups using google analytics and awstats - if I find anything interesting, I’ll post up some results here.

Matt Wilcox

May 6 2009 @ 11:31pm #

@Florent

That’s an approach that’s been tried too, and it doesn’t work. My anger comes from extreme frustration, and it’s not because of a lack of effort on my part, or the part of designers in the industry. Take a look at my critique of the WASP Community CSS3 Feedback: http://mattwilcox.net/archive/entry/id/1031/

This is old ground. No matter if we write on our own blogs or fumble around in the strange hoops, disjointed blogs, and antiquated systems the W3C claim are “open dialogue”; designers are ignored. Engineers refuse to understand. Bert Bos continues to argue against 10yrs+ of sustained demand because, well damn, the stuff we want might be hard to achieve.

I don’t care. We need fundamental changes to CSS. The difficulty of implementation isn’t a designers problem. That’s an engineering problem. Doesn’t change the fact we still need things CSS doesn’t offer and which just get dismissed time after time.

Look at Andy himself, he was on the CSS WG and quit. Because it’s not workable. Because the CSS WG, to all intents and purposes, from outside AND inside, is a closed system where designers have too little influence, and stuff get politicized to death.

Anyway, the CSS WG is for now largely irrelevant. But that’s a whole other blog post I wrote and never published. Why? Because I realised I was raging against an indifferent, impotent, and irrelevant nothingness.

It doesn’t matter if a magic wand was waved and CSS3 got all the stuff we want. Math, variables, DOM traversal & inspection, and all that jazz I’ve been banging on about for over two years! Because the implementation into browsers will take at least 5yrs to become relevant to designers, and until any CSS3 attribute gets cross browser support in 90%+ of site visitors, we can’t USE them. Certainly not for layout.

The future of CSS layout and display is not going to be decided by any WG. It’ll be decided by browser vendors who implement stuff they come up with after listening to designers (transitions, transforms, font embedding, etc), and for the next few years, it’ll be all about JavaScript patching up display problems because CSS can’t do what we want. I hate that, but that is exactly what is going to happen: we’re going to rely on JavaScript for display. It’s already happening.

Phil Ricketts

May 6 2009 @ 11:50pm #

Matt speaks the truth…

Jeremy Helms

May 7 2009 @ 03:46am #

“@Matt”

Best read I’ve had all day. Preach.

Phil Oye

May 7 2009 @ 01:49pm #

Andy, I’ve been working on a jQuery solution to this problem off and on since your workshop in Sydney (which was great by the way). The code is linked below, but the gist of it is that tests a CSS font stack and it adds a class corresponding to the first installed font in the stack only. This will let you do all manner of advanced typography tricks.

FontAvailable doesn’t solve the problem if the user has arial, helvetica, helvetica neue, and verdana all installed and you want a different line-height for each, at least not without additional coding on your part.

But of course, fixing CSS itself would be a bit better altogether.

http://github.com/philoye/FontUnstack/

Florent V.

May 7 2009 @ 04:29pm #

Matt, i read your post and it looks like a good illustration of what i was talking about: feedback on a blog, that reflects your opinion (though comments show that others share this opinion or parts of it), that criticizes the CSS WG’s decisions and attitude, and hints to what you would like to see instead.

What’s missing here?

1. Organized, community- or committee-base input.
2. Detailed propositions with use cases, dummy code examples, description of effects.

You replied “This approach has been tried before”, but don’t offer a decent example of that. (I’m not saying that your article is not valuable, mind you.)

You highlight the requirement for use cases when quoting fantasai’s responses to community feedback, but don’t comment on that. Is that a way to imply that such a requirement is bogus? My take on this would be: if they need use cases (and i understand why they would), some group of webdesigners should work on use cases. My opinion is that the Web Standards Project’s request for feedback was flawed and incomplete, since it did not encourage quality submissions that would strongly make a point.

Time to do it again, but properly?

John Dowdell

May 8 2009 @ 05:39am #

Hi, if you’re interested in advanced typography and layout features, and are not helped by the realities of the “web standards” processes, then the Text Layout Framework in Adobe Flash Player 10 and AIR 1.5 shows great promise in aiding design work across browser brands, across browser versions:
http://labs.adobe.com/technologies/textlayout/
http://www.insideria.com/2009/03/flash-text-engine.html

It’s not fully-baked yet—it’s still in Labs, and does not yet have full authoring-tool support—but the development process for this capability seems more responsive to feedback.

jd/adobe

Commenting is not available in this channel entry.
Hardboiled Web Design

Hardboiled Web Design by Andy Clarke

How the latest technologies and techniques will make your websites more creative, flexible and adaptable. Get hardboiled in all formats from Five Simple Steps. Digital formats also available at Amazon.com, Amazon.co.uk and the iBooks store.

We’ve deconstructed this site to focus on content while we restyle. Expect wonkiness during the transition.