Update: My more recent article on A List Apart, How to Size Text in CSS, provides more info on sizing text using ems.
Text for the screen is sized with CSS in terms of pixels, ems or keywords. As most of us know, sizing with pixels is easy: get your selector and give it a font-size – no more thought required. Sizing with keywords is more complicated and requires a few workarounds, but you’re in luck as the techniques are well documented. That leaves ems. At this point people often leg it. ‘Ems are too inconsistent,’ they say, ‘they’re too hard; they never work.’ Well that may be the received wisdom, but if ever the was a case of FUD then this is it. I will now attempt to show you how ems can be as quick and easy to use as pixels.
If the world were an ideal place, we’d all use pixels. But it’s not, we have the broken browser to contend with. IE/Win will not allow readers to resize text that has been sized in pixels. Like it or not, your readers will want to resize text at some point. Perhaps they are short-sighted, doing a presentation, using a ridiculously high resolution laptop or simply have tired eyes. So unless you know (not think) your audience won’t be using IE/Win or will never wish to resize their text then pixels are not yet a viable solution.
Keyword-based text sizing will allow all browsers to resize text so this is a possibility, but I don’t find it gives me the precision that pixels would give me. Using ems however, allows all browsers to resize text and also provides pixel-level precision and so they tend to be my unit of choice.
OK let’s dive into ems. I’ll show you, from scratch, how to size text in a document using ems. I’ll assume throughout that we are dealing with a browser set to ‘medium’ text. The default size for ‘medium’ text in all modern browsers is 16px. Our first step is to reduce this size for the entire document by setting body size to 62.5%:
BODY {font-size:62.5%}This takes 16px down to 10px which I’m using purely because it’s a nice round number for example purposes – 10px text is too small for the real world. From now on it’s easy to think in pixels but still set sizes in terms of ems: 1em is 10px, 0.8em is 8px, 1.6em is 16px, etc. If you are laying out your document using CSS (which you are, right?) then you have probably used a few divs to group together elements. Apply text-size to these divs and your job is almost done. Consider a two column layout with header and footer:
<body>
<div id="navigation"> ... </div>
<div id="main_content"> ... </div>
<div id="side_bar"> ... </div>
<div id="footer"> ... </div>
</body>
#navigation {font-size:1em}
#main_content {font-size:1.2em}
#side_bar {font-size:1em}
#footer {font-size:0.9em}So this would give us a document where text in the navigation and side bar is displayed at 10px, the main content is 12px and the footer is 9px. There now remains a few anomalies to sort out (you’d have to do this even if you were sizing in pixels). In Mozilla-based browsers, all heading elements in our aforementioned #main_content div will be displayed at 12px whether they are an H1 or an H6, whereas other browsers show the headings at different sizes as expected. Applying text-sizes to all headings will give consistency across browsers, for example:
H1 {font-size:2em} /* displayed at 24px */
H2 {font-size:1.5em} /* displayed at 18px */
H3 {font-size:1.25em} /* displayed at 15px */
H4 {font-size:1em} /* displayed at 12px */A similar job needs to be done on forms and tables to force form controls and table cells to inherit the correct size (mainly to cater for IE/Win):
INPUT, SELECT, TH, TD {font-size:1em}And so to the final tweak and the bit folks seem to find most tricky: dealing with nested elements. We’ve already touched upon it with our headers, but for now let’s look more closely at what’s going on. First of all we changed our body text to 10px; 62.5% of its default size:
16 x 0.625 = 10Then we said our main content should be displayed at 12px. If we did nothing, the #main_content div would be displayed at 10px because it would inherit its size from the body element – its parent. This implies that we always size text relative to the parent element when using ems:
child pixels / parent pixels = child ems
12 / 10 = 1.2Next we wanted our h1 heading to be 24px. The parent to our h1 is the main_content div which we know to be 12px in size. To get our headings to be 24px we need to double that so our ems are:
24 / 12 = 2And so it goes on. Tricky stuff occurs where rules like this are applied:
#main_content LI {font-size:0.8333em}This rule implies that all main content list items should be displayed at 10px. We use the same straight forward maths to achieve this:
10 / 12 = 0.8333But what happens when one list contains another? It gets smaller. Why? Because our rule actually says that any list item in the #main_content div should 0.8333 times the size of its parent. So we need another rule to prevent this ‘inherited shrinkage’:
LI LI {font-size:1em}This says that any list item inside another list item should be the same size as its parent (the other list item). I normally use a whole set of child selectors to prevent confusion during development:
LI LI, LI P, TD P, BLOCKQUOTE P {font-size:1em}And that’s it. When sizing text in ems there’s really one rule to remember: size text relative to its parent and use this simple calculation to do so:
child pixels / parent pixels = child emsPixy’s list computed styles is fabulous bookmarklet which shows the cascade of calculated font sizes (or any other CSS property). Mozilla’s DOM Inspector is even more powerful as it allows you to see which CSS rules are affecting any given element in order of cascade priority so you can see why your text is or isn’t changing size when you expected it to.
If you’re finding the maths all a bit complex, try using Riddle’s handy em calculator.
Classically, an em (pronounced emm) is a typographer’s unit of horizontal spacing and is a sliding (relative) measure. One em is a distance equal to the text size. In 10 pixel type, an em is 10 pixels; in 18 pixel type it is 18 pixels. Thus 1em of padding is proportionately the same in any text size.
Make sure you read Patrick H Lauke’s comment on perfecting this method for IE5/Win.
Pete F. wrote:
I like to start the page with a default font size definition in points, then use “em’s” of that point size for specific items. Works well across all browsers, including IE/Win, IE/Mac, Firefox, Opera and Safari.
Marko Samastur wrote:
Just a small comment from a math nut. 75% of 16 is 12, not 10.
So, if you want to go from 16px to 10px, you need to set font-size to 62.5% (unless browsers have their own math and 75% actually works).
Rich wrote:
Marko – thanks for that. Schoolboy error duly corrected.
James Craig wrote:
Fantastic article, and a perfect description of how to use ems. I disagree with one small part of the method though: the arbitrary body size. I’d recommend leaving the body size at 100% and scaling the rest down in ems accordingly. Of course, the downside is that the default is no longer the easily-divided 10 pixels. The upside is that it works well with user style sheets.
Imagine I was a more-technical-than-average user (more people will figure out user CSS eventually) that had a preference for larger fonts. Perhaps I had vision impairment, perhaps I had some standard hyperopia gaining with age, or perhaps I just liked reading large text better. Not too large, mind you. Just about 120% of normal. Seems easy enough in my user CSS, right?
body {font-size:120% !important;}
That is, as long as everyone uses the standard default size for the body element. Trying this one your example yields massive text. I’ve also seen other arbitrary examples like 76 percent or 80-something percent. The more variations there are, the worse it becomes.
So that’s my two cents. Do you agree? Again, lovely article… (We just differ on one small detail.)
Gordon wrote:
Wonderful article, and you are right FUD was stopping. No more!
Thanks for taking the time to capture this info, it’s people like you that help people like me look good (well.. better at least..)
Mike P. wrote:
James, I believe that 76% came from Owen Briggs work:
http://www.thenoodleincident.com/tutorials/box_lesson/font/
Shawn Medero wrote:
My own testing tells me 76% is as small as you can go before things text becomes unreadable in some browsers.
ie wrote:
An excellent article. I think I finally understand how to make ems work.
Nonetheless, the em approach seems to me to be fairly unwieldy. I differ with you that “sizing with keywords is more complicated.” The ALA article you’re alluding to was the first of its kind. Things have moved on since.
The technique has stood me in good stead many a time.
body, div, table, h1, ... h6 {
font-size: x-small; fot-size: small; /* ALA uses Celik’s hack, I prefer Tan’s hack */
}
This gives you a “base” font size 13px in all major browsers if and when set to “medium” text size. Now you can alter text size using either ems or percentages without a usual ripple effect or tedious calculations.
When you size text, let’s say, from smallest to largest in IE, it’s always legible. See www.stopdesign.com
With ems you may get horrific text size. See www.micr.cz
patrick h. lauke wrote:
two issues that are worth mentioning as well:
– IE gets its text resizing horribly wrong when just using ems. if your text size is set to normal, it’s fine, and ems relate directly to what the equivalent percentage would be…so having 0.75em on the body would have the same effect as 75%. now, bump the text size up or down, and you’ll notice that IE scales ems far more drastically than percentages, resulting in too big / too small text. the deceptively simple solution: in addition to having something likebody { font-size: 0.75em; }
you need to add an extra rule (i usually do it on the html) in percentages, which helps IE get its bearing back in terms of resizing…so
html { font-size: 100%; /* IE hack */ }
body { font-size: 0.75em; }
now resizing works consistently.
– although, as per the cascade, setting the font-size on the body should really influence all text sizing in the document, IE seems to ignore it when it encounters a table. the naive approach would be to set the font size for both body and tables like sobody, table { font-size: 0.75em; }
this works in IE, but any other same browser will honour the cascade, resulting in table text actually being sized to 0.75 of 0.75 = 0.5625em. the solution, similar to the previous one, is to add a percentage size to the table
body { font-size: 0.75em; }
table { font-size: 100%; /* IE hack */ }
i seem to remember that this same issue happens with selects and inputs as well, and can be solved in exactly the same way, by adding a 100% sizing to them in the CSS.
i like to call these the “be patronisingly over-specific, so IE knows what you mean” rules…and the beauty is that these don’t break in other browsers, and – apart from being “obvious” – don’t really fall under the category of hacks per se, as they don’t rely on bugs in any browser’s css parsing like, say, the box model hack does…
Alex Giron wrote:
Great article… I will defenitly give this a go.
Thanks.
Ralf Göke wrote:
Hi there!
Yep, great article. Thanx for that. But theres one thing missing: For some reason Safaris default font size is only 14px. So using your recommended percentual values lead to a nearly illegable font size on Safari. Luckily, Safari provides buttons to increase font size by default. I think most Safari users are able to use it. :o)
take care, Ralf
Harry wrote:
Re: Satisfying Safari and IE
I’ve found this to be a good way to initialize an opening font size, for the sake of Safari and IE:
body {
font-size: 100%; // For IE
}
html>body {
font-size: 16px; // IE can’t read this
}
Now use ems as normal. IE gets what it wants, Safari moves to 16px, as do all other modern browsers, and ems in the rest of your elements will scale relative to 16 pixels.
Andy Hume wrote:
I am a strong supporter of sizing with keywords. Unfortunately this method is not often used because of the age old issue of designers wanting control.
My feeling is that we should remind ourselves that we are destined to fail when trying to force ‘the precision that pixels would give…’
OK… fewer and fewer people are sizing text in pixels; but we should go further – as the use of ems and percentages is still not as reliable or simple as keywords:
1. Keyword values do not compound when elements nest. ie, <body> is set to small, then <p>will be small and a <div> in that <p> will be small. A lot simpler than the math needed to calculate your em values.
2. In Gecko and modern IE browsers font size set with keywords will never be reduced to less than 9px, and therefore will never be illegible.
3.Many Mac users have reset their default font-sizes back to 12px/72ppi, resulting once again in tiny font-sizes bearing on the illegible. This problem is fixed by using keywords.
By using ems you are assuming certain things about your users, and not taking into account their preferences. Let the user decide what their default font-size should be – don’t reduce it by 62.5% because of your own ideals.
Thanks for listening. Andy.
mateo hamburg wrote:
hi there,
i just came across your site from www.pixelgraphix.de who announced an article about advanced css-knowledge. i was then truly surprized when i reached here – because i can hardly read anything. view an original-size screenshot of what i saw here: www.mateohamburg.com/screen_clagnut.png
this is not what could encourage me to read on – if i then could read at all…
i am using nothing too spooky – it’s a firefox 0.8 which is told to be a state-of-the-art-thing. it’s running on a pentiumII-win98-machine – yes, that’s old, but not a c 64!
thanks for listening,
mateo
patrick h. lauke wrote:
looks at mateo’s screenshot and mutters “somebody hasn’t got font anti-aliasing enabled on their machine”...
Rich wrote:
We’ll have to agree to disagree on this one. If, by using anything other than keywords, we are destined to failure, why did the W3C spend all that time and effort consulting with typographers to develop the current options for font sizing? Keywords are a valuable solution but are not the be-all-and-end-all. I still maintain that if IE/Win could resize text we wouldn’t be having this argument: screen text would be sized in pixels and print text sized in points.
It is worth stressing that the 62.5% I set for body size is not a recommended default text size as the resulting 10px is far too small for body copy. However it does make the numbers easy as a starting point for those used to working in pixels and converting to ems. They were really the intended audience of this article.
Rich wrote:
Mateo,
The problem you’re having here is bad, old copy of Lucida (or Lucida Bright). This is a really badly hinted version and that is what is causing the illegibility. On the right hand column there is a style switcher enabling you to use Georgia instead. Click the ‘Microsoft’ button and your display will magically heal. Otherwise you could just click this link:
/switcher.php?set=type_ms
Andy Smith wrote:
To get more consistent sizing you can give a percentage size for the body to IE, and a pixel size to other browsers. You could use a conditional comment or a hack to do this, for instance:
This way the text is resizable in all browsers, and the only people who will get a different default font size to what you intended are IE users who have changed the font size in their preferences.
I think Netscape 4 may have a problem with percentage sizes so it’s probably best to give a pixel size to that as well.
Andy Hume wrote:
Rich,
The W3C create specifcations/standards for the web. Unfortunately we know that standards are oft ingnored by browser makers, designers, and users – for example…
Em’s would be fantastic if :
-Netscape 4 didn’t ignore them when applied to text; and other old browsers didn’t nest incorrectly.
-Users did not reduce their default font sizes to lower than 16px.
Keywords are based in the user’s default font size; so are ems: but the size of xx-small will never be smaller than 9px thereby reducing so many of the problems that users experience with ems, ie. too small text.
I do not deny, of course, that pixels are the utopian solution… if it was not for IE/WIN.
Andy.
Travis D wrote:
Your code examples in this post do not display in my browser, IE 5.1 for the Mac, running System 9.2.1.
All I see are intros ending with a colon, then two lines of blank space.
Rich wrote:
It looks like IE/Mac has problem with
overflow:auto. I’ve disabled that for the moment until I find a suitable solution so IE/Mac users should be able see the code examples now.Philippe wrote:
IE mac destroys all height declarations on elements with
overflow:auto(except div). I’ve that documented here. You should visit sometimes :-). (Solution is to float the block).But a nice overview on ems, although I wouldn’t go for such small size on the body tag. I can’t read it. Just to add one thing, my preferred method:
body {font-size:100%}html>body {font-size:1em}
The first line is for IE Win and its inability to scale fonts correctly if originally specified in ems, second one for all others (and this avoids some problems in Opera 6 and older Safari).
Rich wrote:
Laurent Denis has very kindly translated this post into French.
Nick Cowie wrote:
Excellent article, the point most commentators are missing is that use ems not only for text size but also to size the divs containing the text. So you do not get long lines of difficult to read text. Convential wisdom of the last 120 years has 40 to 60 characters per line as the optimal/prefered reading length. That is very easy to do using ems for text size and container size. Not something easily done with keywords.
Personally I use font-size:76% in my body tag, to set base font to 12px for most modern browsers (including Safari 1.2). Netscape 4 is a problem because lack of inheritance from the body tag (but at less than 1% of users it is not something I worry to much about).
I use a little javascript to increase my base font size to 13px for browsers in the 801 to 1050 pixel width and 16px for greater than 1050 pixels. That combined with a 60em container div holding my content, gives 720px wide container at 800 by 600, 780px on 1024 by 768px and 960px at 1600 by 1200px.
Mark wrote:
Pixel sizing is illogical: it relies on current display technology.
Suppose a new type of display is launched next week which has half the dot pitch, allowing users to comfortably run 2048×1536 on a 15” display.
My em-based site (http://tranchant.plus.com/) will be fine – the user will set their default font size to something readable, and my site (except images) will appear the same as before, but taking advantage of the higher resolution display quality.
“Your” px-based site will be totally illegible unless the browser supports resizing – in which case it’s no longer using your suggested pixel sizes. So why use them in the first place?!
Also, setting body font sizes below 1em/100% is just plain rude. I’m here to read the site, not marvel at how the tiny font size looks techie and ‘leet.
Rich wrote:
I couldn’t quite work out if you read the article or not. I state quite clearly why sizing in ems is a good idea and go on to explain how to do it – that’s the whole premise of my post! Maybe you’re just agreeing with me by disagreeing with pixel-sized text, but on that count you are slightly off the mark.
This seems a logical argument but is not actually true as CSS has dealt with this potential issue from start. In CSS terms, a pixel is not actually a physical pixel but an area of screen space roughly equivalent to a pixel on a ‘normal’ CRT screen. The CSS 1 Spec says:
“Pixel units [...] are relative to the resolution of the canvas, i.e. most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the UA should rescale pixel values. The suggested reference pixel is the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is about 0.0227 degrees.”
Setting body sizes to below 1em/100% is certainly not rude, because it is far from the whole story. In my article I set the body size to 62.5% to make the maths easier by way of example. Every single text element is then sized UP from 62.5% to something more readable. If you want to read text at an equivalent of 16px that’s your lookout – you have the technology at your disposal – and sizing in ems, as this post both extolls and explains, provides the means to do so across all browsers.
Mark wrote:
Yeah, I read the article, and yes, I do agree with the motives behind it. The “Your” site (notice the quotes) is aimed at the still-sceptical reader.
I don’t agree with the “If the world were an ideal place, wed all use pixels.” quote though.
If the CSS reference pixel isn’t really a pixel at all, that makes it even less logical to use. CSS’s workaround to deal with people using it improperly has destroyed any chance of it being used properly. I could imagine situations where true px-sizing could be useful to fit in with an image, but if the UA is required to scale real pixels to match the reference pixel, the measurement becomes totally pointless.
Wrt to my “body” comment, I was referring to the body text rather than the body element. By sizing to 62.5% 1.2em, you are sizing your content text at 75% of my browser default.
So what should I set my browser default to? Something that makes your 75% content readable, making all unstyled or correctly-sized sites too big; or correctly, making yours a struggle to read. Sure, I can resize any site easily, as I’m using Firefox, but what’s your rationale for using a font size 75% of what I want?
Rich wrote:
The rationale is simple. Most (not all, I know) people run their browsers with text size set at the default. The default text size is bigger than I want my text to be displayed at so I drop the size down from the default to the size I want. My desired text size happens to be roughly the size that almost every other website uses, so for the vast (and I mean vast) majority of users will get a text size they are used to.
Additionally, I simply can’t reconcile leaving body text at 100% with commercial web design. Unless clients are targetting a very specific audience (the elderly perhaps), clients will always want text sized smaller, perhaps to be the same as everyone else, perhaps for aesthetic reasons, perhaps to fit in with their corporate identity.
I appreciate the sound reasoning behind leaving body text at 100%, but clients’ desire to make text smaller won’t go away and to be honest that doesn’t bother me as I can’t think of a single attractive and well designed website that uses 100% body text size.
Mark wrote:
Rich wrote: I cant think of a single attractive and well designed website that uses 100% body text size.
Perhaps you should reduce your default font size then… ;-)
csalib wrote:
This is a fantastic resource! Thanks for breaking it down for us. I would like to also refer the interested to another site which I found complements this site perfectly. http://www.thenoodleincident.com/tutorials/typography/incremental_differences.html
Keep up the good work!
Thanks,
Christine
Kim Siever wrote:
“we have the broken browser to contend with. IE/Win will not allow readers to resize text that has been sized in pixels.”
IE/Win is not broken. It does exactly what the designer has told itrenders fonts based on pixel measurements. Technically speaking, the other browsers are broken.
That being said, the choice of pixel-based fonts is a poor one. And we all know there are poor designers out there. Don’t blame bad design practises on a browser that is doing exactly what the designer told it to.
Rich wrote:
If the other browsers are broken it is only from the designer’s perspective, not from the user’s perspective.
If, as a user of both the Web site and the browser, I ask for the text to be ‘extra large’ and the browser does nothing then the browser is broken – it’s not behaving as I expect or require.
Mauricio Hernandez wrote:
Very clear explanations!
Thank very much for such contribution to my so-far small knowledge.
I hope once I get more experienced I could also contribute.
RockOfVictory wrote:
Being a CSS newby, I’m trying to do this right the first time with ems and a fluid layout. Would any of you mind taking a look at my petty problems (related to this post) on sitepoint:
http://www.sitepoint.com/forums/showthread.php?p=1333597
msg wrote:
Great.
I’m just moving from px to ems and reading your article is the most worthwhile 5 minutes I have spent in weeks!
7colors wrote:
This article has helped me understand better relative text size but what I did on my site is to use 80% in the body and then just use percentage for all the other text sizes. It seems to work all right, is there any reason why it shouldn`t be done like that?
Chris wrote:
I had a problem when using this as it seems that IE can’t deal with fractions of percentages so it approximates 62.5% to 63% – not a big deal in some ways but it would be nice to know all browsers are hauled into line and the body font size is exactly 10px in all browsers.
So I tried the following, which also sets html>body to 10px to take care of the Safari issue as someone suggested before. (I’ve only tried this on XP so would like to know if it works on a mac).
html {
font-size: 1.25em; /* 1.25×16px = 20px */}
body {
font-size: 50%; /* adjusts base font to 10px */}
html>body {
font-size: 10px; /* overrides the above in all browsers except IE */}
Christophe wrote:
great intro for an “em” newbie such as myself – thanks
john kerr wrote:
could u tell me is there a code /script to let me give button/link options on all site pages to give 3 or 4 text size choices to the user
i’d find this really useful
john
Rich wrote:
Try these for size (geddit?):
Jehiah wrote:
I found it usefull to set all items to 1em using
body * {font-size:1em;}
instead of just
INPUT, SELECT, TH, TD {font-size:1em}
as your recommended. (but you got me headed in the right way, so thanks!)
Dave Benningfield wrote:
Can you help me with a patch or fix for Microsoft Internet Browser. My screen loads up a gigantic screen size with huge fonts that even overlap. Each web site I visit requires lots of scrolling just to view one page. How can an inexperienced computer person solve this problem? I’m using windows XP home edition 2005 and Internet explorer version 6. Help?
geoff wrote:
I’m new to CSS but eager to begin using em for font sizing. However, I’m trying to modify an existing stylesheet that contains this: h2 {font-size: 1.1xcem; text-transform: capitalize;} and I’m confused about that “xcem”. can anyone shed some light on what the “xc” is all about?
Thanks a lot!
Rich wrote:
I can understand your confusion – there is no such unit as ‘xcem’. When in doubt, run your style sheet through the free W3 CSS Validator. In will valid individual snippets of style or a whole style sheet in one go.
terra Admin wrote:
Hello authors of this lesson!
I want to thank you for such useful and needed for me article. I should comment that some your visitors know a little bit more in ems . But anyway i like that I found you.
Regards
ros wrote:
I have no spacing in my blog item. How do I solve that?
pj wrote:
Why do you set the text at this when we’ve been taught to start out a stylesheet with the body font size at 100.01% ??
BODY {font-size:62.5%}
And how do you make your form text field expand as you type in it. That’s very cool. Have never seen that before.
Pamela
PJKinann
Rich wrote:
pj – why were you taught to start out a stylesheet with the body font size at 100.01%? I don’t understand what that would acheive – it looks like an obscure workaround for a browser bug I’m not aware of.
And the expanding text box is a bug in IE/Win, not a feature!
Jan Claire wrote:
How does one present several sizes of type in one sentence. Each time an <Hx> or <p> tag is used, it starts a new line. Is the answer to use EMs?
Branko wrote:
Great article! It’s great to see someone actually trying to make life easier for others and taking the time to try and explain some of the issues involved in developing good looking and consistent websites. A great platform for newbies. Keep up the good work. It’s great for newbies to see into the minds of some of today’s web designers/developers.
Rich wrote:
Thanks Branko! That’s why I write stuff like this – it’s always good to feed back into the community.
John W. wrote:
I can’t get IE 4 to recognize the base font size set in the body. It doesn’t seem to like percentages or ems, only pixels. My client has to consider a third-world audience and needs IE 4 to work. Suggestions?
Robert Douglas wrote:
em sizes fail in any widescreen display. This almost makes them completely useless for ANY part of a website. They are displayed so large that you have trouble viewing the page.
Anyone know of a hack that fixes this?
Rich wrote:
John W – if you need resizable text to work in IE4 I suggest using points (eg 12pt) like we all used to back in the day. It’s wrong, but it works.
Robert Douglas – I’m not quite sure how you’ve implemented ems, but they work fine on any display in my experience. There’s not reason for them not too. And if the text does appear too big for some reason, just drop the text size down in your browser.
OpeRon wrote:
MAN, was it that simple?
i spent about 10 Hours trying to find an answer and it was THAT SIMPLE
Thanks a LOT
Brandon wrote:
your take on ems to pixels conversion doesn’t seem accurate. For example, 1.1 ems is MUCH larger in a browser than 11 pixels is (for Verdana anyway). So something doesn’t seem quite right with your conversion stats.
Rich wrote:
Brandon – did you set the
font-sizeof the body to be 62.5% first? That is what is required to make the conversion work. Here it is again in full:body {font-size:62.5%} /* for IE/Win */html>body {font-size:10px} /* for everything else */
Now 10px equates to 1em (with browser text size set to default medium)
Mark Tranchant wrote:
Why?! Why should an ideal world have pixel-based displays? Pixels are tied to a technology. I know there’s a “W3 pixel” which is not necessarily the same as a device pixel, but surely the ideal way to display text is in relative sizes to the user’s preferred size.
This is where em and % win: the user can set a preferred body text size, and the author can size headings up and “small print” down accordingly. Graphic elements can also be relatively-sized. In fact, my entire site, with the obvious exception of images, is em-sized.
Rich wrote:
Because (as you noted yourself) there is a difference between devices that have actual pixels, and pixels as a unit of measurement. But primarily because it is easier to use pixels. There I said it – there’s no inheritance, and the like, to worry about.
But that’s not specific to text sized in ems and %. In good browsers text scales up and down from user preferences for text sized in pixels too. If IE/Win did this as well there would be no problem sizing text in pixels.
That said, I will add a caveat about the future unknown. Browsers (or operating systems) will need to obey the concept of the W3 pixel in order for webpages to display as expected on high resolution screens (300 dpi are not too far away now). This applies to anything sized in pixels, not just text.
Mine too.
Jim wrote:
Good stuff. I always find that it’s fun to spend weeks scratching your head about stuff like this and then find an article that explains everything you need in five minutes flat!
By the way, for Mac types out there, Xyle Scope is a bloomin’ ace alternative to the Mozilla DOM Inspector. I find it has a better interface. http://www.culturedcode.com/xyle/
Krystof wrote:
I am designing a free beginner CSS layout at http://www.kwiknfree.com/web-design/templates/absolute.shtml
You’ve convinced me to use EM for spaces-and I never believed in PX for fonts-but:
When I tried font-size:1em, my IE6 browser “text size” will toggle from very tiny to very huge.
.
......Not acceptable for accessibility! I have not tested your in-depth suggestions, so probably I’m missing something. But I am also skeptical of the permanence and stability of changing the base away from 100%. So for now, I’m sticking with font-size: “medium,” “small,” “x-small” etc.
Krystof wrote:
Just like to say: please ignore my above comment. Obviously I came to this site hardly able to understand. Now after 2 weeks of Googling and forum discussion I find this page especially easy to understand. The main article PLUS the replies PLUS Rich’s replies to the replies together comprise an outstanding overview of the pros & cons of all sizing methods-not just EM. Many little questions answered. Read it all. Don’t miss out.
(For rank beginners I still would suggest keyword sizing, with a standardized 4.01 doctype and ‘preferably’ but not essentially a Tan or Celik hack. However when this becomes limiting, EM looks ideal for flexible layouts because EM-sized spaces can closely match the EM-sized text. Just be clear that Rich does not especially ‘recommend’ the 62.5% body figure, and there are those who say 100% is a bit safer.)
theUg wrote:
First of all, I want to join the choir of praises for that article amongst others on the subject of relative font sizing and, crucially, on relative elements size spepecification, is very helpful and makes everything easier.
Important note on the 62.5% declaration however. Although it would be so nice to work with the base of 10px but, unfortunatelly, nothing is ideal, for this world is broke.
This number would not work depending on the minimum font size specified by user.
In Firefox by default the minimum size is not specified. In Opera, there is a curious picture—in my WinXP installation the minimum is set at 6 px, but in my Linux version, the minimum is at 11px. I’m pretty sure those are defaults for I never tweaked it (as a matter of fact, I learned about this feature couple days ago :)).
I don’t know if those are defaults in th v8.5 because I put it on top of the old instances of v7.54 and Opera rarely (if ever) overrides user settings.
Whichever the case, the point is that if user sets the minimum font size to anything over 10 pixels, the whole math crumbles and you can forget about pixel precision. I think it is very important and this article should be updated or at least this matter suold be discussed and mentioned.
P. S. By the way, minimum font size option in Firefox doesn’t seem to work very well. I tested espn.com in both Opera v8.5 and Firefox 1.0.7 on both WinXP and Linux. While Opera changes the fonts on the page according to minimum settings, Firefox wouldn’t change a thing.
I might be doing something wrong here, but If not so, then in your face, mozillovers! :)
Flo wrote:
Wow -this is a really cool solution :)
Thanks a lot for this article and all your comments..
IE users will be very pleased ;)
earl lee wrote:
great job… what can i say… “stupendous”
Ed Timm wrote:
This text is so small and so light,I cannot read it.
Help
Tom wrote:
Nice article.
Thanks.
Felix Miata wrote:
When users who have instituted a basic defense against Owen Briggs style “body {font-size: 76%;}” visitor disrespect by adopting a user stylesheet with one simple rule, such as “body, p {font-size: medium !important; line-height: normal !important; font-family: zxqxwzx !important;}”, instead of too small text, visits to pages using the Clagnut visitor disrespect technique get too big text.
My default size is quite as I like it, and needs no author adjustment.
Rich wrote:
Hi Felix. Firstly 16px may be your preferred default text size but it is certainly not everyone’s. You can always resize the text in your browser using ctrl+ or ctrl-. If you really need text at a certain size, one quick keystroke when required is hardly onerous.
Secondly I don’t necessarily recommend authors set their text size to 62.5% in this article, I merely use it to get round numbers to simply the examples.
Thirdly if you want overwrite the author styles described in this article you should use create a user style sheet with this rule:
BODY {font-size 16px !important}Designers do their best to give their readers a design which they think works best. Because not all users start from the same point, it is not always possible to deliver the same reslt to everyone. However that is the point as the ultimate control is always in the hands of the user – if the user knows enough to change their settings from the default, designers can do little more than assume users know how to do that properly.
Felix Miata wrote:
Zoom is a defense mechanism browser makers provide so users aren’t forced to squint to read text styled by authors who don’t respect user defaults. It’s not perfect. As you can see in for example https://bugzilla.mozilla.org/show_bug.cgi?id=181438 Firefox can easily overshoot the user default. In fact, more often than not, at its fixed zoom steps, that’s exactly what it does. Using your 16px X 62.5% X 120% example, a user with 16px default at his first zoom step will get 12px X 120% = 14.4px, too small, and at the next step 14.4px X 125% = 18px, too big.
I don’t use a 16px default, because that’s far too small, as I’m not content to use any common lowfi screen resolution. Depending on display size, viewing distance, and resolution, I mostly use either 20px @ 1280×960, 22px @ 1400×1050, or 28px @ 1792×1344. All those in fact translate to almost exactly the same physical size as 16px @ 1024×768 does.
So, rather than fixing a new size in user CSS for each switch to a different resolution, I can use the exact same user CSS file on every system regardless of other settings, by setting font-size: medium !important. And when I copy this same user CSS file to customer computers, whether using Opera or Firefox or even IE, they enjoy the same result – whatever size default they have chosen, or retained as chosen by the browser maker, is enforced against all pages. It works fine on Briggs pages, but not on Clagnut pages. So, yes, using zoom, which usually takes more than two tries to discover won’t get me back my default, is “onerous”.
True you don’t directly recommend a 62.5% default, but the way the example is laid out it implies the usual bogus author assumptions that 16px is too big, that 12px is good, and that designing using px for sizing generally is good. The web is a fluid medium. Good web designs embrace that, sizing as much as possible in % or ems for text and containers, leaving px for minor adjustments like padding, margins or borders.
As I said, my default size is quite as I like it, and needs no author adjustment. This goes for many other users, and deserves respect from most web authors. After all, most of us using the web use Personal Computers, designed to be personal tools to be tailored to best suit each particular user’s needs. If 16px is too big for you, change your browser default, and don’t reduce by some arbitrary percentage whatever your visitor has decided he prefers. Designers who impose smaller than default sizes on visitors are not doing “their best”, regardless whether it’s px or % they do it with.
BTW, 16px as an initial browser default is not carved in stone. Users on M$ who choose “large fonts” in their system settings get 20px rather than 16px, because the IE default is, as it always has been, not 16px, but 12pt. Many “high” resolution XP laptop users have been having 20px defaults for quite some time, as vendors have not so recently taken to initializing them to 120 DPI during pre-sale configuration. On a Mandrake 2006 or SuSE 10.0 Linux system, the Ephiphany proportional default is not 16px, but 11pt (and monospace, 10pt). That’s 14.67px if the DPI is 96, which it more likely than not won’t be, but instead somewhere between 75 and 90. On a Fedora Core 4 Linux system, the Konqueror default is also 11pt, which is accompanied by a 9pt minimum. On a Xandros 3 Linux system, The Firefox proportional default is 14px, not 16px, and for monospace, it’s 12px. I don’t have any Macs, but I’ve heard Safari and Camino may also default to less than 16px. So, assuming the user default is 16px is not only rude, it’s often wrong.
Scott wrote:
Whichever way you slice it, the essential problem is still the fact that IE/Win won’t resizie text set in pixels.
There are also two problems with ems:
1. IE Win resizes em text too dramatically.
2. Ems are relative to the system default font size, which can differ cross-platform.
What we need are some basic css rules that we can set on the body element to acomplish the following:
1. Consistent default font sizes, cross-browser and cross-platform.
2. Text that can be resized cross-browser, (and won’t get sized ridiculously in IE/Win).
3. A convinent and logical method of specifying font-sizes on individual elements.
Here’s my suggestion, which takes into account the fact that IE7 will probably not support reszing for text set in pixels, but probably will support the child selector, meaning we can’t use this to hide our non-IE rules. So I use Conditional Comments, like this:
body {font: 10px;}
<!-[if lte IE 7]><style type=”text/css”>
body {font-size: x-small;}
</style><![endif]->
<!-[if lt IE 6]><style type=”text/css”>
body {font-size: xx-small;}
</style><![endif]->
Element font-sizes can then be specified in %, with 100% equal to 10px, and so on. Text set at 110% (equivalent to 11px) will still go too small in IE/Win, but only when the text size is set to Smallest. Otherwise, this method seems to fullfil all of the above criteria.
Well, it works for me!
Callie Bowdish wrote:
Thank you very much for this great description on working with sizing text on IE/Win. This is the most helpful page I have found.
You comment on setting the font-size in the body to a % has made a possitive difference in having our css work with sizing fonts on IE. My page, at work, was having too drastice of a size change in IE/Win. Next I have to explore the inherited shrinkage. This page is just the help I needed for getting the IE text sizing to work.
thanks again,
Callie
Le Caphar wrote:
At last I’ve found an efficient solution to that problem. This was long-awaited. Thanks a lot !
Florian Steiner wrote:
I used the hack from patrick h. lauke for IE but implemented it different.
In one project we did, I finally got a problem with the sizing of the text:
IE was working fine but Firefox displayed font sizes much too big.
After searching around, not knowing what the problem was I found out that it is important which DOCTYPE you are using.
The implementor of the CMS changed from XHTML in my mockup to HTML4.
It seems that font sizes defined by CSS act different if it is HTML4 or XHTML 1.0 Transitional.
so the CSS for XHTML was:
font-size: 1.1em !important;
font-size: 70%;
to get the same sizes with HTML4 the CSS was:
font-size: 70%
the first line with em’s made the text to big in HTML4
barrie wrote:
Some sites have begun to have huge text-bigger than anything that any of my fonts could make. Like 3” letters. I am assuming this is some type of computer problem, but could it be related to my recent use of a large (12 pt. Verdana) font, as some of the Google sites indicate? Thanks!!
forz wrote:
this helped me. thanks
Josie Belliard wrote:
Hi
I wanted to team up with someone to figure out how to use css like I used AUTO TABS, NO FLASH, End Line without advancing lead (in traditional typesetting)
Here is a line parameter I would create in traditional type and I could modify it for any line length, column width or point size/style.
<IS><AT99,C><NFO><AT1,L><h1>This is the longest line 1<AT1<L><FP18><ATL,2><h3>(middle column only insert space)<IS><AT2,L><FP18><ATL,3><h2>Item 12<ATL,3><NFX><AT99,C><IS>
<CT99>This is title and will be centered on the rest
<MCO>
<CT1>This is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1, keeping typing away, this is column 1,
<MCR>
<CT2>keeping typing away, this is column 1,
<CT3>Item 1
Item 2
Item 3
Item 12
<MCX>
Now, if you decide to change the parameter line for handheld devices,
then just change the point sizes in the no flash parameter line at the top, along with the line lenght.
Is this familiar to you?
tks
Josie Belliard
Jules Landry wrote:
I’d like to know what you think about using: “xx-small, x-small, small, medium, large, x-large, xx-large” for the font-size property?
It’s easier to play with than ems, it validates and it allows the user to increase or decrease the display size, even in IE.
Jules Landry wrote:
I just realised you already discussed that. I didn’t know “keywords” was refering to small, x=small, etc.
Devlin M. wrote:
This helps explain alot. I’ve always wanted to use em but never knew the correct way of implementing them, I’ve always used %. With the wave of the future going to CSSP this will help with my layout immensely
Martin Ström wrote:
Great article!
As for the problem with nested elements (the mentioned solution is to include all elements like
LI LI, LI P, TD P, BLOCKQUOTE P {font-size:1em}
shouldn’t it be enough to do something like
body {font-size: 1.3em;}
body * {font-size: 1em;}
Yorki wrote:
Using %s as reference for later ems won’t work correct for IE – at least according to my experience. It’s better to use pixels as reference for later ems – it’s more reliable.