Treading the line between designer and developer

Sass - Syntactically Awesome Stylesheets

Yesterday there was quite a lot of discussion on Twitter about CSS preprocessing frameworks such as SASS and LESS.

It was all in response to a blog article by Nathan Borror detailing why SASS isn’t for him. In the article’s comments there is some interesting debate on the pros and cons of preprocessing frameworks.

For the uninitiated, CSS preprocessing frameworks add clever functionality to writing stylesheets like variables and mix-ins, and ultimately result in writing less CSS to achieve the same result. A good thing in my book.

But it seems many designers are resistant to a technology that abstracts the syntax of a styling language that they are already familiar and comfortable with.

I’m cool with that. If a designer can design well then I don’t really give a monkeys what tools they choose (or choose not) to work with.

And I empathise with their point. SASS can seem a bit complex at first - certainly if you don’t know anything about Ruby. Whilst it’s true you don’t need to know Ruby to use SASS or LESS, seeing as they are technologies built on Ruby it stands to reason that if you know what a Ruby Gem is you’ve got a head start.

Doing it wrong?

So, SASS isn’t for everyone. That’s cool, we can all live with that. But a comment on Twitter by Andy Clarke got up my nose a bit:

Malarkey on TwitterPro tip - "If your CSS is complicated enough to need a compiler or pre-processor, you're fucking doing it wrong!"

Now I’m sorry Andy, but that comment is just ignorant. By your own admission you don’t get SASS, you can’t even install it let alone play with it long enough to come to a reasoned judgement, so you’re not really in a position to tell people who DO know what they’re doing that they’re “doing it wrong”.

The truth is that preprocessing frameworks do offer many practical benefits. One of which includes mixing the styles from unsemantic grid frameworks into your semantic IDs and classes. Surely that’s something that would get Andy wetting himself with glee?

The problem with preprocessing frameworks is not whether they offer any tangible benefits or not. Clearly they do if you know what you’re doing. The problem is the learning curve - the technical barriers.

Andy is a self-confessed “designer not a developer”. Designers want to design, not mess around in the command prompt. I can understand that.

In fact it’s quite common for web “designers” to be nothing more than masters of Photoshop. Even the casual mention of a doc-type or a selector can cause some designers’ eyes to glaze over.

For these designers, the point where they stop being a designer and start being a developer is when they switch off Photoshop.

Back to our friend Mr Clark. Not only is he a very talented designer, but he’s also one of the worlds leading experts on semantic and standards based HTML and CSS development. He’s written books on the subject!

So despite what Andy will tell you, I’d argue that he’s a designer who is also very skilled at a bit of development. Other designers like to dabble in a bit of PHP or JavaScript. And some take that further and learn other languages and frameworks.

The blurry line

People like to draw a line between designers and developers but the reality of working on the web means that most of us tread both sides of it a little bit.

Some people prefer to focus on the tools and skills that they are familiar with whereas others like to learn new tools and try new techniques. In either case is anyone “doing it wrong”?

Of course not.