A Matter of Styles

In: Articles

By Ethan Marcotte

Published on August 11, 2004

Until recently, cascading style sheets (CSS) were the most tragically hip technology available online. Touted as the way to create page layouts by, well, the folks that wrote the specification, style sheets were long denied any serious consideration in corporate development environments. Poor browser support stranded CSS in the “isn’t that nice” realm of Web development, a technology best relegated to the fringes of the Internet. For years, the likes of WaSP have railed against this mentality, insisting that we should say to hell with bad browsers, and embrace these standard technologies that could bring our sites—and by extension, the Web—forward. Proper use of CSS would make our pages lighter, make them easier to build and maintain, and generally make life rosier for a site’s users and owners alike.

And the evangelism is finally paying off: such high-profile CSS redesigns as Wired, Fast Company, Sprint and ESPN have brought our indie-rock technology into the mainstream. If the likes of Yahoo and AOL are seeing the benefit of CSS, other corporations will inevitably follow; what does this mean for those of us already making a living with style sheets?

The next few years should prove an interesting time, to say the least; we’re largely an independent and self-educated bunch, having relied on weblogs, mailing lists, and sundry online resources for our education in style sheets. Voracious readers and independent thinkers, much of our collaboration happens online; one designer publishes a cool CSS technique and another refines it, the very definition of virtual collaboration. So if companies are slowly recognizing the business case for CSS, what will happen when they begin clamoring for our services? Our army of the self-educated will march into the fray, and CSS samurai will be collaborating not online but in the workplace—which will bring another set of challenges entirely.

Seeking A Standard Approach to Standards

Eustace is a junior developer working in a mid-sized software company. Much of his daily routine is involved with bug reports, user support tickets, and the like. While it’s nothing too glamorous, Eustace enjoys the work, and the paycheck doesn’t hurt either. Today, however, his supervisor dropped a different task in Eustace’s lap: the vice president of product development is meeting tomorrow with a prospective client, and a fairly sizeable one at that. During the meeting, the VP apparently wants to give a demo of Rorshach, the company’s most popular Web application; but since this account is being so hotly pursued, he’s asked for a few modifications to be made in time for the meeting. Hoping to show the client a rebranded build of the application, the VP sent a few visual changes to Eustace’s supervisor, who then passed them on to our fearless developer.

Eustace looks over the list of changes he’s been asked to make in the demo. Nothing too egregious, he thinks: the client logo needs to be added to the header, but most of the changes are a matter of switching the color palette to match the client’s branding guidelines. He’s feeling pretty confident about tackling these changes because Rorshach’s entire interface is generated by style sheets—a technology, he’s told, that makes redesigns like this a piece of cake. So he grabs the CSS files he’ll be working from, and starts with his first task: replace the dark blue (#036) used throughout Rorshach with the desaturated green (#9C9) from the client’s logo. Firing up his favorite text editor, he gets right to work.

After about ten minutes, Eustace is cursing softly under his breath: what should have been a simple find-and-replace has turned into a tedious editing job. Rorshach’s style sheets total nearly three thousand lines of code—and by now, Eustace is all too aware of how many different developers currently maintain them. His find-and-replace dreams were quashed by more methods of color notation than he’d care to think about: some of the application’s developers prefer to write #003366 in its entirety; others are fans of the terse #036; a few sadistic souls apparently ditched hex notation altogether, and opted for rgb(0, 102, 153). And by the time he got to this:

.classOne {
color: #003366;
font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
font-weight: bold;
}

.classTwo {
color: #CC0000;
font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
font-weight: bold;
}

.classThree {
color: #006633;
font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
font-weight: bold;
}

…well, it’s enough to make a junior developer run home, close all the drapes, and have a good cry while listening to Depeche Mode in the dark.

Of course, all of the above CSS is perfectly valid, and work wonderfully in Rorshach’s interface. But while they all do their job admirably, they’re making Eustace’s downright frustrating. Of course, these are rather contrived examples, and probably more than a little façile; Eustace will likely be working for a couple of hours on those color changes, rather than the couple of days it would have taken in an old <table>-based design. However, inconsistent coding styles can be a true liability in an environment where CSS is written or maintained by multiple hands. At the least, issues in team-developed style sheets could lead to the minor inconsistencies that have Eustace tearing his hair out; at the worst, unwanted or unnecessary styles will creep into your application, which can prove quite a liability when maintaining a few thousand lines of CSS.

Quality Control

The quality of code generated by a team rarely owes as much to the skill of the individual members as it does to the level of communication between them. It might sound suspect, but the success or failure of a project is often contingent upon effective communication first, and technical experience a close second.

Fortunately, there are a number of ways to maintain a high level of quality in a team coding environment, some perhaps more effective (or, depending on your viewpoint, infuriating) than others. This isn’t an exhaustive list, but rather a few suggestions; whatever you ultimately settle on should reflect not only the needs of your project, but of your team as well.

Learning to Love The Style Guide

Certain companies will, naturally, recommend that effective communication can be achieved through documentation: that by writing down best practices of CSS development, team members will each refer back to the shared document during a project and follow the guidelines therein.

Hang on, quit snickering for a moment: if approached in the right vein, the act of writing a “style guide” for a team of CSS developers can be a helpful exercise. Too often style guides are written by a single developer, from a single set of coding idiosyncracies; when other folks are asked to incorporate these “best practices” into their own work, excitement isn’t exactly at a high—on the face of it, the team members are being asked to abandon their own tried-and-true techniques for another’s. Of course at this point, cross-team consistency runs the risk of becoming a thing not to strive for, but instead something to resent.

The more challenging, yet invariably more rewarding approach is to collaboratively write the document: an approach that involves no small amount of time and patience, as well as more than a little skill at facilitating team discussions. Explain to your team the goals of the meeting, as well as the benefits of the style guide you hope to produce with their help.

And then, open the table for discussion: the goal of this meeting should be to hear what’s important to the members of your team. Of course, this is where your facilitation-fu comes into play: folks tend to get protective of their coding style, and are bound to disagree with others. Even matters as simple as the appropriate use of longhand or shorthand properties can get ugly; I’ve seen developers argue at length which was a more practical approach:

#block {
background: #FFF url(/files/includes/images/articles-a_matter_of_styles-quot-my-image.gif") top left no-repeat;
}

Or:

#block {
background-color: #FFF;
background-image: url(/files/includes/images/articles-a_matter_of_styles-quot-my-image.gif");
background-position: top left;
background-repeat: no-repeat;
}

Naturally, if a discussion’s about to come to blows, you might not want to address it within the scope of the style guide. The document should aim to make your teammates’ lives easier, and not to validate one coding style over another; keep that in mind as you write, and your style guide will better serve those you work with.

Of course, the wonderfully ironic thing about technical documentation is that as soon as you get it down on paper, nobody will read it. While that’s something of a generalization, style guides and other “best practices” documents are easily ignored in a fast-paced production environment. When a deadline approaches and day-to-day production challenges arise, few developers are going to consult a lengthy document that reads like a less interesting version of the Financial Times. Furthermore, handing a loose set of coding guidelines to ten different developers can often produce ten different interpretations. A much more practical approach to maintaining the quality of your code is to not only document desired best practices, but to use techniques that will reinforce them throughout the life of your project.

One Coder To Lead Them All

Certain team environments benefit from designating one developer to act as a UI lead, who “owns” much of the CSS development in a team. Responsible for the initial construction of valid, CSS-driven templates, the lead’s work is then handed off to other developers for production. When that hand-off occurs, the UI lead should walk the others through the CSS: the general structure of the style sheets, why certain hacks were used, and other stylistic decisions. Sharing this knowledge not only helps the team better understand the finer points of the CSS they’ll be working with, but also allows the style sheet’s author one final check of her work before it moves into production. And there’s nothing like a second pair of eyes on your work: having other developers review code you’ve been close to will often highlight areas that could be streamlined.

Additionally, this exercise can set the stage for another venerable quality control mechanism: code reviews.

Code Reviews

Or, to speak more broadly, “More Fun Than A Root Canal.”

Code reviews have acquired some rather unsavory associations, even though they can be an excellent way to keep the quality of your style sheets (and its developers) razor-sharp. Too frequently these reviews are used in tandem with performance reviews, as they can provide valuable metrics on a developer’s progress in a given job. However, scheduling frequent reviews of code-in-progress can not only help you catch possible Eustace-infuriating code inconsistencies, but also highlight redundant or conflicting styles. Reviews such as these can prevent unwanted or unnecessary code from creeping into your site, and help ensure your CSS is a lean, mean, bandwidth-friendly machine.

These reviews rarely stand on very much ceremony, in my limited experience: they’re often a frank discussion between two developers about some code that one has written, with an eye toward providing the author with some feedback on her work. Of course, giving the reviewed developer a chance to comment on her work can be invaluable, too—critical thinking about my own code isn’t something I do nearly enough, and I always appreciate the opportunity to do so. Discussions such as these can frequently benefit those that participate, and the code being reviewed can only be improved as a result.

At any rate, bring donuts. Those will definitely win you some serious brownie points.

Spring Cleaning

Of course, frequent reviews and well-written templates will never obviate the need for occasional clean-up. This happy duty often falls squarely in the lap of the UI lead—fitting, as the original templates were her fault, and she’s often in the best place to assess their current status. Having one developer weed through the code produced by your team can be an expensive and time-consuming situation, but is often the most effective way to inject that last bit of quality into your CSS. Furthermore, if there has been sufficient quality control throughout your project, the need for extensive revision is lessened somewhat.

A Recipe for Success

As you’ve likely noticed, this article is offering solutions for problems that have yet to fully manifest themselves. Furthermore, they comprise just one person’s professional experience—and of course, there are multiple ways to resolve a given problem during a project.

However, the fact remains that many of us are accustomed to the “lone CSS wolf” role, acting as the sole developer and UI lead on many a Web project. The Web is slowly, surely shifting toward treating CSS as the de facto method for creating our pages’ presentation layer, and we’ll eventually have to work in less independent environments in order to support the demand for CSS development. Our once-unpopular little technology has come a long way, baby—we’d better learn to grow alongside it, for it’s about to get even bigger.

Related Topics: CSS, Web Standards, Web Teams