To be clear: about 80% of what I know about CSS I've learned in the past 9 months or so, despite having dabbled in HTML since the late 1990s -- I've long hand-tooled my own HTML for my personal websites and many discussions which allowed HTML markup. And I'm coming at this almost completely from the user experience perspective. To be more specific, my user experience. I respect your experience, but the practices I've seen in live code are ... simply infuriating.
If you are designing for the screen, pixels are your medium and you should be aware of them.
Pixels are an aspect of your medium. Not all pixels are created equal: they're not the same size, brightness, or color. Screens have hugely varying numbers of pixels, and can be resized pretty much at whim. Used to be you could rely on having at least 80 columns of text visible, with handheld devices, that's rarely a safe bet (reading the comp.risks digest, with its fixed-format presentation became all but impossible). I'd argue that ems and percents should be your principle units.
Where I use px it's for image padding (though I'm switching to ems for that), and border widths (though again, ems might actually make more sense, I'm just used to specifying 1-8px borders ...).
My point is that, for content, that is, text, your measurement should principally be about text. Your ems font sizing point has merits (well, except for your use of 14px for your font size), but you've got plenty of alternatives: smaller, medium, larger. Or absolute sizes: (though I'd suggest avoiding these): xx-small, x-small, small, medium, large, x-large, xxlarge. And realizing that '0.5em' is really saying "scale this to about 50% of normal text with" pretty much obviates your complaint that the typical character isn't 1em in width. Or, if you want a fixed relationship, percentages. I usually set my header tags at 150, 140, 130, 120, 115, 110, though I may bump that up (200% or 300% for major heads) or down (5% or smaller steps). And I'll often set these differently for header, article, aside, and footer elements (larger, normal, smaller, and smaller, typically).
Example of using ems for height and spacing is the drop caps on both my subreddit and Dreamwidth styles.
My focus on single-column layouts for text content (note that I actually like the multi-column mode for navigation and promotional elements -- when in sufficiently wide-screen displays) means that pixel-perfect placement is rarely an issue. I've also taken to styling navigation lists as "display: inline" or "display: inline-block" elements, several instances on the examples screenshotted at reddit, specifying inline-block gives you access to the :first-letter pseudo-element which you can see in the reddit menus on my personal subreddit http://www.reddit.com/r/dredmorbius. The inline styling means that you don't really have to worry about the width of the internal options -- they space themselves out appropriately.
And my use of margins plus padding means that you get both a fluid text box and a minimum guaranteed margin. 2em is tight but workable. This also means that you can set your default font for containers, say:
Setting a font size for the body (I actually usually set this smaller than my preferred reading font: 12pt for body, 15pt for the article, and possibly others for the header, aside, and footer elements (rarely below 10pt). This lets me set the overall page bounding in the #container segment (margins and padding), without skewing the overall widths of the other page elements, and preserving the option of individually scaling fonts and line heights within them. And if my padding widths are slightly off between header, article, aside, and footer, really, it's no big deal. The medium is inherently variable.
As an example of where things go haywire with px-specific stylings, Google+ uses a really complex bit of HTML to render its post and comment scores. It includes independently placed "+", tens, ones, and rating button elements. And if you're not using precisely the font sizes Google assumes, the characters are horribly mis-aligned and clipped. I've had to fix this multiple times as G+ changed its classnames (some completely asinine CSS minifier/obfuscator they use). See here:
I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.
Good practice there.
I swear to fucking god I'll shoot the next HTML monkey I lay my hands on who uses px for line heights, or fucks with letter spacing. It may just be with a squirt gun, but I'll shoot 'em.
The other factor to consider is that you also have access to the @media selectors which can key off of display size. I make use of this on my Dreamwidth blog, http://dredmorbius.dreamwidth.org/ The Kosmic Kat logo is a background image of the #header block which actually includes all of the top-of-page elements, not just the title segement. Given LiveJournal's HTML template, in order to accommodate both wide and narrow screen placements, I had to find a transition point at which the logo moves above the title text, and the right margin for the blog and post titles is removed. It's not a totally elegant solution, but it works sufficiently for me: I get my little branding element, and the text doesn't get horribly mangled.
If you are designing for the screen, pixels are your medium and you should be aware of them.
Pixels are an aspect of your medium. Not all pixels are created equal: they're not the same size, brightness, or color. Screens have hugely varying numbers of pixels, and can be resized pretty much at whim. Used to be you could rely on having at least 80 columns of text visible, with handheld devices, that's rarely a safe bet (reading the comp.risks digest, with its fixed-format presentation became all but impossible). I'd argue that ems and percents should be your principle units.
Where I use px it's for image padding (though I'm switching to ems for that), and border widths (though again, ems might actually make more sense, I'm just used to specifying 1-8px borders ...).
My point is that, for content, that is, text, your measurement should principally be about text. Your ems font sizing point has merits (well, except for your use of 14px for your font size), but you've got plenty of alternatives: smaller, medium, larger. Or absolute sizes: (though I'd suggest avoiding these): xx-small, x-small, small, medium, large, x-large, xxlarge. And realizing that '0.5em' is really saying "scale this to about 50% of normal text with" pretty much obviates your complaint that the typical character isn't 1em in width. Or, if you want a fixed relationship, percentages. I usually set my header tags at 150, 140, 130, 120, 115, 110, though I may bump that up (200% or 300% for major heads) or down (5% or smaller steps). And I'll often set these differently for header, article, aside, and footer elements (larger, normal, smaller, and smaller, typically).
Example of using ems for height and spacing is the drop caps on both my subreddit and Dreamwidth styles.
My focus on single-column layouts for text content (note that I actually like the multi-column mode for navigation and promotional elements -- when in sufficiently wide-screen displays) means that pixel-perfect placement is rarely an issue. I've also taken to styling navigation lists as "display: inline" or "display: inline-block" elements, several instances on the examples screenshotted at reddit, specifying inline-block gives you access to the :first-letter pseudo-element which you can see in the reddit menus on my personal subreddit http://www.reddit.com/r/dredmorbius. The inline styling means that you don't really have to worry about the width of the internal options -- they space themselves out appropriately.
And my use of margins plus padding means that you get both a fluid text box and a minimum guaranteed margin. 2em is tight but workable. This also means that you can set your default font for containers, say:
Setting a font size for the body (I actually usually set this smaller than my preferred reading font: 12pt for body, 15pt for the article, and possibly others for the header, aside, and footer elements (rarely below 10pt). This lets me set the overall page bounding in the #container segment (margins and padding), without skewing the overall widths of the other page elements, and preserving the option of individually scaling fonts and line heights within them. And if my padding widths are slightly off between header, article, aside, and footer, really, it's no big deal. The medium is inherently variable.As an example of where things go haywire with px-specific stylings, Google+ uses a really complex bit of HTML to render its post and comment scores. It includes independently placed "+", tens, ones, and rating button elements. And if you're not using precisely the font sizes Google assumes, the characters are horribly mis-aligned and clipped. I've had to fix this multiple times as G+ changed its classnames (some completely asinine CSS minifier/obfuscator they use). See here:
https://plus.google.com/104092656004159577193/posts/b4azoTVU...
I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.
Good practice there.
I swear to fucking god I'll shoot the next HTML monkey I lay my hands on who uses px for line heights, or fucks with letter spacing. It may just be with a squirt gun, but I'll shoot 'em.
The other factor to consider is that you also have access to the @media selectors which can key off of display size. I make use of this on my Dreamwidth blog, http://dredmorbius.dreamwidth.org/ The Kosmic Kat logo is a background image of the #header block which actually includes all of the top-of-page elements, not just the title segement. Given LiveJournal's HTML template, in order to accommodate both wide and narrow screen placements, I had to find a transition point at which the logo moves above the title text, and the right margin for the blog and post titles is removed. It's not a totally elegant solution, but it works sufficiently for me: I get my little branding element, and the text doesn't get horribly mangled.