Should You Hyphenate?Published 10 years, 5 months past
A couple of weeks back, PPK posted about the sudden emergence of CSS hyphenation support in several browsers (which got picked up by WebMonkey, the lucky dog). At the time, there was some confusion about whether a
lang attribute it required to allow the hyphenation to happen — PPK said it did, but my testing indicated the opposite.
Well, it turned out that at the moment I did that test, I was running Firefox 16, and FF16 apparently honored the
-moz-hyphens property with nary
lang a attribute in sight. We might ask how that’s supposed to work, since hyphenation dictionaries are language-dependent, but never mind: it did. Firefox 17, on the other hand, requires a
lang attribute value in order to apply
hyphens (note the lack of prefix).
I haven’t gone running down the behavior of other browsers, because the upshot is this: if you want hyphenation to work in a future-friendly way, you need a
lang attribute. What older versions do will become of fading relevance.
All of which raises a fairly important question: should you enable hyphenation?
After all, hyphenation, I am told, was invented to increase the density of text and reduce the number of column inches needed in printed media, where paper can be expensive and space at a premium. Hyphenation, in other words, was devised as a trick to let authors be a little bit more wordy. (Also as a way to help reduce interword spacing in fully justified text.)
On the web, of course, we have no physical length constraints: The Web Ain’t Print. We can run on as long as we like, limited only by our thesaurus, our RSI flare-ups, and the attention span of our readers.
But wait…that’s all true for the desktop web. We have lovely big monitors and easily resizeable windows and zoomable text. On mobile devices, however, the real estate is much more limited. We still have infinite length, yes, but line lengths tend to be a lot shorter on iPhone or Android — particularly if you’ve given your mobile users a nicely readble font size.
Right after PPK’s article hit my aggregator, I turned on hyphenation here on meyerweb. For desktop reading, at first it caught my eye a bit, but now I don’t see it at all. Years and years of print reading has made it seem familiar. Things would be just fine without the hyphens, of course. But when reading pages on mobile, the hyphens feel useful. They give me a little bit more reading for each “screenful”, and just feel comfortable.
Thus my recommendation of the moment: if you’re going to use CSS hyphenation, turn it on for mobile contexts. For desktop — well, that’s a much murkier call. It may well depend on your font family, layout, default language, and so on. If you do turn them on, just make sure you have that
lang attribute (I put mine on the
html element) so your hyphens will persist.
The only rebuttal I would have for the mobile argument is for non-mobile optimised sites, where users will have to pan more to complete single words from one side of a sentence to another. Not a problem for a responsive site where no sentence/paragraph is wider than the viewport, however.
Russell, that’s exactly what I meant: responsive sites. Although even in meyerweb’s 2005-era positioning-based responsiveness, which not quite what we think of today as Being Responsive, the hyphens worked out pretty well. Most sites that shovel the desktop layout into a mobile device won’t fare as well, I suspect.
I like the use of hyphenation for the reason you outline. Having started in print media over ten years ago, my preferences for the controls that print gives authors leads me to think that the same controls should be coming down the pike for web authors as well.
I’m talking about minimum letters before a hyphen, minimum letters after a hyphen, max number of hyphens in a row, whether or not to break capitalized words, and avoiding breaking the last word in a paragraph to create a nasty orphan. Users of software like InDesign would be familiar with these common “H&Js”.
@page media types have orphans and widow declarations, but those reference the first and last lines of paragraphs, not hyphenation preferences. How long before we get more control over hyphenation, I wonder?
Eric, are you sure hyphenation was invented for the reason you mentioned? I always thought it was invented to avoid having reams of whitespace between words, which hinder readability. Hyphenated text is much more readable. Enabling authors to be more wordy sounds more like a useful side-effect to me.
Prince XML has hyphenate-patterns (to specific the breaking algorithm), hyphenate-after (how many characters minimum after the break), hyphenate-before (min characters before the break), and hyphenate-lines (max hyphenations in a row). In general, Prince has some of the best CSS typographical support in the business.
Lea, that’s also true for justified text, as I mentioned in the parenthetical. But I’m pretty sure (though I’m no expert) that whether justified or no, hyphenation let you get more text per line of text, especially in narrow columns like in newspapers.
Webkit also needs the lang attribute, afaict (I always set it on the root element as a rule anyway). It is still not turned on in Chrome, fwiw.
As for the question of better, fine-grained control raised by J. Hogue above, CSS4 text will have additional properties:
As a non-native english speaker, I can say that hyphenation makes it more difficult form me to read the text. I have to somehow reconstruct the word in my head before understanding.
This is most probably due to my lack of reading english books, I learnt mostly english on the web where hyphenation didn’t exist until recently ;)
Just my 2 cents..
Probably an issue for users with a lower reading age or lower literacy, as well as non-native speakers?
Reading your article on desktop felt awkward to me. I am out of practice with tracking from a hyphenated line end to a mid-word line start.
Seeing “exam-ple” wrapped so that “ple” is the only bold part of the text just below the “Your Comment” box looks especially weird.
Following along that line I see “comment—espe-cially” which also looks pretty odd.
The print designers I work with would want to typeset those area manually to avoid the hyphen.
Tested with Firefox 188.8.131.52 in Windows 7.
Eric – You may want to exclude hyphenation on <code> tags within your blog. For both readability purposes (since many CSS tags already make heavy use of hyphens) and to avoid introducing some confusing/misleading references, for example in this article:
Is it re-peating-linear-gradient? Or perhaps repeating-lin-ear-gradient?
I also noticed the instructions for commenting offered me a <del date-time=””>, where that attribute should simply be “datetime” (no hyphen).
I also just tested against my comment above and was able to get it to be displayed as “http://meyerweb.com/eric/thoughts/2012/05/31/gradient-repeti-tion/” which I find a bit jarring.
I don’t know that you can easily fix this, because an <a> tag may contain a URL which you may not want to be hyphenated, or may contain text which you would want to be hyphenated.
Excellent point, Kevin. I just suppressed it for
kbd(as I had been for
blockquote). I can only imagine what might happen if a stray hyphen got into a
kbd-wrapped Unix command line example!
Some links for light reading (18/12/12) | Max Design
[…] Should You Hyphenate? […]
As a side note, I experienced a weird behavior in Safari on a page that included this declaration (“hyphens”). It broke the styling of paragraphs styled with “white-space:nowrap” as the text in these paragraphs did wrap :-(
Who are we kidding? Since when did hyphenation help readability? Can you find one study to back this up? When I say readability, I mean actually reading the text, not just glancing at the layout and saying “ah that looks more readable”, pleasant maybe, readable no.
I often notice myself mentally reconstructing hyphenated words to understand them. I don’t think I’d consciously be aware of that if hyphenation was truly more readable.
In handwriting, hyphenation is rare. In young children’s books, hyphenation is not used. Hyphenation only exists to cut costs.
So save it for media=”print” CSS.