I mentioned a couple weeks ago that I was working my plans to include stops to upcoming conferences. The first of which was the Future of Web Design NYC and the second being the first Sidebar Workshop. While I couldn’t make it to Washington D.C. for Sidebar, I thankfully was able to make the short trip to New York for FOWD.

Unlike last year, I was able to make FOWD 2008 a two day event. While New York isn’t too far from Albany, making the round trip last year was quite a long day. On the day of the workshops, I met up with Colin Devroe and Chris Fehnel to hang out, and snag some awesome Thai for lunch and check out the Apple Store. We made a day of it, snagged a beer or two, and waited for conference day.

Conference day

FOWD had another spectacular lineup this year. The keynotes found a wide range of topics, and the variation was excellent.

And that’s that

I had a great time at FOWD this year, Carsonified really knows what they’re doing and they make the experience really great. I can’t thank Colin and Chris enough for putting up with me over the two days; I really appreciate it.

Again with content management?

I’ve come to the realization that clients and content management systems do not mix. As an example, in a recent RFP (a subject unto itself), the outlined requirements of the provided CMS included the ability to adjust kerning, line-height, typeface, and color of all content on the page.

Going beyond the fact that this request was put together by someone who has absolutely no idea about modern Web design, I’m beginning to see more fluff along these lines. Are we really at such a level where average potential clients are making the leap to such things as kerning and line-height?

The client issue

What it comes down to, I suppose, is the level of client you’re working with. There are clients who just want what they have seen as possible. If there is a feature available and you don’t offer it, your skill is inferior. We’re well aware of scope creep and bloat, but clients do not often respect either.

I’m not knocking the client perspective in the least. I, in fact, truly enjoy doing client work. I feel accomplished when a client is both impressed and pleased with their project once things have been pushed live. It’s a great feeling, knowing you have helped make their project a reality. My company makes a consistent effort, however, to debunk many of the preconceived notions that follow clients through our door. It’s often a strenuous process, but everyone is better off for it.

I’m consistently in a battle with trying to better the overall experience for a client, while keeping a close eye on the direct effect any change will have on the design. I’ve written before on the general abuse of content management systems by clients. I’ve even brought up the trouble with WYSIWYG in CMSs. While both pieces shine a harsh light on client interaction with your designs, I’d like to start focusing on any positives that can come from using a WYSIWYG editor.

Overall effectiveness?

I understand that every CMS under the sun employs a WYSIWYG editor for most copy-areas, but it’s not working. I cannot in good faith discredit all the time and effort that has gone into the leading editors, and I don’t see them going anywhere soon. The trouble, however, is that they’re too easy to break. I can’t count the number of times I’ve had to manually edit a WYSIWYG block because the editor lost track of a strong tag somewhere along the line. Clients will call, furious that the entire page is bold, questioning the value of our entire CMS based on the fact that he pasted directly from Word.

It’s not his fault he used Word, however. Commonality shows that Word is a standard method of formatting text in the business world. To say that he is “not allowed” to use Word because it breaks his website goes back to the age-old issue of Internet Explorer “breaking” the Internet. Designers know it to be true, but to everyone else, the project itself is the failure, not the utility.

The trouble here is the divide between how I view the Web, and how clients view the Web. Not just taking into consideration the quality and semantic value of markup, but the design itself. A client doesn’t realize that a stylesheet has been carefully prepared for his benefit, that center justifying, bolding, and typing in all caps isn’t going to achieve the effect he’s looking for.

Stuck in a rut

I truly wish I had a flawless solution for this issue I can’t seem to leave behind, but I don’t. At the very least, I will make a continuous effort to provide the most streamlined, stripped down WYSIWYG copy editor I possibly can.

One thing I’d like to specifically raise as an issue is that of including imagery in WYSIWYG editors. I haven’t thought too much into it, but I think preventing the addition of images directly in a WYSIWYG field will solve quite a bit of my issue. That is not to say that the inclusion of images will be removed completely, simply delegated to the CMS itself as opposed to the editor. While impressive, the handling of images directly within a WYSIWYG editor has never worked out in my favor. I can’t count the number of times a client has requested that someone “look into the image on the About page, it looks funny.”

While I don’t see the omission of images in WYSIWYG as a plausible solution, it’s something I’d like to work at over the coming months. I’m not sure how, but it will be a goal of mine.

While the articles published by many of the speakers at these events are invaluable, the presentations and workshops always seem to end up at a higher level. You’re able to get that much more out of an official keynote. Whether it be the associated visuals, or the fact that you’re able to physically see and hear a designer you’ve been following for years, something about the event leaves you with that much more.

Future of Web Design

If you’ve been reading Monday By Noon for the past year, you’ll know that last year I was able to attend the Future of Web Design 2007 in New York City. It was a fantastic event. I was able to go with a few of my colleagues and we all had a tremendous time.

Thankfully, Carsonified is bringing back FOWD NYC for 2008. I’m still working out some logistical details, but I’m nearly positive I’ll be able to attend this year as well. Should it all work out, I’ll be able to again see some people I didn’t get to spend nearly enough time with. Colin, for instance, and maybe Jonathan, although I’m not completely sure if he will be attending. I was only able to shake his hand at FOWD 2007 primarily due to the (literal) line of people waiting to ask him questions. Hopefully I’ll be able to meet a few others face to face this year now that I’m more used to the scale of FOWD; we’ll see!

If you’re at all on the fence about going, just take a quick look at the list of speakers for this year - very impressive. I’d take the time to list the keynotes I’m most excited about, but that would mean typing up each presentation slotted for the day. In all honesty, there are some big names presenting on some great topics throughout the day, and I can’t wait.

FOWD starts a week from today, November 3, with a day of workshops and continues until Conference Day on the 4th.

Sidebar Workshop

To my surprise, the four musketeers took it upon themselves to become even busier by putting on a workshop of their own. The team at Sidebar Creative presents Sidebar Workshop on November 12th, 2008 in Washington D.C. Not only am I thrilled that the Sidebar team is putting on a conference, I’m thanking my lucky stars it’s on the East Cost.

A full day has been put together starring each of the Sidebar Team. Bryan Veloso will be speaking on interface planning and design, Dan Rubin plans on talking you through the export and optimization of images for your designs. Steve Smith will speak on the process of bringing your markup and style together, and Jonathan Snook will provide some of his wisdom on JavaScript libraries.

Last, but certainly not least, the Sidebar team has allowed for a group discussion at the end of the day. They’re offering a chance for attendees to ask specific questions they’ve got, and get instant feedback. If you’re in the D.C. area, I’d suggest snagging a seat at this event. The Sidebar Creative team is an impressive group consisting entirely of highly respected professionals in our field.

I hope it all works out

As I mentioned, I’m still working out some of the gritty details surrounding both events, but I’m doing my best to make it happen. Have you committed to either event?

One inescapable limitation from which we’ll never be able to escape is that of color contrast. While it’s only obvious to ensure you’re working within acceptable limitations of color contrast in the general sense of design, we have even more to contend with. Our designs must be equally readable in a myriad of situations.

Sure, print designers need to worry about what their piece is going to look like in various lighting conditions, or how a digital file will translate to something physical. There is a lot to consider as far as the method of printing as well as the material itself. Web design brings something completely new to the table; monitors.

The trouble with contrast: monitors

Even if you’re new to Web design, it won’t take long to realize that contrast is something that never goes away. Even when you’ve got a solid grasp on limitations, and you piece together a design specifically surrounding color contrast on the Web, your client will request the type be a bit darker & bold. Unfortunately, client intervention doesn’t tie directly to this issue, so we’ll move on.

Computer hardware has a tendency of following the adage “you get what you pay for.” Unfortunately, when it comes to many people and computers; the cheaper the better. Bargain equipment is very attractive for a number of reasons, none of which we’ll need to explore at this time. What does matter to us, is that many of the monitors on which your design will be displayed are of much less quality than yours. Your gradients will be less noticeable, your drop shadows nearly nonexistent, and your type more difficult to read.

It seems dismal, but Web designers need to account for the worst case scenario, or very close to it. We have the responsibility of producing work which is not only usable, versatile, aesthetically pleasing, standardized, valid, and optimized, but also beautiful on substandard equipment.

Keeping your contrast in check

There are quite a few tools available for testing your color contrast. There have been many articles written on the subject as well. Some fantastic research has been performed, allowing us to easily observe our color contrast and measure it against accepted values.

I have a tool that I’ve come to know and love in testing color contrast. Color Contrast Check by everyone’s favorite, Jonathan Snook, has come out on top for me. His tool conforms to accepted standards, and allows designers to very easily check to see how the contrast measures up.

There are many other tools available for checking color contrast, which do you use?

Not only am I a big fan of WebKit because it’s an extremely solid engine in and of itself, the developers get it. They’re consistently implementing features we all want to use, all the while refining their lightweight, reliable engine.

The Web Inspector Redesign

The WebKit team recently hit another grand slam with me in giving some love to the Web Inspector; it’s been redesigned. There is so much to say about the redesign, but that’s better left to the team itself. Instead, I’d like to briefly cover what I’m loving about the update.

The first change I was in love with was the decision to have the Web Inspector default as a panel in the browser itself as opposed to a separate window. Every time I use the Web Inspector in Safari, I always end up toggling that option and using a panel instead. Although it’s a tiny, fairly specific personal preference, I’m glad to see it changed.

I’m a big fan of the direction in which the interface changes are headed. I think the grouped information organization method will help developers do exactly what they want to do when they want to do it. Additionally, the interface now includes the console on every panel: awesome. Integration of the error and warning counts: awesome.

The Elements Panel

The Elements panel has had quite a bit of work done as well. Visually it’s quite similar but the WebKit team notes that a number of changes have been made under the hood. Specific to the way I work is:

• Automatic updates - the DOM tree will update when nodes are added to or removed from the inspected page.
• Inspect clicked elements - enabling the new inspect mode lets you hover around the page to find a node to inspect. Clicking on a node in the page will focus it in the Elements panel and turn off the inspect mode. This was contributed by Matt Lilek.

Of particular importance to me is the first item above: automatic updates. In this age of ‘JavaScript everywhere’ I’ve become increasingly dependent on the DOM as represented in the viewport, not the initial rendering. My workflow consists of using View Source as one reference (representing the initial document load) and comparing that to the living DOM. This is great news for me considering the way I work.

Inspecting clicked elements is something I’ve found myself doing all the time via Firebug lately. I’m not sure where I picked up the habit, and I don’t think it’s a bad one, but it’s great to see the feature available in the Web Inspector.

The Web Inspector update also includes style property editing. I’ve noticed that many developers are in the habit of using live CSS editing to fine tune things before committing to a stylesheet. I’ve never found myself in the habit, but I’m glad to see it in the Web Inspector update; it will be very attractive for many people. On top of that, the Elements panel lets you edit just about every aspect of your document live, making it quite an impressive tool by itself.

The Scripts Panel

I don’t believe any modern Web developer can make it very long without writing at least a small bit of JavaScript. That’s not to say that JavaScript represents a burden we all have to deal with, quite the contrary. JavaScript should be a technology all modern Web developers have on their utility belt.

The previous JavaScript debugger of the Web Inspector has been completely replaced with an integrated debugger: awesome. The debugger itself has been given a great jump start, incorporating some consistency with Firebug. You’re able to check out all the script resources present in the current document. You can set breakpoints, pause, resume, and step through the code. The Scripts panel also provides a sidebar consisting of the current call stack and in-scope variables. This is a great direction for the Scripts panel and I can’t wait to see it evolve even further.

If I had it my way, the Scripts panel would next include tracing of Ajax calls a la Firebug. I use that feature all the time. Having the ability to visually note when a call is made, when a call is completed, as well as the details of the call itself (e.g. response) has proven to be very valuable to me. Sure there are workarounds in logging much of the data, but it’s a great thing to have it all baked in.

I love WebKit

There is tons of information in the official Web Inspector redesign article, and I highly recommend you check it out as soon as possible. WebKit has always been half a step short of my full adoption primarily due to a lack of developer features, but this update has solidified my opinion that I’ll be using WebKit as a primary environment sooner than later. The features keeping me from switching have been menial things, but features I’ve become very comfortable with. The features are now making their way into nightly builds, and I couldn’t be more excited.

Links have become extremely big players in two major aspects of the modern Web; usability and search engine optimization. Anchors now have a measurable effectiveness based on both their href and what is more important: link text. How do we come up with link text? Are there any conventions to follow that will benefit our end goal whether it be improved usability or better SEO (or both)?

Some time ago, Cameron Moll published a very brief post asking exactly that. He went ahead and used a very comprehensive example, asking his readers where they would place the anchor. An astounding number of comments provides quite a bit of insight.

Link text and usability

It may seem a bit odd to juxtapose link text and associated usability, but the two do have common ground. I’ve written before on the (still common) tendency to use “click here” as link text and the issues that rise as a result. The phrase “click here” while strikingly suggestive, provides absolutely no insight as to the resulting action, unless viewed in context with surrounding copy (or imagery).

While “click here” has been accepted by the vast majority of Internet users as a completely valid (and sometimes suggested) phrase to use as link text, you’re much better off taking a few minutes to piece together a more effective string.

Link text and Search Engine Optimization (SEO)

Effectively phrasing your link text will also hold many benefits when considering your SEO efforts. Search engine technologies have embraced (to a high degree) the text used in hyperlinks. Search engines will view that text as an explanation of the resource to which it links.

When comparing a link to a product on the Web, for instance, there are many choices as to what link text you may want to use. Cameron’s example is extremely comprehensive in presenting quite a few options for link text. It only takes a quick look at the comment thread to see the varying thought that goes into the creation of link text. It’s great to see how other people view links, and the reasons chosen for which text to use.

What’s important to remember is that link text can have significant effect on both the usability and SEO of any document on the Web.

With all of us knowing better than to use “click here”, have you come up with any sort of system to help you develop your link text? Do you consider SEO when marking up an anchor? Do you make an effort to fill in the title attribute? What other tips or tricks do you have up your sleeve?

Presenting a comp

Over time, my company has come up with a few ideas as far as ways to effectively present our designs. We’ve gone so far as to bring one of our own machines to a client meeting in order to make sure things were presented properly.

Very often, clients would have concerns about tints, hues, contrast, and other design elements. That is not to say a client is incorrect in doing so, these are issues constantly under fire simply by the medium that is the Web. We were doing ourselves a disservice by bringing our own equipment (which has been calibrated) and using our own software. At the end of the day, even if a client loves a design on your own gear, when the design is shown to a friend, it won’t look the same.

The issue isn’t inescapable, though. No matter what, when the client shows the site to someone else on a different monitor, that’s the way of life in Web design. It is important, however, to avoid creating ideal experiences when presenting Web design.

The way it should be

We had to keep in mind that we’re presenting websites. We’re used to compensating for the shortcomings of the medium, so why make things harder by presenting in an ideal environment?

We’ve come up with a quick and dirty development process just before the designs are presented to clients. During this process, the website will be loosely put together as a static, stylized document. The markup will be junk, and there might even be some inline styles. It doesn’t matter though, we’re just presenting a comp. The markup we’re writing won’t make it past the end of the day. It needed to be quick though; we bill by the hour.

Using this method, we’ve got a design for presentation that will be properly viewed in a browser. It’s much more effective to present this way not only because the client is in a proper mindset, but the design resides in surroundings which affects perception. Browser chrome can indeed have slight influence on a design when compared to a flat file viewed in another application.

There are also times where it’s applicable to include a bit of pseudo JavaScript interactivity at this stage. Sometimes for us it’s very difficult to explain in words the interaction that will be made available. Most of the time clients are hearing about Ajax for the first time and it’s quite difficult to thoroughly understand what’s going to happen.

Beyond that, and perhaps most important, is the fact that the client is viewing the design under their circumstances. Their OS, their browser, their color calibration, their habits and tendencies. All of their concerns will be effectively settled because they’re able to “work” with the design as it was meant to be.

Interestingly enough, Andy Clarke has just posted his thoughts on the issue on For A Beautiful Web and indicates that he takes this process even further. He’ll piece together quite a bit more markup and style than I’m used to, and simply work from there as the design progresses. With each iteration, a link is provided to his client and the cycle is repeated until completion.

While I think that’s a great idea, unfortunately I don’t see it working for my company quite yet. Our clients are far too quick to change their minds throughout a project, which would result in us taking numerous steps back, causing an awkward exchange when we bill for the design work that wasn’t ever used. Either way, it’s great to see another outlook on the process.

How do you present designs? What’s worked? What hasn’t?

It’s also widely known that many people have a hard time standing behind Web standards. I’m not speaking about those that simply plead ignorance when it comes to the subject, no. I’m writing about the respected designers and developers who in recent months (years?) have been very outspoken toward the lack of advancement we’ve been suffering with.

There is quite a large group who feel the powers that be are not advancing technology to the best of their ability. Who can blame them for feeling like that? A quick mention of CSS3 will put that into perspective. I do need to be clear: I am the last person to discount the efforts of anyone. I’m so very thankful for all the hard work that’s gone into the technology so far, but I need to be honest in saying that I’m equally as frustrated as many.

I’d love to be able to write CSS3 without a care in the world. On the same page, I’d love to not have to worry about cross browser consistencies as well. I’d love to drop support for IE6 like so many others. There are countless reasons why IE6 shouldn’t be a concern, but the trouble of the matter is this: my clients are using it. Sure, we all try to educate our clients, but I’ve had limited (if any) success in trying to produce a browser convert. The support of IE6 seems to be, in part, backed by knowledgeable designers. All I can do at this point is sit back and be jealous of their success. For the time being, it’s not in the cards for me (yet), but I anxiously await the day.

2022

The latest strike against Web standards wasn’t a strike at all, it was a gut-wrenching twist from within. In a recent interview, well known and respected HTML5 editor [WHATWG] Ian Hickson, provided a timetable outlining the progress of HTML5. To get to the most interesting part: HTML5 will reach ‘Proposed Recommendation’ in the year 2022. It feels strange for me to type a year representing that long down the line, but it’s accurate.

It’s difficult for me to imagine a proposed timeline including milestones that far into the future. To me, in Internet years, 2022 feels like the year 4000. I think this timeline accurately represents the frustration held by many designers. I’d like to reference a quote from Jeff Croft. In his most recent article, Two Thousand Twenty Two he readily describes his frustration:

I’ve got work to do, here. I don’t have time to sit around reading specs and interviews by spec editors detailing what is going to happen in 13 years. God knows where I’ll be in 13 years. Quite frankly, I’ll be pretty [...] disappointed in myself (and our entire industry) if I’m writing HTML in 13 years. Hell, if I’m still alive in 2022, I’ll think I haven’t been playing hard enough.

I care about right [...] now. My clients care about right [...] now. Our users care about right [...] now…

I will admit, I’ve gone ahead and removed a few choice words, but I completely sympathize with Jeff. I’m as excited about the evolution of HTML as the next guy, but 2022? I, like Jeff, don’t have time for that right now. I’ve got more work to do than I can shake a stick at, and trying to keep up with a spec that won’t be ready for 13 years is not in my best interest at this point. It’s depressing to say it, but I’ve got to focus on worrying about things today. My company does client work, and they’re not going to care one bit about any of this; they care about their budget, their timeline, and their website working in their browser.

Again, I cannot stress enough how appreciative I am of the geniuses behind this evolution. I respect everything being done to advance the Web, but I think at this point, things are shifting. Instead of proposed specifications and the like, we’re going to see the browser makers themselves take control of the reigns and begin implementation sooner than later. That’s what I’m excited about.

Of course, I will continue to keep an open mind about HTML5, but until it reaches a level of applicable usage, I plan on sticking with the toolset I’m given.

What’s most frustrating to hear when a new project comes through the door is something similar to “we need this as quick and cheap as possible.” Immediately your creativity is strained by a timeline. In an ideal world, the creative department would never have to confine their work to a schedule. If that were the case, however, certain projects would never ever be completed. A project end date is part of the process, but forcing something to be “quick and cheap” should be in no-one’s best interest.

Websites on the cheap

As we’ve all heard before: everyone does Web design. It doesn’t take any special talent and can be done in a weekend. The stigma of Web design is unavoidable, and with each project you’re faced with an uphill battle to prove your professionalism and talent. The fight becomes draining quickly, and without quick resolve, the design process becomes a tedious chore instead of the craft you have come to love.

You cannot blame a client for wanting something to be affordable and within their budget. You can blame a client for having misconceptions and disregard for what you do and how you do it.

Client quality affects invoices

My office feels strongly about partnering with clients. We have been very successful when clients are equally interested in a psudo-partnership. Unfortunately, we’ve had a certain amount of difficulty when a client insists on putting our expertise to the wayside and art direct a project from start to finish. This, of course, only rises to the surface after a great kickoff meeting, too late for any red flags to be risen.

Not only do we become frustrated with the lack of direction a project falls under when a client becomes Art Director, we also face the recoil of client outrage when their cost estimations must be revised to compromise. Even worse is trying to explain an invoice value when the client forgot our discussion about the estimate revision last month. At that point, things are turned back around and we’re again given the label of “professional” and questioned as to our ethics and/or (lack of) industry experience.

I don’t mean to imply that an exchange such as this is at all common, but I can only assume you’ve had at least one bad client. Money is a terrible thing to argue about, but it should be respected on both sides. You’re a professional, and the invoice you provide will have an equivalent value of work to back it up. A client receiving the invoice should not only be prepared for it, but also be appreciative of your service. If he or she has had a negative influence on the project by making more work for you due to a personal bias, adjustments should be expected.

My company estimates project cost based on hours. We do our best to make estimations accurate by including The Client Factors as well as considering our past experience. We’ve become quite good at it, but there’s always room for improvement. The one thing that has remained completely consistent is the correlation between client direction and invoice figures.

We have a healthy respect for clients, and more respect for their knowledge of their industry. We can also have a respect for their knowledge of our industry, but here’s the problem: it’s usually terribly inaccurate. Whether it be based on limited experience, clients will usually have it stuck in their head that things are only done one way. That bias can (and usually does) mean disaster for a project. The relationship will be strained, the project will suffer, and the cost estimations are nearly useless.

Our most successful projects are a result of positive client education paired with an open mind and desire to learn. Project cost estimations are scarily accurate, and client satisfaction is through the roof. We do our best to predict the future as far as reading client personalities is concerned, but we’re only human, and predicting the future is difficult. Our main goal is to find common ground with a client, act as their design department instead of their design lemming, and make a solid effort to create the best end product we possibly can, all the while keeping their budgets and timelines in mind.

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.