CodeinWP CodeinWP

Screencast: Why You Shouldn’t Use CSS Font Shorthand

Screencast: Why You Shouldn't Use CSS Font ShorthandStarting today, and pending the work involved and subsequent success/failure, I will be regularly posting screencasts on Impressive Webs. Most of my writing time is spent authoring stuff for Smashing Magazine and Web Designer Depot of late, so I thought, as a change of pace, I could start doing some screencasts for my own site.

The inspiration for this idea, naturally, comes from the screencasts on Nettuts and CSS-Tricks. Jeffrey Way and Chris Coyier have been doing screencasts for quite some time, and I definitely have to give credit to them for the inspiration. I’ve especially enjoyed Jeffrey’s recent video quick tips on Nettuts.

This screencast is discussing the CSS Font shorthand property, and why I don’t think it should be used.

I hope the sound and video quality are acceptable. Let me know what you think — and be nice, it’s my first screencast!

35 Responses

  1. Good points. A couple (hopefully not too) critical points:

    Vid quality could have been better. It’s hard to read some of that even at fullscreen.
    Volume seemed quiet.
    Maybe state some of your points early in the video. Viewer had to make it halfway through the video before you start on why it’s a bad idea to use the shorthand version.

    Good stuff though, keep em coming!

    • Hey Dean,

      Thanks for the tips. I definitely have to try a better quality next time, as I did notice the problem with viewing the code. In this particular case it wasn’t as crucial, but I’ll have to experiment with different quality in future screencasts and see how it goes.

      And the sound was a little puzzling to me as to why it was quiet, so I’ll have to experiment with that as well. I think my mic settings/levels were too low because I was trying to avoid voice distortion.


  2. You have good points presented here, but I think it’s up to the experience of the designer. you said it yourself, a experienced designers would know, but a beginner …. “donde esta la biblioteca” . But when we speak of the functionality, the purpose of the code (loading faster), isn’t shorthand coding better ?

  3. I agree.
    I have never taken the habits to use font shorthand, whereas I conctantly use the others shorthands. And the reason is probably one of the point you mention, why do we have to start with font-weight and finish with font-family, it’s illogical to me ?
    So I don’t think, I’ll ever use it.

    Good arguments in this video.

    • Damian Muti says:

      Personally i disagree with this.
      If we think in that way, we must wonder why we should keep an order in the margin/padding shorthands aswel, and nobody does. To keep an order is a good way to help manteinance.
      I agree with Marty about his final question.

      Good screencast anyways, mate :)

      • Thanks, Damian. Glad you enjoyed it.

        Regarding the order of the shorthand values: You’re right, order is good, but with shorthand there is no logic to the order. It almost seems anti-logical. And the fact that some are required and others aren’t, combined with the inheritance issue, just really makes it not worth the trouble.

        I think the only instance where it would be acceptable and preferred to use font shorthand is if you’re working for a big design agency and you know that anyone else that works on your code is going to be an expert CSS developer. In that case, I think it’s acceptable.

  4. Rob says:

    Rarely do I get anything out of screencasts. I’ve never seen one I liked and didn’t bother to look at this one. A second problem is you can’t skim to find what’s important to you and frequently waste my time paying attention to the boring and uninteresting.

  5. Marty says:

    Seems that the only real issue is inheritance. All of your other points were preference. Should advanced coders write so beginners can understand or should beginners try to understand more advanced code?

  6. Rich Sturim says:

    Great argument. I’ve never been keen on font shorthands — it always seemed little gain while sacrificing clarity — the fact that it’s can be unpredictable, as you detailed, is yet another reason to keep these properties in longhand.

    Now for borders detailed in shorthand — that’s a different story :)

  7. Mark Host says:

    I agree/disagree.

    I think the biggest drawback is knowledge of CSS. Though, I have learned all of these shorthand syntax in addition to the many IE bug scenarios (or even Opera/FF stuff).

    I like using the shorthand, but it took me sometime to feel comfortable. I personally love it for general declarations, and then I use the long-hand on specific elements that needs some adjustment.

    Why use the font tag to declare font-family when all you want to change is the size and style? It just depends on the situation and user.

    Good job on your first video!

  8. Steven Schrab says:

    My biggest problem with font short hand is having to re-declare the fonts I use as well. Often I’ll use the same font for the whole page and just apply it to the whole page. The font-size and other styles are what change a lot, so I change those at a class level. It seems more wasteful to me to have to rewrite “Times New Roman, Times, serif” any time I just need to change the font size.

    If the font declaration wasn’t necessary, I’d be all over it for font-size and line-height. Really wish it worked more like that.

  9. David says:

    Hey Louis – There are always people out there who are just learning this stuff. So I’ll start off with saying that I give you props for taking the time to make the screencast (well done by the way – keep it up), and for sharing your opinion and knowledge.

    That said (yep, here comes the “but” ;) – I disagree with the reasons you gave against using the font short-hand property.

    Basically, it seems your main argument can be summed up as “it is confusing for beginners.” And yes, I agree, it can be. Indeed, a beginner with little knowledge of CSS syntax will potentially misuse any property they don’t understand, and get unexpected results.

    However, this lack of understanding does not mean the property is unusable as you argue. Certainly the property is not “unpredictable,” as an earlier commenter said. The problem is not with the property. The problem is with the CSS coder who doesn’t understand how to use the property properly. I know that sounds rather circular, so I’ll try to elaborate.

    The spec for the property is very clear, as are the general principles of the CSS cascade and specificity:
    * You must explicitly declare all the values, otherwise the defaults are used.
    * You must also declare certain values in a predefined order.
    * Depending on the specificity of other selectors, the short-hand may very well override individual font long-hand rules (i.e. “font-weight” “font-style” etc) that you’ve set previously. Or vice versa.

    This is how the property and CSS in general is supposed to work. So again, the fault here does not lie with the font short-hand property. The coder’s lack of understanding of how to use the property is the problem. It is matter of knowing when to use short-hand and when not to – as Mark Host pointed out above – and indeed there are very useful times to use the short-hand declaration… including, as you pointed out, when it allows you to code more efficiently. Like any tool, you need to know how to use it.

    One other quick point: you pointed out that auto-complete functions available in certain text editors like Dreamweaver don’t write the short-hand property in the correct order by default, and use this as an argument against the short-hand property. At the risk of sounding like a hand-coding snob (which I freely admit I am), the problem here is again not the short-hand property. The problem is the coder’s dependency on a text editor to do the coding for them.

    So in summation – I think the take away point here is that beginners should learn how the CSS properties work (which you did a good job of explaining), develop the knowledge of appropriate and efficient CSS use, learn how to hand-code, and not be dependent upon text editors. Thanks for letting me rant, hopefully constructively.

    • Excellent points, David, thanks for your input.

      The funny thing is, I agree completely with what you’ve said, except I still don’t think font shorthand should be used. The problem is that CSS and web developers do not “live in a vacuum” (as the saying goes). That is, we’re affected by our environments and the people around us. We use text editors that auto complete for us, and we have others that will one day take over our code, etc. So, while your points are 100% true in theory, I just can’t accept them in practice.

      Thanks again!

  10. Ken says:

    except the thing that the line height should be defined again if you’re using font shorthand, I see no other problem in using it.

    And, by the way, I am defining the font properties once or maybe twice per css file – I see no problem defining the line height two or even three times :)

    Thanks for tutorial!

  11. Sunny Singh says:

    Exactly the same problems I use to run into. I only use shorthand in my reset for the body, and then use individual properties which would inherit anything else from the body.

    I agree it makes more sense and keeps the cascading thing in order. If I want font size changed, I just set font-size and that’s it. It will still be in arial (or whatever your default) font, with whatever else you declared. It also helps for changing properties a lot easier, especially with hover effects and what not.

  12. e11world says:

    very interesting. I actually didn’t know about some of the ordering problems and that is more clear to me now. I always used both techniques at the same time but maybe it’s time to standardize things.

  13. carlnunes says:

    As soon as I saw a Windows interface, in your screencast, I stopped watcing it.

    Here’s my contribution on the font shorthand:

    Don’t use it. Why? To avoid specificity issues. K.I.S.S.

    • I would love to do my screencasts on a Mac. So much more attractive, if for no other reason. But unfortunately, I’ve always done my work on PCs, and never had a reason to switch.

  14. Great video! I started using shorthand a few weeks ago and I love the way it looks. I’m never seen a document on it so I just assumed since it was CSS the styles would just cascade. Personally I don’t understand why it doesn’t cascade. Is there a reason why you wouldn’t want it to cascade?

  15. Pr0v4 says:

    I’m completely agree!

    At the end of the day, a good website shouldn’t use more than 3/4 typography rules, so using the shorthand version of he font property to save, how many?, 6/10 lines of code is not that big deal…

    BTW about the video, good job! As been said from other users if u’re gonna be able to improve the quality will be really appreciated!!!

    In the meantime, keep up the good work!

  16. Kevin Mist says:

    I appreciate your new step into the video blogging world. I have found it fun to watch the progression of Chris Coyier’s blog as he gets better and better at doing them. I hope you keep up with them. I have never done one but I have a lot of respect for people that do. Public speaking has never been a strong suit of mine. One possibility for the quality issue is to have a dl available for the High Def version while keeping the live one a little smaller.

    Keep it up. I have bookmarked your site only because you have done this video.



  17. Adam says:

    I completely agree. Just one more thing to think about when coding. We have enough to think about when creating a new site.

  18. arnold says:

    Im sorry but the font shorthand property doesnt really bother me at all.
    It usually depends on the situation when the user codes,. for me its saves lots of lines and really readable for me.

    please more quality resolution on the video.

    thanks for the screencast btw,

  19. paul says:

    There’s a very useful guide I use when I’m not sure about CSS shorthand :

  20. Jason says:

    I’ll have to say I’m on the side that doesn’t really use the font shorthand properties, mainly for the reason a few others have mentioned. I generally deal with only one font family on a given page/site, and having to re-declare the font family to alter other properties just seems like more of a waste.

    What I would love to see is the CSS variable(?) inherit being used in shorthand declarations. This is a peeve with several shorthand selectors. If the font property was set in order(weight, variant, and style), where “inherit” could simply replace values to bring the original cascade back in order.

    This is something I’d like to see applied to margin or padding shorthand properties as well. Lacking a good real world example right now, say there is a list of items, each li is set using “margin: 0 20px” and for whatever reason you have one that needs 10px on top and 30px on the bottom. Instead of writing out “margin-top:10px” and “margin-bottom:30px” I’d like to see something like “margin: 10px inherit 30px”. Yes, in a small case you could simply do “margin: 10px 20px 30px” which would be shorter, but say the list items now need to be given less margin. You now have to track down both declarations, and change that 20px in multiple places, whereas with an inherit value, you can change it in one place, keep the specific margins on the single li item, and save from using extra lines and characters.

  21. Jeff says:

    Great work, love the screencast idea and hope you add more in the future!

  22. This cast is absolutely your personal idea. I don’t agree with you about not using it. But you explained well the diferences and pro/cons.

    font shorthand has cons but still have much advanteges over extracted usage.

    Here is CSS 3 font document:

    VIM, Textmate and Eclipse also does perfect with auto-complete, maybe it is time to change your text editor :)


  23. aer says:

    speak a bit louder :/

    • It wasn’t my voice that was quiet, it was the level in the recording. Unfortunately, I was testing with headphones, so I mistakenly thought it was loud enough. I’ll improve it in future screencasts.

  24. Adam says:

    I think the lack-of-inheritance argument is the strongest point – it was news to me!

    The music: Minutemen (The weird thing is, I had just been listening to a Podcast by Mike Watt, the bass player from that band, seconds before I started watching your video – small world!)

  25. bryec says:

    I agree with all of the points stated in the video, the shorthand is very cumbersome, and can be reinforced by the fact that your Dreamweaver auto-complete feature doesn’t support it fully. It’s definitely not something I would use in a collaborative effort, or in some code I’d like to be clean or readable, but it is not without merit; it’s useful to constrain styles in code you want to keep as small as possible. I use the font shorthand while coding javascript applications, or offline scripts kept as lightweight as possible.

  26. Anthropos says:

    I don’t see why the inheritance is an issue. font does just the same thing other shorthands do and are supposed to do. For example, background behaves just the same way. A shorthand is for setting *all* related styles, not only the specified ones. One can argue if the omitted values should be inherited or set to default, but font is not special let alone worse than other shorthands regarding this.

    • Yes, but the difference is, the font related properties are expected to be inherited down through elements, whereas background and other shorthands are not expected to inherit in that way, so there’s no surprises in those other cases.

      I should point out that this is an old post and my view has changed now. I don’t think it’s wrong to use font shorthand, but I still think for modular and maintainability reasons, it’s just easier to do longhand.

  27. robopuma says:

    Perhaps you could repost the video to youtube since has decided to remove it! Alternatively maybe delete your article, although it would be a shame to waste your hard work…


    • Oh, yeah, thanks for the heads-up. I’ll probably delete this post to be honest, it’s a bit out of date and I don’t completely agree with everything I said in it anymore.


Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field and deep URLs are not allowed in the "Website" field. If you use keywords or deep URLs, your comment or URL will be removed. No foul language, please. Thank you for cooperating.

Markdown in use! Use `backticks` for inline code snippets and triple backticks at start and end for code blocks. You can also indent a code block four spaces. And no need to escape HTML, just type it correctly but make sure it's inside code delimeters (backticks or triple backticks).