- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 09 Jan 2012 18:35:40 +0100
- 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 Linotype',serif; > 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 editor.) 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 frustrating. > _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 defined.) > 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/ Cheers, Anton Prowse http://dev.moonhenge.net
Received on Monday, 9 January 2012 17:36:12 UTC