Ms. Nicole Sullivan is among those looking to improve CSS code. She has been promoting “OOCSS,” or “Object Oriented CSS,” her methodology for how to design and refactor CSS¹. She has collected a number of best practices for architecting a CSS framework. The benefits are simple: CSS will perform better, become more modular, as well as being grounded with a consistent API, making it easier to learn and use. This is accomplished by reducing the file size and complexity of our CSS.

While many of these techniques can be considered common practice for experienced CSS programmers, implementing them can be difficult. The art is in analyzing trade-offs and picking the optimal path. That said, these rules are not for everyone, or every site. It all boils down to deciding if the site’s performance gain is greater than the time it takes to learn and use the techniques.

Useful for sites with

• Many pages
• A common visual and structural design
• Critical performance requirements

Less useful for sites with

• A few pages or just one page
• Varying design (possibly “portfolio” or design sites)
• Few performance concerns

So how do we get started? We go hunting for bad code smells. In Chapter 3 of Refactoring: Improving the Design of Existing Code, Martin Fowler and Kent Beck coin the phrase “code smell,” meaning “structures in the code that suggest the possibility of refactoring.” Simply put, we go looking for chunks of code that our intuition tells us could be cleaned. In the chapter heading, Grandma Beck is quoted (then talking about child-rearing), “If it stinks, change it.” We’ll take a more formal approach to finding these code smells, going from easy to difficult. First, we’ll sniff around the CSS selectors, and then move onto the CSS properties. Finally we’ll look for visual design patterns that can direct the structure of our CSS.

Selectors

Selectors are both the easiest place to find code smells in CSS and the easiest to correct. Three big code smells tend to stink up CSS selectors; unused selectors, location-based selectors, and overly specific selectors. Each contributes significantly to increased CSS file size.

Unused Selectors

Code that does nothing is obviously wasteful, and is the first candidate for removal. Tools like dust me selectors that can spider a site can identify all of the unused or orphaned styles that your stylesheets still contain.

Location-based Selectors

Location-based selectors prohibit code reuse because they are intended to isolate styles for a specific part of the page, yet frequently used HTML components are often reused in a different context. Therefore, its counterproductive to hard-code that initial context into a selector.

Location-based selectors are easy to spot. The pattern is a long list of selectors that starts with the same initial selector, as follows (assuming the source is reasonably ordered).

.sidebar {…}
.sidebar .nav {…}
.sidebar .nav .box {…}
.sidebar .nav .box .header {…}
.sidebar .nav .box .body p {…}

Because each selector chain starts with a location-based selector, none of them are reusable. What if we add a new group of pages that use the same .box structure but need to be placed in the content, header, or footer? A novice would add more comma separated selector chains, but that amounts to copying code.

.sidebar .nav .box, .content .nav .box, .header .nav .box, .footer .nav .box {…}

The correct approach is to factor out the common functionality while ditching the location-based rules. Now the styles can be reused regardless of the box location.

.box {…}
.box .header {…}
.box .footer {…}

Why not break the .box and .header/.footer chains apart? Here the .box class encapsulates the .header and .footer behaviors, hiding these names from the global scope and allowing the “header” and “footer” classnames to be used elsewhere.

To those looking ahead to HTML5, you should already recognize how this pattern can be applied to section elements containing header and footer elements.

Varying specificity

By 2010, everyone should be aware that adding “style” attributes directly to HTML elements is a bad idea (and code smell). What about everything else?

Selectors that contain properties set as !important should be avoided because their specificity makes them difficult to override.

Browser selector hacks like * html {…} should be avoided because they tend to require redefinition of both the problem properties and all other properties, leading to duplicate code. When hacks are needed, use property hacks like the star (IE7 and less) and underscore (IE6 and less) instead.

Because IDs can be used only once per-page, selectors containing IDs can typically only be used in a specific place on each page. IDs are great when you need to grab something from the DOM in JavaScript, but avoid them in your CSS.

Element selectors should be used to provide element defaults, especially when redefining styles previously zeroed out by a reset stylesheet. Using them for anything but defaults tends to yield repetitive CSS.

Keeping selector specificity as similar as possible makes it easy to use classes that only define differences.

HTML:

CSS:

.box { padding:1em; color:black; border: 1px solid black; }

/* simple selectors because the specificity is equal to the base ".box" object's selector */
.green_border { border: 2px solid green; }
.red_border { border: 2px solid red; }

Properties

Properties appear in CSS more frequently than selectors, and as a result their quantity masks their code smells a bit. However we can exploit their frequency to find repetitive code².

Margin: 0 and padding: 0

Resetting the margin and padding properties to zero is extremely common. Using a reset stylesheet will help you do this everywhere in one place. A reset will zero all margin and padding properties, leaving only the non-zero values left to set. If you find that your CSS contains more instances setting the margin or padding to another value (for example, 1em), you can edit your reset or add a global rule setting this alternate default.

Before:

(my.css)

.portlet {margin:0; padding:0; … }
.header {margin:0; padding:0; … }
.footer {margin:0; padding:0; …}


After:

(Reset.css)

div {margin:0; padding:0}

(my.css)

.portlet { … }
.header { … }
.footer { … }

Float

Overuse of the float property is a code smell indicating repetition in placing items on a page. Use of a grid structure will reduce duplication caused by object placement. Rather than have each element float itself, a grid structure will do this all one time only.

Font-size

It’s rare for sites to use multiple sizes of body text on one page, or site wide. Therefore most font-size properties are likely used to define header-like text sizes. Ms. Sullivan does an excellent job pointing out, that of a finite number of font-sizes that can be used on a page, there are even fewer that a user can differentiate (for example the difference between 15px and 16px browser font sizes). Font-size therefore is usually a code smell for repeating headers.

Mingling box model, visual formatting model, and presentational properties

The CSS specification groups similar properties into sections. The Box model is the most famous (because it had previously been the most infamous). Everyone is familiar with its margins, paddings, and borders building on widths and heights. The Visual formatting model uses the display, position, float, clear, and z-index properties to dictate the layout of the boxes in the document. The CSS specification makes no mention of “presentational properties,” but that’s a term I use to include color, background, font, and text properties that style the boxes or their contents.

Separating selectors along these lines allows for greater code reuse. The box model properties are the most easily re-used of the three. It is not uncommon for a number of boxes on the page to share the same properties, so moving these properties into a new class will allow you to apply these styles in a consistent and efficient manner. The visual formatting properties are typically less likely to be reused, therefore separating them from the boxes will allow greater reuse of both the visual formatting and box properties.

It must be noted, however, that there will be cases where the same box model properties will often be paired with the same visual formatting properties. In that case it is perfectly acceptable to leave them coupled together.

Presentational properties are the least likely set to be reused. This isn’t surprising because they are typically dependent on the contents of the boxes. That makes these the most logical candidate for extraction, because doing so will increase the usability of the remaining properties.

Keep in mind we are still trying to build a consistent API for others to use. Creating new patterns of box model, visual formatting model, and presentational property oriented classes will give future developers a wide range of flexibility to mix-and-match these classes while styling new elements.

Visual design patterns

In the last section, we looked at the effects of mingling box model, visual formatting model, and presentational properties. Searching for visual design patterns is the next logical step, albeit a complicated one.

This technique is tricky. Unlike the others, this has the additional restriction in that it is usually only suitable for finished designs. Attempting this on an in-development design may send you on the road toward madness. Additionally, it doesn’t lend itself very well to searching code. In effect we are looking for repeating groups of CSS properties… but these properties can typically span multiple selectors! So instead of looking to the code for patterns, we look for patterns in the other direction, at the visual output.

This technique also takes the longest, since it requires looking at all of the pages on a site as a whole.

Headers

Finding headers on the page should be fairly simple, and to be honest, you’ve probably taken care of this searching for repeated font-size properties as described above. However a visual inventory may convince you that your headers are more alike than different, and you may find an opportunity to tighten the differences. You may even decide to dump one of the variations—even better.

Portlets

In a portal or information dashboard oriented design, each chunk of output, whether contained in a box/window type structure, or structure-less (think Apple’s Dashboard) is bound to share common characteristics. In the structure-less design you can focus on extracting the visual formatting properties into reusable classes defining position. Box or window contained portlets can be constructed using a combination of box model, and presentational properties. And if you’re using a dashboard design, these chunks of output can probably be arranged using a grid structure.

Grids

Alignment is the key to identifying patterns where grids can be applied. Take five steps back from your monitor and look at the top-level page objects. If some of these objects are loosely aligned, they can probably be included into a grid. Sketch the grid and the objects within on a piece of paper. Now walk three steps forward, and look at the each individual section in your wireframe. If you identify objects aligned in your sections, you may be primed for using a nested grid. Sketch that grid (have you realized that you’re wireframing yet?). Keep going until you’ve exhausted all of the sections you’ve drawn (have you realized you’re using recursion yet?)

Then start the tedious process of tearing out the previous code and replacing with a grid structure.. The end product will be far more efficient and easier to maintain. (Which grid should you use? Which every you choose! As long as you are using one your code will be cleaner and more efficient.)

“Media Blocks”

One pattern that Ms. Sullivan found frequently on the Facebook site is something she has coined a “Media Block,” which she defines as “an image to the left, with descriptive content to the right.” Simply put, this is just a compound object, which is slightly more abstract than the previous examples. She analyzes these media blocks in two steps. First define their constant functional properties (what they do), then identify the variables in the design (parts could fluctuate in certain conditions).

Not all sites will contain objects like these, but if yours does, identifying the patterns will help to reduce code duplication and promote code reuse.

More

This short list couldn’t hope to represent the entirety of the visual design patterns that can be found on a website. That’s why a site inventory is required. If you find similar patterns repeating multiple times, this is a chance for you to optimize.

Results

Once these rules have been applied, your file size should be smaller, so less information has to be downloaded, making the page load faster. The overall complexity of your CSS rules should also be reduced, meaning the browser will have less redundant rules to apply, and your page should load faster. And finally, you will have defined an API for common CSS across your site, making it easier for developers to create new pages.

Footnotes

¹ Personally, I find the choice of the “OOCSS” or “Object Oriented CSS” name both poor and misleading. To call something “Object Oriented” when the metaphor doesn’t fit (CSS has no data per se, and it certainly has no methods) is confusing, especially when the audience is likely to be familiar with the term. To then give your CSS library the same name and overload the term twice obscures a very useful set of CSS refactoring methods.

² This can be accomplished with the Unix tool grep, a powerful text searching utility. It is also possible to accomplish this through your editor, as long as it supports searching multiple files at once. It is especially useful to be able to count occurrences across files.

I’ve been exceptionally busy at work, we’re beginning to finish up a much needed, much discussed by librarians, redesign of PubMed.  We’ve put a ton of user interaction effort into this project, as well as a good sprinkling of graphic design (watch out, I even did some parts!)  I think people will be really positive about these new changes.

[Just for the record, if someone happens to stumble upon this from the librarian community, yes, release date is still end of summer, and yes, there will be a Beta period, so no need to worry about a short timeline to update your class or instructional slides.  We do listen!]

It’s also been exciting that we’ve brought a few new people on board.  Always exciting to have new hires, despite the fact that it’s a lot of work… and all of the trainings I have to do.

What else…  I’m planning on attending the DelveUI masterclasses this week in Brooklyn.  It will be interesting to see what some of the heads of state have to say about the field.  I’m a little excited, this masterclass format isn’t the usual boring no-content fluff that you hear at most conferences. I get the feeling that there will actually be code present!  My thanks to the lovely Jina “Sushi & Robots” Bolton for the opportunity for the free ticket.

I’ve been reading… way too many things.  I’ve been reading Learning jQuery 1.3, jQuery UI 1.6, and jQuery in Action and you’ll see the reviews of those two books very soon.  (Can you tell that we’ve switched to jQuery at NCBI?)  I’m a little behind with that reading, but I’ve been working hard on other things.  Additionally, I went on an Amazon spree, and started reading Programming the Semantic Web, An Introduction to Lambda Calculi for Computer Scientists, To Mock a Mockingbird, 101 Things I learned in Architecture School, Code Complete 2.   Last but not least, I’ve also been reading any photography book that I can get my hands on.

Yes, that is a lot of books, and I haven’t had much time for them.  I’ve been working hard at work, and I want to relax a bit when I come home.  Once summer ends, things will return to a slightly more regular pace.  I’ve been learning so much on the job, that I’m not very worried about falling behind in reading.

It’s the summer, so I have been riding… not a ton, but some.  I wish I had time to do more, but I don’t have time for everything.  I have been taking long-ish 7 mile rides home, and then going out to play some basketball with my roommates.  That’s a good time.  As soon as I finish this post, I am going to go and fix my fixie… my favorite Bianchi… I somehow mashed the pedals hard enough to shear off part of the thread of both the crank and the pedal, so there go the original cranks and some lovely MKS Sylvan Track Pedals that were on there. I’ve got a new, generic replacement crankset and new Sylvan’s.  Also, I’m moving from a 42×15 to a 46×17, but with the change in crank length (172.5 down to 165mm) I’ll have the same gear ratio as before.  I’m interested in seeing how the shorter cranks feel.

Not to mention le Tour this year… I was captivated.

And then I’ve been taking some photos.  Still have been good on my New Year’s resolution of taking a photo every day… with the exception of Jan 20 (yes, Inauguration Day, the day more people in my Washington DC area took photos than any other this year).

I also got an iPhone.  While I was in California for Joel and Olga’s wedding, I dropped my phone of more than 5 years on a rug, and the antenna that had been barely holding on for a few months finally fell off completely.  I had previously told myself that I would try to wait until my phone broke before getting a new one. So I was going to buy one at the first sight of antenna problems, until it was suggested that I wait for a new version.  Well, my phone’s demise and the new version’s release coincided, so now I have a 3GS.  Really the thing I like most is having my calendar with me at all times.  The only other part I really like is the speaker, so I can listen to music while on my bike for the first time.

Alright, so that’s about that for the moment. Go out and do something summer-y, that’s what I’m doing.

“Forms suck.  If you don’t believe me, try to find people who like filling them in.”

Are you kidding, I paid for a book that begins like that?  My first reaction was that I could have written that!  Well I didn’t write it, and I also feel that I got my money’s worth out of Web Form Design, Filling in the Blanks, by Luke Wroblewski.

Forms are hard.  I don’t think I need to mention how hard they can be for users… nor do I need to mention what’s at stake if a user finds your form too difficult.  Every web developer who doesn’t have his/her head in the clouds should know that.  Forms, however, are also very difficult to create… correctly!  A well designed form requires a lot of careful, detailed thought.  You have so much to consider… usability issues, accessibility issues, and you usually don’t have anything to go on except for your personal experience.  This book will help you methodically approach form design, and give you the experience of an expert to guide your decisions.

Web Form Design is useful, because Mr. Wroblewski takes a very detailed approach to each aspect of form design.  Within each chapter, he thoroughly analyzes the major elements to consider when designing a form.   For example, the chapter on “Actions” is devoted to action items such as submit and cancel buttons.  One of the sub-sections discusses where to place these items on the page.  The author first presents the reader with the following image demonstrating all of the reasonable placements for the submit and cancel actions.

Using eye-tracking and usability data, he then discusses the pros and cons of each arrangement, without ever deciding one is better then all others.  This is key because it lets the reader, knowledge in hand, decide his/her own course of action.

The book is especially valuable because of the user data, eye-tracking data, and case studies presented within. Mr. Wroblewski’s backs his reasoning with either a summary of these tests or with an example culled from his experiences.  He reinforces his points with a number of demonstration images, all available from the book’s flickr page.  Then he includes a short “best practices” section to close each chapter, outlining what was discussed.  These can be used almost as checklists.  Interspersed in the text are sidebars which present real-life examples and perspectives from numerous field authorities.

Web Form Design is written well enough so that it can be easily read within a few hours.  However, it’s real place is beside you the next time that you have to design or write a form, so that you will be able to make intelligent design decisions, rather than just best guesses.