- Subscribe and get the new articles every now and then directly in your reader — I recommend using Google Reader
Be smart with your CSS
Read comments ‣ (1)
written by Marek Foss
Whether you agree or not, Cascading Style Sheets have become one of the key elements of modern websites. HTML was said to be just a container, possibly semantically organized, for your data. In fact, some people would love to see HTML be like XML, and I am one of them. The distinction between raw data (XML) and presentation layer (XSLT) gives you flexibility and makes data display simple. But for starters, it’s like shooting a fly with a canon. So take good care of your CSS, or you’ll end up in a big mess of data and styling. Here’s one idea I came up with while making this blog.
First of all, try not to use any styling HTML markup. Get rid of non-breaking spaces, break-lines etc. If you want to make spacing between elements, use padding or margin in CSS. If you want to make an empty line between paragraphs, don’t type 3 break-lines, use the paragraph tag and styling.
Don’t use non-breaking spaces or break-lines:
<a href="#">Link 1</a> <a href="#">Link 2</a> <a href="#"> </a>[paragraph 1]<br /><br /><br />[paragraph 2]
Semantic data is the hot topic now, but creating your HTML semantically does make sense. For example, instead of calling your comments and trackbacks bottom-links, call them feedback. Don’t name classes and identifiers after styling properties, like blue-right-fadeout — it’s better to name it by it’s content, i.e. twitter sidebar.
Another good idea is to actually use lists, tables and paragraphs where they have purpose. For example, don’t just put important links to categories or subscriptions as plain a href inline elements. It’s a list of links, so why not to actually use an unordered list? Also, make use of headers, there’s a whooping 6 of them and the could all be helpful.
<h3>Subscribe:</h3> <ul> <li><a class="rss ico" href="http://feeds.feedburner.com/f055">RSS feed</a></li> <li><a href="http://twitter.com/f055">Twitter</a></li> <li><a href="http://www.feedburner.com/fb/a/emailverifySubmit?feedId=2696605&loc=en_US">Email</a></li> </ul>
Don’t worry about the looks, you can always display them inline using CSS. And about that, one clever technique I started implementing is to divide the raw CSS from the color one. Not sure what I mean? Check my raw blog CSS at f055.net/blog/print/ — yes, you are right, this is what you would get if you printed the website.
What you do is create 2 CSS files, like raw.css and color.css. You define all colorful tags in the latter CSS — color, background, text-decoration all go there. The former, raw CSS is for general arrangement, div layout etc. I also used it for generic font families and sizes, but you could remove that and make it even more raw. Like when you read RFC (ok, you won’t make your site plain text…)
raw.css: color.css:
body { body {
border: 0; background: url(gfx/tiles.png) top left repeat-x #00f;
margin: 0; color: #fff;
padding: 0; }
font-family: sans-serif;
}
There are 3 advantages of this approach:
- You have a raw, highly accessible CSS, good for printing and universal access
- You can easily change color themes
- Your CSS is organized even further
It doesn’t matter how many separate CSS files you have, so think how you could make your life easier using more than one. Remember the times when people would write bulletin boards in one PHP index file? Divide and conquer is the way…
PS. Raw CSS could be stripped of all div positioning and font-styling, which is probably the ideal universal access approach.
Comments
I have to disagree on the “usefulness” of having a separate sheet for colors. It’s an EXCELLENT technique if you’re maintaining one simple website or a blog but I don’t believe it scales on the developer level for larger, more distributed sites and should be avoided.
I base my premise on limited experimentation only and that means I hold not the absolute truth but where I come from, things change a LOT… we modify our templates often and it’s more of a pain to synchronize declarations for one selector into two separate style sheets than it is to have all the particular selector’s “styling logic” in one block of accolades (think object-oriented)
I agree with your markup examples and suggestions, though I would propose another “styling” paradigm where you layer your style sheets following some n-tiers logical pattern.
Basically, every website has it’s globally applicable “rules” such as general link colors, form elements’ look and feel etc.. etc.. Let’s call these resets and defaults (which could be one stylesheet).
Then usually a website has headers, footers, sections, boxes and sidebars that are common or re-used accross the site. These should also be in their own little stylesheet environment, I call them “structurals”.
Then, all we have left are the little parts of “special” content like interaction buttons, widgets, sliders and stuff like than AND you have your microformated or semanticaly organised pieces of micro-content (which constitute bigger “groupings” or blocks of content). These I reffer to as components and primitives. The idea is to target these independently of any
“structural” they might be incased within.
I believe a system like this makes it easier to target a bug and know exactly where to go and fix it. If it’s a structural bug, then you look for structurals.css if it’s a bug with “some button in that sidebar map widget” you know exactly which section of your “components.css” file to be looking at…
Anyways, keep up the great thinking Marek!


