em instead of px and pt in CSS

So I've been learning about em and using it instead of using px and pt for font-sizing in CSS. Does anyone else here use em?

It's very confusing but I am doing it right - at least my site looks right in FireFox.

Let me just say that it's so much easier doing px IMO. I don't understand the use of em yet and how it works...but I am learning from this site:
http://www.webmasterworld.com/forum83/5272.htm

Anyone here use em? Tell me about it please..

 

Stomme Poes uses em im pretty sure. i dont know if he will see this or not though

 

Anyone else's opinion?

 

I use it all the time.

What you need to do is declare a base font size and leading (line-height) for the body selector. I use 85% for the font-size and 1.5 for the line-height, and then toss in a 1px letter-spacing declaration as well since I find it's far easier to read text with some fonts (such as Tahoma and Verdana) when I use it.

An example would look like this:

* {
	margin: 0;
	padding: 0;
}

body {
	background: #FFF;
	color: #000;
	font: 85%/1.5 tahoma, verdana, arial, helvetica, sans-serif;
	letter-spacing: 1px;
}

Code (markup):

From there, I just size all of my containers' widths using EM, without regard to the current font size (since it's all relative to the default font size in each browser). When done properly, it can yield some spectacular results, such as this: http://www.dan-schulz.com/temp/4columnlayout/

 

Yeah I use em, not for everything... I don't use pt because that makes more sense for a print.css, but I will also use px (for container sizing, almost never for text, but that depends).

I made a group of ungodly-long forms and for the first time sized not only the text but the label widths and the form boxes themselves in em and it came out quite nice I think ( http://stommepoes.nl/Homeselling/secondhome/invoeren2.html play with text-enlarge) but I didn't do what Dan did in setting a "base size" (it likely makes things easier, but I'm stubborn that way). Instead, I have a not-really accurate ruler from FF Web Developer Toolbar which measures things in px and then I went to this page which is also not-too-accurate (esp since em does not equal any particular font size, it's different per computer anyway) to get a ballpark em number to start with before adjusting as I tested text-enlarge in every browser.

Teh Crusties here will encourage you to use px for text if the text must fit a background image or something like that... in which case, you'll make the font size like 16px or something so the rest of us can actually read it. I know the whole 9px font size thing is popular with designers and "looks professional" but who cares about that when you can't read the stuff??

 

Just in case this may be useful, I set my body font size to 62.5% (which = 10px since the browser default is 16px) so I can use ems everywhere else easily. After doing that 1.1em = 11px, 1.8em = 18px and so on.

@Dan – nice 1px letter-spacing tip for fonts with wide bases.

 

16px is never the browser's default. IE and Opera obey the system metric, Firefox and other Gecko browsers tend to use 16px, and Safari uses the Mac settings, even when emulated on Windows.

To make matters even worse, some people (such as myself) often turn up the font sizes of our browsers (I do it on a per-site basis with a combination of page zooms and/or user stylesheets in Opera) just so they can read what's on the page.

And that's assuming the real screen resolution as at 96 .dpi (for Windows - Linux is at 75 .dpi IIRC) and not 120 .dpi (or 100 for Linux). Using 100/120 means you're jacking up the font sizes by 25%.

 

Well, it's actually a bit more complicated than that...

The 'system metric' is the oft-forgotten part of web design that way too many websites are broken in regard to because people jumped 'too far' onto the %/em or nothing bandwagon, using dynamic fonts inside fixed-width containers or over fixed-height images... Then they go online wondering why on 'some windows machines the site is broken while it isn't on mine'.

Basically, from the early days of Windows when they first added support for higher resolutions (windows 3.0) one of the big 'concerns' was the 15" 8518 display, which when tied to a 8514 graphics card was meant for CAD use and ran at up to 1024x768 - while most the rest of the world ran 640x350 on 12" or 14" displays. This much higher resolution resulted in the fonts being illegibly small - yet people who had 8514 adapters and displays (the precursor to the VGA) wanted that full resolution for the increased detail.

HISTORICAL NOTE -- It's worth mentioning this is before Steve Jobs was sacked from apple for refusing to put color displays on the computers, which is why he went and founded NeXT with it's 24" monochrome CRT's)

Microsoft's solution to the 'problem' in Win/286, Win/386 and Win 3.0 was to include a second set of raster fonts 25% larger than the default ones - the so called "8514 Large Fonts" - which by the time of Windows 95 was called '120dpi' to the standard display's "96dpi".

The change to listing the DPI was a response to apple, who's hardware in the early days had a fixed dot pitch of 72ppi, so the software was set to 72dpi. That little tiny monochrome display allowed publishers to hit 'actual size' in PageMaker or Quark and miracle of miracles, GET ACTUAL SIZE.

The Microsoft attempt at adding this to windows with the ability for any size display to have it's accurate dpi set was sabotaged by legacy software from the start, most of which relied on raster fonts instead of the 'new fangled' cleartype fonts that were introduced with Windows 3.1. The sheer volume of different display sizes, the rapidly changing standard resolutions available as the technology increased from VGA to SVGA to XGA, coupled with the inability of joe user to even understand what DPI is much less that they could change the resolution of their display led to the efforts of a 96dpi standard, much less the 120dpi alternate, being abortive at best.

It's interesting to note that the 'standard' resolution most Windows 95 users ran on their 14" CRT's (10.66~ inches wide viewable) - 640x480 is in fact 60dpi - the default value in the unix world, 75dpi, is accurate at 800x600... 96dpi is in fact only an accurate measurement on a standard 14" CRT at a whopping 1024x768, which very few people would even consider a usable resolution if working with text in the default font sizes.

Apple too abandoned the 72dpi standard the moment they went to color displays, but had no option for increasing the DPI to keep 'actual size' accurate. It was because of this that DTP programmers made their applications have their own DPI adjustment settings to make actual size accurate... You can even find this setting in Acrobat and many other Adobe programs on every platform under preferences > page display > Resolution.

So how does this effect web browsers? Under windows all browsers except safari do at least try to pay attention to the system metric, using it to determine what an 'inch' is, and therin all measurements based on inches, like points, will scale based on the system metric. Under *nix there is a DPI setting for X as well, though some toolkits like qt and GTK choose to ignore that and use their own settings - and not all programs, even if they are built in those toolkits, actually obey the OS setting - mostly out of either lazyness or ignorance on the part of programmers. (Just as a handful of little utilities like nvidia's 'NTune' crapplet or 90% of the rubbish barfed up in a fixed dimension window in javas don't work right on large font windows machines)

The big problem is how the default size is declared - Gecko based browsers by nature of their Nyetscape heritage set their font size in px. This was actually one of the strikes AGAINST Nutscrape back in the day as resolutions increased and more and more users started using the Large fonts/120dpi setting... We will likely see a similar backlash as LCD resolutions start to increase upwards of 120dpi. (My 1920x1200 left LCD is at that physical 96dpi for example, which is why I run the large fonts setting)

The breakdown of browser default behavior is as follows:

Opera and IE6+ actually sets it's in px as either 16px at 96dpi or 18px at 120dpi (which is NOT the full 25% system metric increase). This was done because:

IE5/earlier used 12pt, which is why %/em fonts are so much 'larger' in older IE versions on 'large font/120 dpi' machines. (like mine) and why you'll see some 'frameworks' have browser specific hacks to try and shrink the default font on those older browsers.

Netscape, Gecko, Firefox, et al... Always declares itself as 16px, but declares a 1.2em line-height which can cause major headaches since it never throws fractions away, resulting in inconsistant line-heights. Because it declares fixed px as the default font size, the default font size ignores the system metric making Gecko and it's kin a 'last choice' so far as accessability goes, but even more annoying is pt, inches and the rest DO obey it.

Safari Regardless of what hardware platform it's on, it's 96dpi or nothing (which oddly enough conflicts with MacOS' default 72dpi assumption). The windows version ignores the system metric, and I really doubt it even has the capability of handling other DPI built in.

From that, we can classify the various fonts as follows:

PX - pixels The necessary evil. Pixels for 'content' - large open areas of text, is a total and miserable fail because not only does IE not resize them, the also do not obey the 'system metric' so 120dpi users do not get larger fonts at default zoom. That said they DO have their use, that use being inside fixed width containers or anyplace where the font size being enlarged by the system metric will break the layout. The key to using PX is to use a font that is BIG ENOUGH IN THE FIRST PLACE. 12px is bare minimums from an accessability standpoint, and I get twitchy about using less than 14px. You want a font smaller than that, use another metric like pt or %/EM. Netscape and by extension Gecko screws up PX by letting you resize text set to px, while leaving all other px elements the same size - this is actually one of the cases where IE got it RIGHT - because a px is a pixel, and you do NOT resize pixels because it's a fixed PHYSICAL MEASUREMENT on your display. Anyone starts talking about pixels as dynamic needs a foot up their ass unless they are going to treat ALL pixel measurements as such - like Opera does EXTREMELY well and as IE7 makes a half hearted attempt at.

PT - Points A point is SUPPOSED to be 1/72nd of an inch (again, 1:1 with the old tiny screen black and white Mac's), but with people not bothering to calibrate their DPI, programmers being lazy and writing all their software based on pixel sizes, that meaning is pretty much lost targeting screen media... That said, how did it become so popular in the late 90's when CSS was introduced?

Simple, it is the easiest scale that in integer granularity (therin reducing rounding errors) obeyed the system metric in both IE and Netscape. 90% of the browsing public still doesn't even realize you can resize text in the browser (yes, I pulled that number out of my ass and it's an exaggeration - you get the point) but enough of them, especially back when 17" CRT was out of most people's price range and before things like 'cleartype' could get rid of jaggies, upping the resolution one notch and then telling windows to make all UI fonts 25% larger was really attractive. This is why MOST of your commercial forum softwares STILL default to PT for their font sizes. The only one that does not do so, phpBB, is next to useless for 'large font' users with it's raging chodo for retardedly small 9px fonts.

%/EM - Based off the existing font size, starting from default unless you set otherwise, this has become the new 'sick fad' of fonts. It has it's place, that place being for content. I used to rail against it's use completely because 90% of the layouts people made using it were broken on my machine (again 120dpi/large fonts) and I'm not making my display look like shit just to cater to one poorly written website. The people who advocate it's use to the exclusion of all others are idiots so far as I am concerned. (Though I was an idiot for knee-jerking that it was useless because everything these 'zealots' had done in it appeared broken to me)

If restricted to use inside areas that are sufficiently wide and completely dynamic on height, it is the ideal choice because it obeys the system metric in Opera/IE and can be resized in any browser. The big key to using it is making sure the area is wide enough (150px wide column + %/em fonts = disaster waiting to happen), that you aren't combining it with image based backgrounds that will break if the height or width grows...

One of the things I used to argue against it on is that it ignores the system metric in Netscape/Gecko based browsers - I've flipped on my opinion on this for one simple reason, anyone who gives a shit about content resizing or accessability isn't using those steaming piles of garbage that resize content like Netscape 3's sweetly retarded crack addict cousin in the first damned place. They have likely moved on to browsers that at least try to do it better like IE7, or browsers that get it RIGHT like Opera. Oh Noes, the layout breaks when you try to resize text in Firefux - Does it let ANY page resize without breaking worth shit once you get anything more complex for styling than a flat colors on the page? **** no. So screw 'em.

Oh, and as noted trying to use %/EM to translate to pixels is bullshit and breaks the moment the system metric changes in IE and Opera - AS WELL IT SHOULD. If anyone is ***ing up that behavior, it's Firefux and it's Nutscrape heritage. (gah, remember the days when we used to praise IE for implementing standards and badmouth Netscape for piss poor implementation? There actually WAS such at time people!)

Basically:
px - used for areas like headers where image replacements are used, menus where there are fixed height or width backgrounds behind your text, or anywhere else you need to 'interface' with a fixed image background - and if you are going to use it, 12px or larger.

pt - if you care about obeying the system metric in Netscape and/or Gecko based browsers, it's your only practical tool. Otherwise don't bother.

%/em - Good for content, miserable /FAIL/ when inside a narrow fixed width area or when interfacing with fixed size images. I find 85% with a 140% line-height a good 'starting point' to toss in the body tag.

Some time ago I made a quick little html that showed the various rendering differences between browsers with large fonts on vs. small fonts in all the different browsers.
http://battletech.hopto.org/for_others/font_test.html

Which reminds me, I REALLY need to modernize that.

Hope this helps SOMEONE - assuming they can make it past it's girth.

... and remember, I worked in Print AND am legally blind, so I know what the **** I'm talking about when it comes to accessability and fonts

 

I dont like em because i can never get my site to fit with my images correctly. the images always stretch and look horrible, if i set it to width:22em; (approx 270 px on my browser) and height:10em; when i try to view it on another browser, or change my font size, it stretches and gets kinda pixelated. thats why i use px, so that its 100% the size of the image in photoshop

 

Why the hell would you want to resize images with EM?

 

I've seen some whackjobs on other websites (you know WHERE Dan!) advocating doing that - with images that are pretty much photographs you can get away with that to an extent, most web content is line-art or flat graphic, so trying to state their sizes in EM is going to be a total and miserable /FAIL/ - You know, same type of whackjobs that advocate treating images like they were a paragraph of text. (sorry folks, an image is NOT a paragraph - two words is not a paragraph - a list of links is not a mother puss bucket paragraph!!!)

Which is why I say px for images or text that will interact with images, pt or %/em for 'copy' (copy is the print term for your actual content text)

Of course, if it's a content image it should always be pixels - if it's a presentational image you shouldn't be able to declare it's size in the first place since it should be applied as a background in the CSS - see site logos, borders, dropshadows, etc, etc. - You use a IMG tag for those, the site is already made of /FAIL/

 

asked someone on another forum how to use ems so that my webpage would be stretchable, and they said to set a size on a div in em instead of px and put your background image in it too. :S i dont know. lol i use px.

 

Great post deathshadow! +rep added Wish more people would take the time to post like that!

 

Let me resume it in a nutshell; EM allows the users to scale their font sizes when required and allows the interface (when properly coded) to flex with it. You basically want to use EM values for headers and text, some of your containers if necessary but not for other things like images.

Tip: I like to declare the body's font size at 67.5% rather than 62.5%. It basically translates to 1em=10px. It makes it easier to declare font-sizes to the exact size you want it.

 

That's only true if the declared font size in the browser (if it uses its own and doesn't respect the system metric) is set to 16px. In other words, it'll work best in Gecko based browsers where the user hasn't adjusted the font size at all and is relying on the default settings.

 

I prefer px to em

 

Really? I wasn't aware of that! I've noticed no difference in Gecko to Trident-based browsers in terms of font size with the exception of the Headers. I've yet to really test KHTML and Presto in-depth though so maybe they differ. Thanks for mentioning it, though! I'll definitely keep an eye on that.

 

In 2k/xp - display properties > settings > advanced > general > dpi setting - change that to 120dpi/large fonts, watch all your measurements with that 67.5% nonsense break in Opera and IE. This windows setting is increasingly popular as the native resolutions on LCD's goes up. (I wouldn't even want to use my 24" 1900x1200 LCD without that setting)

Again, see this page:
http://battletech.hopto.org/for_others/font_test.html

pay attention to the ones that say "default size" - also look at how gecko does wildly different default line-heights than everyone else thanks to rounding errors, which means on the vertical you might get 10px per em, you might get 9, or you might get 11.

Which is why the whole 67.5% NONSENSE is just asking for a site using it to break.

 

In theory, aslong as the page is made to not break unless the fonts are insanely large, it doesn't really matter what font size is declared - as after all, browsers, default font sizes, and DPI change it to whatever they want anyway (making it impossible to make it pixel perfect across all browsers on all systems, boohoo)

 

That's not entirely true. We ma know how to change our settings, but Joe Sixpack and Grandma Edith will rarely know how, if they're lucky.