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.
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.