Over the past few months, I’ve been trying to keep an eye on myself as far as writing CSS goes. Writing CSS leaves a lot in the hands of the author, and every designer has his or her very own method to madness. When it comes to CSS, you can do anything you want, which is mostly valuable, but sometimes hurtful with inexperience. I’m always curious to know the thought process behind writing CSS from the eyes of the author, as every stylesheet can be quite different from the next.
The way you write your CSS today depends heavily on what you were initially taught (self or otherwise) in conjunction with other things such as what you’ve read that counteracts your teachings, as well as the level of desire to improve your craft. I like finding out the lessons learned behind your reasons (or lack thereof) for writing CSS the way you do.
I really enjoy writing about CSS, and if you’re a fairly recent subscriber, here’s a quick breakdown of my tips, tricks, and suggestions from the past:
- Write Better CSS
- One of the earliest articles I had written for Monday By Noon, but I still practice much of what was written over three years ago.
- Improving Your Process: CSS Techniques Part 1
- In the first part of the Techniques series, I mentioned a few ways that I tried to be more organized with my CSS writing, especially when working with a team. I have made some revisions since the publication of that article, specifically in dealing with browser defaults. Apart from that, I still stand by the advice offered in that piece.
- Improving Your Process: CSS Techniques Part 2
- In this article I made public my switch to using a reset stylesheet. I also tried to put into words some of the thought process behind my front end development process. You won’t find many code samples in that article.
- CSS Organization Methods and Writing Style
- This article was all about writing style. Style as far as comment blocks, overall stylesheet organization, right down to single line versus multiline. I touched on the idea of using flags as a hook for searching to quickly find various sections of your stylesheet, but that didn’t catch on with me.
With that reviewed, I’ve got a few other things I’d like to share as far as my CSS writing style is concerned.
It’s about patterns
One of the best habits I’ve found for myself is the desire to find patterns in designs. Patterns go a long way in design, and every good design inherits a certain level of pattern. Whether it be in organization, texture, or otherwise, a pattern provides consistency, and you’ll see patterns everywhere on the Web.
It will be in your absolute best interest to discover these patterns prior to writing a single line of markup or style. You want to use patterns to your benefit. Not only will finding patterns reduce your workload, it will make maintenance that much easier.
Jeff Croft recently posted an insightful article on finding patterns in CSS, but instead compared it to applying OOP concepts to CSS. I’m a big fan of Jeff, and much of my fandom comes from a similarity not only in workflow, but also opinion and thought process when it comes to Web design. In that article, Jeff puts into words something I’ve tried to verbalize in the past, and I’m thrilled to have it as a reference now.
I can see how using OOP methods in your CSS can be an eye-opening discovery, but it’s very important that you don’t become overzealous with it. As with many aspects of Web design, there is a fine line to walk when it comes to finding a happy medium with something like this. You’ll need to take a step back and really think about your implementation before taking action, else you’ll find yourself fighting an uphill battle when it comes to troubleshooting and maintenance. Using too many classes in a widespread way is going to cause trouble when you need to make a sitewide change and need to edit nearly every file on the site because you used a combination of classes in too many places.
Before I begin writing a line of markup, I take enough time to look at every comp for a website. I’ll look to see which elements, both structural and stylistic, have a repetitious property to them. I’ll keep these repetitions in mind as I write my initial markup, and then again when I’m later starting to write my CSS, and use the patterns to my advantage. Experience will help you better recognize and use patterns as you design and build more websites, but it will be a great skill to focus on throughout your career.
It’s also about structure
One of my biggest peeves when maintaining CSS is poor stylesheet structure. That is to say, when a production stylesheet has been in place for a decent amount of time, and the website has undergone some revisions, the edits were not properly put in place. Instead, declarations are sometimes simply appended to the end of the file to ensure their application, instead of finding the proper place in the file in which to make a change. I can recognize the desire to do such a thing, especially if you’re doing maintenance yourself, and the original file structure is so unkempt it would take hours to sift and organize it yourself. While the fault lies with the original author, it’s something that should be entirely avoided from the start.
I don’t mean to say that the way I write my CSS is a superior way to do so, my point is that you need to have some structure to your stylesheets. The technique I use for structuring my stylesheets is roughly the following:
- Global styles such as ‘main’ copy properties (size, color, font) at the top
- Global structure definition (main (secondary) page structure)
- Header styles
- Content area styles
- Sidebar styles
- Footer styles
- Per-page specific styles
My basic reasoning is to work top down as far as specificity is concerned. I’ll work from the most global properties down to the most detailed as I work through a stylesheet. I try to keep things organized with how I think in a way. I’ll start with the main structure of the document, and then continue to style the header, content area, sidebar, and footer, respectively.
Once the more generic, consistent styles are taken care of, I’ll set up sections of the stylesheet specifically for one-off pages in the site should the design require it. Proper attention is given to these groups of styles via comments outlining which page is associated with a set of selectors.
Working in such a way will help you abstract which edits will affect the site in its entirety as opposed to the single instance you’re trying to modify. When working on a site you didn’t originally style, it’s very easy to make an edit that may in fact destroy a significant portion of the site you’re not even aware of.
Do you consitently keep your CSS in check?
Is it strange that I still put this much emphasis on the quality of my stylesheets? Are you at all interested in how other people write CSS or do you prefer to work in the way you’re comfortable? What techniques do you use when organizing your stylesheets from a more global perspective, as opposed to writing comments here and there for reference?
I’ve been trying to keep my stylesheets in order as much as I can (for the most part). Even though I’m not a very good coder, I try to emulate actual programming by indenting my CSS. So, any child is indented from its parent. I usually start my CSS out with a very basic margin and padding reset, and work my way down the HTML structure, starting with container, then header, then navigation usually, then content, footer, etc. Then, I too, have page-specific styles towards the end (unless it’s #container.homepage and #container.content_page where I’ll put the styles near the other #container styles).
One thing I have been doing, and liking, is separating styles out into layout.css and text.css. This may not be a perfect solution, as I know it’s extra HTTP requests, but it works for me, and it’s not like I’m developing sites where that extra request is going to be a problem. It helps me keep things organized, kind of like separating style from content.
I haven’t tried doing too much “OOP” styling, but I’m hoping to experiment with it a bit where new projects allow.
You are true … its the pattern identification that plays a key role in building a custom css framework
Ha! I structure my stylesheets the exact same way you do! Call me crazy, but I also use consistent “typography” in my comments to indicate up to four levels of headings and subheadings. I recently started experimenting with indenting child elements as @Ben Carlson described above, but I have mixed feelings about it. I think it’s something I will only do (if at all) in the page structure section.
By the way, I don’t think it’s at all strange that you put so much emphasis in the quality of your stylesheets. I think a big part of the fun of CSS is making your styesheets as beautiful as possible, because code is poetry! Even though I am pretty sure I know what works best for me, I am endlessly fascinated by other people’s methods.
@Ben Carlson: You’re definitely not alone in segmenting your stylesheets into separate files. I gave that a go for some time, but didn’t like the setup/maintenance factor. It was cumbersome for me to edit two files to style a single element. It was rare though, as type is quite global in comparison to everything else you style. I do see the value in abstraction, but personally prefer to have everything combined. Thanks for the notes!
@Julie: Glad to know it’s not only me consistently checking into myself as far as my styles go!
There’s a tool now to organize css like you mention – styleneat.com – works great.
Good read, nevertheless.
Writing better CSS has always been important to me. I do stray from structure for small edits, sometimes. I used to be the person who appended changes to the end of the document. Usually do to laziness or because there are multiple CSS files to search for the correct place.
I like the way you structure your CSS, starting globally and working down to the details. I tend to have a very small global declaration and put details into every other declaration. This is something I am working on… Finding the pattern, as you mentioned.
I use just one CSS file. I don’t use comps: the markup comes first and the CSS fits around that.
The organisation depends on what I’m designing. If it’s a simple blog theme it’s: basics (reset, html, body), layout, typography and then the individual area changes (header, nav, content, comments, sidebar, footer). I’m pretty disciplined when slotting amendments in.
If I’m designing something a bit more complex then I tend to take a more modular approach (which corresponds to OOP, I guess). So I’ll start with the basics, set the grid and then declare lots of reusable, presentational classes and organise them along the lines of colour, rules, size and proportion. ‘Unsemantic’, but HTML5 will solve that problem.
It’s a fair point, and I generally structure my CSS in much the same way as yourself. I would disagree that you ‘need’ to do it though, it’s really a personal matter, however annoying that may be to other people. And I’ve definitely had to spend more than my fair share of time sifting through unkempt, randomly ordered stylesheets, trying to make some sense of them.
If you work solo, write any old mess you want, but if you have to work with anyone else, keep it tidy. It makes life a lot easier for everyone.
[…] Improving Your Process: Thinking More About Your CSS […]
[…] Improving Your Process: Thinking More About Your CSS – Jonathan Christopher […]