W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: CSS and Type

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 09 Jan 2012 18:35:40 +0100
Message-ID: <4F0B256C.5060404@moonhenge.net>
To: www-style@w3.org
CC: Matthew Wilcox <mail@matthewwilcox.com>
> _The problems with CSS’s type functionality_
> Ignoring some of the typographic subtleties which CSS doesn’t handle so
> well there are two basic problems:
> 1) The way fonts are declared
> The programatic nature of CSS’s type implementation sits at odds with
> how type works. In particular, font substitution is a major stumbling
> block. In CSS we set a font-family as a list of possible fonts in order
> of declining preference. Then, usually in separate rules, we set things
> like font-sizes, weights, margins, and padding on HTML elements.
> The first problem with this method is the font-family list itself; it’s
> a pretty sad list because, almost by design, the default system fonts
> share little in common. Thus making “substitution of similar fonts”
> something of an impossibility.

Note that you can have a long list of fallback fonts.  A Web search for 
"css font stacks" returns numerous resources listing stacks of the form
font-family:'Bookman Old Style',Bookman,'URW Bookman L','Palatino 

> But the larger issue is that should a
> fallback font be in use it is highly likely that the apparent size of
> the font will be wrong, the baselines may not match up, and the
> relationship between the typeface and the measures we’ve defined will
> look wrong. That’s because all of those measures we set up are based on
> how our preferred typeface looks, and because the font-stack is unlikely
> to provide similar enough typefaces those measures are unlikely to work
> well with the substitute font.

This I fully sympathise with.

> 2) The lack of baseline control
> Much like in old-school physical print, CSS uses the em box as a unit of
> measure. When you set a size in CSS, it’s the size of the em box you’re
> actually setting. So far so good. Unfortunately CSS has little concept
> of a baseline, and that’s a problem - because although type is measured
> in em’s, it is not em boundaries to which type is aligned. It is
> alignment to the document’s baseline which is important. People dealing
> with physical mediums will offset the text to ensure that all text, no
> matter it’s size or different measures, hits that baseline correctly. We
> can’t.

You should clarify that CSS has little concept of a *document* baseline. 
  (In fact CSS21 has no such concept.  There is a Line Layout module[1] 
in CSS3 but it is severely outdated and I don't know if it has a current 

A font in CSS certainly has the concept of a baseline, though.  It can 
be thought of as one of the properties of every glyph.

> The extent of the control we have is using vertical-align, which
> defaults to baseline.

Indeed, all glyphs on a line are mutually baseline-aligned unless the 
author uses the 'vertical-align' property to change that behaviour.

> Unfortunately, vertical-align has no effect on any
> element that’s set to display block. Which includes paragraphs, lists,
> headings - all the stuff we care about.  It’s only of any use with things
> set inline or table-cell. Which doesn’t interest us much here.

But the vertical-align that you want isn't the same as the 
vertical-align that CSS possesses.  I presume you want vertical-align on 
blocks to enforce a baseline grid.  However, CSS's vertical-align 
wouldn't make any sense on blocks.  It's a different beast.  So it's not 
so much unfortunate that vertical-align has no effect on blocks; rather, 
you view it as unfortunate that it isn't the property that you wish it were.

> Another part of CSS’s baseline problem is that as soon as we insert some
> content that is not a multiple of the baseline all text that flows
> afterward is dislodged from the overall baseline. So, as soon as you
> include an image, video, or external resource the chances are very good
> that rest of your page will not align correctly. This would not happen
> in print.

This is indeed the case.

The lack of a document-level or even block-level baseline grid can be 

> _How I’d like CSS type handling to change_
> Fundamentally, the typeface should be the root of all other type related
> measures, not divorced from them. CSS should be able to set different
> values for margins, line-heights, paddings etc depending on the typeface
> that’s in use. That’s exactly what would happen in print if the designer
> was told to switch typeface - things would get re-flowed to suit the
> typeface rather than be straight out swapped, especially if the new
> typeface was a poor match for the preferred one.

Indeed.  (This would require a complete rethink about how the stack is 

> I’d also like CSS to be more aware of the baseline. I want my text to
> align to a given document or section baseline - so if I set the root
> element baseline to 26px all type should be offset by whatever is
> required to make the type’s baseline align with the root element’s
> baseline. CSS should also be able to cope when an image is inserted that
> isn’t a multiple of the baseline: text that wraps underneath should
> still align to the root baseline.

Hopefully the CSS3 Line Layout module will be revived at some point!

[1] http://www.w3.org/TR/css3-linebox/

Anton Prowse
Received on Monday, 9 January 2012 17:36:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:09 UTC