There’s been a welcome resurgence of interest in web typography over the past year or so, with many articles and conference talks offering techniques and theory. Frequently asserted is the notion that good typography requires accurate control of font size and line-height. But this is the web: it’s a special medium where the reader can have as much control as the designer—the implication being that text on the web, while bending to the designer’s will, must also be reliably resizable across browsers and platforms.
In this article, we will reconcile the designer’s requirement for accuracy with the user’s need to resize text on demand, arriving at a best practice that satisfies designers and users and works across browsers and platforms.
We’ll reach our destination by the traditional method of trial and error. With more than a nod to Owen Briggs’s pioneering work of 2002, I have created a base case with six iterations and 161 screenshots. Follow along, won’t you?
The test suite#section2
The content used for testing purposes was a two-column layout with body copy on the left and a sidebar on the right. Text was set in Arial to aid consistency across operating systems and platforms.
The browsers used for testing were Safari 2, Firefox 2 and Opera 9.5α running on Mac OS X Tiger, along with Internet Explorer 6 (IE6) and Internet Explorer 7 (IE7) running on Windows XP with ClearType turned on. Clearly this is not an exhaustive list of browsers, operating systems, or rendering engines, but it covers the majority of users out there today.
Each operating system and browser was run using its default settings.
Every iteration was tested to see how each browser rendered text at smaller, medium, larger, and largest sizes, along with 90%, 100%, 110%, and 120% page zoom levels, where applicable.
Base case#section3
First it was necessary to verify that browsers provided a consistent baseline from which to start. The base case shows that in each browser, the default text size is consistently 16px when no styles are applied (other than the browser defaults), and the text scales fairly consistently across the board.
Text size in pixels – iteration 1#section4
The default text size of the base case is a good starting point, but for most people (designers, clients, and their customers) 16px is too large for body text. In our example, the body text was reduced to 14px, with the sidebar set at 12px. This first iteration does just that, setting the fonts in pixels:
.bodytext p {
font-size:14px;
}.sidenote {
font-size:12px;
}
The result is that Safari and Firefox still resize the text, whereas IE6 and IE7 do not. The text can be resized in Opera and IE7 by using the page zoom tool, which magnifies the page layout, text and images within.
Text size in ems – iteration 2#section5
Although browser market share differs from site to site, and browser share statistics are drawn in sand, it’s safe to say that IE6 is still used by many people. So setting text in pixels would leave many people no means of resizing it. There’s also an argument that says IE7 users should be able to resize text without being forced to use the zoom control.
The next unit to try for text sizing is ems. The em is a true typographic unit, recommended by the W3C, and affords a precision keywords lack. Working from a default of 16px, the following styles should give the desired text sizes:
.bodytext p {
font-size:0.875em; /* 16x.875=14 */
}.sidenote {
font-size:0.75em; /* 16x0.75=12 */
}
The results show that, across all browsers, text at the medium browser setting is rendered identically to text set in pixels. It also demonstrates that text sized in ems can be resized across all browsers. However IE6 and IE7 unacceptably exaggerate the smallness and largeness of the resized text.
Body sized as percentage – iteration 3#section6
A fix to the exaggerated text resizing of IE6 and IE7 is to size the body using a percentage. So retaining the ems on our content, the following styles were tested:
body {
font-size:100%;
}.bodytext p {
font-size:0.875em;
}.sidenote {
font-size:0.75em;
}
The results show that the difference between larger and smaller browser settings in IE6 and IE7 is now less pronounced, meaning we now have all browsers rendering text at an identical size on their medium setting, and resizing text consistently.
Setting line height in pixels – iteration 4#section7
Recent web typography articles such as “Setting Type on the Web to a Baseline Grid” (A List Apart, April 2007) stress that good typography requires a vertical grid, that is to say a solid vertical rhythm achieved with a consistent, measured line-height. The key implication is that line-height should be the same regardless of the size of the text (so that line-height, or the vertical grid, remains consistent, regardless of font size).
For our example, a suitable line-height is 18px, so that is added to the body as follows:
body {
font-size:100%;
line-height:18px;
}.bodytext p {
font-size:0.875em;
}.sidenote {
font-size:0.75em;
}
The results show that the 18px line-height is inherited by all text on the page—note how the sidebar text has the same regular rhythm as the body copy. Specifying a unit (in this case, px) when setting the line-height enables the value to be inherited throughout the page. If a unitless line-height had been specified, the multiplier would have been inherited, resulting in line-heights being rendered proportionally to the text size, thus breaking the vertical rhythm.
Unfortunately the results show that the 18px line-height is not scaled by IE6 and IE7 when text is resized, meaning the largest setting appears to squash the text.
Setting line height in ems – iteration 5#section8
When pixels failed before, we turned to ems. Repeating the logic gives us the following styles:
body {
font-size:100%;
line-height:1.125em; /* 16×1.125=18 */
}.bodytext p {
font-size:0.875em;
}.sidenote {
font-size:0.75em;
}
The results show accurate, consistently resized text and line-height across all browsers. Perfect. Or nearly so.
The Safari monospace problem – iteration 6#section9
The observant among you may have noticed a wee glitch in the Safari screenshots: the monospaced font included in the body text is rendered inconsistently. For text set in pixels, Safari renders the monospaced font at the same size as the proportional-width text surrounding it. When text is set in ems, however, Safari renders monospace text much smaller than the surrounding text. The inconsistency appears to stem from Safari’s default text sizes, which are 16px for “standard fonts” and 13px for “fixed-width fonts.” Safari 3α on OS X does not appear to suffer from this problem.
You could decide that undersized monospace text in Safari is something you and your readers can live with, and as Safari 3 is included in OS X Leopard and the latest update to Tiger, it will not be long until the problem pretty much disappears. For the nervous control freak who can’t wait, an alternative fix is to send text sized in pixels to Safari.
The following code appends a downlevel-revealed conditional comment to our styles, so that pixels are sent to all browsers except IE6 and IE7 (note the [if !IE] syntax, instructing IE/Win to ignore the markup that follows).
<style type="text/css">
body {
font-size:100%;
line-height:1.125em;
}.bodytext p {
font-size:0.875em;
}.sidenote {
font-size:0.75em;
}
</style><!--[if !IE]>--><style type="text/css">
body {
font-size:16px;
}
</style><!--<[endif]-->
The results show consistently resized text and line-height across all browsers, including the monospaced text in Safari 2.
Conditional comments are controversial, with many detractors and proponents, but I believe the approach is appropriate in this case, as we are using a browser feature (conditional comments) to work around a browser behaviour (non-resizing of pixels). It should also be noted that, for the sake of clarity, the code listed above presents CSS rules within style elements; best practice would dictate the use of linked style sheets instead.
Conclusion#section10
Our task was to find a way to size text that allows designers to retain accurate control of typography, without sacrificing the user’s ability to adjust his or her reading environment. We tested various units across common browsers. Sizing text and line-height in ems, with a percentage specified on the body (and an optional caveat for Safari 2), was shown to provide accurate, resizable text across all browsers in common use today. This is a technique you can put in your kit bag and use as a best practice for sizing text in CSS that satisfies both designers and readers.
Addendum#section11
Ems can be tricky to work with, especially when nesting elements deeply, as it can be hard to keep track of the maths. However, commenting your style sheets well and styling elements from the body inwards can keep things easier to follow. This more complex example and its accompanying style sheet demonstrate how to size nested elements using the body as the starting point.
Aren’t the problems with em sizes on IE6 and IE7 caused by the fact that an em is a bit smaller on those browsers? .9759 times the size of a “regular” measure, if I’m not mistaken.
I’ve always followed the 62.5% method – setting your body to have a font size of 62.5% means that any browser where the user hasn’t deliberately* changed their default font settings will set 1em equal to 10px. This means subsequent calculations are much easier and you can increase/decrease not only your text sizes but your entire grid, depending on how large/small the text is.
For an example, see the top few rules of “this CSS file”:http://www.beseku.com/includes/css/screen/core.css to see font sizes being easily calculated.
* Sorry, the asterisk above was because if a user has set their font-size to be something different, I don’t want to be ‘that guy’ – the one who changes it, (see also, resizing browser windows).
For those that want to use constant line height, your article will be useful; and those that don’t can ignore that part of it. However, although you cite others for regarding this as good typography , I gather that you embrace the concept yourself. This certainly isn’t the accepted wisdom for print, and it is ironic that the ALA page on which your article appears doesn’t go along with this either. I don’t accept every aspect of the ALA style (block paragraphs are my own special hate), but the smaller leading for items in the sidebars just seems to work. The converse I do not find to be true. I’m all for grids and rhythm on a page, but I think fixed leading irrespective of type size is out of tune.
I’d like to echo Ben’s comment above; the 62.5% method is surely one of the most widely used em-sizing techniques but doesn’t get any coverage in this article.
Personally I set my font-size:62.5% on the element, leaving my
free to set a sensible em size to cascade down.Wouldn’t this then cause anyone with a different browser default(I use 14px) to be shown text that is clearly not the same size as the designer intended them to see? If you apply the 62.5% method to my browser, you would then be presenting me with 8px text.
Should you really force some of your users to resize the text before they can read anything on your site?
I too have been using the 62.5% method ever since I picked it up from some “WordPress”:http://www.wordpress.com themes I was looking at. It has worked well for me, but I am going to try this method in my newest site I am about to start work on. I really appreciate the time the author took to make screen shots to show the comparisons.
Now… if only our clients understood how hard it is to get the fonts sizes consistent in all browsers… 🙂
I’m pissed as anyone else that you did not mention the 62.5% rule. I was like.. ‘who is this amateur?’. But then I see the link to Clagnut. “You are the person the internet has to thank for the 62.5% rule!”:http://clagnut.com/blog/348/ ! Well thank you.
I would, however, like to have seen some review of the techniques that CSS frameworks like YUI, Blueprint, and Tripoli use.
“http://clagnut.com/blog/348/”:http://clagnut.com/blog/348/
Thanks, @Paul Irish. Exactly.
Mr Rutter is the author who introduced the 62.5% rule many of us are already using. And now he is introducing a new best practice, based on experimentation shown in the article, and a desire to control the vertical grid as well as the font size.
Perhaps readers will forgive this innovator for continuing to innovate on our behalf, and will now actually consider what he has to say in the article, instead of criticizing him for not sticking with the rule he himself gave us.
A good, robust way of writing cross browser font-size CSS is something “we’ve”:http://www.tictocfamily.com/ been discussing at work recently.
We had previously been using the 62.5% technique and were fairly happy with it until reading about the associated issues with users who had changed the default text-size of their browser (incidentally, it was while exploring the rather useful “Blueprint”:http://code.google.com/p/blueprintcss/ framework that I read this).
One of the team here had suggested using pixel sizes for all but IE6, which would be given it’s own, percentage-based, styles but that just seemed like too much work for my liking (maintenance would also be made more difficult).
As much as using em’s can be a pain while dealing with nested elements, at least we now have a proven solution that would appear to cover all bases.
Thanks to the author for sharing. 🙂
@Cameron: Using pixel sizes for all but IE6 is something we’ve done at Happy Cog more than once (see Daniel Mall “here”:http://www.danielmall.com/archives/2007/02/07/the_agency_formerly_and_currently_known_as_happy_cog.php for instance).
I’ve been using the keyword method advocated by Dan Cederholm in Bulletproof Web Design where you set the font size with a keyword and then adjust by percentages off of the keyword. Has worked very well for me and was curious why no mention of it here.
I think the combination of techniques here is brilliant, and will make a great foundation for universal typesetting best practices on the Web. I still can’t help thinking that it’s a ridiculous state of things that one browser dictates so much complexity (however elegantly executed) to achieve such a basic technique. But if we worked around the box model for this long, I think we can handle this until IE6 goes to that single-digit percentile in the sky.
Another article about how to work around IE’s shortcomings.
Every other browser on Earth can enlarge or reduce text that is set in pixels. I will continue to specify my fonts in pixels, and if anyone wants to resize it, then they can zoom the whole page or download a more capable browser. Most of the people who are still using IE are the same sort of people who will never even click on their menu bar to see that there are text resizing controls, so it is a waste of my time to use complicated workarounds to accommodate the small minority who expect to resize text in IE. It is Microsoft’s choice to not let my text be resizable, not mine. If people accept IE as their browser, then they are accepting that decision and should live with it.
On the issue of “vertical rhythm” as being good typography: its a bunch of BS. Somebody made that up a year or so ago, but it is certainly not accepted as good typography. In fact, the space between paragraphs should be less than a full line, as that IS accepted as good typography.
“Math’ is non-countable. There is no plural of “math”.
@Brad Kemper: The idea of vertical rhythm is much older than one year. Where is it said that paragraphs should have less than a full line between them?
@Brad Kemper: Jason is right, vertical rhythm is as old as dirt. To reiterate, the author’s goal here is to “reconcile the designer’s requirement for accuracy with the user’s need to resize text on demand, arriving at a best practice that satisfies designers and users.”
I’d like to thank you for putting so much time and effort into this article. The screenshots were especially useful, and I’m sure they were quite time-consuming to create.
Many of the previous comments make good points (I’m not sure I agree with the one-size-fits-all line spacing technique, either) but I certainly welcome the dialog and any new insights into handling typography in this clunky thing we call a web browser.
@Brad Kemper: “Math” and “Maths” are both correct, as they are both colloquialisms for “Mathematics”. “Maths” is the form more commonly used in non-American english speaking countries. Richard Rutter is from the UK, hence, “maths”.
Like Derek, I’m also curious why there is no mention of the keyword method. It provides consistent, resizable text, and at the time of this writing, it has been tested in a wider array of browsers and platforms than the method suggested in this article. See the Yahoo! UI Library for a detailed description: http://developer.yahoo.com/yui/fonts/
Thanks for this. I have been looking for a good introduction to the best way of using em’s for a while now. I am now ready to go an apply these techniques to my websites.
Thanks again,
@derek allard and @Michael Christopherson
The “keyword method”:http://www.alistapart.com/articles/sizematters/ was actually introduced by Todd Fahrner in A List Apart in May 2001. Mr Rutter *does* refer to that method (and that article) in his article. The problem with keywords, he says, is that they are imprecise—by which he means, different browsers interpret them differently.
Thanks for drawing attention to this issue. As one with imperfect vision, I have my browser set to 24 points default. I constantly run into problems where text is poured into boxes that are sized in pixels, and it just does not fit. Go to slate.com and hit CTRL + several times (in Firefox) to see what I mean.
Even worse are sites that open up text in a fixed size popup window, with the Submit button at the bottom and no scroll bar. It might work at the default font size, but not with anything bigger.
Thanks for drawing attention to this issue. As one with imperfect vision, I have my browser set to 24 points default. I constantly run into problems where text is poured into boxes that are sized in pixels, and it just does not fit. Go to slate.com and hit CTRL + several times (in Firefox) to see what I mean.
Even worse are sites that open up text in a fixed size popup window, with the Submit button at the bottom and no scroll bar. It might work at the default font size, but not with anything bigger.
The point about setting line-height with units to keep it consistent is very interesting and useful; but I can’t believe we’re _still_ seeing people advocate setting a default text size less than 100%. The reason browsers have such a large default text size in the first place is to compensate for clueless web designers scaling down the text; carry on scaling down the text, and the browsers will just keep increasing the text size so that people can actually read the damn page.
The number one complaint I hear about web pages, by quite some distance, is that the text is too small. It’s nice that you put in some effort to allow people to scale the text if they need to; why not just leave the text at the user’s default size? If the user really hates 16px text, they can find out how to change it but, I suspect, most users are much less bothered by text that’s bigger than needed, than by text that’s unreadably small.
Please forgive a beginner if this question is off-base, but I was wondering why percentages can’t be used? Once the body is set to 100%, why can’t all other font-size declarations use percentages? Aren’t ems just relative to the parent element anyway?
And, on a somewhat related note, is the use of points necessary for print style sheets? Or does the author’s method print as consistently as it displays without a separate font-size declaration?
@Jeffrey
Sorry for the confusion. The method I’m referring to, which I inappropriately called The Keyword Method, is a bit different than Todd Fahrner’s original method. I’m not sure if it has a name, but it involves a combination of keywords and percentages to achieve consistency across browsers. “Yahoo!’s version”:http://developer.yahoo.com/yui/fonts/ of it contains a nice pixels-to-percentages conversion chart.
The idea of *pixel perfect* vertical rhythm is *not* what the *vertical rhythm* is about. And it is the same with font sizes — as monitors have more (and different) number of pixels per inch (especially on laptops) it becomes unnecessary to have equal and pixel perfect font sizes among all browsers, displays, monitors and devices.
Vertical rhythm is about *contrast*, points of *reference* and *flow* of the elements. There are many layout “examples”:http://bjorkoy.com/blueprint/sample.html where “text doesn’t”:http://clagnut.com/blog/348/ look harmonic (or could be improved) although their heading and text spacing follows certain logic of math.
Web designers should forget about the absolute values and start to think in relative terms (which makes the web design different from the print). Design and composition in general is about the _harmony_ and _relationship_ of different elements of information.
Therefore, it would be very useful to look at the text sizing from the perspective where element weight, line spacing and margins are more important than the ability to convert between pixels, ems and percentages.
I have made a collection of “Konstruktors CSS snippets”:http://konstruktors.com which include styles for basic typography and fluid grid/column based layouts. The typography part is based mainly on visually sound element contrasts — “view an example”:http://konstruktors.com/WordPressTheme/SansserifRacer . Another good example is “Tripoli”:http://monc.se/tripoli/examples/sample_f.html
At the same time there is no such thing as the perfect font, heading or line-height size. The designer has to decide with her own set of reasoning, which might even be unknown to the regular “viewer”. And this is exactly why design is so interesting and exciting.
Personally, my impression is that text sizing in CSS is a bit of a mess.
Sizing in ems seems silly, because ems are a measure of horizontal distance, not vertical distance, and for different fonts the horizontal-to-vertical ratio can vary.
Pixel sizing might make sense when trying to match text size to a fixed-size image, but really nowhere else.
Ideally, I think we’d all size our text in points, then any browser at default font size would take screen resolution into consideration and display the text perfectly just as it would appear on paper at the same point size.
(reply to comment 30).
That is where the ‘ex’ would be very useful. Sadly, implementations differ quite a bit.
WebKit (Safari) and Gecko do one thing (the most correct one: the ex is based on the x-height of the specified font) where as Opera and Trident (iExploder) do it more simple: 1em = 2ex.
Strictly speaking, neither are wrong (are allowed by the spec). The Gecko/WebKit method is more precise and sensible.
Scaling based on the default size to get accurate pixel results seems a strange concept me. If you need pixel-precision then px units seem the natural choice. Whilst it may have been a good compromise to use ems or percentages five years ago due to IE6’s dominance, IE7’s page zoom allows pixel-sized text to be resized whilst keeping it in proportion with image sizes, and other browsers employ a range of other text-resizing methods that are not affected by px units. Firefox for example, lets the user set a minimum-font size.
The other problem is if a user has changed their default size to something other than 16px — which is something I would like to change to 14px so that I can more easily read websites that have not set a size — then, as encountered with Safari’s default size for monospace, all bets on your pixel accuracy are off.
Also, isn’t it a little rude to be effectively saying “I don’t know what your default text size is, but I want it smaller than what you have chosen!”?
bq. Perhaps readers will forgive this innovator for continuing to innovate on our behalf, and will now actually consider what he has to say in the article, instead of criticizing him for not sticking with the rule he himself gave us.
Hang on there … The article specifically states that the methods proposed lead to difficult calculations when using EM sizing throughout a site. So if, in the forum that you are promoting, a commentator states that they prefer the original methods because of such a problem, and doesn’t see the benefits, they get sarcastic responses?
Without trying to provoke massive argument or come across as a dick, and fully admitting that I had no idea who came up with the original 62.5% idea, (if such a thing can be credited to one person), what the hell is the point of allowing people to post and discuss the merits of different techniques?
This sort of inventiveness and creativity should be put to a higher purpose than moving around letters around a page.
It’s been fifteen years, at least, since WYSIWYG was introduced to the masses for desktop publishing et cetera. That web techs should be fussing over tenths of a percent in a declarative page description language is just so 1970’s. Shades of Troff, indeed.
In any case, writing CSS as plain text is error prone, and error messages are usually nonexistent. We should be using property sheets for defining styles.
The techniques for producing consistent, multi-browser text sizing should only need to be known by those few programmers building WYSIWYG web writing systems.
Well I actually enjoyed the article. Thanks for the great screenshots and valuable information for cross-browser differences.
I use ems for font-size and have to admit that I have not used the 62.5% technique before. So I’m now off to have a play with that…..
None of this addresses the fact that *your* text on ALA is too small!
Body text should _never_ be rendered outside the range 90% to 110% (or 0.9em to 1.1em, if you prefer). If you find that, on your computer, it appears too large, then you should change the settings on your computer.
I have my computer set to display the text at the size I want. Your 0.8125em is too small, so I have to enlarge it to make it legible – this is _not_ good practice!
@Stephen Down: What’s too small for some is just right for others. We don’t aim to please everyone (and we’d be silly to attempt it). Changing the text sizes on our computers doesn’t make much sense. We need to keep our setups at the defaults so that we can approximate a baseline for testing.
We’re trying to make it comfortable for as many people as we can. We’re sorry if you fall outside of that, but that doesn’t mean our practices are bad. The fact that you _can_ resize it _is_ good practice.
On the setup I use everyday, there IS a difference in font sizes between Mac and PC when they are both set to the defaults. On my PC, which sits right next to my Mac, the fonts are bigger than they are on my Mac. So I do not get that the fonts are the same size. Does anyone else experience this or am I the only one?
In addition, I would also like to know why you can’t use percentages to solve this problem. It seems to work for me.
I did like the article though.
@Brad Kemper:
bq. Every other browser on Earth can enlarge or reduce text that is set in pixels. I will continue to specify my fonts in pixels, and if anyone wants to resize it, then they can zoom the whole page or download a more capable browser.
I’m usually one of the first on the IE-bashing bandwagon, but I think it’s wrong to do that here. IE _are_ following the specification by not resizing text specified in pixels, and other browsers are _wrong_ to do so. Pixels are for when you absolutely need the text to display at a particular size, and browsers should respect that. Text that can be resized should be set in ems, percentages or keywords.
But regardless of the rights and wrongs of it, you’re showing a very negative and unhelpful attitude. The vast majority of people using the internet, and particularly those in the 90% of people who use IE, don’t care about web design, they don’t care about web standards, all they want is to be able to browse websites. If you are deliberately stopping people from resizing body text by using px measurements then you’re just as bad as the people who omit alt text and who use Javascript popup links “because anyone who can’t cope with that doesn’t deserve to use my website”, or whatever crappy justification they come up with.
As web designers, we have a responsibility to clients – to design a website that serves their organisation’s needs – a responsibility to the general public – to design a website that allows them to access the content and services therein and that is easy and pleasing to use – and a responsibility to the web design community – to promote and use best practice, to continually raise the bar, deliver the best we can, and encourage others to do the same.
There’s no place in there for having a tantrum about people using unsatisfactory browsers.
About the monospace ‘problem’ – Safari and Firefox both keep monospaced fonts at 13px. Safari 3 on OS X does as well. I’m not 100% sure about 3a mentioned in the article, but I believe it used 13px as well.
If like me, you don’t want to revert to pixel-sizes to bypass this, “here is my solution”:http://dusan.fora.si/blog/normalize-monospaced-text-font-size to the problem. But it does use some css hacks and might not be future proof.
@Voyou Desoeuvre:
bq. The point about setting line-height with units to keep it consistent is very interesting and useful; but I can’t believe we’re still seeing people advocate setting a default text size less than 100%. The reason browsers have such a large default text size in the first place is to compensate for clueless web designers scaling down the text; carry on scaling down the text, and the browsers will just keep increasing the text size so that people can actually read the damn page.
It’s nice to know I’m not the only one banging on about this! Jason, I see what you’re saying, but I still fundamentally disagree. I have the text on my computer at the size I find most comfortable to read. On Opera, ALA appears fine, if a little on the small side. On IE6, it is completely illegible.
Yes, it’s good that I can change the size – but that’s not good practice, it’s simply working around bad practice.
Browser chrome is there for a purpose. The settings to allow people to set a preferred font size are there for a purpose. Once someone has set their preferred font size, all websites should then be legible without having to further fiddle with things.
The main problem, as far as I can see, is that by using ems, you stuff things up for IE users who have their text set to anything other than ‘medium’. I might be wrong about the cause of this, but I think it’s a bug in the way IE treats ems at non-medium text size.
eg, on another site, if I resize from ‘medium’ to ‘smaller’, the text reduces by about 25%, and retains a sensible size … but if I resize from ‘medium’ to ‘smaller’ on ALA, the text size *halves*, which is why it becomes illegibly small. Other changes result in similarly dramatic changes – at ‘largest’, I only get about 12 lines of text on the screen.
When using only EMs, IE creates a new baseline for the text and enlarges and reduces from said baseline (instead of the original baseline dictated by the browser’s default size). It is because of this anomaly that the text is reduced and enlarged beyond what would be considered normal, and what is offered by other browsers.
In other words, if “Larger” is 150% of a 1em baseline, “Largest” will end up being 200% of the new 150% baseline, instead of being 200% of the real 1em baseline. This, of course, makes the enlarged text abnormally large. And the same works in reverse for text reduction.
This is a bug, but one that’s easy to get around. The rule: Never start sizing text in EMs in the style sheet (even if you want to use EMs). Always start with percent, as in 100% (instead of 1em). Doing this normalizes this baseline font size bug in IE and allows developers to use EMs anywhere else in the CSS file. So something like this is the cure:
body {
font-size : 100%; /* Set a cross-browser baseline in % */
}
#wrapper {
font-size : 0.9em; /* Then size the text as you want */
}
Hopefully what I just posted can be fixed to look as it should.
Just a couple thoughts…
I am both a web and print designer and I like to believe I know a fair bit about typography. Why web designers/developers have become obsessed with everything being set to a rigid baseline grid is beyond me. Where did you get this from? If you know anything about print you know that you don’t set all text to the same baseline grid—it looks like crap. It’s bad practice. It doesn’t make sense.
I also don’t understand why everyone is so obsessed with having such control over the size of text. Aren’t we supposed to be over this already? I agree fully with those that have said that body copy should appear at the user’s default size setting. End of story. That’s the point isn’t it? I’m 32 and I find the text on this site a little small. God knows what I’ll think of it when I’m 52. Why are we trying to figure out better ways of telling users what we think they want?
When I design for print I take total control. When I design for web I hand over some control to the user. I’m happy with that.
I came across this “pt” measure, that is supposed to resemble true size (postscript points), so very common things like 9pt/12pt could be done in that very way. I have been using this pt method for a while; By the way, I find “ems” making a lot more sense than pixels, meaning I find them more of a natural measure for type than pixels. Eventhough I feel uncomfortable having to write uncomprensuble things like: 0.873em.
anyway, I’ve seen that Pts do rezise. So I have been using them happily
Gabriel,
The main reason for not using pt for screen work is that points are defined as a physical measurement of 1/72 inch. How that is displayed on screen is a matter of luck rather than judgement – Windows and Mac render pt very differently.
Yes, by all means use pt in your print.css, that’s what they do well. But they don’t belong on screen – that’s why we have percentages, ems, keywords and pixels.
Try to set (for example in Windows) different DPI in screen settings, you will get sometimes unusable design with your default CSS using EM’s units. The problem appears on small LCD’s with high resolution (mostly small notebooks). I think, the best is to let user to choose appropriate size of text (by choosing from predefined CSS styles).
But in a perfect world, where the operating system could detect display’s dpi and set its own dpi accordingly, pt would make a lot of sense. Such as it is nowadays, most users don’t really know what dpi means and even a smaller percentage have actually ever tweaked this setting.
BTW – There used to be a dpi setting in Firefox that let you determine your display’s dpi. But I can’t find it anymore, have they removed it?
Ok, now we have Arial pretty much covered — but it’s a pretty ugly and bland font — especially when you see it practically *everywhere* today.
What I would like to see next is a technique to make the font sizes consistent on different systems when you use a list of fonts, because you expect that different users have different fonts installed.
For example, this simple style:
font-family: Techno, Impact, Haettenschweiler, sans-serif;
will render at completely different sizes depending not only on the user’s DPI setting, browser’s default font size and zoom level and system’s hinting settings, but also on which of the fonts are available, what arcane rules the browser in question uses to select a font from the list, where the font files came from and the phase of the moon.
It would be really awesome if someone found a way to deal with it. Of course, embeddable fonts would solve this easily — but they are only in one rendering system, and not even a web browser.
Good to see someone hacking out hard comparison data.
Confirms what I’ve found on my own – font rendering is now remarkably consistent from browser to browser.
A one-whitespace-fits-all line-height (leading) regardless of font size flies in the face of readability studies measuring both speed and user-preference. Disregard.
Line length is an issue much worth thinking about.
Plus tightening the word-space property. (Any data there?)
And, very occasionally, letter-spacing.
Lastly, how about the ability to intelligently justify text, hyphenation and all?
Let’s go for it! Solid work, this.
This is a great article, thank you! I have been feeling the need for an update on Owen Briggs work, and it is fantastic someone has done that work for us.
With an old PC screen sitting beside my clean, high resolution mac-connected-monitor, the size differences in IE have been irritating me for a while. The old monitor seems to have large pixels, so that everything looks clunky, and it is hard to know what is the monitor, what is a PC-talking-to-a screen issue, and what is a browser issue.
So thanks for some hard facts/screen shots and a new formula. All I have to do now is get used to figuring the maths with nested ems. And decide where I stand on the line-height issue.
> For example, this simple style: font-family: Techno, Impact, Haettenschweiler, sans-serif; will render at completely different sizes depending not only on the user’s DPI setting, browser’s default font size and zoom level and system’s hinting settings, but also on which of the fonts are available, what arcane rules the browser in question uses to select a font from the list, where the font files came from and the phase of the moon.
Given that the font will display differently on different machines because of the user’s size and zoom settings (which is a _good_ thing), why make a fuss if it displays differently for other reasons? You’ve already found a reason why the design has to be flexible, so just let go and accept that there may be a few more differences in the way the text is rendered.
Put this on your home page:
Is the text on alistapart.com too small?
A. Yes
B. No
I haven’t read ALA for a while, and I’m pretty shocked by the comments. What is wrong by showing manners and using a bit more language to present your criticism other than ‘idiot’? It looks like communities are going the same way as USENEt did: the drain.
Apart from that, one commenter expressed that he is happy to give control to the user, which is something I am for myself. However, I feel that using this method the comtrol is in the hand of the user: if you change your default font sizes in your browser preferences than you have to live with the consequentes. Scaling pages up and down will render proportional typesetting, which is what this article aims at.
I do not like page zoom like Opera and IE7 display because of scrollbars, so this method gives a bit more flexibility. Well written and very clear and tested examples!
When testing the 62.5% rule really at 62.5%? When testing font-size output in different browsers I found that Opera displays the font at the next smaller possible size at 62.5%.
So I tried to bring it up to 63% which worked out perfectly for all browser (ie 6-7, firefox, opera).
Anyone know the reason for this?
the funny thing is that only one person talked about the difference across browser’s platform, the truth is this:
safari mac and safari pc = no changes in font sizes
firefox mac and firefox pc = big changes in font sizing
conclusion:
safari most consistent browser across pc/mac platform.
Firstly, Stephen Down wrote defending IE’s non-resizing of fonts set in pixels: “Pixels are for when you absolutely need the text to display at a particular size, and browsers should respect that.”
Not this argument again. All I will add is this: what if the text size chosen is considered too small by the user? Who dictates that they cannot choose to enlarge it? No-one should! To hell with fixed pixel fonts. Even IE5/Mac could resize fonts in pixels. (And even IE6 can enlarge pixel fonts if you use ‘zoom:’ in your stylesheet, or create a User Stylesheet. So it seems more of a bug than a deliberate feature, though I could be wrong. Anyway, since it is the only browser to do this, we can ignore it.)
Secondly, the person who wrote about enlarged text not fitting boxes in Firefox will be glad to know that Firefox 3 (released in beta form as I write) can enlarge the whole page. Of course now there are people complaining that they only want the text enlarging! Well an option for either method would be good. But at least Firefox has now joined the ranks of Opera and IE7 in intelligent page resizing. Zoom on!
Thirdly, I am viewing this site with the text enlarged myself, because I agree with others who say the text is too small. Just my opinion of course.
T really liked the article. Thank you.
I got tired of calculating the ems and wrote a small php-script to calculate them for me
http://www.sange.fi/~vtakanen/typography/linefeed.php
Caveat: A work in progres.
.. and not the one you might think 🙂
The syntax used is not only wrong, it will cause IE to not render anything after the comment – it’s never considered closed…
instead of
–>
you should have used
Ran across the problem as I was using your guide, and suddenly, IE7 did not render my page at all – after changing the conditional comment as described above, it worked perfectly…
Also, if one considers quirksmode.org a reliable source, read here: “http://www.quirksmode.org/css/condcom.html”:http://www.quirksmode.org/css/condcom.html
As was touched on earlier, I think this kind of debate points out the limits of CSS as a formatting model – the tinkering with CSS to produce consistent effcts is a rewarding challenge – but ultimately I always feel as though both HTML and css are already anachronistic, in terms of what they were originally purposed for – styling text documents – and what they are increasingly called on to do – i.e. structure user interfaces for web services.
I been asking this question to myself a thousand time and this is one of the best examinations of text sizes. Given me great insite into building my next website.
Thanks
bq. Not this argument again. All I will add is this: what if the text size chosen is considered too small by the user? Who dictates that they cannot choose to enlarge it? No-one should!
My view on it is this:
You should be able to set a _minimum text size_ in your browser settings, so that no text will ever be rendered smaller than, eg, 12px (or whatever else you consider the minimum that you can read). This would be the equivalent of a user !important, and would override anything the website says or does.
You should be able to zoom the page (text, images and layout) to enlarge or reduce it as appropriate. Opera seems to do this better than IE7, but that may just be because I’m more familiar with it.
The designer should be able to make concrete layout _suggestions_ that the browser will respect where possible. That means that there are *some* occasions where the pixel size of text is important to the layout – eg, because it has to fit with images that are necessarily sized in pixels.
That’s why we should *not* use px for font sizing as a matter of course – because it should be reserved for those occasions when you absolutely need the text to be displayed at that size – 99.99% of the time, ems or %s are the right way to go.
The main reason that browsers do support resizing of text in px is because they are trying to compensate for the idiocy of designers who have inappropriately specified text in px across the board.
I personally don’t understand some designer’s desire for such pixel perfect designs. Web pages should be more fluid than that (of course there are exceptions). I personally use em and fix the IE issue by setting the body font-size to 100%, as was mentioned in an earlier post. For the main content I generally use 1em because that should be the default. I don’t do any .865em or whatever, I just make things relative, often .9em or 1.5em.
I don’t care much for the zoom option in some browsers, but I do think it would be good for browsers to have both options of zoom and text size in-/de-crease.
Just as another vote, I find ALA text size too small. I’m currently viewing the page 3 notches up, though my eyes are tired, but usually use 2 notches for the site and I’m in my mid-20s and have good eye sight. Too many sites are decreasing their font-sizes. The default 16px is there for a reason like others have stated. Though I find it funny that the texarea box for writing a comment is quite a bit larger than all of the other text on the page.
Overall, nice article and good things to think about.
I first settled on pixels for font sizes after reading the original release of Zeldman’s DWWS. Ems have a certain attractiveness, in that they let you set a base size and then set everything else in relation to that. That flexes nicely, if I want to rework a sheet with a new base size and have everything change proportionally without having to touch all declarations.
However, this is the sticky bit that I completely don’t understand: What’s with the compounding on nested items? Why in the world would I want to embrace a typesetting standard that requires me to keep track of where in the document hierarchy a piece of type is and then CALCULATE the proper setting to keep the type AT THE SAME SIZE? That’s crazymaking. The push for standards was about stopping the madness, and it seems this is just an exchange of one form of madness for another. “Stop all the browser code forking!” (Hooray!) “Compute arcane, essentially meaningless size settings (1.375em
?), and make sure your nested items have their own settings (for each level of nesting) to compensate for compounding!” (Hooray?)
This is progress? All of this to accommodate a segment of users who have chosen to use a tool that doesn’t do what they want? That sounds like a personal problem. Whatever happened to individual accountability? Why should an industry adopt an awkward, recursive practice of font sizing to fix something these users should be fixing themselves? Any self-respecting programmer would snort and walk away. Any self-respecting designer would just decide you’re crazy.
Perhaps this is related to the notion that several have brought up about the rigid baseline grid being a typographic anomaly that has grown up in the soil of typographic ignorance on the web. Maybe those who are valuing “upsizing for all! (even apathetic IE 6 users)”? over and above sensible methodologies are mostly politically correct nouveau-web fanboys who are ignorant of the older, and more established streams of thought coming from the worlds of typographic design (dating to at least Gutenberg), and programming (Donald Knuth, anyone?) that inform these issues.
I think I’m sticking with pixels. Page zoom is a good solution. IE6 users are the only ones left out. Anyone with vision problems should do the research to solve their problem by changing browsers to one that does what they want. If they don’t, then it’s their bad, not mine. Web makers shouldn’t have to jump through flaming hoops backwards to accommodate apathetic users who want to complain about type sizes when the problem is their passivity towards solving their own issue.
I try avoiding putting styles (like fontsize) on the P-tag because CMSs don’t always relyably produce the desired clean HTML-output. Sometimes the editors used in CMSs produce a P-tag around the content, sometimes they don’t. If you try to catch this in your templates by putting a P around where the content is loaded, you will get invalid code when de editor does produce the P (P within P).
So I try to put these styles on the surrounding DIV. Did anyone work out the alteration of this code to suit this need?
Someone had to do this testing – I’m glad to say that my non-scientific testing correlates to richards findings. Now I can rest assured that there is a proper way to set sizes in css – ems baby, ems.
Plus, I think guttenburg would be happy. The pixel shall not win this battle. 😉
I used this article while designing a site I’m working on now. I have always had problems with (em) and cross browser quirks, this is great for make those readily apparent. Previously I had giving up on em just because of all the browser issues associated with it. This method has proved flawless so far on the site, and I will probably use it on all subsequent sites I design.
Another awesome piece of research and testing, cheers Richard. If the article upsets me in one way, it’s in realising that this sort of article should only be enforcing the test we’ve already carried out…unfortunately time and resource doesn’t always permit so it’s thanks to you again – this article will be passed around our developement team and adopted as apart of our coding standards.
Using ems (or any percentage method) to resize fonts pretty much guarantees sub-optimal design and legibility. This current “received wisdom” of web design, focusing so hard on technical aspects, generally fails to recognize the nature of pixel-rendered fonts.
Fonts cannot be resized successfully simply by using ems or any other percentage method. They are not like svg objects. Fonts are an art form and the size in pixels is critical. If you render a font at 80% that was drawn at, say, 18px in height, you do not get the same font 20% smaller. You get a different font that is usually less legible and less attractive, and is often downright ugly and hard to read. Resizing fonts by using percentage reduction is tantamount to resizing images by using percentages.
If you want your typeface to look good at different sizes, you have to retain style control. This means using fixed font sizes and providing alternate font sizes yourself, which is fairly easy to do through a server-side script.
Thanks for posting up your article. I’ve used the test pages you provided and looked at them in FF2/IE7 on a PC. Using the EM method you’ve described, there is still a large font jump in IE7 on the PC. Has anyone else noticed this, and is there a recommended cure?
Fantastic article, but on thing really stuck in my head as I looked thorough the countless screen-shot examples (cant beat pictures), the difference that ClearType makes with browser rendering in comparison to the mac fat’n’furry soft rendering.
I get that its a personal preference, but wouldn’t it be great if Apple and MS could just agree that fonts should display as they were intended to by their designers.
Hi Richard,
This is a wonderfull experiment and I would like to thank you very much for sharing it with the world. However I have an objection inregards to your conclusion.
First please let me draw your attention to what you have here:
The tests that you have done are based on the following environment:
1-Tests have been done with limited number of browsers as you pointed it out yourself but they are not the majority of the browsers as you mention in your article.
2-Tests have been done in two operating systems.
3-Tests have been done with one font-family.
4-Tests have been done in a two column layout.
5-Tests have been done with XHTML strict doctype and charset=utf-8
So what is the objection?
Even though I look at the conclusion of your article positively (and BTW i have experimented myself in some part of my site) however I believe it only applies to your experiment and cannot be generalized as you have generalized in your article.
Clearly there are other factors which affect the rendering of a web content. The structure of web content and the environment in which the web content is present are the most important part affecting the rendering process.
As you know It is possible for a content to be rendered correctly in one layout / browser/platform however with problems such as overlaps in the same layout but in different browser/platform or in different layout / browser/platform.
So if we use another layout or structure other than two column layout or another font-family, etc. it is possible to see some inconsistencies or it needs to be proved by some more experiments that there are no any inconsistencies.
So basically it is not enough for a text or any element to be a cross browser/platform text / element. It also needs to act properly in relation to it’s neighborhood preventing any layout stability problems when viewing normaly or when resizing the browser’s window or applying zoom etc..
That is why I have defined the layout stability on my site located at cssfreelancer.awardspace.com to address this issue.
As you can see in my site, I have:(I am aware of that 62.5% thingy :), I have experimented the following too)
body { font:96%/1.7 georgia,serif}
Line-height (unitless for body but in ems for the rest of the elements)
Then I have two sections. 1-Navigation elements 2-Rest of the document.
I have set the font-size in ems for Navigation elements and no font-size declaration for the rest of the document. That is set for all browsers.
With the above combination of font-size and line-height, I have experimented my layout using browsercam’s online service with different browsers including IE6,IE7, AOL, Camino, Konqueror, Different versions of (Firefox, Netscape, Opera, Safari,Mozilla, ) on different platforms such as Windows Vista, Windows XP, Windows 2000 Professional, Linux and Macintosh. The screen captures are available at the following
URL:
http://www.browsercam.com/public.aspx?proj_id=389986
My experiment proves that, for my layout and with my test parameters like font-family etc. setting the above mentioned CSS rules turns out to be a consistent cross browser and platform solution.
However I still can not generalize it and I am still debating on it.
Any comments in this regard would be greatly appreciated.
@Loren
I had the same problem and could not figure out the problem. But since I have a large monitor and bad eyes I changed my dpi to 120. And apparently IE7 takes that into account when displaying fonts. All is good now that I switched my font dpi back to 96.
@article base case – "For most people (designers, clients, and their customers) 16px is too large for body text" is a rude and unsupported assertion. While empirically it can be said it is quite evidently true of web designers, the same cannot be said of the other two groups. The "size" of 16px has been creeping down for over a decade as the average PPI has been creeping up. While it may well have been true over a decade ago that most people agreed the defaults were too large, there is no published evidence anywhere I have found to support that assertion against the average current environment. OTOH, there is at least some published support in contradiction “http://www.useit.com/alertbox/designmistakes.html”:http://www.useit.com/alertbox/designmistakes.html and recommending that user default size be respected “http://www.w3.org/QA/Tips/font-size”:http://www.w3.org/QA/Tips/font-size to be found on other than my own web site.
Konqueror defaults to a pt size that is less than 16px when the DPI is 96. All IE browsers default to 12pt, not 16px. 16px only appears to be its default as a consequence of the a default M$ system setting of 96 DPI. Use of other than 96 is common on recent and current laptops (which, by the way, have been outselling desktops for several years), which typically have a considerably higher than average PPI and need OEM correction to avoid illegible text on their already small displays. Manufacturers have made 120 DPI a virtual default for laptops. The result is IE and other browsers whose defaults are not set in px give users who have not made further corrections 20px @ 12pt instead of 16.
@article&more (Richard R, David L, others) – Line-height set other than unitless is a bad habit. That only unitless carries down the cascade as a factor rather than as a previously computed value is a good thing. It means when zoom or minimum font size are employed by the user’s agent to turn your mousetype into otherwise legible text that that text is not constrained to a space into which it cannot fit without overlapping the text above and below it. See “http://mrm.no-ip.com/auth/line-height-inherit.html”:http://mrm.no-ip.com/auth/line-height-inherit.html to understand the problem.
@1 (Kari P) – IE em sizing problems are complicated. As answered earlier, setting a % size on body eliminates IE’s basic compounding problem. What hasn’t been mentioned is that the various browsers round differently. That means the starting point can be different right off the bat, but as they cascade and additional sizes are added, the rounding differences also compound. Take a look at “http://mrm.no-ip.com/auth/Font/font-rounding.html”:http://mrm.no-ip.com/auth/Font/font-rounding.html for more detail via a testcase.
@5+ (James S, more) – No one here yet mentioned a not inconsequential result often encountered on pages using the Clagnut/62.5% method. 62.5% is really convenient only for designers who think they need to size things in relation to this variable and unknown size thing called a px. Invariably these designers prefer text in their work to be a smaller size than average people are comfortable with. For defense against this rude designer behavior, modern user agent makers include functions like text zoom, page zoom, and minimum font size. When text zoom and/or minimum size are applied by user agents based upon the Gecko rendering engine, the ostensibly intended effect is multiplied in a manner similar to IE’s font sizing of ems that aren’t applied against an ancestral % size. The effect is truly overlarge text (based upon the visitor’s preferred size), often producing overlapping and/or hidden (inaccessible content). “http://mrm.no-ip.com/SS/Clagnut/eonsSS.html”:http://mrm.no-ip.com/SS/Clagnut/eonsSS.html demonstrates the problem with screenshots, but you can easily see for yourself by setting equally default size and minimum size to a size significantly more than 16px and then visiting a 62.5% site, such as “clearleft.com”:http://www.clearleft.com.
@26 (Voyou D) – Please stop repeating the mantra. The defaults stopped being "big" years ago. For most web browsers the default size measured in px has not changed for at least 12 years, and probably much longer. Because of the decrease in average PPI over the years, the apparent default size has been decreasing. To the rest of what you wrote, well said.
@32 (Adrian D) – It isn’t a little rude, it’s a lot rude.
@37 (Jason S M) – Not only does changing your browser defaults not not make perfect sense, you’re derelict in your testing thoroughness to not be constantly changing them to emulate the wide range of possible user conditions. There are too many variables in user environments to assume that users have one resembling your own, regardless what the system and browser settings were when you got your own hardware. Assuming any user setting to be wrong and in need of arbitrary adjustment by someone with less than 100% of the situational facts is nothing short of rude.
@39 (Stephen D) – Web browsers are user agents, not web page author agents. Those incapable of accommodating user wishes and needs are broken. It doesn’t matter what your design requires or the CSS specs seem to say. If I can’t read it, it’s worthless.
@48 (Dusan S) – Modern open source operating systems can and do detect display DPI, thus rendering text on screen sized in pt exactly the same size as when printed. The problem is that screen resolution falls short of print resolution, while the average distance between text and user’s eyes is considerably greater for screens compared to books, magazines and newspapers. Text on screen usually needs to be physically bigger than printed text in order to be equally comfortable to read, or even legible. Firefox for Linux and Mac do allow a different assumed DPI, but there is no UI for changing it. Type about:prefs in the urlbar, then dpi in the search box to find the pref.
@55 (Andrej T) – Decimals in font size rules are ignored by IE. 62.5% is treated by it as 62.00%.
@62 (Kendall C) – If you’re in the design business, you’ll probably find yourself back on ALA often. Make yourself a user stylesheet that applies exclusively to it via Gecko’s @-moz-document facility and you won’t know about its tiny text until it gets a CSS overhaul that breaks your overrides.
@68 (Mason B) – If you’re using a decent modern display better than the median, you have enough PPI that small differences in font sizes should produce no apparent qualitative differences. I don’t ever find smaller than my default fonts easier to read, regardless how many px it took to render them, or how good they "look". Indeed, if you render a font at "font-size: 80%" that was 18px in height, what you actually get is a font 64% in size. CSS "size" is only nominal, not real. Real size is a function of both height and width. A 16px character contains around 128 discrete px, measuring around 8px wide by 16px tall. A character box exactly 80% of 18px high would be 6.4px wide by 12.8px tall, providing about 82 discrete px.
Be part of the solution to the problem rather than part of the problem. Accept that 100% of the default size is best. Personal computers are intended to be personalized. Assuming they have been is the right thing to do, no matter how few have actually had it done. Just because web designers all think browser makers are morons is no justification for assuming smaller is better for anyone other than yourself. If the defaults are too big for you, personalize your own PC, not mine.
Jay’s comment perfectly sums up my feelings on this whole ridiculous practice.
http://www.alistapart.com/comments/howtosizetextincss?page=7#63
Where can i get the page zoom tool?
I still have doubts regarding the best solution of what type of font to use. Still testing different variations.
Keep up the good work.
I´ve got much problems with the text size in Ie and Firefox, too.
But this discussion and it´s including links helps me a lot.
Thanks everybody
@61 included: “That means that there are some occasions where the pixel size of text is important to the layout — eg, because it has to fit with images that are necessarily sized in pixels.”
However, there is an easy method to size images in ems – see http://www.wats.ca/show.php?contentid=33 for example.
You’re right that keeping track of the math percentages with ems can be tricky. Luckily, with a good handful of browsers for testing, and a logically laid out stylesheet, it gets much easier.
Being that I don’t have the grasp of CSS that the author surely does, i’m sure my comments might not be appreciated….. I am of the opinion that it is best to set the pixel size absolutely as most sites (should) have a significant amount of content. As a designer, I prefer knowing exactly where every letter is going to appear in relation to every graphic. It helps me to visualize where images should or shouldn’t go and more. Of course, I am a bit old school in my methodology, but it is still my preference 🙂
I liked the effort that was put into this article. That was a whole lot of screen captures and thought.
*Thank you!*
I came to this site as a whole, looking for the answer to a question:
How can I/we create documents, that might be one or more pages and be shown one any platform (I use Ubuntu) or browser, print correctly onto pages (at the right DPI for images for example, over 72dpi), scale to work for those with vision needs/screen resolution/device…
and
not have to rewrite/change/tweak/etc the content?
And be hyper linked together so one document can be related to another.
I have found that using table-less valid strict XHTML code and CSS for style while basing most (if not all) things on _em_ makes the cross platform – cross browser challenge fairly do-able.
_I was inspired towards this back in the CSSzenGARDEN days._
_Thanks to all you designers that made that site rock!_
But then there is printing and portable devices and better accessibility.
One only lives so long. How many times do we really want to recreate the same document/content for a new device, browser, printer, email or software just because a decade has passed
-or MS has some new notion of how to keep people locked into THEIR closed source-
?
As artists, do you not want to create new art instead dredging through old documents and recreating old documents to work with current technology?
A paper page is the size a paper page which is fixed and yet not as and now we have many countries and thus pages sizes.
What is the best approach for the long run?
There is much ado about creating web page/site that work for what ever is current and happening in the now like a fluid 3 column lay-out but
I am asking/questioning/yearning about content.
*NOTE:*
Even the content I write at this moment is UNUSABLE again with out tweaking because it is coded to Textile which seems to only be some what working and is not XHTML…
Seems like the CSSzenGARDEN site slowed way down for a while and they look like they are going strong. : )
The A List apart is an A list site for sure. Thanks again…
Table cells with multiple lines break the rhythm of the complex example. I checked it using the “background image”:/d/settingtypeontheweb/images/gridbg.gif
There’s also a easy trick for this one:
An em is 16px.
10px equals 62.5% of 16px, or an em.
So if you put the font-size for the body element to 62.5%, it’s easy to calculate the other ones.
E.g. if you want 12px font-size, you just put in 1.2em. Because 1.2 * 10 = 12.
Regards,
Pieter
Generally, I love ALA’s typesetting, and this article was good. However, when I went to the complex example, I noted something that from the standpoint of readability is just plain wrong: The same amount of vertical space before and after heads, esp. subheads. As a reader, you need visual cues to connect a [sub]head to the text it is heading; therefore, there should be visibly more space ABOVE the head than below it. Not to pick specifically on this writer–I see this all over the web.
A very informative article, however…
When it comes to CSS, positioning containers is the real pain. Choosing some lovely font sizes and colours is a nice gentle way to finish off an otherwise stressfull afternoon of building a CSS website.
There are two properties that allow you to automatically set the capitalisation of your text. First, font-variant allows you to set all your characters in small versions of capital letters.
p {font-variant: small-caps; }
That would create text like this. It looks cool, and works well for acronyms, like NATO. The second property is text-transform.
div {text-transform: uppercase; }
Can someone please explain why, in the “complex example”, the multiplier is usually 16, 14, or 12, and in one instance it is 18?
e.g.,
font-size: 1.125em; /* 16×1.125=18px */
margin: 1.286em 0; /* 14×1.286=18px */
border-bottom:0.083em solid #ccc; /* 12×0.083=1px */
margin:1em 0; /* 18×1=18px */
??
Thank you
I’ve used the principles in this article as my best-practices for years. However, my company just stopped supporting IE6 last year and we are now revisiting our best practices for sizing text. Since most browsers now use page zooming, we’ve considered switching to pixels to size our text, but our new concern is mobile browsers. How well do mobile browsers handle different units? Which unit is best to use with mobile browsers in mind? I’ve heard many say that Ems are still the best practice for mobile devices, but I’ve noticed that iPhone 4 doesn’t seem to size the complex example http://www.alistapart.com/d/howtosizetextincss/complexexample.html from this article correctly. Is it better to use pixels for mobile?
Most of the wordpress themes that I have encountered do have a widget or plugin to allow visitors to change the text size, as it is sometimes too small from default, and messing with the CSS can be a pain at times.
Thank you for the article and your effort.
I just thought I would offer comments now that it is almost 4 years old, and surely out of date. It seems like this article advocates acrobatics of web design with ems, percentages etc, when, to me, if you can’t read something you magnify it with glasses or the equivalent, zoom, on your browser. Magnifying the text and images (line height etc) keeps their context and their visual relationship constant – a good thing. advocating the ability to resize the text while keeping other things like images constant is a misguided idea because when increasing text size eventually the relationship of text to images gets uglier and nonsensical. If there is a need to magnify text, wouldn’t it also help a visually impaired type to magnify the images, too – bring them into focus?
In addition, I agree with the unpopular Brad Kemper – good typographic practice is to add less than a line between paragraphs – I prefer 1/2 a line. I am not a coder giving my typographic opinion, but someone who has lived and breathed typography for many years and has been recognized for skill in typography. I am not too familiar with the author’s concept of vertical rhythm, but vertical rhythm should not be slavishly adhering to a baseline grid – that would be a monotonous rhythm – not to interesting and rather mechanical.
I’m with Josiah in that I too, am curious which unit is best to use with mobile browsers in mind?
http://www.alistapart.com/comments/howtosizetextincss/P80/#90
It would be nice to get an update to this article with mobile devices in mind. I’d be curious if EMs are still the best solution, or if something like REMs with an appropriate fallback or pixels is preferred now. Pixels seemed to have gain a lot of popularity for sizing fonts.
I know in jQuery Mobile they use pixels for font sizes and also in the HTML5 Mobile Boilerplate:
body { margin: 0; font-size: 13px; line-height: 1.231; }
Yet knowing a pixel is no longer a pixel on some new devices like the iPhone4, it makes me think pixels aren’t the correct solution to sizing fonts on these newer mobile devices where the pixel ratio isn’t 1:1. I havn’t done any testing on font-sizing on mobiles yet but I would think EMs or REMs with an appropriate fallback will be the best solution for mobile?
Just picked up an old book of mine called Bulletproof Web Design. It suggests setting the body font size as a Keyword…. small… and percentages to stray form the base. eg h1, 150%
This seems rather a good idea than having all that crazy em mathematics. What do you guys think?
If this is ever updated please include more sample calculations. Font size ems seems to be easy to figure out, but the line heights – especially when the font is larger than 18 pixels is giving me a headache LOL. Similar to @lauras2009 question above.
It’s also not clear to me why this was updated away from the 62.5% rule, when that kicked out such lovely round numbers and made the maths so much easier.
Richard thank you for presenting this info so clearly. This is another element in a developer’s bag of tricks to help create responsive web design.