Word-flow on the Web
Managing widows, orphans, ragging, line-breaks and readability online hasn’t historically been as easy as in-print. Here’s how I implement my print-design background into text on the web. For the record, I will be ignoring hacks such as <WBR> and ​ tags because they’re not future-proof — I don’t want to go back and painstakingly change my markup later — this has to work forever. And CSS orphans and widows — according to the spec, sadly — are only for use in ‘paged’ content, such as @media print, so I’ll be ignoring those too.
The Problems
First, we’ll examine each problem one at a time. Widows and orphans are just the beginning — we will dive into line-lengths and ‘ragging’ for a more whole look at readability.
Widows & orphans
Wikipedia defines a widow thusly:
“A paragraph-ending line that falls at the beginning of the following page or column, thus separated from the rest of the text.”
Wikipedia defines an orphan thusly:
“A paragraph-opening line that appears by itself at the bottom of a page or column.”
“A word, part of a word, or very short line that appears by itself at the end of a paragraph. Orphans result in too much white space between paragraphs or at the bottom of a page.”
En-dash & Em-dash
In my opinion, there’s nothing uglier than an — or – preceding the last word on a line — kinda
like this.
I prefer to use and .nowrap to set guidelines for how these areas are allowed to wrap. Again, it’s a personal preference, but I think that ‘padding’ — and – with a word or two makes readability flow better. That’s why I typically disallow them from only having a single word preceding or succeeding them in a sentence. This goes for other less common punctuations which tend to start or finish a sentence or phrase, such as … (ellipses). Personally, I don’t mind if an &mdash; or … end a line, but I don’t like when there’s a single word succeeding or preceding them on a line… so I’ll put an between the two succeeding and preceding words.
Readability
This is a little more ethereal, and open to personal taste and preference. I’ll talk through my own preferences, and how I code HTML text to make them happen.
Readability is the cumulative effect of how words (and their ideas), line-length, line-breaks, font and general typography interplay to create an overall experience.
This is why I keep saying that a lot of these things are subjective — they depend upon the ideas being conveyed in the text, the general ‘feel’ of the flow and the typographical specifics being employed. When in doubt, use your intuition, and play a lot. The best way to ‘break’ your text flow is to change the container size (which will affect each line’s character count) and see what happens. Fix whatever you don’t like.
The Solutions
Here are the short, simple and future-proof solutions that I use when hand-crafting text on the web.
Non-breaking space
Oh the glorious — it is the single most useful character entity when controlling readability on the web. We would all do well to get to know it better.
Traditionally for those bothering to control their web typography, people have used between the last two words at the end of each sentence to prevent orphans. For me personally, I hate word hyphenation in-general. I think it adversely affects readability, so I put s between both the last two words in a sentence, as well as the first two.This prevents a sentence starting with a single word on a single line, and in my opinion, improves readability.
Here’s an example of how this sentence is coded:
Here’s an example of how this sentence is coded:CSS white-space
The CSS white-space property is your friend. Why not just use ? Because of hyphens; while old Windows specifications had a character for non-breaking-hyphens, it’s thing of the past, and there is no modern equivalent. Because of , there are specific cases when a CSS class should be used, and sparingly. In my opinion, the two legitimate use-cases for a specific CSS class are the following scenarios:
- A hyphenated word ends a sentence
- You don’t want a specific hyphenated word to ever be at a line-break
Personally, I don’t like to ever allow hyphenated words to line-break. Here’s an example of how I’ve coded the previous sentence:
Personally, I don’t like to ever allow hyphenated words to <span class=”nowrap”>line-break</span>.My CSS class looks like this:
.nowrap { white-space: nowrap }Notice that I didn’t put an between “to” and “line-break“. In my opinion, it doesn’t look strange or adversely affect readability to have just the hyphenated word “line-break” as (technically) an orphan — because it is comprised of two words. However, if the hyphenated word was, for example, “so-so“, then I might be inclined to add that preceding because “so-so” is quite short.
Line length & Ragging
As perhaps the most important rule of readability, line lengths should be around 55 characters (including spaces), with a +/- of 10 depending upon your font, line-height and other typographical attributes. When designing for web nowadays, this is not as easy as it sounds — you need to watch for how mobile browsers are automatically resizing your text. Use a ‘reset’ stylesheet such as normalize.css to level the playing field, and then CSS @media queries to adjust for mobile browsers.
Most of the time, it’s simply a case of watching the container width of a paragraph (or other block of text) to roughly control character count on a given line. But sometimes it’s more complicated — such as in the case of a ‘responsive’ website which changes the size of containers according to screen real-estate.
Ragging is a lesser-known term in the web industry that comes from print design. It refers to the aesthetic balance of line endings, and how they interplay in a single paragraph. Generally-speaking, print designers want an aesthetic balance from line-to-line so that there aren’t jarring white-spaces on the right of each paragraph (assuming your paragraphs are left-aligned).
Ragging is more difficult to control in web (compared to print) because in web, we’re forced to hand-craft each line of HTML code in order to get the result we want, whereas in print design, common software like Adobe InDesign is arguably smarter in how styles can be applied globally. While CSS is supposed to let us do this, it’s not there yet, and the few attributes we do have access to are not yet widely implemented.
Questions
A few relevant CSS attributes have been added to the spec since CSS2. These properties are: hyphens, word-wrap and word-break.
hyphens: none | manual | autoword-wrap: normal | break-word | initial | inheritword-break: normal | break-all | keep-all | initial | inherit<pre>These lines will be pre-formatted</pre>.
Why I don’t use these
I’ve experimented with these extensively, and unfortunately my outcome is that browser support and consistent implementation just isn’t there enough to use them reliably, yet. But due to my own personal preferences of typography, I don’t even need them. It would be nice to not have to use and my .nowrap class everywhere, but at least I know those are going to remain consistently implemented.
Compared to print software
For ragging, it’s interesting to note features such as balance ragged lines (Adobe InDesign) in print software which performs some magic to improve ragging. In the web world, we don’t have a standard equivalent without resorting to javascript. The only 3rd-party implementation I’ve ever used is Shaun Inman’s Widon’t WordPress plugin. While this was a great solution to lessen the frequency of widows, it doesn’t allow for the type of fine-grain typographical control I’m accustomed to from my print days. Until these newer CSS attributes are consistently implemented across browser, I’ll continue with the scheme I describe above.
Why not use <pre>?
I don’t use <pre> (as opposed to .nowrap) because most browsers have default styling for it — it has overgrown its’ original use. 99% of the time I don’t want any of that styling, and there’s no use in battling the browser for it. In my opinion, a CSS class is a more semantic way to accomplish this task.
Summary: The flow concept
The general idea is that you want to picture the flow of text in your head as you code… and this takes a little getting used to. As you code, think about where you want line-breaks to happen, and where you don’t. Like in the above paragraph example, notice that I put an in-between “lazy” and “dog” right before my … — I decided I didn’t want a line-break right there, because the flow of readability might be affected.
While you can get away with just implementing the rules described above, the best readability on the web will come from a combination of rules and intuition — just like all the best book layouts. Don’t think about what your text looks like when you’re viewing it, but rather know that the layout will change from device to device. This means you’re only controlling flow.
Originally published at chrislorensson.com.
