In recent years, as an off-shoot of the “web 2.0” movement, typography has really taken off and now plays a major role in web design. And font usage is also quite an important factor in CSS development — despite that it has not gotten to the point where any font can be used freely without some tricky, sometimes complex workarounds.
Font declarations and related properties in CSS are fairly straightforward to write in longhand. But there is a shorthand CSS property for declaring certain typographical properties that is well-supported across all common browsers, but a little quirky to work with. In this article I’ll describe how the css font shorthand property is used, how it can be misused, and what potential drawbacks there might be to including it in your CSS code.
CSS Font Properties in Longhand
First, here is a code segment that lists, with example values, all the font properties in longhand, so we can get an idea of what exactly we’ll be dealing with when we condense these same properties into one font declaration in our CSS code.
body {
font-family: Arial, Helvetica, sans-serif;
font-size: 13px;
font-weight: normal;
font-variant: small-caps;
font-style: italic;
line-height: 150%;
}
There are other typography-related CSS properties, such as text-align and letter-spacing, but the ones I’ve listed above are specifically the 6 properties that can be included in a font shorthand declaration.
How the Shorthand Property is Declared
If we wanted to condense the above code into one line using the font shorthand method, we would use the following syntax:
body {
font: font-style font-variant font-weight font-size/line-height font-family;
}
So, keeping with the values we used above, here is how our new lean CSS code block would look:
body {
font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
}
At first glance, you’ll notice the savings in typed code, since we’ve condensed 6 lines of code into just 1.
Some Things to Keep in Mind
As mentioned, the font shorthand property is a little bit quirky and, to the inexperienced, can be quite puzzling. For example, take the following code block:
body {
font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
}
p {
font: small-caps normal 13px/150% Arial, Helvetica, sans-serif;
}
With the above CSS, we’ve declared 6 typographic properties and values on the <body> element, then declared the same properties and values on the <p> element — except we’ve removed the reference to “italic”.
Your first thought might be that this means the <p> element will still have italicized text, because it will inherit that value from the <body>, but this is not the case. In this case, all <p> elements will have their font-style property reset to “normal” due to the fact that it was omitted from the shorthand declaration.
The font-style, font-variant, and font-weight are all optional values. If they are included, they must be placed before the font-size. But if one or more are omitted, they do not default to the value of their parent; their value will default to the initial value for each property. Of course, if you delete the entire shorthand declaration, then normal CSS inheritance will take place.
Omitted Mandatory Values
If you omit the font-size or font-family values in the shorthand declaration, the entire line of code will become null in relation to its application of styles. In other words, in the following code block, the <p> element will inherit all the styles applied to the <body>, because the font declaration for the <p> tag does not have all the mandatory elements, and so the entire line is nullified:
body {
font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
}
p {
font: normal normal 23px/250%;
}
And the same would result if we removed the font-size. (Although in this case, we would have to remove both font-size and line-height, otherwise the line-height value would become the font-size value.)
Finally, if you want to declare a line-height, as shown in all the examples above, simply place the desired value immediately after the font-size value, with a slash in between.
The Order of the Values Matters
I’ve already touched on the order of the values, but it’s worth emphasizing. If you don’t put the values in the correct order, at best you will get unpredictable results. At worst, you will make the entire line of CSS null. So, to ensure the shorthand declaration is working, the order of the values must be as follows:
- Any or none of the optional values, in the preferred order: style, variant, weight
- font-size
- optional line-height, following a slash
- font-family
Thus, you cannot put the font-family at the beginning of the declaration, nor can you put the 3 optional values at the end. This is different from the background shorthand property in which the order of the declared values doesn’t matter.
Special Keywords to Inherit System Fonts
A very interesting method of declaring your font in even shorter shorthand is to use special keywords that will allow the styled element to inherit the typographic properties present in controls and other objects of the user’s system. I’ve never used this method before and honestly cannot think of a practical use for it, but here are the 6 optional keywords available for its use:
body {
font: caption;
}
.header {
font: icon;
}
.article {
font: menu;
}
p {
font: message-box;
}
.meta {
font: small-caption;
}
.footer {
font: status-bar;
}
The elements styled in the above code will inherit the typographical properties used in the respective system controls and objects signified by the various keywords. Again, I don’t see much of a use for this, and I have never actually heard of it being used, but it is a legitimate CSS application of the font shorthand property, and evidently is supported across all current browsers.
Drawbacks of the Shorthand Method
While the obvious seemingly simplified CSS code can make the font shorthand property seem quite attractive, in all honesty, I think it is a fairly overrated method of declaring these 6 typographic values.
First, it is not as easy to read and edit as is 6 clear lines of code with definite descriptions. Second, if you’re using a CSS editor that provides auto complete drop-down options, all the options for the font shorthand will be grouped together, which could slow you down a little bit. Third, with today’s much faster internet speeds, a 5-line difference per font declaration isn’t really all that much, especially when you factor in the extra length of the one line of shorthand code. So the ease of use will likely outweight any kilobytes in bandwidth savings. Finally, the possibility for typos and errors is much greater in the shorthand method, making the traditional method even more appealing.
Summary
So, as it stands, for the reasons stated above, I personally will be unlikely to be using the font shorthand declaration in any project. But now that you are aware of it, what do you think? Do you use it often? Are its quirks worth the effort?
First off, great write-up! Covers everything in a clear way that should be easy for anybody to understand.
Like you, though, I don’t see myself using the shorthand for font. I’ll still use shorthand for background, border, margin, etc. For some reason, it just seems like those shorthand properties go in a much more readable order than what the font one’s do.
There’s a YUI video with Nate Koechley where he recommends against using the ‘font’ shorthand property due to inconsistencies in browser implementations. Fast forward to about 13:40 of the video here: http://yuiblog.com/blog/2007/10/29/video-koechley/
@Andy Ford:
Thank you, that looks like an interesting video. Actually, I think you meant 31:40, that’s where he discusses font shorthand.
And what he says about the font shorthand property is pretty much what I’ve said in this article. But I think he may be slightly incorrect. He seems to suggest that only certain browsers will break when mandatory values are omitted, but my understanding is that all browsers will break the same way, and as long as its declared properly it will render just fine on all browsers.
“Your first thought might be that this means the element will still have italicized text, because it will inherit that value from the , but this is not the case. In this case, all elements will have their font-style property reset to “normal” due to the fact that it was omitted from the shorthand declaration.”
Now that I’ll admit I didn’t realize; I’ve always written certain properties in short-hand, such as background properties, borders, and (to some extent) fonts; I didn’t realize that shorthand could also reset properties – that’s definitely something to keep in mind while debugging/editing code. Definitely a post I’d bookmark – while most shorthand is pretty straight-forward, I have to admit from experience that the font declarations can be pretty tricky.
I have that ‘font’ shorthand sequence printed out. Stick it on an overhead board. Right in front of me. I don’t know about you but I could never remember font shorthand.
@Impressive Web – Good catch. It is indeed 31:40 and not 13:40 (oops!). Nate left it very ambiguous by not naming any specific browsers but I can only imagine that he and the YUI folks investigated it on more browser/environment configurations than me!
Like you, I’m not a fan of the ‘font’ shorthand because of the drawbacks you outlined. I think there’s also a risk of handing off CSS files to less experienced developers who may not fully understand the ‘font’ shorthand.
I also think the same could be said about the ‘background’ shorthand but to a lesser extent. However – unlike ‘font’ – I use the ‘background’ shorthand extensively.
I use CSS shorthand pretty much everywhere except in the font property. The first is the issues you and Andy were discussing. The 2nd is simply I don’t like the way it looks, I think it looks disorganized. I also believe you can’t include the color in the css font shorthand, so you have to have a separate line for that anyway. And like Andy said, if you hand it off to people who might not know as much CSS, there can be a problem there.
When writing my CSS, I like to go line by line for each property. For me, it helps to read everything cleanly. So when I write all the font properties, I keep them all on the same line.
I love the shorthand. It’s just like all things, either you know how to use it or not.
For example you want to make all headings in a special section stand less out:
#comments h3 {
font: inherit;
font-weight: bold;
}
This is just elegant. This is just tidy. Imagine doing this without the shorthand.
Thanks for a fairly in-depth look into font: .
I usually just rock two css files for my wordpress themes, style.css and fontface.css. Naturally that leads to a lot to scroll through, so it’s definitively nice to use shorthand techniques to make my code less bloated. :)
Nice and clean writing. I understand it very well. I wasn’t aware of such things before.
and I’m trying to write a CSS editor.
Site is bookmarked.
Thank you
I believe you are mistaken when you say:
Instead, they will always default to “normal” regardless of the “initial value.” For example, h1 usually has an initial value of bold, but the following will reset it to normal (not bold):
This is a bit of an older article and I don’t think my explanation was great. But technically you’re not really correct in what you’re saying. The styles the browser adds are not the “initial” values that I’m referring to. What I’m trying to say in the article (which I may not have understood at the time) is that the optional properties will themselves be reset to “normal”.
The browser adds “bold” to heading elements, but that has nothing to do with the value of (for example) the
font-weightproperty. That property has an initial value of “normal” at all times but the browser changes that with its own stylesheet (which is why many use a reset).But I’ll see about changing the wording on that, just to be more clear. Thanks for pointing that out.