This morning I caught a pointer to TypeButter, which is a jQuery library that does “optical kerning” in an attempt to improve the appearance of type. I’m not going to get into its design utility because I’m not qualified; I only notice kerning either when it’s set insanely wide or when it crosses over into keming. I suppose I’ve been looking at web type for so many years, it looks normal to me now. (Well, almost normal, but I’m not going to get into my personal typographic idiosyncrasies now.)
My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts
kern elements with inline
style attributes that bear
letter-spacing values. Not
kern elements. No, you didn’t miss an HTML5 news bite; there is no
kern element, nor am I aware of a plan for one. TypeButter basically invents a specific-purpose element.
I believe I understand the reasoning. Had they used
span, they would’ve likely tripped over existing author styles that apply to
span. Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way. Because the markup is script-generated, markup validation services don’t throw conniption fits. There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.
The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future
kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s
kerns. The currently accepted way to avoid that sort of problem is to prefix with
x-, as in
x-kern. Personally, I find it deeply unlikely that there will ever be an official
kern element; it’s too presentationally focused. But, of course, one never knows.
If TypeButter shifted to generating
x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof. It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet. It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more. Settling on some community best practices could save us some trouble down the road.
Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details. That throws a fairly large wrench into the gears, and requires further contemplation.