Should You Ever Use Longhand for Padding and Margins in CSS?

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:

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?

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.

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/

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.

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field. If you use keywords, your comment will be deleted, or your name will be replaced with the alias from your email address. No foul language, please. Thank you for cooperating.

Instructions for code snippets: Wrap inline code in <code> tags; wrap blocks of code in <pre> and <code> tags. When you want your HTML to display on the page in a code snippet inside of <code> tags, make sure you use &lt; and &gt; instead of < and >, otherwise your code will be eaten by pink unicorns.