Fonts: em,px,pt, %

Found this great article describing all the differences with examples.

CSS Font-Size: em vs. px vs. pt vs. percent | Kyle Schaeffer - Web Design and SharePoint Branding

It seems to me, with my limited knowledge on the said subject, that if you’re not designing for mobile, px is just fine to use because most all browsers support the zoom feature (Ctrl +, Command +).

It would seem a pain to write %/em for body content yet write px/pt for text you don’t want enlarged for the possibility of breaking the design (eg Nav). Also the added headache of %/em with nesting.

I know this is probably a big debate amongst designers. Just looking for some clarification and not a big debate :slight_smile:

The point about not using px is because you want to allow things to get larger. If it breaks your navigation too badly, you should probably take a look at how you’re coding those (most of the time, it involves giving one dimension freedom to grow so it doesn’t “break out”).

If you set your body to 62.5% font size, that essentially resets it to 10px, so you can then very easily figure out the pixels you want (i.e., 16px => 1.6em).

And how is that not addressed with the browser’s zoom feature?

Even on my droid I’ve looked at sites with px text and I can zoom in to read with no problems…

Not all browsers can zoom px text. Even if it’s only the older ones, it’s so easy to do that why not?

Also, there is a difference from zoom and changing the text size.

I know the difference, if I come to a site with really small text I just tap command + a few times and i’m good.

I also know about 65% rule and it’s a great idea.

However, to me it seems a pain to have to take into account for the text that you don’t want to be enlarged in relation to the keeping the integrity of the design. And also dealing with nesting issues.

GAH, not that lie again… Well, more a lie by omission. See, that little bit of math is so flawed you cannot/should not rely on it for building a page – ever. Seriously I meet whoever started advocating that in a back-alley bad things will happen. More typical idiocy started by people who failed to grasp how things work under the hood.

See, not all computers have 16px as their default font size, as that 16px default is/should actually be declared as 12pt… Yes, PT. IE and Opera both traditionally treat their default font size as such just like all other good little doobie windows programs… because Windows lets you change the “system metric”

So what is a “system metric”? Basically it’s a dpi setting for your display. Just as you can change the resolution of your screen, you can also change the dpi setting for font and application rendering. The generic default settings on most computers is 96dpi… But windows has had the option to switch to 120dpi pretty much since Windows 3.0! This means that instead of a 16px default font in browsers, you SHOULD get 20px… which throws that 62.5% nonsense into havoc as it ends up being 12 or 13px (depending on browser rounding) instead of 10px.

That’s the ENTIRE REASON for using %/EM, so that it is based off the DEFAULT font which is NOT A FIXED SIZE. That is also WHY PX is a miserable fail at accessibility. As a Large font/120dpi user if I have to dive for the zoom, there is something wrong with the site I’m visiting!!!

Some handhelds render at 72dpi… some desktops render as high as 192dpi… Windows has let you set any dpi you want since Win9x, with the two standard sizes of 96 and 120 as the ‘default choices’ – Win7 now offers four default choices – small (96), medium (120), large (144) and extra-large (192)… and the browser SHOULD obey that. (though Gecko and Webkit do not… Opera and IE do/can). Even in browsers that don’t obey it automatically, you can manually change the default font size!

I made a page a while back to show all the different behaviors of the different browsers when fed all the different font metrics.

Effect of Font Metrics on Common Sizes

pay particular attention to the behavior of %/EM and PT on 120dpi systems in IE/Opera compared to 96dpi ones.

This also where that article has a massive flaw – even though it too is popular misinformation. See, PT is NOT fixed, no matter how you color it. How can I say that? Simple, it’s relationship to dots is not fixed!!! Where people get the idea that PT is a fixed measurement is beyond me – because it flat out isn’t in relationship to screen pixels or print dots!!!

A pixel/dot is a fixed hardware measurement – it’s the smallest real unit the physical device can make. This is WHY resizing “pixels” actually makes NO SENSE WHATSOEVER!!! I’m actually with old-school IE on this one – px fonts should not be resized – unless as Opera introduced and STILL does better than anyone else you resize ALL elements that are declared in PX!

PT is a measurement based off inches… so if the number of dots/pixels per inch changes, the number of dots/pixels per PT changes. Look at that page of mine – at 96dpi you end up with 12pt equalling 16px; at 120dpi 12pt equals 20px… at 1200 dpi high quality print, 12pt = 200px!!!

It’s why for a long time developers used PT on sites, and it was THE choice for forum skins right up until around 2003 – it was the only measurement that automatically adjusted to the system metric in all browsers (even nyetscape/gecko obeys PT auto-sizing). It’s also why I was slow to adopt %/em because I didn’t want netscape/gecko users to have to dive for the zoom in the first place!

I’ve changed my tune on that now, because I’ve realized that accessibility and Gecko or Webkit is such a joke because they LITERALLY believe all machines are 96dpi (as several webkit devs have run their mouths about in the past) so much like everything else accessibility related in those browsers – it’s a total joke… much like geckotards clinging for dear life to the resizing of text like the sweetly retarded cousin of nyetscape 4 that it is, accessibility in those browsers is a bigger joke than it is in IE… So screw 'em, %/em for content areas it is. It also doesn’t help that Opera 10+ no longer obeys the system metric on PT, even though it checks the system metric and does set the default size to 20px on large font/windows systems (bizarre)

Though I see little wrong with px for areas where image interactions force you into it for layout reasons – assuming it’s small things like buttons, controls or narrow fixed columns, so long as you keep in mind that anything below 12px is illegible for large font/120dpi users, and I personally wouldn’t go below 14px unless you do all uppercase on that. (add 2px more for serif fonts!)

Case in point, these forums, where the text entry boxes and posts are all a nice big easy font with my 120dpi setting, but the text on areas like “send trackbacks to” or the labels next to the checkboxes under “miscellaneous options” is uselessly small to the point I have to zoom 50% to even read them – all because they’re declared as a uselessly small 11px (for christmas only knows what reason)… Well, zoom or move my head to a foot and a half from the display instead of the comfortable 2 and a half to 3 feet I usually sit at.

Though that’s why I run a user.css here in Opera to override all the font sizes into something USABLE. (even if it does screw up the layout slightly).

Still, if I have to zoom a layout just to read it as a 120dpi user, I have the overwhelming urge to pimp-slap whoever wrote the page, as there’s no excuse for it apart from ignorance… or letting the “but I can do it in photoshop” nimrods have their way with pissing all over accessibility.

So you’re over all message is use %/em and px where necessary (buttons etc)

You are absolutely correct, deathshadow.

In situations where screen resolution is 72dpi, 1px = 1pt (because pt is now defined as 1/72 of an inch). Since the default is 16pt, which on screens which have a resolution of 72dpi (where 1px = 1pt), that means your resolution is 16px. 16px * .625 = 10px (or 10pt, on a screen with 72dpi). That is where the 62.5% rule came from.

However, you are absolutely correct that on a screen with a higher DPI (such as 96dpi, where 1pt = .75px), you wind up with 16pt giving you 12px. This means 62.5% gives you 7.5px, which means everything else is tinier.

However, if you do 16pt at 62.5%, that means 10pt. 10pt at 96dpi is the same as 10pt at 72dpi, 120dpi, 625000dpi, etc. So, then doing em based on that will result in the same size regardless on the screen.

So, I did misspeak when I said it was “equivalent to 10px” somewhat, but the end results are essentially the same.

To the OT, yes, use em/% for content font using px as sparingly as possible.

PT should of course only be used for printed versions where it does properly represent a fixed size - the alternatives for print are CM or IN but both of those are somewhat larger and so lead to more complicated fractions which is why PT was created by the printing industry in the first place.

PX fixes the size to the screen resolution so that the same text will appear huge at 72dpi and microscopic at 200dpi - it is the least fixed of all the ways to define font size and gives you almost no control. It is only really useful where you want a border to be displayed as thin as possible and so define the border as 1px.

To actually get text to display on the screen at a consistent size you have to use EM which then sizes the text relative to the base font size that your visitors have defined on their computer - in other words it will be big enough for them to read.

PICAS!!!
Seriously I was confused by the first reply and then by this:

…if you do 16pt at 62.5%, that means 10pt. 10pt at 96dpi is the same as 10pt at 72dpi, 120dpi, 625000dpi, etc. So, then doing em based on that will result in the same size regardless on the screen.

but somehow it miraculously clicked … maybe.

A pixel is a fixed measurement, while a PT is a fixed measurement RELATIVE to a real wold size ( 1/72"). DEFAULT UA sizes are actually in PTs not PX ( I think this is what confuses people, as when you set your default font size in the preferences it doesn’t specify unit of measurement. This is what I think is throwing people off.

Back to the the math. The number of pixels in an inch varies by the resolution. 96dpi… pits 96px in an inch where as 120dpi fits 120 pixels in the same space. 72pt text can be 96px or 120px, the key is to realize that there is no DIRECT correlation between PX PT (w/o first knowing resolution). AND THUS the quote above made sense!

The next thing to understand where and WHEN to apply this knowledge. since a (single) bg image will not resize… if you wanted to emulate the text as if it was part of the image (you need to keep it from changing size) then PX comes in handy, to some extent. That is some older browser applied zoom to text… enlarging text content from it initial size… even if it was set in PX.

For more fluid containers then ems/% is the most suitable method.

At least, that’s how I understand it.

Actually it depends on the browser – the big three standards browser engines (gecko, opera and chrome) now state theirs in px – Opera still auto-adjusts it’s default to match, but seems to ignore the system metric for PT now… funny since Gecko ignores the system metric for it’s default but obeys it for PT…

So, I did misspeak when I said it was “equivalent to 10px” somewhat, but the end results are essentially the same.

Here’s the problem: it was supposed to be a way for people who cannot think in anything other than pixels (and btw, how many screen pixels is a CSS pixel? Answer: depends on the screen/device and the browser, and this is even worse for mobiles, so have fun there) to “convert” the pixel amounts they wanted into an em unit.

These formulas are bunk. I have a medium-high screen resolution, meaning my eyes strained a bit at the Desktop default. I’m not sure if this is the same as a system metric, because it’s controlled entirely by the GUI here, but I raised the default font for my Desktop and also Desktop applications from the 10px it was sitting at to 16px.
Firefox is a Desktop application to Gnome and so enlarged everything. Buttons, inputs, and menu bars are wider in my FF than in my Opera or Chrome (who don’t seem to be able to detect my Desktop font settings) who show things to be absolutely unreadable. When designers take that 10px=1em rule by making the body font too freaking tiny (the original technique called for enlarging the text on the container within the body, which it seems everyone forgets to do), it unnecessarily makes junk harder for many of us to read.

My suggestion: learn to use em’s as they naturally work, rather than trying to figure out how many pixels an em is (because, as we’ve explained, it depends on the machine, the settings, and the browser, so there never is one good answer).

Set font-size to 100% on the body (which should be the user’s default, whether that’s 9px or 20px or anything else) and then be careful not to set font-size on containers themselves, but just on text.

Setting containers’ dimensions in em’s allows a lot more flexibility for those boxes if text is enlarged. There are pitfalls to using them and you have to get the hang of it so you don’t end up in cascade-hell. Generally you’ll find you set actual font sizes rarely, and are really never more than a single parent-child level away when you do this (no extreme nesting and font-size setting, that’s insanity).

I learned it, and I’m a moron, meaning anyone else can learn it too. It takes time. You can even use one of those ruler-plugins to measure in px some box you’ve set in em until you can have a general ballpark figure in your head (though you’ll need to check across machines and browsers), but eventually you’ll be able to show with your fingers apart how wide something of X em is. That’s the goal.

Since that is the default you wouldn’t even need to specify it if it weren’t for a bug in some versions of IE where setting it resolves the bug.

Since that is the default you wouldn’t even need to specify it if it weren’t for a bug in some versions of IE where setting it resolves the bug.

That’s pretty much why I do it.

And Crusty will pipe in and say a line-height should be mentioned along with it for X-browser compatibility.

Is there any real difference between em and %? (i.e., is there any situation when 1em =/= 100%)?

Also, while I agree that in an ideal world using ems as intended is the best… unfortunately most of us have to base everything off of designer comps (where the fonts are in px), so we have to “convert to px” in order to do our jobs. =p

Yes there are situations where 1em doesn’t equal 100%, Consider defining a block as 100% wide compared to one that is 1em wide any they should be very different widths.

I disagree that you have to ‘“convert to px” in order to do our jobs’ as that will guarantee that the page is broken most of the time and rarely looks anything like the designer comp. You have to define the font sizes in em if you want them to change size in proportion to the rest of the page content when someone configures their browser to work differently to that of the person who created the comp. You might as well say that all distances should be measured in pixels - let’s start by considering where someone sets a pixel equal to the distance from here to the moon or equal to the distance between the two atoms in an oxygen molecule (both rather extreme but also both possible when it comes to pixel sizes) - what will that do to your designer comp?

unfortunately most of us have to base everything off of designer comps (where the fonts are in px), so we have to “convert to px” in order to do our jobs. =p

There’s your mistake. Why are you letting some Photoshop jockey set pixel fonts for something everyone is supposed to be able to read? Are they magically able to control everyone’s browsers and OSes and eyesight so their 12px really is 12px?? (I’m so glad they can’t. I’m finding myself needing to enlarge more and more pages recently… not sure why)

This is why y’all make pages that break in browsers for those of us who can’t read that fancy 9px light-grey-on-white (but, it looks so professional and the boss demands it!). Pixel perfection == none of the flexibility necessary for web pages. Making a web page imitate an image perfectly belongs in print. Since we all know this, we need to pound this into the brains of those who dare call themselves “web designers”. Any of them worth their salt do understand how text works on the web and design for it (and know the limitations and abilities of your code).

If you’re actually placing some element over an image then you have to use px (unless image is SVG). For the rest? No way. When I enlarge your web pages’ text, I can guarantee it’s not what some designer designed.

Since a pixel has no fixed size, a design for a web page cannot possibly be based on it. At least not by a professional web designer or anyone else who has completed web design 101. Only a complete newbie who barely knows what the web is would use pixels.

question - is it one milllion pixels = one inch or one million miles = one pixel?
Answer - both can be correct since a pixel has no fixed size.

Hello there Bades,

Nice question. It doesn’t matter much these days (for screen design and development, but I do agree very much with Stephen right above my post here). I say focus your energy on more important things. Personally I use em (for reasons mentioned by Stephen and for those old crappy suckers of browsers that I loathe to support) so I suppose that would be my recommendation. :slight_smile:

Have fun and good luck with your stuff!

Oh, and I just skimmed through the thread but I believe there are some excellent answers up there already—by some very skilled people—so please do learn from them as well as any other reliable material you can find, and keep yourself up-to-date. That’s all from Daniel for now, and as always you can feel free to message for more advice or chatting. :slight_smile:

See why I say 99% of the people “designing” pretty pictures in photoshop have NO {expletive omitted} BUSINESS designing Jack… as the “but I can do it in photoshop” mentality is responsible for more FAILED websites than any other approach to page building.

Crappy fixed widths too big for netbooks and too small for desktops, fixed height image backgrounds with text over them, px metric fonts, visual elements that are impossible to scale to the size of their content – and a general attitude from them that if you’re not a 1024-1440 wide 96 dpi user, you can go perform a sexual act I’m not entirely certain is anatomically possible.

Hence my saying markup your content (or a reasonable facsimile) FIRST, with semantic markup and ZERO concern for the layout other than the default CSS off appearance – THEN design your layout using CSS so everything is nice and fluid and viable – then and ONLY then do you hand off to the PSD jockey to make the goofy graphics you hang AROUND the content.

It’s a bitter pill for the visually oriented/artsy-fartsy crowd to swallow (took me three years) but people do NOT visit websites for the goofy graphics you hang around the content! – and when the “design for a certain size screen with fixed size fonts” nimrods vomit up a broken page, it can be the prettiest thing on the planet; but if you can’t actually USE it to get at the CONTENT - it’s worthless.

While the ugliest pages on the planet (Amazon, eBay, slashdot) can rake it in hand over fist because they have content of value that people want… and are able to actually get at.

Seriously, I’m tempted to track down whoever started this “draw a pretty picture first in photoshop” asshattery and put them down like Old Yeller… especially with the majority of people using that approach being COMPLETELY unqualified to design ANYTHING for the web…