meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 17 December 2012

Where to Avoid CSS Hyphenation

Last week, I asked “Should You Hyphenate?”  This week, I’m going to assume that you decided to answer in the affirmative and talk about some good practices (I don’t know if they’re best practices just yet).  This post was actually triggered by a comment from Kevin Hamilton on last week’s post.  He said, in part:

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… Is it re-peating-linear-gradient? Or perhaps repeating-lin-ear-gradient?

He’s absolutely right, of course.  If you’re going to blog about technical topics, or even if you’re just writing a style sheet that you expect to release into the wild for use by anyone, there are some elements that you should avoid hyphenating.  And since hyphens is an inherited property, it isn’t sufficient to set it for a limited number of elements and assume you’re done.  You have to make sure you’ve turned it off for the elements that shouldn’t be hyphenated.

In my opinion, those elements are:

Yes, most of those are old and obscure and in some cases (massively) deprecated, but they’re all elements that could be hanging around on a web site and by their nature shouldn’t have their content hyphenated.  I mean, I would hope that a browser would recognize not to hyphenate an acronym or abbreviation element, but who knows?  Maybe ZOMGWTFBBQROFLMFAOCOPTER has enough word-like strings to qualify for hyphenation in some hyphenation dictionaries.  (Or not.)

“So what about pre?” you ask.  A very good question.  I rate that as a solid “maybe”.  For most uses of pre, the content won’t line-wrap anyway thanks to white-space: pre, so it’s a moot point.  However, if a pre has been set to white-space of pre-wrap, pre-line, or even normal, then hyphenation may well kick in.

At that point, the question is what kind of content the pre contains.  It apparently is no longer meant to be rigidly preformatted, as the element name would imply, so what is it?  If it’s a code block, there should already be a code element present within the pre, so suppressing hyphenation for code will be sufficient.  Ditto if it’s an example of user input (kbd), program output (samp), and so on.  This is why semantic markup matters.  It’s why, if you’ve been using it all along, you can make fine-grained choices here.

Of course, lots of people weren’t as forward-looking as you and anyway nobody’s perfect, so it’s probably a good idea to switch off hyphenation for pre, just in case the more semantic elements were left out.

There are similar questions to confront regarding q and blockquote.  If you’re quoting someone, almost certainly something that someone wrote, is it advisable to hyphenate that text when they didn’t?  I’m honestly not sure if it matters or not.  I’ve personally suppressed hyphenation in those cases, but I did that purely on instinct and I’d love to know what content and typography specialists think of that question.  (Be polite, please.  We’re all learning here.)

For the last interesting question, what about auto-linked URLs?  If we suppress hyphenation for all links, then that solves one problem to introduce another.  What I have noticed is that if you drag-select CSS-hyphenated text, the auto-generated hyphen(s) and line break(s) are ignored when you copy the text.  You just get the original.  That’s why I don’t think it’s really necessary to suppress hyphenation on the a element, though I’m willing to change my mind in the presence of new evidence.

Thus, at the moment, meyerweb’s base style sheet contains the following:

body {hyphens: auto;}
code, var, kbd, samp, tt, dir, listing, plaintext, xmp,
      abbr, acronym, blockquote, q {hyphens: none;}

I may adjust those rules over time, but that’s where I’ve landed.

Update 18 Dec 12: I should make it more clear that this post is intended to be a starting point, not the final word.  I’m not proposing that these are all the elements on which one should ever suppress hyphenation, full stop, end of discussion.  There may well be others, like form labels and textareas and text inputs and so forth, that should also be excluded.  (Though I kind of enjoy watching my text input get auto-hyphenated as I type.  It’s a little surreal.)  Hopefully, this post will get people thinking about exactly how authors should handle hyphenation if they do choose to put it in place, and eventually help us figure out some solid best practices.

December 2012
SMTWTFS
November February
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Archives

Feeds

Extras