Slim and sexy style sheets
When it comes to conservative code, CSS files usually get the short end of the stick. Grabbing all of the presentation and layout information from the HTML and dumping it in the CSS has finally become a standard process for most designers. (If it isn’t yet, make it yours.) While this is the exact purpose of a style sheet, there are plenty of methods by which a designer can make sure that the CSS that loads for every page is, like the HTML, as clean and concise as possible.
CSS as a Process
For many designers, the process of building a style sheet consists of starting with the outer containers of the HTML structure and working their way in, aligning and styling as they go. How many times have you sized and centered your #wrapper element, and then moved onto aligning the logo and primary navigation in the <header>, and then continued your way down the page? This process certainly works, but there is a much better and quicker way to handle CSS. Much as we did with the HTML, we can recycle code and use a modular approach in a way that makes more sense and takes less time.
Instead of designing a style sheet with the HTML in mind, we should carry over our mindset from the rest of the design process, putting the user first. In our new and improved CSS process, let’s start with the most important and prevalent elements of our design. These will almost always be the content. The whole point of delivering clean and semantic code is to ensure that no matter what the screen, device or context of our visitor, they will have access to the fantastic message that our website is trying to convey. For this reason, we’ll start the primary portion of our style sheet with the typography.
01 |
body, select, input, textarea { |
02 |
font: normal .825em/1.25em Tahoma, Geneva, sans-serif; |
03 |
color: #353838; |
04 |
} |
05 |
h1, h2, h3, h4 { |
06 |
font-family: Georgia, "Times New Roman", Times, serif; |
07 |
color: #202020; |
08 |
} |
09 |
h1, h2 { |
10 |
font-size: 1.875em; |
11 |
} |
12 |
h2 { |
13 |
text-align: center; |
14 |
font-weight: bold; |
15 |
line-height: 1.5em; |
16 |
border-bottom: 4px solid #e5e5e5; |
17 |
-webkit-box-shadow: 0 1px 0 #b2c6e1; |
18 |
-moz-box-shadow: 0 1px 0 #b2c6e1; |
19 |
box-shadow: 0 1px 0 #b2c6e1; |
20 |
margin: 1em 1.25em; |
21 |
} |
22 |
h3, h4 { |
23 |
font-size: 1.25em; |
24 |
margin: .75em; |
25 |
} |
When it comes to text, we start with the most global rules and get more specific as we move down the style sheet, a pattern that should be repeated for other portions of the website.
Because typography is usually the most heavily used element on a website, it stands to reason that we should define our core font rules on a high-level element, such as the <body> element. If we want different typographic rules for headlines or certain page elements, we can declare them just after the default settings. If you have trouble figuring out which typographic declarations to add to your high-level selector and which to use as overrides, simply mark them all up and then identify which are the most common. Apply the most common declarations to the high-level element, and build specificity as you go forward.
With the typography set and the HTML structure solid, we have a website that could technically be delivered as a functional product to any device or browser. Anything we do from this point on should be to enhance the user’s experience.
For many designers, enhancing the experience starts with coloring the page. After typography, the color palette is arguably the element that most affects a website, and therefore should be next in the style sheet. I find that a good color palette is ingrained in every level of a design, and that breaking colors out into a separate section of the CSS leads to a lot of extra lines of code and a lot of selectors that are used solely for color but that have twins throughout the style sheet serving other purposes. I am not a fan of branching a single selector into different bits for the sake of lining up declarations. However, neither method is inherently good or bad. Find a system that works best for you, and maintain consistency across the project.
Finally, we get to the structure and layout of the website. With wonderful typography and eye-catching colors sprinkled throughout our website, we can line things up the way they should be and in a way that makes the website easy to read, navigate and interact with. We can continue with the method we adopted for the typography, putting the general rules first and then getting into the details later on. One thing that will hold us back is the lack of a hierarchy in HTML for anything other than typography.
Looking at the elements included in HTML4, the specification was clearly not prepared to support the complex layouts that designers and clients demand today. We had six levels of importance for headlines, but only abstract elements like <div> and <span> for structure, with no way to indicate hierarchy. HTML5 has gotten us closer, but we aren’t there yet. To make up for this, let’s look to the global class structure that we started implementing in our HTML earlier. We used the .contentContainer class to define the areas of our website that will be visual containers for our content. This class gives us the power to style a big portion of our website quickly and allows us to easily add new containers later without having to force them to fit the style of our website using CSS.
1 |
header, footer, .contentContainer { |
2 |
background: #f1f1f1; |
3 |
-webkit-box-shadow: 0 0 15px rgba(0, 0, 0, 0.25); |
4 |
-moz-box-shadow: 0 0 15px rgba(0, 0, 0, 0.25); |
5 |
box-shadow: 0 0 15px rgba(0, 0, 0, 0.25); |
6 |
border-radius: 3px; |
7 |
} |
Reduce, Reuse, Recycle
Much like with HTML, style sheets can get pretty funky when we get to the point of adding and removing individual declarations in order to get an element to look or behave the way we want. The gracious way in which Web browsers handle CSS rules that they don’t understand or don’t need makes this practice rather common, thus bloating our style sheets. For this reason, go back through the style sheet at the end of the day and remove any rules that no longer serve a purpose. The task is a painstaking one, but as with most such tasks, plenty of tools exist to help us along.
Another task that can save size and space is to group selectors that have the same set of style declarations. From a technical standpoint, it makes sense to create a group of selectors whenever two or more share at least one declaration. I love to take advantage of grouping selectors by using something I call CSS effects. With some of the new CSS3 declarations, I’ve found that I can move the layer styles that I copy and paste in Photoshop right into my style sheets.
1 |
.mainBox, .secondaryBox, .footerBox { |
2 |
background-image: -moz-linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0)); |
3 |
background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0))); |
4 |
background-image: -webkit-linear-gradient(rgba(0, 0, 0, 0.3), rgba(0, 0, 0, 0)); |
5 |
background-image: -o-linear-gradient(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0)); |
6 |
background-image: -ms-linear-gradient(rgba(0, 0, 0, 0.3)), to(rgba(0, 0, 0, 0)); |
7 |
background-repeat: no-repeat; |
8 |
border: 5px solid rgba(0, 0, 0, 0.2); |
9 |
} |
We can apply this declaration stack to any element on our page to achieve a gradient. The use of RGBa allows us to retain the background colors of individual elements and to “outsource” the gradient style to a common selector.
When combined with healthy HTML practices, spending more time on the essential pieces of solid Web design results not only in faster pages and a lighter server load but, more importantly, in a user experience that thrives on any platform regardless of the design method employed. Speaking of user experience, we still need to add one important piece to this puzzle.
Leave a Reply
Want to join the discussion?Feel free to contribute!