Most CSS developers eventually come to learn that, because of code savings, using shorthand notation is usually best. For this reason, I strongly recommend using shorthand notation for almost all CSS values, including padding and margins.
While I encourage developers to use shorthand for padding and margins, I would also like to point out that there will be times when using longhand notation may be the better choice. Of course, in a case like this, it’s usually up to personal preference. But I have found certain instances where longhand notation made more logical sense from a performance perspective, as well as from a future-maintenance perspective.
First of all, if you don’t already know, shorthand notation works basically the same for padding and margins. It consists of four space-separated values representing top, right, bottom, & left (in that order, which is clockwise on the box). After some experience, most CSS developers will have this memorized, making reading shorthand for padding and margins almost instantaneous.
One Possible Exception
Here is a circumstance, however, where I feel it’s appropriate to use longhand for either margins or padding: Suppose you have an element whose margins or padding are applied via the element type selector. Something like this:
ul {
padding: 20px 0 10px 10px;
}
Now, all ul elements will have the specified padding. But there’s one ul element (or a group of them) that you want the padding adjusted for only the one side — let’s say for example, the padding-bottom setting, which in the example above is set to 10px and is the third value in the declaration.
After applying the adjustment via a class, your code could end up looking like this:
ul {
padding: 20px 0 10px 10px;
}
ul.other {
padding: 20px 0 0 10px;
}
The code above isn’t too bad, but I think it would be more maintainable and easier to read if you did this:
ul {
padding: 20px 0 10px 10px;
}
ul.other {
padding-bottom: 0;
}
Now you can instantly see the padding settings for all ul elements, while easily seeing that the “other” ul elements have an altered bottom-padding setting. And this would especially be helpful if the declarations were not placed near each other in the CSS. You may not immediately be aware of the padding settings for the ul element, and you may not know that you have to set the top, right, and left values back to what they should be. (Remember that whenever you use shorthand notation, all the values need to be declared again, otherwise you’ll get undesirable results.)
Of course, you should be using something like Firebug to confirm styles on unknown elements, but I still think it’s easier to deal with the longhand example when maintaining the stylesheet, and I think it will be easier to understand at a glance. And of course, the same would apply when dealing with margins.
In This Case, Longhand Uses Less Code
And the added bonus here is that in this instance, using longhand actually makes the code smaller. Instead of a 26-character shorthand declaration that requires all values, you now have an 18-character longhand declaration with a single value whose other values are inherited.
I do this habitually now, so whenever I see a padding or margin setting set in longhand in one of my stylesheets, I know that it’s because the other margin and padding settings on that element are inherited from another part of the stylesheet.
What do you think? Have I overlooked any other important factors, or is this an acceptable circumstance for using longhand for padding and margins? Are there any other cases that would justify declaring either of these properties in longhand?
However, most of these savings shouldn’t be significant, because surely you’re gzipping and minifying your stylesheets. Go for maintainability over file size.
I’ve been doing that for years for the exact same reason. Shorthand is best for most of the time, but when I want to make it more obvious (to myself and possibly future maintainers of the code), I like to make sure that the defining difference is more easily noticed.
I actually just recently started using short hand. While it’s nice and all, there’s a bit of solidness that I feel is missing
btw, when you referred to it within the article you said bottom-padding instead of padding-bottom, it’s good in the code though so I figured you weren’t all there
Heh, you’re right. Fixed it. Thanks. :)
I agree with you. In my personal opinion i would say that you shouldn’t use shorthand all the time. It very makes sense to code like you.
Your code is smaller and people who look at your code can better understand it.
Best regards,
Stefan
Thougtfull article. Liked it. :)
I concur. To learn the shorthand, I use the mnemonic “TRouBLe.”
While this doesn’t apply to margin or padding it is probably still worth mentioning that the iPhone doesn’t support shorthand -webkit-border-radius. Instead, you must explicitly define each corner. See: http://www.westciv.com/iphonetests/
Just a small shorthand-related gotcha.
I understand the point of the article, but consistency is good too. What if you wind up needing more than just a padding bottom? Then you would have to go in a retype the shorthand to replace the long hand. I think you should always use shorthand for consistency and maintenance. Five less characters won’t make a difference that’s worthwhile.
And I support whatever works for you or anyone else, so use shorthand exclusively if that helps you.
And yes, you’re right, if it needed more than just padding on the bottom, I would definitely go for the shorthand. That was the point of the article, to show that longhand could be used (in the case of needing to update just one of the padding values) as the correct option both for maintenance (although you disagree, and that’s fine) and for optimization (fewer characters than shorthand).
It’s important that new developers understand inheritance and how it provides better organization…talking about multiple stylesheets. Shorthand notation provides a trail for identifying the initial declaration. However, every developer will have unique coding practices.
I agree. Using longhand in this instance makes perfect sense. I usually refrain from using the two-value shorthand declaration (for padding and margin) simply because it takes a bit more time and effort to modify in the future.
I’ve been using longhand and thought shorthand was the “proper” or professional way of doing things. Guess I was wrong.
@christopher corbett – Never heard of the “TRouBLe” trick to remembering shorthand. That is pretty clever.