A Few CSS Best Practices09/17/2013
A few reminders / tips for CSS. These aren’t necessarily Dirigo-specific, just best practices. Keep it clean. Make it consistent. Start with a framework. Use the "reset". Comment the CSS...
I wrote this short list of CSS best practices based on a project that I worked on this morning.
- Avoid using class names like “purple”, “big”, “largeText” or “margin50”. Class names should describe the element or collection, not the style - the CSS properties describe the style. If that color changes you would have to modify your html to change the appearance, which defeats the idea of separation of concerns. Or worse, you would have a class name called “purple” when the background-color might be declared red.
- In the above case we should strive to have reusable elements. For buttons, we might have .primary or .secondary classes, or .cta (call to action). If a client decides that all of their product “Buy Now” buttons will have higher conversion rates if blue and underlined, do you want to modify your html, or a single class name? Search and replace may get you close, but what about user content stored in a database?
- An exception to the rule would be a constant class that will never change (which is rare). For example, if you created a grid system and .large described an 80% wide block, that might make sense since in that example you need to describe size for layout purposes.
- Chris Coyier has a nice article on semantic class names worth reading.
Don’t forget the ‘+’ and “:first-child” selectors. Instead of tacking on a “.first” class you can use css to style the first (or first child, sibling, etc.) as you need. This also enforces consistency and reduces the need to remember class names.
Avoid redundant class names on html elements and keep the tag name out of it. Having a class called .anchor or .paragraph is super confusing. Either style the a or p tag, or come up with a class name that is more appropriate to its context.
I like to have a class called “userContent” that resets various rules when in a user-editable context. For example, I like to have list-items with “list-style:none”. However, most users using a cms expect bullets and indentation on a ul when using a wysiwyg. If you wrap all user-editable content in a userContent class you can easily adjust for these cases.
Bri Garrett added:
I like to use :after and the property content to create delimiters for navigation. It is pretty useful and I think it is a clean method.
Another cool trick I use is a double border using :after instead of box-shadow. You can apply a double border to an element by setting the :after to absolute, top:0px, height/width 100%. I use this method to add attention to CTA buttons.
Another thing I like to use is display: inline-block. Sometimes, it is much less complicated to make an element inline-block than messing with floats. Really useful for navigational elements and small adjacent items.
And Gerry Shannon said:
I’m starting to really appreciate inline-block over floats as well, mostly because the floats need a wrapper that is overflow:hidden and sometimes that causes other issues … like dropdown navigation not showing.
JP followed up with:
In Edge there are two classes to contain your floats : “.contain” (which simply does overflow:hidden), and “.container” which is a little more complex :
Just know that you can use .container when you need overflow on a container that has floated elements. And as Gerry mentioned inline-block can be a viable option as well.