Obligatory history lesson:

'em' is a classical typographical term to talk about relative
measurements within a typeface: it's the phoneticisation of the letter
'm', and denotes the total width of the 'm' glyph. 'en' is used for
'n'; other useful relative measurements include 'x-height' to denote
the upper edge of 'straight' lowercase letters relative to the
baseline.

In digital typography, it's a lot more vague. For one, it is no longer
intended for internal measurements of the typeface, rather the
relative font-size — and whether set in pixels, picas, or whatever,
font-size is a little arbitrary: all measurable aspects of the glyphs
'M' or 'm' (or indeed any other glyph) set in Arial are smaller than
12px; with Calibri they are smaller still.

The purpose of em-based sizing on the web is to provide a relative
font-size: h1 {font-size: 2em} will make top-level headings twice as
big as the default font-size. An irritating aspect is that the default
font-size I mentioned is subject to other ems. If that h1 is inside a
div with font-size: 2em, it will end up four times larger than the
base.

This is useful because certain screens have higher pixel densities
(12px-sized fonts are fine on my 96ppi desktop but illegible on my
326ppi phone), and some people, particularly those with bad sight, may
prefer different resolutions for type.


Practically speaking:

I don't see a convincing argument for having layout elements infer
their size based on font-size. I tried this once, and ended up with
30em as a total width that worked well on desktop with my base
font-size of 12-pixels — but for those people who need higher
resolution base heights, this is a disaster: the layout requires
massive panning left and right to be able to make sense of it
(especially on the phone, which has pretty limited screen size).
Better keep the font-size based on the em, but keep the layout
measurements fixed or fluid based on fractions of the viewport (%).

If you're not interested in any of these aspects, use pixels: they're
precise, unambiguous, and suffer none of the headaches of the cascade.


Regards,
Barney Carroll

barney.carr...@gmail.com
+44 7429 177278

barneycarroll.com
______________________________________________________________________
css-discuss [css-d@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Reply via email to