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:

1. Global styles such as ‘main’ copy properties (size, color, font) at the top
2. Global structure definition (main (secondary) page structure)
3. Header styles
4. Content area styles
5. Sidebar styles
6. Footer styles
7. 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?

Advertise here with BSA

I’d like to cover some common techniques for writing CSS. This article is in no way meant to indicate that method A is in any way, shape, or form superior to method B. Please keep that in mind as you read. Topics such as this tend to spark quite the debate, but that’s not my goal. The purpose of this article is to provide insight to other ways of doing things.

Commenting your CSS

As with all software development, commenting is applicable and important when it comes to CSS. Also similar to other software development, with CSS there are good methods of commenting, as well as less than ideal methods. Comments can be useful not only as a personal reference, but also invaluable to your teammates or coworkers.

At the top of the list comes headings/grouping. Many developers will segment their CSS into related groups of selectors. This helps a great deal when it comes to maintenance. Having all of your related styles in proximity with one another is greatly beneficial. There are a number of ways to effectively group your styles by section. My preferred method is as follows:

/* Heading
------------------------------------------------------- */

.selector { property:value; }
.selector #selector { property:value; property:value; }

Creating headings allows me to quickly scan a style sheet and make the change I’m looking to implement. There are many different methods to effectively format your headings, make sure you’re using one that’s easily identifiable, e.g.:

/* =========== */
/* = Heading = */
/* =========== */

.selector { property:value; }
.selector #selector { property:value; property:value; }

/* =========================================
   HEADING */

.selector { property:value; }
.selector #selector { property:value; property:value; }

/* ============== [ HEADING ] ============== */

.selector { property:value; }
.selector #selector { property:value; property:value; }

There are plenty of ways to segment your code with a few simple headings. My only suggestion is that you implement it in some way, and remain consistent with it.

Another fantastic, quick to implement, handy comment is a color glossary. Simply making a quick note at the top of your style sheet can save you quite a bit of time searching for consistent color values.

Leaving yourself (and your teammates) notes via comments, while not very common from what I’ve seen, could prove to be useful. The issue here, however, comes down to why you’re leaving the comment in the first place. If your styles have become so convoluted that you’re leaving an explanatory note, you may want to revisit the cause of the requirement.

Single Line vs. Multi Line

As you may have noticed in my samples, I write single line CSS. Single line vs. multi line CSS has been a debate since the beginning, and continues to evoke heated discussions to this day.

Most of the debate stems from a direct disruption to the overall readability of the style sheet. Many developers see single line CSS as completely unreadable, while others feel the same way about multi line. I think the main reason behind that is because each developer is looking for something different when they read a style sheet. I, being of the single line variation, hunt for selectors first. Once I’ve found my selector, I’ll continue to look for my desired property/value combination, and go from there. Multi line developers seem to hate the fact that property/value combinations aren’t given nearly as much ‘weight’ as selectors, greatly reducing readability.

Both camps are right. There are pros and cons to each way of writing CSS, and at the end of the day, like with all things, you need to do what’s best for you. Just because someone else uses slightly different formatting doesn’t make them any better or worse.

Proposed solution

I write my (single line) CSS in CSSEdit. One of the reasons I like to use the application is because it’s got reformatting built in. If I need to work on a multi line style sheet, CSSEdit will reformat it to my liking with the click of a button. When I’m done, I can reformat it back to the way I found it and call it a day.

Unfortunately, CSSEdit is a Mac application, and there are quite a few developers who don’t run OS X. To ‘share the wealth’ of this feature in CSSEdit, I took some time to put together a CSS Reformatter. Powered by the sweet CSSTidy, the Reformatter lets you paste your CSS, choose a template format, and provides a reformatted style sheet for you to work with.

I haven’t had a whole lot of time to work with it, but the Reformatter also allows you to implement your own custom CSSTidy templates. If you don’t like ‘my’ multi line or single line templates, feel free to use your own.

Again, it’s not a matter of one method being superior to the other, just be sure to use what you’re comfortable with. Establish a standard among your team, and reformat your CSS to that standard before stopping work on it. Everyone = happy.

Other methods of organization

One technique that has come up from time to time is that of alphabetizing your CSS. Basically, the idea is to alphabetize both your selectors as well as properties to make finding specific declarations a very speedy process. At first I was a bit taken back by this approach. It seemed like quite a bit of work both in the initial writing as well as maintenance of a style sheet. I suppose, however, if you’re accustomed to writing CSS this way, you’d be very quick in locating various items in your style sheet. Unfortunately, I don’t like this technique simply because it removes all structure from your document. You could say it’s structured based on the alphabet, but in my opinion segmenting the styles based on their context is a bit more applicable.

In mentioning ‘findability,’ I’d like to also bring up flagging. Many developers will use certain special characters in their comments to allow quick scanning of a style sheet by way of the editors built in find functionality. For example, you can flag certain comments with an equal sign to signify it is of one ‘group’ of selectors, your heading for instance:

/* =Heading
------------------------------------------------------- */

.selector { property:value; }
.selector #selector { property:value; property:value; }

The idea behind such flags is to bring up the editor find dialog, enter ‘=’ and simply search your sections one by one. Personally I haven’t adopted this approach in favor of straightforward heading comments, but I can definitely see value in it. An issue that may come up, however, is standardization of the flags amongst your team. Make sure everyone is using the same flags for the same purpose, else you’ll be both confused and frustrated when picking up where someone else left off.

Separating style sheets

A technique I’ll see from time to time, is that of separating style sheets into different files based on purpose. That is to say, there will be one style sheet for typography, another for colors, one for layout, and more. The purpose is to abstract certain selectors based on what you’re looking to do with them, as well as trim the overall length of your document.

Personally, this method has been more cumbersome than useful for me. I find it difficult to force myself to take care of all the type in one style sheet, colors in another, etc. Additionally, when it comes to maintenance, I dislike the fact that I potentially have to open multiple style sheets to make a ‘single’ edit.

Style sheet compression

The last bit I’d like to touch on is CSS compression. To be brutally honest, I never compress my CSS before deployment. I think that may be because of the way I write CSS, however. Since I write single line, compression rarely yields anything more than marginal reduction. I’d rather save myself the extra layer of maintenance in remembering to keep an uncompressed version.

There are times, however, when I think compression can be a very useful thing. It’s important to keep in mind that Web browsers download style sheets in their entirety. Anything you can do to reduce that latency will improve performance. If your writing style produces quite a bit of whitespace and/or comments, it may be in your best interest to compress your CSS before deployment.

My style

As I mentioned, every developer writes their CSS in a unique way (more-or-less). I write my CSS on a single line basis in CSSEdit. I don’t use CSSEdit for the Preview functionality or anything like that (although it is quite nice), I use it for two reasons. Number one I mentioned earlier; it has built in functionality to reformat CSS on the fly. The other reason I use CSSEdit is because the application allows me to generate a tree structure within my document by way of flagging comments:

The left column in the interface is a folder structure which allows me to interact with the sections of my CSS. I’ve come to rely quite a bit on this little feature, and it’s one of the main reasons I don’t use my regular text editor when working with CSS.

I hope this piece was at least in part interesting to read. I’m always curious to find out how other developers get things done, so if you don’t mind, take a minute to leave some feedback based on your preferences. The more you’re exposed to as far as methodology is concerned, the better equipped you are to evaluate the way you do things.

Advertise here with BSA

Better control browser defaults

In part 1, I mentioned that controlling browser default styles can really help cut down your styling time. Using the universal selector, you can clear any default margin, padding, or border with a single line of CSS. While this tends to help out quite a bit with browser defaults, there is quite a bit more you can do.

As I’ve written before, I keep a copy of Eric Meyer’s reset CSS lying around to take care of browser defaults as opposed to using the universal selector. His optimized stylesheet comprehensively controls much more than something like:

* { margin:0; padding:0; border:0; }

I’ve found Eric Meyer’s solution to be much more helpful and stable in practice, and I’d suggest that you give it a try to see if it helps you out during your styling process.

Give yourself an applicable head start

A reset stylesheet can be an absolute time-saver. When doing client work, saving yourself some time here and there is becoming more of a necessity. In my personal opinion, when comparing design and development time on a project, development time should be kept to an absolute minimum while design time is maximized.

That doesn’t go to say that I feel development comes secondary to design; on the contrary. The difference between the two resides in the nature of each. Development is something that can be sped with each project. As nuances and speed bumps are overcome, a developer can significantly decrease the time it takes to produce high quality markup and style for each document they’re working on. Efficiency can be increased quite a bit simply by building more websites.

Design is a bit different in the sense that each project brings in a new set of rules. Each project is solving a different problem, circumventing new limitations, and providing quality solutions. Development usually presents itself with a constant set of conditions, which can be learned, expected, and avoided from the start if necessary.

As a result of this difference between design and development, there are ways to decrease development time, allowing for an increase in design time to remain in a limited budget. One way to help yourself to decrease development time is to use a CSS framework.

CSS frameworks were an extremely hot topic late last year, and I think all that needed to be said in their regard has been discussed (at least twice). I think the major difference in opinion rooted from the misunderstanding & assumption (mine included) that CSS framework proponents were pushing a single CSS framework upon others; that wasn’t the case.

I use Eric Meyer’s reset stylesheet on my projects. I use a CSS framework. Although it’s very limited in size, it fits the qualifications of a framework. As I mentioned earlier, reset styles help me to be more efficient at work, and finding a solid starting point for yourself with CSS can help you as well.

Control your clearing

In my experience, the most troubling aspect of CSS to grasp for newcomers is floating elements. When trying to help those new to CSS, trying to explain when to expect certain behavior can be a very frustrating experience for those new to CSS. Keeping that in mind, controlling your floating elements can really help alleviate a headache or two down the line.

Some time ago, Robert Nyman wrote a post explaining a few ways to clear CSS floats without extra markup. The post is great as an overview of some different techniques for clearing your floats. There are some great comments to read as a follow-up as well, and the piece as a whole can really help keep your floating elements under control.

Adding to the recurring theme, building more websites will help the most to learn when to expect a need to clear a float.

Separate page-specific styles

This tip may be less applicable, as it really only comes into play with larger websites with a bigger design budget. Something I’ve found myself doing quite often is physically separating page-specific CSS from the bulk. This involves incorporating both a pagevar as well as a pagegroup for each page of a website, which applies an id and class to the body of every document.

This gives me plenty of control should I want to target a group of pages (or specific page) with CSS. What’s important is to keep things organized; separating page-specific CSS can help significantly with maintenance, especially if your CSS is well commented.

Limit your refresh frequency

When I was first learning CSS, I quickly fell into the habit of refreshing the browser after nearly every selector was given a property and value. Soon enough, I would write a line of CSS, knowing exactly what it was going to look like, yet I’d refresh the browser anyway. Just to make sure I suppose.

Taking a step back to look at things, consistently switching apps and refreshing the browser to see how things are going can slow you down significantly. It’s important to learn to trust yourself as you become more proficient with CSS. Trust that what you’re styling is going to behave as you expect, and limit your refresh frequency as much as you can.

The trouble comes with writing too much and not knowing where to start compensating. This comes with the territory, and will remedy itself as you build more websites.

Refine your selectors

Finding the happy medium with specificity can be of great benefit. While you want to know which elements you’re targeting with CSS, it can really help to take advantage of specificity by keeping your styles to a minimum.

Difficulty may be found earlier in your development career in that you’re not sure why a certain element is improperly rendering. You’re sure of your CSS, sure things are as they should be, yet the browser renders something glaringly different. Chances are you haven’t found a quirky rendering bug (although I’m sure we can all agree we wish we had), but something is going on with your specificity. Styles are inherited when applicable, and this can be taken advantage of to a very high degree. The key is to specify to the proper degree, ensuring your control over the document presentation.

Closing up Part 2

I hope these tips, while a bit simple, helped out. CSS is a fantastic skill to have, but it is a skill which can be constantly refined over time. Keep in mind that the faster you are with development, the more time can be spent on problem solving by way of design. This allows for a wider variety of circumstances under which to fall when developing, as opposed to finding repetition in your work.

Advertise here with BSA

Truly understand what you’re doing

Web design and development is a skill. There are amateurs and there are professionals. Unfortunately, as far as the general public is concerned, making a website can be done in Word with just a few clicks. As a professional you should take pride in what you do and convey that pride in the work you produce. Take the time to research the medium in which you work. There is a vast amount of information, both technical and otherwise, surrounding the Web as a whole. As with any profession, your work deserves the research to back it up. Know your industry.

Read as much as you can

The most talented designers and developers are readily accessible at any hour of the day, directly or indirectly. These industry leaders are constantly providing massive amounts of their knowledge publicly. The majority publish to personal (as well as professional) websites, blogs, or otherwise. Many have published complete books as well, some of which is the best documentation you can get your hands on. We’re in a unique position in that we’re able to read the latest and greatest information the instant it’s published. Take advantage, subscribe to feeds, take some book recommendations seriously, and read as much as you can.

Write as much as you can

After reading articles, books, posts, or otherwise, take some time to provide your thoughts. They don’t need to be ground-breaking or Earth-shattering. If you’ve got a question; ask it. If you’ve got an (appropriate) opinion; express it. Involving yourself will do nothing but propel the speed at which you can come to a conclusion regarding any questions you may have. If you’ve got a lot to say about something, start a blog, write a post or article, write it down and get it out there. Your contribution will help future designers/developers who have the same questions or concerns.

Talk as much as you can

Engaging in dialog is another great way to gain some knowledge you may not otherwise come across. Whether it be in person, over an instant messaging platform, or a thread in a forum, I’ve found direct conversation to be a great way to broaden my view on various subjects. I’ve discovered completely different viewpoints through conversations that changed the way I do things significantly for the better. Many times, an outsider’s view will be the eye opening information you were looking for in the first place.

Try something new

Many times, people become comfortable in their own process, in Web work or otherwise. It hasn’t let you down yet, so if it isn’t broken, why fix it? While I tend to take that very stance when it comes to many things, with Web development I do not. When it comes to the Web, things are changing and evolving at far too quick of a pace to feel completely comfortable with how you do everything. New technologies and techniques are proving to be more effective all the time. Some really intelligent people are producing tools and processes for us to use in an effort to help produce higher quality work in the most efficient way possible. It’s great to keep up on these developments, but take the extra step and try implementation. If you think a different piece of software may be better suited for an upcoming project, give it a try if the a budget or time frame allows. There are many articles on such things as how to Write Better CSS or articles which provide someone’s Bare Bones Style Sheet. I’ll always keep watch for an eye opening way of doing things that just makes more sense than what I’m doing now.

Keep yourself organized

Organization is very important not only when it comes to your work, but when it comes to life as well. Knowing how to keep yourself organized will help you to retain focus on the tasks at hand and help you to keep Getting Things Done. As a Web designer or developer, you spend nearly your entire day at your computer. Take the time to keep it organized. Have a naming convention and file structure in place that you use for everything. Keep your emails in order and sign off AIM if it’s getting in the way. Your buddy from college can send those pictures later on. Organization should be applied to your code as well. Coming up with a company or personal theming convention can help things tremendously, for example.

Make more websites

Taking a page from the book of Kyle Neath, by far one of the best ways to improve yourself as a designer or developer is to do more work. Whether it be client based or simply a personal project you’ve had rattling around your head for the past few months. Set aside sufficient time to produce the best work you can, as it is a representation of yourself and you should take pride in it.

Remain enthusiastic

One of the best ways to improve yourself as a designer or developer is to be excited about what you’re doing. Take comfort in knowing you’re doing quality work that displays your talents. Becoming involved in the industry will help boost your excitement about what you’re doing like no other. Enjoying what you do will retain your hobby being your career. Web design and development has a tendency of becoming slightly frustrating when you’re taking on a new language or technique. Take frustration as a sign of determination. Give yourself a minute to gather your thoughts and resume where you left off. Having enthusiasm in your work will help you be more productive than anything else, and distaste will bring you to a grinding halt.

Always keep learning

Finally, by far, the best way to improve yourself as a Web designer or developer is to keep learning. Don’t ever think you know as much as you need to know, or that you know more than the majority so you’re better off and that’s good enough. There will always be something to learn, something to discover. The knowledge involved in working with the Web is extremely vast, and it inherits many principles and theories completely unrelated to computers or the Internet. Be humble in your knowledge and continually try to learn as much as you can.

In summation

I know this list is far from complete and it doesn’t aim to be. It is a small overview of a few pointers that have truly helped me try to improve my process and hopefully at least one can help you as well. I don’t mean to come off sounding as though I feel I’m an expert on the subject; on the contrary, however (see Way 9). Again, I hope this list can at least act as a refreshment, and hopefully spark a bit of conversation as well.

Advertise here with BSA

Templating and theming can help you work faster

It wasn’t until I started working in Web development professionally when I was introduced to the concept of worthwhile templating (as opposed to cheesy Web templates you can buy for $49.95). I was quite naive to professional Web development in that I was only freelancing on the side during college (I’m sure you can relate). I wasn’t used to having more than one client at once, and I surely wasn’t used to the pace of development required to keep multiple clients pleased. I quickly learned that it was the templating technique in place that was one of the many ways this company kept up with their queue.

The template in use was nothing magical, it was simply a group of files that set the overall structure of a website, encompassing all the necessary tools needed to tie in with a custom CMS. The idea is quite simple, but the benefits are exponential. Having this group of files at your disposal helps to get a working environment for development up and running in a matter of seconds. Configuration variables used throughout the website are defined in a single file, only needing to be edited after the initial copy.

After a working development copy of a new website is put in to place and functional, work can be done on incorporating your design into your template. Instead of working with the header, footer, and content files of a template, I’ve come to prefer working with the initial site comp in a static HTML document first. This document is also templated, including a single instance of the header, footer, and content files in one. This helps me avoid any troubles that may arise due to a server-side issue that may have nothing to do with my markup. Once I’m done with markup, the code can be pulled into the respective header, footer, and content files for use in the template.

Templating your own personal sandbox

Once you’ve got a reusable starting point for your projects, another step that can be taken to make your process that much better is theming your template. The idea of theming ties in heavily with the concept behind using CSS in conjunction with HTML as well as good programming practice. It is a good idea to keep style separated from content, as well as separating server-side code from markup as much as possible. This helps avoid issues down the road when a redesign needs to take place, or something on the back end needs updating. Keeping these areas separate will help you to be confident that your adjustments will only affect that which you intend.

The template our development team uses consists of a theming convention as well. Themes have their own organization, kept separate from the markup, which is also kept separate from any custom functions needed on the back end. Even if there’s only one theme, it follows the convention in preparation for the possibility of a future redesign. Variables linking the website to the theme are defined in the single ‘configuration’ file discussed earlier.

When creating a theming structure, it’s important to keep in mind semantic image use. While images directly related to the site design should be included with the template, images that are used in context should be separated so they can be retained should the theme be replaced in the future. Beyond grouping images for a design, coming up with a templated theme can also be of benefit (as you can see by Mr. Brett’s article). Having templated style sheets for screen as well as print, which incorporate elements you find yourself using nearly all the time, can really help speed up your process. Launching a redesign can most of the time consist of changing a variable or two in one file.

Theming as a step toward future proofing

Not only does theming help your own process, it can also help to future proof any project you work on. Having a set structure established with every design can ensure the work required to make updates in the future is both straightforward and rapid. Future proofing is a wonderful side-product of good practice. With a standards-based approach to Web design, you’re well on your way to producing websites that can stand the test of time in function and display as well as maintainability.

Make sure you’re helping yourself

The important think to keep in mind is to make sure that you’re helping yourself, not hurting yourself. If you put too big of an effort into templating yourself, you will end up limiting your ability to get things done. Instead of a template helping you get things started, it will act as the first of many hurdles that stand in your way. You’ll have to take time to remove unnecessary pieces that didn’t need to be there in the first place.

It’s one of those cases where ‘less is more’ in a sense. The object here is to give yourself enough of a platform to jump from without turning things into a free-fall dive once you make the leap. What is your templating/theming process?

Advertise here with BSA