Categories
Design

CSS Needs Better Typography Controls

I think it’s about time the WWW started getting better typography controls in CSS. If you look at what typography designers can do in print applications like InDesign, the typography capabilities in CSS are still relatively primitive especially in the context of responsive design.

In the late 90’s as a beginning web designer, I would always have to tell my boss (a very experienced typography designer) that the things she wanted to do with type just wasn’t possible.  It’s now 2022 and many of those things still aren’t possible (though we do have web fonts now at least.) I’ve been waiting for decades for some of these typography controls to come to CSS standards and web browsers, so maybe if I describe them properly, someone will notice.  (Now this is also on the CSS working group Github.)

Runts

CSS still has no runt controls. A runt is when a paragraph ends with one word on one line. It’s very ugly. In print design software, we can fix this procedurally by selecting the last X number of characters using a GREP style and applying a no-break attribute to them. So if I set the last 15 characters to no-break in a paragraph, that will make the last 2 or 3 words stay together and therefore stay on the last line no matter what the container’s width becomes. This is not possible in CSS, but I think it should be.

The syntax could be something like:

p:nth-last-char(15) – selects the last 15 characters of a paragraph.

p:nth-first-char(15) – selects the first 15 characters of a paragraph

Then we could have something like below that applies the nowrap white-space attribute to the last 15 characters of a paragraph:

p:nth-last-char(15) { white-space: nowrap; }
/* keeps the last 15 characters of a paragraph from wrapping to another line */

One current work around for this is to add a </br> break tag before the last two or three words in a paragraph and use media query breakpoints to apply “display: none” to the </br> tag in instances where the paragraph width does not create widows on the last line. This requires manually adding the BR tag to content in the database and also requires manually measuring which media query breakpoints should activate or deactivate the work-around. That’s way too much work for something that can be automatic with a GREP rule in InDesign.

With InDesign, I can use GREP styles to apply a “nobreak” character style attribute to the last 15 characters in order to fix the widows in all paragraphs.

Paragraph composer

Another issue in WWW typography is in the ragging of text on each line. There are no decent controls for this.  With InDesign, I can choose from different automatic paragraph composer settings and then I can tweak the minimum and maximum variations for things like word spacing, letter spacing, and glyph scaling.

Paragraph line ragging on the web often looks like this with huge imbalances between line lengths. This is extremely ugly in terms of typography design and reduces readability.
InDesign’s paragraph justification style options let me assign max/min word spacing, letter spacing, and glyph scaling percentages such that paragraph text will be adjusted accordingly.

The syntax could be something like:

p { paragraph-composer: multi-line-composer;

 word-spacing: mindesiredmax(80%, 100%, 110%);

letter-spacing: mindesiredmax(-5%, 0%, 5%);

glyph-scaling: mindesiredmax(90%, 100%, 110%); }

The CSS word-spacing property already exists, but doesn’t support any minimum/maximum variations within a multi-line paragraph composer. The CSS letter-spacing property also exists, but again doesn’t allow for variations within a paragraph according to the paragraph’s line ragging. There are no glyph scaling properties in CSS.

A balanced rag between lines in a paragraph is ideal in terms of typography and this is done by increasing or decreasing word spacing, letter spacing, and glyph scaling on a line-by-line basis in order to decrease the differences in line widths and make a more pleasing paragraph shape.

Sentence Spacing

Nobody does good sentence spacing in typography design anymore, so very few people probably even know about this aspect of typography design. Many people these days follow the convention of including only one space between sentences. For paragraphs with shorter sentences, this reduces the number of visual “pigeon holes” that may clutter the paragraph. However, with longer paragraphs filled with longer sentences, the single space between sentences makes the paragraph more difficult to read. Thus the smart way of typography design is to increase the space between sentences within longer paragraphs, while reducing the sentence space between shorter paragraphs.

See the advice given by Philip Luckombe in The History and Art of Printing (London, 1771):

Another rule that is inculcated into beginners, is, to use an m quadrat [i.e., an em-quad] after a Full-point [period]: but at the same time they should be informed, not to do it, where an Author is too sententious, and makes several short periods [sentences] in one Paragraph.  In such case the many Blanks of m-quadrats will be contemptuously called Pigeon-holes; which, and other such trifles, often betray a Compositor’s judgment, who may be a good workman else.

Also see: Why two spaces after a period isn’t wrong (or, the lies typographers tell about history) – Heraclitean River (archive.org)

I’m not sure what the syntax for a sentence spacing control should be as ideally we should have selectors to control shorter sentences separately from longer sentences. Perhaps the selectors can be defined by sentence character count.  Currently we have no CSS selector for sentences at all, nor do we have any attribute for controlling the space between sentences. Maybe something like

p:sentence-char-count(minmax(3, 30)) { sentence-space: 1em; }
/* selects sentences with 3 to 30 characters, applies 1em of space between sentences. /*
p:sentence-char-count(minmax(31, auto)) { sentence-space: 1.5em; }
/* selects sentences with minimum of 31 characters and no maximum, applies 1.5em of space between sentences. /*

Who else is sick of bad typography?

Do the people in charge of creating new CSS standards just not know about good typography design? At the very least, I wish all of the typography controls available in InDesign were also available in CSS with future web browsers. The web has been the future of publishing since the turn of the century, but typography design on the web isn’t even up to speed with the 16th century.

See the related CSS GitHub Issue.