Digital Web Magazine

The web professional's online magazine of choice.

Smart CSS Ain’t Always Sexy CSS : Comments

By Martin Ringlein

July 15, 2008

Comments

Ryan

July 15, 2008 11:58 PM

I have to say, I have been slowly moving towards this way of thinking (cautiously) since working on very large sites. My personal is small enough to keep semantic naming conventions but once you start developing 800+ page sites those semantics can become meaningless and very difficult to manage/extend as you build.

Also, in the past before so many sites used CMS templates, updating the html was a pretty big task. Now, you simply update one file that is included globally.

One technique I have been using lately is to give an element a structural/presentational name as well as a semantic modifier:
<div id=“navigation” class=“horizontal”>

This has really helped to keep the CSS simple.

Great article.

Martin Ringlein

July 16, 2008 12:45 AM

@ryan, thanks for the comment!

I think you hit the nail on the head. Many of us, when learning CSS, start by reading “CSS Zen Garden“ and “Designing with Web Standards“ and immediately apply that basic logic and understanding to our relatively small portfolio/blog sites; and then as we progress in our careers try and keep that strict purist mentality. And of course it makes sense; many of the inspiration sites such as CSSBeauty.com showcase great examples but are at the end of the day also small brochure type sites — I think there is something to be said for that.

Shaun O'Connell

July 16, 2008 1:14 AM

One thing to note is that it is not the job of CSS to overcome the shortcomings of your development team, content management system, or internal processes.

Hear hear!
I’ve experienced that recently doing the CSS for a complex web application, where the web app went thru a complete redesign of its front-end. Not only did we have to flush the old CSS and replace with new CSS, but we also had to edit multiple templates to get it to behave the way we wanted.
Thankfully it was mostly re-ordering of content (for floats) and adding more elements to allow for the more intricate design.

One potential point you missed is about readability. If many people are going to be working on your HTML and CSS, then it makes sense to write both in a readable fashion. Don’t obfuscate classes and ids by using acronyms or abbreviations. Break your CSS up into sections. etc.

I think there’s value in approaching a web app in a CSSZenGarden manner (ready for redesign). A redesign on code with good separation between content and presentation means you will be spending some work on the HTML but most of your work will be in the CSS. The less time you spend on maintaining multiple HTML files the better.

Good article.

Chris

July 16, 2008 1:33 AM

I agree that like all things it’s about being practical. Naming your markup for the remote possibility your footer will become a header sounds like a waste of time and money.

But I certainly wouldn’t want to see a return of class names such as ‘red’.

Giving elements semantic class-names makes the stylesheet easier to understand.

‘div.error’ is obviously a div that holds an error message.

‘div.red’ could be anything, used anywhere someone wanted red text. Dare I change it? Using the canonical example, say the font colour for error messages is changed by the designer. If I rename the class to ‘div.orange’ now I have to update the HTML file too.

That’s an extra step for no good reason. If I’m dealing with a static website, I might have to update that class across several files. And if I was going to do that, I might as well use <font color=“red”>!

Martin Ringlein

July 16, 2008 2:10 AM

@Shaun, I think many of us have been there, but that book just isn’t as popular as a classic Zeldman.

@Chris, I completely agree with you and to Shaun’s comment, there is much value in approaching front-end development in the “CSSZenGarden manner (ready for redesign)“. I think my automotive website example sums up the “red” issue and my concerns where it might be applicable.

I don’t advocate we go back to changing ‘div.error’ to ‘div.red’ … but what I fear is that basic fundamental thought is keeping us from making smarter more logical decisions where presentational meaning might be necessary. I’ve just been in too many sessions where we spend more time deciding what to name an element than we should have simply because we want to be “sexy” even at the cost of being logical and smart.

Really, at the core, this topic is just about realizing some of the early thoughts we had on best practice were really starting points and guides to learn and begin. Many of us are beyond the beginners state and yet we are fearful of breaking out of our early teachings that didn’t necessarily mean to constrict us the way they have.

They gave us training wheels so we could learn to ride a bike without the fear of falling; but many of us our building our own bikes and not realizing we don’t have to build them with training wheels; that was just a guide to get us started.

Patrick Griffiths

July 16, 2008 2:29 AM

This is simply the wrong way to approach the subject, which is why it is far from being smart.

The separation philosophy is a great one – markup is for one thing, style sheets are for another. It’s a brilliant complementary marriage, not an “unfriendly divide”. The early web standards adopters and advocates you talk of aren’t pie-in-the-sky idealists, they have (usually) suggested best practices that have lead to serious improvements in modern web design. And it’s worth noting that many have worked on sites of considerable size.

The following doesn’t make sense:

“Now, by adding one standard class name to any HTML list element you wish to be horizontal; you save yourself the four to five lines of your CSS that would have been required every time”

Why would you be requiring four to five lines of CSS every time? And there’s nothing magical about presentational naming conventions. However you write your CSS, if you believe you can save yourself lines of code by using a certain class name why can’t you use a meaningful class name instead of the presentational one? “utility”? “extra”? “further”? There will be something that makes sense from a meaningful point-of-view.

The argument about redesign is a very, very old one. Few preach that an entire site will be redesigned just via the CSS. Fundamental small changes that could render presentational attributes misleading is quite a possibility, though. But, also, what about other devices? What does “horizontal” mean to a screen reader? And might you use a different style sheet for print that makes some things that were vertical on screen horizontal? You might do. Again, the attribute names are rendered “meaningless” and can be downright confusing (especially when more than one person is working on a site, as you mention) when you need to think about how the content is displayed or otherwise accessed.

The bottom line is this: If you are in a position to create and edit the markup and the CSS there is absolutely no need and no advantage to calling things “red” or even “horizonal”. If you can’t handle markup simply as the structured content it is meant to be then you need to go back to Web Standards School.

Much like using the em element rather than the i element, when you’re tempted to use a presentational markup there is always a perfectly acceptable, better meaningful alternative.

Schmoo

July 16, 2008 3:15 AM

Amen, Martin, A-!#*&%#-men.

Common sense beats rule-following every day of the week. The moment you realise that is the moment the training wheels come off. (…and the moment just before that is when you’re loudest advocate of the rules, but hey, that’s another subject ;))

Ben Darlow

July 16, 2008 3:26 AM

What a confusingly written article, and what poor arguments. Reading the article felt like it was a rebuttal to some internal debate over how a specific client site should have been constructed, rather than what you’d expect from this site: clear and useful opinion on ways to improve our skills. Why would using a semantic class name necessitate more lines of CSS than a
presentational one? Why would you need metadata like car model colour to serve as a class name?

There are many definitions of the word ‘standards’ in the dictionary, and the one cited in the article doesn’t sound like the most appropriate description in the case of web standards (I would have gone for ‘a required or agreed level of quality or attainment’) but in any event the author appears to be confused about the difference between ‘standards’ and ‘patterns’; most of what we advocate to our fellow professionals are actually design patterns, and these generally exist for a good reason. Dismissing them by simply vilifying them with the notion that sexiness is the most important concern is a straw man argument.

It reminds me of reading something in the Daily Mail; lazy and uninformed opinions are presented in such a way as to seem to the uncritical eye as good advice, whilst quietly pandering to the unspoken preconceptions of the audience. But precisely what we don’t need is more web developers taking this attitude and dragging the web back into the dark old days of pre-standards web design.

Martin Ringlein

July 16, 2008 3:50 AM

@Patrick, thanks for the comment.

With respect to “… adding one standard class name to any HTML list element …” — it is more about thinking of the broader system. Terms such as “utility” or “extra” are not very meaningful and perhaps not practical. You could have a horizontal navigation for your global account navigation, for your footer navigation and then for a variety of tabbed modular content boxes; maybe even for a breadcrumb. One term doesn’t bring meaning to all of those; the logical consistency among them is the horizontal nature. Each are unique in what they do on the site, but share about 4 lines of the exact same CSS for their presentation; that shouldn’t be repeated time and time again.

I agree that the point on redesign is dated among veterans, but among the masses (designers, developers, managers and clients alike) the thought still exists. And rightfully so as many of us preached that thought when “selling” CSS for layout many years ago.

I am not an accessibility expert by any means, but I typically ensure my content is prepared properly for screen readers, not my class names. So “horizontal” wouldn’t ultimately matter to a screen reader — just as “sidebar” wouldn’t have much more meaning. I could be terribly wrong on that point though.

You do bring up an excellent point with print style sheets; and that goes back to my point of utilizing specificity and the cascade, and not being afraid to do so. This again is a highly debated topic with little to no resolution. But I personally take the stance that my print style sheet is an alternate one that compliments and works with the screen as the base and works backwards from that; in the same fashion as you would use filters or hacks to work with older browser compatibility issues. I agree, from the purest perspective, non-presentational meaning would be ideal, but that isn’t always realistic or more most meaningful (useful) — again, just as “sidebar” would make little sense in a print style sheet where it doesn’t sit on the side but rather under the primary content. You could even decide you want to print your footer at the top of the page; the slippery slope to making your names vague and meaningless to stay pure is a dangerous one.

When you state that you want to “handle markup simply as the structured content” your “simply” is the limitation. And that limitation can add to confusion among teams as well as bloated CSS. And there is just the practical reality that not everything can be non-presentational. We must realize that there are always exceptions and when we do so, that realization helps us work outside of many of those limitations brought on us from our early learning/understanding.

If you worked for Crayola and were tasked with creating a style that gave the color of the particular crayon a text color of that crayon; would you really not just identify the class with the color of the crayon? Isn’t that the easiest and most logical thing to do? I bet the best in breed could spend a few minutes or a few hours coming up with some convention that kept things pure; but should we? The text color only changes when the crayon color changes; so much more than the CSS is changing at that point.

Ben Darlow

July 16, 2008 4:03 AM

You could even decide you want to print your footer at the top of the page

Er, what? Then it wouldn’t be a footer. Logical order of items in a document has about as much to do with presentation as writing direction.

Martin Ringlein

July 16, 2008 4:12 AM

@Ben, that is sort of my point … it wouldn’t be a footer at all and now we are tasked with deciding what to call that div at the bottom of the site that most of us have traditionally called “footer” — because it may perhaps one day, some day, show up at the top of the page in a print style sheet; maybe, possibly could happen.

John Faulds

July 16, 2008 4:16 AM

Have to agree with Ben: didn’t find this a very well written article and didn’t bother reading to the end because it seemed to keep belabouring a point that could’ve been made much more concisely.

bruce

July 16, 2008 4:22 AM

There are some good points in this article, mostly related to the fact that CSS can’t solve everything: show me a big corporate website that doesn’t need a few br elements or extra clearing markup. But that’s because CSS is lacking, not because the “separation of structure and presentation” methodology is wrong.

you’re right with your car analogy. If I had a column on the left of red cars, and one on the right of blue cars, I would use class=“red” and class=“blue”, because in this instance those are structural terms (like “books” versus “CDs” or “Penguin” versus “Dingos”).

But that’s not an argument to use class=“red” instead of class=“emergency”, because red doesn’t mean anything here. (Anyway, for class=“emergency”, you’d want your text surrounded by strong tags to emphasise the importance to devices that couldn’t show colour. Then you’d style the strong elements within div class=“emergency” as red)

Martin Ringlein

July 16, 2008 4:40 AM

@John, sorry you didn’t make it all the way through the article. The point is relatively simple and I’ve highlighted it in a much shorter form throughout the comments. I felt with such a debated topic that more explanation would be necessary to some of the points that help support the concept.

@Bruce, I apologize, I think the article may have implied that I advocate using a class name like “red” over one like “emergency”. I was merely citing examples of the basics we learn in the beginning (not saying they are wrong). That is definitely not the case. My point is simply that “red” is an appropriate name in certain situations so we shouldn’t go into CSS thinking we can never use “red” as a class name, because there are in fact reasonable and logical reasons for doing so; rare of course.

And I agree with you that CSS itself has flaws and I believe that is the reason many of these topics are highly debated and are often left with little resolution.

Patrick Griffiths

July 16, 2008 4:45 AM

@Martin:

But this is about the broader system and you’re sounding like a complete novice. I’m not sure if this is more embarrassing for you or for Digital Web.

“When you state that you want to ‘handle markup simply as the structured content’ your ‘simply’ is the limitation…”

No, it isn’t. The beauty is in the simplicity.

“…And that limitation can add to confusion among teams as well as bloated CSS…”

As I’ve already indicated, and will do again, your method will more likely cause both more confusion and code bloat. I still don’t understand how this method can reduce code unless you don’t know what you’re doing in the first place.

“…And there is just the practical reality that not everything can be non-presentational.”

Then you really don’t know what you’re doing in the first place.

“utility”, “extra”, etc. might not fit, but why would you want a class for everything that has a common presentational aspect, such as it being horizontal? That’s absolutely nuts. It would inevitably lead to enormous code bloat and repetition (because you’ll have so many class names) – the very things you say you want to avoid.

I’m not saying that “horizontal”, or whatever, somehow messes up screen readers or printed media, or anything else (you’re missing the point – it’s not about bending around the code to fit), but a web site designer has to consider these things and if you have a presentational, rather than a structural content, mentality, you are more likely to come a cropper. Obviously.

That’s the essence of it, and that’s why you’re so hideously wrong. If a developer thinks that presentational markup is preferable to meaningful markup (and the term “presentational meaning” is really missing yet another point) except in the most absurd cases, then you need to go back to the start and read (and understand) the basics.

In some ways I feel I should apologise for my tone, but I won’t. This makes me – and should make others – justifiably angry. These battles were won years ago against either novices or hardened pros who stubbornly didn’t want to change.

This graphic design-lead rant is muddled and naive. There’s so much more to front-end web development and, as professionals, we should have moved on.

Alun

July 16, 2008 5:09 AM

The approach in this article also seems to miss the point with regards to the issues of scaling.

If, for example, you are talking about a site with hundreds of pages all having an extra class or two then you are talking about potentially having thousands of lines of extra code being delivered to the browser as opposed to a few extra lines of CSS.

Martin Ringlein

July 16, 2008 5:15 AM

@Patrick, I get it and I appreciate your candid tone. I highly respect you and I’ve looked to you as an amazing resource for many years now. And I know the point of view you are coming from.

I know this is a highly debated topic and there will always be two sides and will continue to not have proper resolution.

My point to code bloat was that…

This:
ul.horizontal li {display: block; float: left;}
ul.horizontal li a {display: block;}

Is less than say this:
.globalNav li, .sideNav li, .footNav li, .moduelNav li {display: block; float: left;}
.globalNav li a, .sideNav li a, .footNav li a, .moduelNav li a {display: block;}

And that wasting time to come up with something like class=“navStyleB” to be generic becomes vague and detrimental.

And with that being said …

This:
<ul class=“globalNav horizonal”>

Is still shorter (considering the CSS) than:
<ul class=“globalNav”>

And that is hoping that you are not repeating the display and float elements for each individual navigation class; which would really increase the bloat.

Mike Stenhouse

July 16, 2008 5:21 AM

“You could have a horizontal navigation for your global account navigation, for your footer navigation and then for a variety of tabbed modular content boxes; maybe even for a breadcrumb. One term doesn’t bring meaning to all of those; the logical consistency among them is the horizontal nature.”

And that they’re all navigation. So “nav” would be a reasonable, meaningful class name. They’re all going to sit in distinct contexts so “div#footer .nav” can both share the horizontal style of other .nav elements and be tweaked for footer display. Either way, “nav” is useful metadata. It’s the kind of hook that makes sense in Javascript as well as CSS, when “horizontal” clearly wouldn’t.

If you think of the class attribute as metadata and choose names appropriately you’ll save yourself pain. I can’t imagine why anyone would do otherwise, to be honest. I thought this battle had been won…

Martin Ringlein

July 16, 2008 5:23 AM

@Alun, scaling is definitely a concern. But when you are getting to the scale that you are counting characters there becomes a larger problem over all. Two class names on an HTML element can be just as long as changing “footerNavigation” to “footernav” to “fNav” or “fn”. Less is more and I agree with that; but keep it as small as possible while keeping it as intuitive as possible.

My concern is more on scaling from a human resource perspective, as well as a business development perspective. Working in large teams that perhaps have never spoken together or passing off large sites to clients that will never interact with the original developer after the point of hand-off.

And working with or without those limitations on implementing rapid modifications or additions that take little time, thought and have a level of guarantee to their expected result on the first attempt at deployment of something new.

Martin Ringlein

July 16, 2008 5:26 AM

@Mike, “nav” is a great idea, but it implies all navigation — both horizontal and vertical (even upside down and sideways if you want it). A typical large scale site can have many navigation elements in a variety of presentational forms. And I’d argue that you might want a list element to be horizontal that isn’t navigation at all; perhaps its instructions to something and you wish to present that on one horizontal line.

Matthew Pennell

July 16, 2008 5:38 AM

Hi guys,

Just wanted to respond to Patrick’s comment earlier — Digital Web is certainly not “embarrassed” to have run Martin’s article; our mission is to publish information and opinion on subjects of interest to web professionals. Martin’s article covers a topic that will be relevant to anyone who has worked on large-scale sites, particularly where they must be handed off to somebody else (often an internal team) at the end of development.

Matthew Pennell
Editor in Chief

Patrick Griffiths

July 16, 2008 6:13 AM

@Matthew

I have to say I’ve had a huge amount of respect for DW for a long, long time.

Perhaps “embarrassed” was the wrong choice of words, but I still certainly find its inclusion and promotion a little odd.

Although you emphasize “opinion”, this is presented as an authoritative article and it strikes me as slightly irregular to DWs usual style and high regard for responsible journalism.

This shouldn’t be relevant to those who work on large-scale sites – I don’t see why that’s an issue at all. It is advocating practices that were argued over many years ago and subsequently largely concluded to be misguided.

Bradley Wright

July 16, 2008 6:13 AM

It seems to me that this whole article can be boiled down to “sometimes you need to cut corners when building websites”, and judging by my own experience and the voice of comments here, some somewhat flawed examples. If you want something to be horizontal when it’s not nav, it’s something else and should be called such. It’s certainly not .horizontal . How is that any different to <TR>?

In my opinion, having been involved in the development of some of the biggest websites in the world (ex-Yahoo!), cutting corners is something you most definitely do not want to do unless you have a damn good reason to do so, as it’s on big teams that code quality and standards are most important, as they ensure consistency and ease of modular/distributed development.

This article would have been better put as an education piece as to how to make teams efficient when requirements conflict with code quality, and when to best cut corners. Making CSS shorter is a red herring, as to experts it’s no easier to understand, and any large scale site should have a defined build process that takes care of file size for you. Code for humans working on one or more parts of your code first, and let machines take care of the rest.

The lessons presented here are too basic for true professionals, and too damaging for basic developers. Additionally, if the editors want to come out in defense of the writing being fairly criticised on their site, they would be better served by not obviously re-hashing the author’s own comments.

Mike Stenhouse

July 16, 2008 6:16 AM

@martin: I’ve worked on more than a few very large scale sites and I’ve never had that problem. I used “nav” because every element in your example list is a form of navigation so I picked that as the common trait. Had your example list had been different I would have chosen something else. You’re moving the complexity from the CSS to the HTML and Javascript. That may be an acceptable situation on a particular project but it’s a compromise. You can choose to make that compromise if the project calls for it but it’s a trade-off that you’ll pay for elsewhere.

I honestly came across this in someone’s portfolio while looking to hire a while ago:

.leftNav { float: right; width: 220px; }

Matthew Pennell

July 16, 2008 6:24 AM

If you want something to be horizontal when it’s not nav, it’s something else and should be called such. It’s certainly not .horizontal. How is that any different to <TR>?

Now who’s using flawed examples? It’s patently obvious that .horizontal conveys more information than TR.

Martin’s point (and I’m sure he’ll correct me if I’m wrong) is that, should you be working on a site and you decide to create a new list that you want to be displayed horizontally, it is far easier to add a class=“horizontal” to your UL and have it work straight away, than make up a ‘semantic’ class name or id, then track down the relevant CSS declarations that control horizontally-aligned lists and add your new element to those rules.

You are right – standards are important in big teams; what you are choosing to ignore is that .horizontal can be a standard as well.

Martin Ringlein

July 16, 2008 6:54 AM

@Bradley, I think you said it best “The lessons presented here are too basic for true professionals, and too damaging for basic developers“. — That is an accurate statement; one that plagues the industry in general beyond this article. There is a huge gap between those playing on CSS Zen Garden for the first time and those building the next iteration of Yahoo.com.

@Mike and to all, there is a fine line between cutting corners, being lazy and being efficient. My .horizontal example is primarily based around the concept that anyone can create a horizontal list out of a UL or OL regardless of the context with nothing more than the addition of a class name (an intuitive one). Without the need to go through the CSS to find how it was done previously (to be consistent), no need to replicate lines of CSS that already exist to accomplish the same objective and all without needing to collaborate with the original author. I can see how my statement might be called lazy or corner-cutting; but I hope some can see how it might also be called efficient and useful.

@Matthew, that is my intention, well put (perhaps summarized better than myself).

When we have an H3, we set one set of rules to define that element and wherever it differs from that set of rules, we alter the change only. So h3 and h3.highlight might share the same font family, size and weight but different in text color. But we don’t re-declare all of the base rules for h3 that we create everytime we use a differing instance of that h3 — that is my point to the horizontal navigation. Create a base rule set and be used throughout the system.

Bradley Wright

July 16, 2008 6:56 AM

It’s patently obvious that .horizontal conveys more information than TR.

Is it? If anything, I’d argue a TR carries more information, since at least it tells you it’s a row of cells. I’ll give you the benefit of the doubt (and the usual lack of context over Internet communication) and assume you just worded that in a particularly bad way.

You are right – standards are important in big teams; what you are choosing to ignore is that .horizontal can be a standard as well.

No ignoring here—I’m criticising the point that presentational selectors are useful in place of semantic selectors. An article on coding standards and management that’s pitched at professionals would be far more involved than this, and one aimed at beginners should not enter into dangerous water like flaunting basic semantics (or ‘semantic(s)’, to quote yourself) on the flimsy grounds presented here.

Jared

July 16, 2008 6:59 AM

I’ve been fitting this approach into my work over the past few months. There are instances where using presentational names makes much more sense. For example, I see this in many blogs: class=“float-right”. This, in my opinion, is a perfectly acceptable case for a presentational name. You can flexibly apply it to any element you choose, keeping your CSS lean. If I have a class of float-right, then I’ll probably have a class of float-left. When I hand this off, I’m pretty confident it will not come up in question.

Now, do you apply this class to everything that floats to the left or right? No. You apply it where it makes sense and only where it makes sense. We all work with different types of people of under different circumstances on different projects. If Martin’s method is not right for the project, don’t use it. If it is, then by all means go with it. Use your best judgement and write your CSS accordingly.

Bradley Wright

July 16, 2008 7:02 AM

Alright Martin, fair play. Code management and efficiency are valuable in any project and certainly should be discussed. I just wish you’d chosen better or more in–depth examples for the beginners.

Ben Darlow

July 16, 2008 7:06 AM

You know what would be really cool? If we just used tables! I mean, WFM.

amirite?

Bradley Wright

July 16, 2008 7:12 AM

This, in my opinion, is a perfectly acceptable case for a presentational name. You can flexibly apply it to any element you choose, keeping your CSS lean.

Then your opinion is wrong. HTML should be optimised as it’s the only thing guaranteed to be seen by every visitor to your page, human or otherwise. And sorry, but using float-right as a class name is even more ridiculous than using right. Why not just put the styles in a style attribute and be done with it? There’s absolutely no separate of style and content in using those class names.

Martin Ringlein

July 16, 2008 7:13 AM

@Jared, I appreciate the comment! I can already feel the comments coming in condemning such an example as “float-right”.

However, it is a common practice to float something to the right and typically give it a left margin and vice-versa. If looking through your CSS file and you notice a dozen instances of …

Something like:
.photo_positionB {float:right;margin-left:5px;}

Then maybe you can condense that and utilize something like:
.pos_right {float:right;margin-left:5px;}

It becomes about condensing the CSS and creating that base style. I know you all hate that the suggestion implies position with ‘pos’ and presentation with ‘right’ … but it does create a systematic and logical approach to a common task that may occur many times over; perhaps even an easy element for content editors to use when writing in a CMS and using HTML.

@Bradely, I respect that; from the comments, I’d say you are right.

@Ben, sounds like a nightmare and I am certainly not advocating that. But, I am sure respected sites like NYTimes.com had their reasons for using tables to control some layout beyond tabular data. Like with tabular data, you can’t say never use tables; no professional would advocate a statement like that.

Ben Darlow

July 16, 2008 7:21 AM

Sarcasm detection failure. I thought the absurdity of suggesting such a directly presentational classname as ‘float-right’ was self-evident enough for me to mock it.

Martin Ringlein

July 16, 2008 7:31 AM

@Ben, I got the sarcasm :-)

I just think it’s a good point; those of us less than 10 year veterans have grown into this industry knowing nothing but the fact that “tables are bad”, some still try and do tabular data without tables because of that fear (wrong, I know, but it still happens).

I think this article alludes to the same issue; we grew into this industry being told not to use tables for layout, to separate presentation from structure — and I fear some have taken that too far where it becomes rather silly and often times detrimental.

Tabular data in a list element is possible, but don’t do it because all you know is that tables are bad. “navStyleB” is an acceptable class name, but don’t do it because all you know is that presentational names are bad.

Bradley Wright

July 16, 2008 7:40 AM

(T)o separate presentation from structure — and I fear some have taken that too far where it becomes rather silly and often times detrimental.

Got an example of that? That’s a pretty bold claim, and I happen to think you’re absolutely wrong.

Martin Ringlein

July 16, 2008 8:15 AM

@Bradley, I don’t think Patrick at HTMLDog will mind if I use him as an example; but his use of the class name “jelly” on his navigation is an example of something that works for him personally but not for us coming into it blind. It doesn’t have presentational meaning, but does it have intuitive meaning at all? Would you know what “jelly” did or when to or how to apply it to other elements?

@Patrick, just using your mark-up as an example, I don’t mean to imply your mark-up is silly or detrimental. I don’t proclaim mine to be perfect or by any means better. You just had an interesting example I thought I could cite from.

Chris

July 16, 2008 8:23 AM

Hehe, well it looks like you whipped up some controversy anyway. :)

Thanks for the reply, Martin.

Cheers,
Chris.

Ben Marvell

July 16, 2008 8:41 AM

facepalms

@Martin do you not think as Web Dev’s we have enough to sigh about in a day without you writing an article like this? Cheers, you just aged me that bit more…

Martin Ringlein

July 16, 2008 8:53 AM

@Ben Marvell,

Sorry for that. But that is sort of the point of the article as well. Here we are a group of intelligent front-end developers debating over the use of a class name. Is the internet going to break if you use “horizontal”? Does .NET not add worse to our mark-up? Are in-line styles not a bigger sin?

The point is to not fear presentational meaning because it can be appropriate. The goal is to keep your CSS light, intuitive and meaningful. Don’t be redundant when not necessary and be intuitive when possible; even if some presentation slips in.

There are bigger problems on the internet with respect to best practices

You want your code to be perfect and pure; I get it, I want the same thing. But realize that perfection is within context of any particular project and the problems your code seeks to solve.

Ben Marvell

July 16, 2008 9:07 AM

@Martin

“You want your code to be perfect and pure; I get it, I want the same thing.”

You see, the thing is, I don’t think you do. Goto your site look at the pretty slider disable javascript and revel in the fail. If you cant make your pride and joy work well, what hope do you think we have as consumers of your preaching?

Victoria Pickering

July 16, 2008 9:08 AM

Martin-
Thanks for writing something that triggers a lot of discussion. While I don’t agree with all of your examples and specifics (and my guess is that you’d find it boring if everyone did), I agree 100% with your premise of choosing smart over sexy.
I’d argue that there are two criteria for judging whether code is smart:
1. does it deliver the desired performance results (load times, bandwidth, searchability, cross-platform performance, etc.)? – not necessarily reaching the absolute ultimate performance possible but delivering results that are good for the client/user/environment etc.
2. how maintainable is it – can other teams easily inherit and update it years later, rather than finding it necessary to trash and start over? As someone who originated in the mainframe era, I’ve dealt with vast amounts of legacy code in my career, and seen the damage it does in both wasted time and stifling innovation.
So, while I can develop extremely elegant code, I make sure that it is not at the expense of real-world practicality, and I think that the underpinnings of what you are advocating are similar.
Victoria

Mark Norman Francis

July 16, 2008 9:14 AM

This, it seems to me, is a very naive view of what is difficult about CSS scaling to many pages or multiple sites. I think the attitude of the author is betrayed here:

Smart CSS is about being meaningful; it is about not being vague and redundant within your CSS simply to be more “sexy”.

It’s the idea that people would write their CSS with redundant rules because they haven’t considered why, but are somehow following the “cool kids”.

Actually, there’s a very good reason to write redundant CSS. Which is that you are making the reasoning behind the code explicit. You are documenting the expected outcome for the next maintainer. You are not saying “hey, a few things look the same, bosh a class on them”. You are saying “this area behaves like this; this area behaves the same (for now); this area also behaves the same”.

If you didn’t have an intimate understanding of everything in the site and the CSS (and that’s anything beyond a simple blog or brouchureware site with a minimum of pages/templates/differences) you could modify the code you thought applied to a given area, only to have it have a knock-on effect somewhere else that you just didn’t expect. Further, you might not even notice it.

This is the biggest problem with scaling as a front-end developer – that you don’t want to have to test and re-test every single thing when making what should be a simple change.

This is not about saving bandwidth. I set standards at Yahoo! across Europe for front-end developers and (as Bradley Wright said above) the authors come first, because bandwidth can be saved by applying compression and automated rewriting scripts to maximise savings. We can’t rewrite developer’s brains anywhere near as easily, and we certainly can’t just throw five more people at a problem.

Writing smart CSS is not about finding the commonalities of disparate sections and refactoring them down to save a rule or two. Writing smart CSS is about writing maintainable, explicit, future-proofed CSS. This article tells you to do the exact opposite, and that is not “smart” in my opinion.

Matthew Pennell

July 16, 2008 9:19 AM

@Ben Marvell: http://en.wikipedia.org/wiki/Ad_hominem

kthxbye :)

Martin Ringlein

July 16, 2008 9:29 AM

@Ben, I tried making it clear in the comments that my personal site isn’t one for judging as I don’t claim it to be perfection (it’s just a blog, and that is okay); and this article isn’t about graceful degradation of javascript either. Someone else can write about Smart JS vs. Sexy JS. Show me a site where the code is perfect and pure? Perfect is something we aspire too, nothing we claim to have accomplished.

@Victoria, thanks for the comment. I think your last paragraph really says it all!

@Mark, I get your frustration as similar comments allude to the same thing. But the simple fact is that Yahoo! CSS today is nothing like Yahoo! CSS 10 years ago and will be nothing like Yahoo! CSS 10 years from now; the beauty of developing on the internet is that you can change. Hell, the Yahoo! business model in the past 10 years has changed and you hang on to keeping the CSS in tact? The ideals of web standards are great, but the reality is that much of what could come in CSS3 and beyond will force us to change our mark-up and our style sheets — how future-proofed are you working towards?

Finding the commonalities is a part of the article, but the main point is making the CSS light and intuitive; reducing human confusion and code bloat. Don’t be afraid of your HTML when working with your CSS; don’t struggle to separate them when they work so closely together. It isn’t about saving a rule or two, it is about saving time and energy working with rapid development on teams that may have little to no communication and that not having an impact. It is about working with a pre-existing entity and replicate its parts or whole effortless — having it make sense and not be vague because you want to impress ‘the cool kids’.

Anton

July 16, 2008 9:29 AM

If you all don’t mind, I’d like to add my $.02 in that regardless of what classnames you decide to use, if you are in a situation where you have a large site that’s going to be handed off to other developers then you really need to be creating style guide documentation to accompany it to define usages and provide examples.

Otherwise, expect nothing but confusion and possible failure from those inheriting the work provided to them without instructions.

Mark Norman Francis

July 16, 2008 9:48 AM

@Martin – When I say “future proof” I do not mean “set in stone for a decade”. The CSS we ship on our properties evolves on an almost daily basis, and any actively developed property will generally have some sort of update every month or so. By future proof, I mean to say that the developer making a change knows what to expect from the outcome. This is the crux of my argument – by combining rules and playing fast and loose with semantics you are robbing the ability of one person to fully understand the impact of a given change.

By properly modularising code so that it affects only the intended area of change, you can update areas of a site without re-testing everything. You are also much more likely to be able to simply re-use code from another developer, and to properly inherit from truly global stylesheets, because those have also been written in a modular way to minimise side-effects.

This approach also makes you much more agile. You can modify one thing and ship it in hours, precisely because it is modular and has been written to avoid complications.

I suppose we are both advocating the same goal, we just see the means of achieving it in a diametrically opposing way. You think people will be less confused by classes and sharing code where the end result is expected to be the same. I know from bitter experience that this is a very short-term solution, and that being verbose and explicit is a much better approach for long-term sustainability of shared code. This is not about the separation of style from content. It is about a separation of concerns. I shouldn’t have to bear in mind the header when modifying styles in the footer or side-navigation.

Dan

July 16, 2008 12:11 PM

Mark, it occurs to me that that’s exactly what the cascade is for. I don’t think that Martin’s point at all conflicts with the clear and accepted best practice you’ve outlined for scaling larger projects. Having one presentational modifier class mixed in with a sound and well-planned structure isn’t going to create unpredictable results for future maintainers.

I think it’s fair to expect that nobody is going to alter the .horizontal class to make it stack vertically and then wonder why all their horizontal page elements are broken; rather, they’d more likely be augmenting another more semantic classname associated with the same element, or overriding with something else with a higher degree of specificity.

I also think that there are two distinctly different points of view here based on two very different types of developers. Coming from an in-house environment tasked with maintaining and evolving an application, you quickly learn to work one way. At the same time, working in an agency to deliver a fast and easy-to-implement outline (essentially a high-fidelity prototype) is going to lend itself to another, very different style.

As it was said above, common sense always takes precedence. I think the takeaway was that not all development projects have the same purpose, and shouldn’t be confused as such—the most right way doesn’t necessarily correspond 100% with the most appropriate way all the time.

Mark Norman Francis

July 16, 2008 1:14 PM

Having one presentational modifier class mixed in with a sound and well-planned structure isn’t going to create unpredictable results for future maintainers.

I respectfully disagree – I have seen it many times and had to scramble to recover from it. That was my original point. What Martin classes as “redundant” code is actually essential, in my experience.

Speed of development is not the issue either. It is about developer rigour and maintenance – and this applies to quick prototypes equally. We have used a modular approach to deliver rapid prototypes (in a recent internal Hack Day a team of five people delivered nineteen websites in 24 hours). So I disagree that this is a case of either-or.

Steve Marshall

July 16, 2008 3:27 PM

Smart CSS is about being meaningful; it is about not being vague and redundant within your CSS simply to be more “sexy”.

Presentational classes (like .horizontal) as advocated here are precisely the opposite of this: they’re vague and offer no indication of what they actually relate to within the site.

Attempting to manage CSS in this way within teams, particularly for continued development of sites (as tends to be the way for in-house development teams, like those at Yahoo!), can only result in one of two outcomes (or some halfway house):

This probably isn’t much of an issue in fire-and-forget style development of sites but, where long-term maintenance of code is paramount, knowing precisely what the CSS you’re looking at affects, and where on the site makes the difference between an hour of development with an hour of testing and a day of development, a week of testing, and another of bugfixing.

Further, the article seems to present the idea that HTML’s sole purpose is to provide a framework on which to hang CSS; rather, HTML is the only piece of the web standards stack that can be relied upon. With that in mind, the HTML should be as pure as it can be. The CSS should be tailored to work with the HTML, not the other way around.

The sentiment that ‘smart CSS is about meaningful’ is arse-backwards: HTML is where the meaning lies, CSS’s sole purpose is to aid the delivery of that meaning through apt presentation. To approach the issue from any other position is to completely misunderstand the medium of the web, and perverting your markup to aid the presentation is the last thing one should do.

Tiff Fehr

July 16, 2008 5:57 PM

@Steve Marshall—you beat me to my point, and more concisely, too. Thank you. I wish I had the intellectual/standards-zealot luxury of teasing out CSS standards for presentational v. structural CSS at my day job at msnbc.com. Perhaps it is a trait of journalism, but meaningful markup is 1,000x more important than semantic class and ID attributes. In our case, CSS sometimes carries a layer of semantic meaning, but that is mostly as metadata for our journalists—content sources, edit history, taxonomy—rather than meaning anything (in display effects) to our readers. If we end up with a string of semantic and presentational classes, we take it as a signal to step back and re-examine the markup. Of course, that’s working within a time-bomb of inherited, multi-developer front-end code.

This topic really shows a divide between people involved in short-involvement development v. long-involvement development, but I don’t think we’re bridging any differences. There is an ideal implicit in the idea of separating markup from style that we can build a massive site running on perfectly semantic markup and smart_+sexy_ CSS. But reality is much more grim and hacky. I have personal vendettas against specific classes that have been in msnbc.com’s markup for 4-5 years of content generation, and my carefully planned removal of the class has a project-dependency and step-by-step plan that will take another year, at least. These are the factors limiting some sites, and zealot-like adherence to standards and presentational v. structural CSS—or smart v. sexy CSS—is a luxury we can only indulge occasionally.

So, my lingering question in all this is: where is the middle ground of nuanced CSS usage that can further the discussion of semantics, standards and style-v.-structure without triggering the usual stances and absolutes?

As an aside, I’d like to thank everyone who has left a comment in response to this thread. Serves me right for seeing the first few come in after I published the article, but then opting to go to bed rather that contribute to the first few. I get back around to the conversation this morning (with a nudge from Matthew about the individual v. team dev schism) and it was already feisty. It’s great to see, even if I’m late in contributing.

Dan

July 16, 2008 8:34 PM

What if you wanted to redesign a site without having to dig through the php/asp in the cms to alter the markup…

I see many people saying that they think presentational naming is useful for working on large web applications and projects. How is that possible? Its infinitely more difficult to dig through the code which generates a page and alter the output, than to just have a system that outputs correct, semantic markup from the start.

When did we become afraid of altering our markup? ooh, I dunno, maybe over ten years ago, when static pages died out?

Bradley Wright

July 17, 2008 1:07 AM

So, my lingering question in all this is: where is the middle ground of nuanced CSS usage that can further the discussion of semantics, standards and style-v.-structure without triggering the usual stances and absolutes?

I think an article about code re-use and modularity would be the way to go. Most of the issues here (leaving aside semantic debates) seem to be around what the actual definition of “future-proof” is, and what value we should ascribe to it.

Andy Budd

July 17, 2008 1:15 AM

Very entertaining article, and always fun to put the cat amongst the pigeons. However like many other readers I obviously have to call bullshit here. This is less to do with being a CSS fundamentalist and mostly about the series of logical flaws used in the article to back up an already weak argument.

First off there is a big difference between using vaguely presentational terms like ‘header’ and ‘footer’ and choosing a name like ‘red’, which as far as I can tell contains no ‘presentational meaning.’

Secondly while the author eschews semantic naming conventions in favour of identifiers like ‘horizontal’ he doesn’t actually explain why this is any smarter than using a semantic name like ‘main-nav’. It still has a standard class name and can still be presented differently based on context. It’s just easier to see from the HTML what this element actually does, making it more meaningful, not less.

In some cases it feels like the author is arguing for semantic mark-up rather than against it. Particularly when he starts talking about the fact that people working on a site aren’t always the people who created them. Personally I would find ‘main-nav’ and ‘error’ much more useful that ‘horizontal’ and ‘red.’

The author also mentions that un-semantic names are better because you can add more classes, which is obviously a logical fallacy as the number of classes you use has no bearing on your naming convention.

The only thing I would say is that the author does have one interesting point towards then end of the article when he discusses the rare instances when items themselves are differentiated purely by presentation. However in the described situation I’d argue that ‘red-car’ is semantic as it’s being used to describe the item itself, not how that item is supposed to be presented. If all red cars were displayed on a green background, then ‘car-green’ would be presentational and wholly unsemantic.

Sadly it’s the tone of the article that really bothers me. The author obviously has a very weak argument so tries to strengthen it by suggesting his way is ‘smart’ while belittling other people for trying to look ‘sexy.‘My feeling is that if you can’t put forward a logical argument without resorting to emotive language you’re obviously on a losing streak. Definitely more Fox news that BBC, if you know what I mean ;-)

Kerri Hicks

July 17, 2008 5:41 AM

“navStyleB” is an acceptable class name, but don’t do it because all you know is that presentational names are bad.

Well, no, it’s not an ‘acceptable’ class name. That’s the point. It says nothing about the content of the element it’s applied to, except that it’s a nav of some sort, which is somehow different than other nav. It doesn’t tell me why the content or requirements of this nav would be different than any other nav, or how I could identify what content to use it with.

If you’re feeling a need to create presentational names such as navStyleB (yes, I’ll make the case that it’s a presentational name, or at the very least, a meaningless placeholder for a presentational name — it certainly doesn’t carry semantic meaning), maybe you just aren’t commenting your CSS enough.

Martin Ringlein

July 17, 2008 7:17 AM

@Andy, Thanks for the comment.

I do not mean to suggest that we replace class names such as “main-nav” and “error” with others such as “horizontal” and “red” — far from that. I am suggesting that perhaps you use “main-nav horizontal” in the instance that “main-nav” shares a variety of presentational similarities to over a dozen other list items like it. My point was not unnecessarily bulk up your CSS by repeating the similarities in “main-nav”, “foot-nav”, “side-nav”, and “modular-nav” … but instead remove the four lines of similarity that make each of those items horizontal and place them in a single class “horizontal” — but call it whatever you want. Call it “jelly” or “superman” or “listStyleB” — the point isn’t calling it “horizontal” the point is that you take the like similarities and put them together rather than repeat them over and over again.

And many of the comments have brought up the point that using a class name such as “red” is flawed when one such as “error” will do — I completely agree. The point isn’t to argue the use of something like “red” … the point is to remember that using “red” or “car-red” is acceptable in certain situations. Just as many of us were programmed to know that tables are bad, many of us have been programmed to know that presentational naming is bad … but tables are acceptable in certain situations, like for tabular data, and my point is that presentational naming can also be acceptable in certain situations such as working with that car manufacturer.

I am not advocating we take two steps back and party likes its 1999. I am simply advocating that we make our CSS as light and meaningful as possible — make it as easy to use and as small as it needs to be.

You and many other very influential people have taught us what we know about best practices (and, thank you!); but my point was that many of the off-situations that we are running into now that we are all grown-up were never covered in our early readings. And now, many front-end developers sit there spending time thinking of what to name it when “if” happens. The point is that, go ahead and use “footer” or “header” or “tophat” — don’t let the desire to be perfect make you more vague than you need to be. Heck, some of the early influencer’s use class names like “top” and “bottom” — which I know have pushed me to think differently. Of course, I thought it was implied that we not go overboard and convert “error” to “red” … but “sidebar” is a common naming convention and we should be content with it regardless of its presentational implications. Arguable I know, the comments have more than proven that.

Chris Coyier

July 17, 2008 7:30 AM

I think there is just a lack of good examples in the article, but I am in agreement that being absolutely super-duper 100% semantic with your class and ID names all the time just isn’t practical.

I have a utility style. I call it “floatRight”. I use it all the time, because often it’s the only attribute I need to apply to a page element. It is PURELY presentational, thus non-semantic. It’s “smart”. It keeps me from having to write #main-content .post img.topFeature { float: right; } and 10 other selectors like that to stay 100% semantic.

Mark Norman Francis

July 17, 2008 7:42 AM

I am simply advocating that we make our CSS as light and meaningful as possible

That is the central part of my point — that is a short-term gain and a long-term pain point. It saves you minutes developing a new feature/module/section/whatever by being able to quickly use a known style. This works only as long as the styles continue to be shared, and the moment they diverge you have created an exponentially large amount of work to re-factor your CSS (and potentially your HTML too).

Jeremy Carbaugh

July 17, 2008 8:00 AM

I can definitely understand Martin’s urge to have generic CSS properties that can be used to give a common style to similar elements. Aside from whether it should be done or not, common styles can simplify development.

Rather than including these common styles in the HTML, it would be great if there was support for CSS property inheritance. Much like object-oriented programming languages, property inheritance would allow you to have a property for a specific element inherit style from a common style.

I’ll take the liberty of making up new syntax for this example:

~horizontal { ... }
.main-nav (horizontal) { ... }
.chapter-nav (horizontal) { ... }

The main-nav and chapter-nav properties would inherit the attributes defined in horizontal. This would accomplish the same goal that Martin is arguing for, yet at the same time keep the HTML free of presentational information.

Martin Ringlein

July 17, 2008 8:25 AM

@Mark, thanks for hanging in there with me and keeping the comments coming; do appreciate it!

I understand your comments about the long-term and that is why I followed up with the bit on specificity and the power of the cascade. While I agree it is neither ‘smart’ nor ‘sexy’ to target ‘#sidebar .horizontal’ and make the list vertical — it is certainly possible and relatively easy to do so. But to change that nav list to become vertical, isn’t it easier to open the template and change the mark-up to remove class ‘horizontal’ and instantly it becomes vertical to its natural state?

My point was that in this situation you don’t have to alter the CSS at all — in your situation you do (and possibly the HTML). I was saying that in a situation such as this, editing the HTML is easier and comes with less possible complications (will the removing of certain styles break other things about the entity; such as removing the float:left or the display:block).

Dan

July 17, 2008 9:39 AM

@Jeremy Amen! I’ve been wanting OO-CSS for the longest time. At some point people need to accept the fact that changes cascade throughout a project. You (I) simply can’t encapsulate CSS in a smart (sexy?), reusable way as it is now.

If I can’t define a layout object called horizontal (which is semantic in the context of a layout, not in the context of data or structure) and then subclass from it for instances as they deviate, then what’s the point of worrying about the ‘right’ way? Find-and-replace across hundreds of repeated selectors seems like a shabby substitute for a properly complete language specification.

Tiff Fehr

July 17, 2008 10:13 AM

I think an article about code re-use and modularity would be the way to go. Most of the issues here (leaving aside semantic debates) seem to be around what the actual definition of “future-proof” is, and what value we should ascribe to it.

@Bradley Wright: Wow, that’s a great answer. Thank you. That is an excellent topic that would take the best parts of this comment debate with a more specific focus. I haven’t seen much about that topic at all, given the skew toward freelance-style code examples and scenarios in articles. Follow-up question: what kind of examples would best fit an article on the topic? I’m concerned that examples showing the complexity behind a large, team-maintained site would be alienating or so self-conflicting it wouldn’t make for a good example. What size of project would be illustrative for both camps?

@Jeremy Carbaugh (plus Dan Drinkard’s agreement): That’d be rad. Now pondering how that would change things in my day-to-day CSS redundancy….

craig

July 17, 2008 10:18 AM

I’m happy to see some debate here. Maybe the best of the best do a good job with standards first approach to coding, but in terms of people I’ve actually met and worked with: people who are obsessed with standards work incredibly slowly and produce incredibly bloated, arcane, bloated, and sloppy CSS.

The average coder just can’t do it well.

At some point people need to come off their high horse and realize that.

Martin Ringlein

July 17, 2008 3:10 PM

Seems from the comments I tried to make too many points and was perhaps myself a bit too vague and broad in my article.

Lets see how this sits with some of you as a closing thought:

1. ‘Smart CSS’ is about having clean and light CSS that performs well when powering large entities that demand flexibility and extensibility. Keeping your CSS as minimal as possible by not being unnecessarily redundant.

2. ‘Smart CSS’ is about creating style sheets that are easy to read, understand and work with. It is about CSS that a veteran team, third part agency or novice hands-on client can work with effortlessly in a rapid fast paced environment without being heavily dependent on documentation or communication that may or may not exist.

3. ‘Smart CSS’ is about understanding and utilizing the true power of CSS through specificity and the cascade and not let purest philosophical debates hinder productivity when the end result should be an attempt at creating the smartest deliverable as opposed to worrying about how ‘sexy’ it might be.

Robert Foerster

July 18, 2008 7:01 AM

I have to agree that it’s sometimes used just because, well everyone has it/doing it.

CSS is great, if the person who built something before you left notes, if they didn’t, it’s a royal pain in the ass sometimes as you hunt down all the itty bitty this and that and gnash you teeth.

While it’s great to keep it clean, and once set up it’s quick, and more importantly (if done correctly) global on your site, it can also lock down innovation.

Also I find it a bit temperamental and we run into herky jerky website syndrome, or what I call chunky monkey loading. Okay, apologies for over blown naming. ;)

Ultimately, CSS is good, but like anything there is no doctrine to follow. Use it as you see fit, and if it delivers what YOU want. Don’t work around it, remember whose the boss.

Also, PLEASE document your CSS. It’s a royal pain when you leave and a new person comes in and has to work like some sort of CSI Web Detective. ;)

Scott Phelps

July 18, 2008 10:09 AM

When I began working for my current employer, they had a custom made CMS which used complex table layouts, css used improperly, inline css combined with external css and custom functionality using javascript and php.

I spent the first two months stripping the cms of all but basic html (in Smarty for those familiar with it), removing html inserted from php and setting up a basic html/css framework to make development faster.

Doing so made setting up a site in our CMS a four hour process instead of a one week process.

After 40+ sites have been set up using our system, it came time for some redesigns. Any site that used the old methods (table layout, etc) had to be scrapped and redone in the new system to save time and money.

This, to me, is the real advantage of removing the presentation layer from the html. Redesign.

We are no longer building custom websites for customers each and every time. Speed and quality equals $.

We all love design, we all love the web, but the truth of the matter is…we make our living doing this.

And yes, the css is highly documented.
And yes, Jquery has replaced customized javascript.
And yes, we use our database identification numbers to create incredibly flexible cascading events. (insert the # into the body id=“db#”)

Martin Ringlein

July 18, 2008 10:58 AM

@Scott, great comment and real life example.

I used to work for a publishing company about five years ago and we went through a similar process. Eventually had to redesign/relaunch 60+ magazine content portals within 24 months — all unique from a content IA/UI perspective.

The great thing for us was the ability to have 5 front-end developers building sites using what is essentially a custom frame-work. We then had a global style sheet that identified many of the commonalities that we knew most sites would require regardless of the content IA or UI.

You know you will have photos in article copy that float left or right and need appropriate padding. You know you will have horizontal lists. You also know you will have block quotes and H1 through H6 that can be generalized for the most part and than further customized using the cascade. You know you will need a way to hide text for image replacement and a way to clear floats and a mechanism for custom image bullets on unordered lists.

Why create those each and every time for 60+ sites those processes may differ between personal taste of front-end devs? Why not create generic and useful rule sets for common elements?

Greg Mayer

July 18, 2008 1:56 PM

Your ‘red’ argument is simply a red herring. If your style refers to the red model of a car, by all means use a class ‘red’.

CSS has long been utilized as the designer’s tool to overwrite and overcome internal barriers between upper management and developers.”
What? Where have you been working? This article does a great disservice to those of us who actually document and communicate on our projects.

“One thing to note is that it is not the job of CSS to overcome the shortcomings of your development team, content management system, or internal processes.”
Well, I certainly agree with you there.

“…being smart isn’t always being sexy.”
I quite agree. But this article displays neither of those qualities.

I probably should have simply let the above comments from those who I respect suffice, but this article is just ‘wrong’.

telga

July 18, 2008 2:33 PM

@martin

“You know you will have photos in article copy that float left or right and need appropriate padding. You know you will have horizontal lists…Why not create generic and useful rule sets for common elements?”

An example of smart. flexible, extensible css:

layout.css
img#lion-cub.article-name,img#lion-cub-group.article-name, #main-content ul {float:left;clear:left}
img#lion-mother.article-name,img#lion-mother-and-cub.article-name {float:right;clear:right;}
img#lion-mother.article-name {padding: 0 0 0.5em 0.5em}
img#lion-cub.article-name {padding: 0 0.5em 0.5em 0}
img#lion-cub.article-name,img#lion-mother.article-name, {margin:0;}

And so on. How could a stylesheet organised as

img.float-right, ul.float-right {float:right;padding:…;margin:…;}
img.float-left, ul.float-left {float:left;padding:…;margin:…;}

possibly be smarter, or have any advantage in flexibility, intelligiblilty, or ease of use for the developer? Especially when you are faced with differences or changes in paddings or margins. Do you now add inheritance? More class names such as class “float-right-extra-padding-left”? Absurd!

Additionally, every loss of semantic mark-up is a loss for your content’s findability and searchability.

Martin Ringlein

July 18, 2008 2:44 PM

@Greg, thanks for the thoughtful comment.

I think your statement, “What? Where have you been working?”, really says a lot to why the article is so important. I want to ask you, where have you been working?

The purest mentalities of CSS are great when working in terrific conditions — when working on your personal website or when working in a large established and well versed team within Yahoo!.

But the real world isn’t like that for many. Many front-end developers never meet or speak with the information architect or the designer or even the back-end developer who integrates. Many front-end developers don’t even code the entire site, they code limited number of templates that are later expanded upon by another.

Heck, some front-end developers never even meet or speak with the end client — just an entry-level project manager at a large public relations firm that knows nothing of web development.

Patrick and Andy use harsh words such as naive and weak — but as much as I respect both of them; it is they who I feel is naive. A naive view of how the world should be vs. how it actually is. A desire to want to be perfect within the limitations of non-perfection.

Some of the very best talent has worked in situations where they know they can’t control the design or can’t control the development. The reality that the best the deliverable will ever be is what is on their machine; and the point of integration will fail because the team, the client and a variety of other uncontrollable elements are ultimately flawed.

Should you use a class name such as ‘red’ over one such as ‘error’ — absolutely not. But if you know the end client will understand ‘red’ over ‘error’ (for whatever reason) should you use ‘red’? Should you try and explain why it should be ‘error’ or should you do what you know is best for the client and what the client wants? Is the client always right or is this great philosophical thought the end all? Will the internet crash because you used ‘red’, will the website stop working in 2 years? Will it ultimately matter for some one off small business shoe repair website that the class is ‘red’ and not ‘error’ simply because that is what just happens to be in the best interest of the client?

The sad reality is that we are all not saving the world, we are all not working on Yahoo! or AOL or NYTimes or LinkedIn or Facebook — the majority of those that do what we do are working on everything else for everyone else. And many of you forget that.

I don’t know what types of projects Andy and Patrick work on; I don’t even know if they do client front-end services anymore — or what year it was the last time they did a quick, low-budget brochure website for a very novice and very stubborn client.

Again though, the article was never about ‘red’ vs. ‘error’ — the article actually never defended the fact that it ever should be ‘red’ and not ‘error’.

The article is simply remembering that we don’t work in a CSS Zen Garden world. Those early influencers outlined a utopian ideal that we aspire to when coding; but not one that we have to achieve. The article is remembering that there is an exception to every rule. Don’t keep the class name from being ‘red’ if in fact that is the best name to use because you think you are killing the utopia; because you are not.

Martin Ringlein

July 18, 2008 3:03 PM

@telga

Think about the context of the situation differently. To my previous comment; imagine you did that CSS for the Lions Club as a client; and the scope of work is completed and handed-off and the client picks up the phone a week later asking to make an image in his press release be in the 2nd paragraph floated to the right (and imagine he sends you a word doc as an example) — without effort on your behalf or cost to the client, you tell him to add class=“float-right” to the image tag and magic will happen. A 1 minute phone call and done.

But you are right. What if the base CSS for ‘float-right’ has a left margin of 10px but in the sidebar you use smaller images and only want a 2px left margin. Instead of repeating all the CSS that makes something float to the right and gives it a margin — you simple do this: “#sidebar float-right{margin-left:2px;}” and you are done. Smaller, lighter and cleaner CSS. Use specificity, that is why it is there.

The key is knowing that you are using the base commonalities of that float treatment over many times and creating a generic rule. If you only float one thing right ever, then yes, dont be generic, be more specific as to your example. But when you repeat a style time and time again such as making a list horizontal; then it just makes more sense.

I don’t think you read the earlier comment on the example of the use of an H3. Think about how you, or most people, use their H’s. You make a general rule for H3 and then you make alterations to those rules using specificity. The H3 may be 20px, red and arial … but in your sidebar it may be 20px, orange, arial and uppercase — but you don’t repeat the 20px and arial both times do you? No, you target #sidebar h3 and make the changes there.

Are all link styles on all websites always exactly the same? Of course not. But that doesn’t stop us from applying a base style to ‘a’ and ‘a:hover’ does it? And then we use specificity to change ‘a.more’ to make it bolder and give it an arrow background icon.

We do this because we use our headings and links in a variety of locations and we can make assumptions based on the typical presentational style they will have.

telga

July 18, 2008 4:07 PM

@martin

“Think about the context of the situation differently. To my previous comment; imagine you did that CSS for the Lions Club as a client; and the scope of work is completed and handed-off and the client picks up the phone a week later asking to make an image in his press release be in the 2nd paragraph floated to the right (and imagine he sends you a word doc as an example) — without effort on your behalf or cost to the client, you tell him to add class=“float-right” to the image tag and magic will happen. A 1 minute phone call and done.”

Imagine that I had my client add to his image id “client name” and even class “press-release-date”. He has now added some very valuable information to his photo that may be of service to him, in the future, in many ways, from presentational; perhaps he would want all photos of himself to have a blue border, to semantic; all photos of himself could have a caption; they could be ordered or organised for meaningful use by technologies not yet developed. I dunno: hyper-microformats? Whatever and how many the potential uses of semantic mark-up, they must greatly exceed the opacity and inherent limitation, and future-boondoggle, of the mark-up “img.float-right”.

Ryan Cannon

July 18, 2008 4:15 PM

I think this article’s advice is bad, mostly because it discusses CSS and HTML outside of the context of the rest of the Web application. In working on a large site, you’re usually dealing with a lot of small modules combined together in different ways in different places. With presentational CSS classes in your markup, suddenly your markup becomes confusing.

For example: ul.horizontal. What happens if next week, Product comes back and says, “well, the nav was horizontal on that page, but on this page, we want the same navigation, but it should be vertical.” Now what do you do? Had you used, e.g. ul.navigation, you could scope that declaration however you wanted and it would still be appropriate.

Semantic classes define what your content is and lets you use them in different places and different ways. Presentation CSS, on the otherhand complete forgets the C in CSS and defines piles of one-off class names that are impossible to maintain or reuse.

telga

July 18, 2008 4:29 PM

@ryan

“Semantic classes define what your content is and lets you use them in different places and different ways. Presentation CSS, on the otherhand complete forgets the C in CSS and defines piles of one-off class names that are impossible to maintain or reuse.”

Exactly what I was trying to say. Thanks, and right on.

Martin Ringlein

July 18, 2008 5:05 PM

@ryan, just remove the class “horizontal” — and like magic it is no longer horizontal and now vertical.

As stated in the article, sometimes editing the HTML is quicker and easier than editing the CSS.

You are missing the bigger point. This isn’t a debate between the names ‘horizontal’ and ‘navigation’ — it is about using class=“navigation horizontal” because the styles used to make “navigation” horizontal are used again on several other classes, like “foot-nav”, “side-nav”, “modular-nav”, etc.

telga

July 18, 2008 5:30 PM

@martin

“As stated in the article, sometimes editing the HTML is quicker and easier than editing the CSS

Not in a well-organised style-sheet or with thoughtful mark-up.

“You are missing the bigger point. This isn’t a debate between the names ‘horizontal’ and ‘navigation’ — it is about using class=“navigation horizontal” because the styles used to make “navigation” horizontal are used again on several other classes, like “foot-nav”, “side-nav”, “modular-nav”, etc.”

layout.css

site-information ul, sub-navigation ul, #archive navigation ul {float:left; clear:left;}

What could be simpler or more flexible or easier to maintain or understand?

minimal design

July 18, 2008 5:31 PM

Very disappointing to read this ill-informed article on here.

The whole point seems to be that “smart” is better than “sexy” in a real life production environment… I believe the author is missing what I consider to be the essence of CSS philosophy: “smart IS sexy.”

No offense, but maybe the CSS talked about here is just not smart enough to be sexy…

Martin Ringlein

July 18, 2008 11:17 PM

@telga, I’ll answer the question for you.

What is simpler than this?
site-information ul, sub-navigation ul, #archive navigation ul {float:left; clear:left;}

How about this?
.left {float:left; clear:left;}

I think it is pretty clear visually which is simpler.

Right now in your example you only have three elements using that style; what happens when it is 8 or 12 or 20? Filtering through that to change is much more difficult and perhaps dangerous than finding the element in the HTML and simple removing the “left” class. But lets also not get hung up on the semantics of “left” … call it “jelly” for all I care.

@minimal design, Yes, “smart IS sexy” … the issue is that “sexy IS NOT ALWAYS smart” – they are not always one in the same. I am not suggesting we be smart and NOT BE sexy — I am suggesting we be sexy but not at the expense of being smart.

@all, I understand the frustrations with the article; I knew them before I even finished writing. Some of you are just always right, you have ‘the way’ and that is the only way. For you I can’t argue a point … you are right and I am wrong. And because I am wrong and wrong against ‘the way’, I am naive and ill-informed and un-experienced; I get it.

But for the rest, the ones that have ever debated where to use your H1 and if you can have more than one H1; this article is for you. For those of you who have ever spent more than 2 minutes trying to figure out what the class name should be because the only thing that makes sense is too presentational; this article is for you. For those of you that have ever debated if you can in a particular situation have an in-line element just sitting there alone in your mark-up without being in a block-level; this article is for you. For those who have ever thought of using a deprecated tag like <b> simply because it is short and you know no matter how wrong, it will still work; this article is for you. For those of you who spend too much time deciding if it should be in a list or not and if so an unordered list or ordered list; this article is for you.

Again, I get the frustration. But as I said in the article, look around at those you admire and even those who call me out among the comments. Look at Patrick using “.jelly” and Andy using “#top” and “#bottom”. Look at Yahoo! using “#newsbottom”, “.first” and “.last” — hell Yahoo! has in-line styles all over the place; isn’t that like a sin? And when Yahoo! does this “<span class=“pipe”></span>” — it doesn’t get much more presentational than that.

But I don’t condemn Patrick, Andy or Yahoo! — and I certainly don’t call them naive, ill-informed or imply a sense of inexperience. Because it is about knowing about reality and real world situations and application. We work with bad clients, bad content management systems, bad developers, bad time-lines, bad co-workers … we work in a flawed world. That reality doesn’t get covered in “CSS Mastery” or “Designing with Web Standards” or “CSS Zen Garden”.

There is no chapter on breaking rules that the chapter before it demanded we set. And the rules (the purest ideals) are broken every day; even by those who taught us otherwise and condemn me for implying that ‘the way’ might not always work.

minimal design

July 19, 2008 10:09 AM

What is simpler than this?
site-information ul, sub-navigation ul, #archive navigation ul {float:left; clear:left;}
How about this?
.left {float:left; clear:left;}
I think it is pretty clear visually which is simpler.

I think you’re confused between “simple” and “short.” The HTML in your option will have an extra class which I need to look up, and the CSS doesn’t tell me anything.

If I were jumping in someone else’s code with a need to modify the archive navigation layout, I would MUCH prefer the 1st example than your option… because I’ll know right away what’s going on, what I need to modify, and what impact it will have on the whole site.

With you method, you have to go in the HTML and remove the “.left” class on that HTML element, which means you cannot assign any cascading style dependent of that “.left” class or else you entire system breaks. Extend that to your entire site and you just effectively got rid off the “C” in “CSS.” “CSS” without “C” is not CSS anymore… This is a pretty clear case of “wrong,” not a hot debate that will never be solved as you portray it.

I don’t think you’re “getting the frustration.” I’ve used “.first” and “.last” before… but as an exception that worked in the specific context of a specific layout (those classes still have a certain amount of meaning related to data structure btw). The way you extend those exceptions to a general CSS approach is what’s wrong and what led me to call you “ill-informed.”

It’s not that I believe there’s “The way” and nothing else… There’s certainly as many styles of CSS as they’re developers… But that’s not the issue here. The issue is:

“because the only thing that makes sense is too presentational”

It’s the “only thing that makes sense” for you according to your presentational approach. You’re arguing on how to call that class but the problem comes much earlier in the process… In other words:

“sexy IS NOT ALWAYS smart”

“Sexy” is not a goal in itself… It’s the result of a smart implementation. Smart is always sexy. You don’t code trying to make it sexy, and reverting back to smart when that’s the “only thing that makes sense.” You code smart the whole time and sexy just happens by itself…

And about the <strong> vs. <b> dilemma… When one’s standard, the other one’s not, and <b> does not offer ANY advantage (besides being 5 characters shorter), it’s a no brainer. Anyone who has time pondering about it shouldn’t be talking about being productive in a real world environment at the same time.

telga

July 19, 2008 11:13 AM

“But for the rest…this article is for you.”

It appears that what is at stake in Mr. Ringlein’s article isn’t a thorough-going discussion on how to write smart(er), more efficient, lighter css. Instead, Mr. Ringlein’s article seems function, on the grounds of “badness”—bad clients, bad projects, and so on—, as an invitation or provocation to break Web standards, to disregard best practices, to flout something basic about the universality of knowledge or information that is basic to our work, to give back to the stupid client or bad project what it deserves, measure for measure; for the developer to be to be engaged by the narrowest kind of consequentialism, where the end justifies the means.

Like some other, earlier commentors, I have to ask, why has Digital Magazine given this article the time of day?

Ryan Cannon

July 20, 2008 10:36 AM

One last comment. Between these three:

<div class=“float-right”>…</div>

<div align=“right”>…</div>

<div style=“float:right”>…</div>

Which one is more intuitive, readable and easy to maintain? Definitely not the first one. None of them are useful as global includes, but the first one introduces another file as a prerequisite. If you’re defining one-off classes for presentation, why not just use the style attribute?

Harry Roberts

July 21, 2008 3:54 AM

No one seems to use the cascade properly at all! Also I see a lot of people wrapping navigational <ul>s in <div>s – why?! The <ul> is itself a container!

Nice article!

Martin Ringlein

July 21, 2008 10:58 AM

@Harry,

I see that a lot as well. That topic came up a lot during the short popularity of the term “divitis”. I think the problem is larger, the battles are fought between the older crowd a long time ago — they assume the battle has been won; but the topic comes up with each generation of designer/developer. There are just so many one-off situations where standards fail; standards in general. We try and aspire to these standards, but the reality is that we all work under different situations; it isn’t a CSS Zen Garden World.

Some developers want to use the extra div to future proof and some just think of <div>‘s as containers and assume best practices has us put all segments of content/code into containers.

Why put the id=“footer” in a <div> when it can certainly live just withing a <ul> and the <ul> is the entire footer area. It is that fear of “if” — what “if” one day there is more in my footer than a list of entities?

I wrote a post a couple years ago on why standards fail, Web Standards – an unnatural feeling!

Shawn Dones

July 21, 2008 8:22 PM

Smart CSS huh? How about smart STRUCTURAL MARKUP. Like the parts of a car, a wheel is a wheel a door is a door, a header is a header a footer a footer. With smart markup comes smart css, not the other way around. One real world comparison that I can’t help but bring up is the stop light. Some call it a “red” light. Some call it a “green” light. There is no argument, it is a “STOP” light. This is the fundamental difference that you cannot understand. Let’s go a step further. The actual bulb inside the “red” or “green” light is a clear “bulb”. This is separation of presentation from structure. Because its smart to create a bunch of clear bulbs and choose the color to add to it rather then create a bunch of red bulbs and a bunch of green bulbs, that would be kinda,.. well, dumb.

Rob Hofker

July 22, 2008 6:40 AM

I know I must be repeating someone here, but still I take that risk.
Clearly this is a difficult area.
I am all for separation of content, markup, style and behaviour. But the separation is never a complete clean one, there always gray areas: :hover in CSS clearly triggers some behaviour.

Same goes for separating meaning from class en id names in markup and css. Using mnenomical naming like ‘nav’, ‘sidebar’ is perfectly correct in my opinion. It adds meaning to the markup and the CSS.

Using double classes like ‘nav horizontal’ makes sense as well, but then again so does ‘mainNav’. Whether you would use the first option or the second depends on the possibility to reuse parts of the CSS code. If you can reuse styling from the ‘.nav’ class for combining it with both ‘.horizontal’ and ‘.vertical’, then it might make your CSS code more compact. It’s more or less a personal choice.

Using a class like ‘.red’ usually is considered wrong, but I have used classes ‘.left’ and ‘.right’, well, left and right in my sites. Mostly in combination with other classes and selectors.

Being also backend developer using object orientation and patterns I am always looking for ways to use the least possible code (read markup and styling) to achieve the effect that is required. This usually boils down to a good technical design which ends up with lots of classes with not too many lines of code in there.
Using this strategy in CSS will bring me many classes with small amounts of markup. A class ‘.right’ fits in that philosophy. It will however result also in markup like ‘<div class=“bar left simple”>’ for box on the left side with ‘simple’ styling.
So, in practice I move between the combination lots of small classes and the lesser specialised longer classes.

The article adds to the confusion and undoubtedly someone will put up a reaction to this one with better and clearer argumentation.

web

July 22, 2008 7:26 AM

Wrong wrong wrong.

Sure this is “easier” and easy to read but its goes against the fundamentals of semantic web.

Use these practices if you must — every situation is different but if your talking about the “best practice” this is not it.

In all cases where business is involved — sometimes there is corner cutting and I would agree that if this is easier for you to write/edit go for it. But don’t fool yourself.

I am a big fan of the cascade and I urge all developers to use body classes in this situation ..

body#aboutUs ul#nav{ /* horizontal rules */}
body#products ul#nav{ /* vertical rules */ }

Martin Ringlein

July 22, 2008 8:08 AM

Again, the high-level point is about reality and that we work in reality; not in the perfect ideals set inside the books we adore and the speakers we admire.

That is why Yahoo! uses “<span class=“pipe”></span>”.

Everyone keeps arguing the examples that are easy to argue and ignoring every example brought up that is undeniable. Will someone defend Yahoo! here and still prove my point wrong?

Or why Andy Budd use class names like “top” and “bottom” — defend that and prove the overlying point of the article wrong.

I like how no one of the 80+ comments has even brought up the issues raised about class names like “sidebar”, “header” and “footer” that clearly connote presentational meaning.

Or simply provide an example of a large and dynamic website that breaks out of the limitations that I call “reality”. A site with more than ten unique core templates and over 500,000 uniques monthly. A site that isn’t a brochure site, an event site, a personal site, or blog-like in nature. A site that has intense visual design elements throughout; a highly designed presence whose mark-up is truly “sexy”.

AOL, Yahoo, NYTimes — they all break your precious “best practices”. Because they all work within reality.

The closest I’ve seen to amazing and “sexy” mark-up is Mixx.com — but being very close to that project, I know the realities are there as well.

telga

July 22, 2008 12:24 PM

@Rob “The article adds to the confusion and undoubtedly someone will put up a reaction to this one with better and clearer argumentation.”

Although not a direct reaction,

http://www.onderhond.com/blog/work/leaving-out-css-type-selectors

is a better and clearer discussion of what Mr. Ringlein admits is only a low-level point in his article: the unlocking of css and html, for gains in efficiency and flexibility, through re-using class selectors that correlate to specific css declarations. (His “high-level point” is, I believe, casting Web standards and best practices in doubt.)

However, while Mr. Ringlein insists, tendentiously, regressively, that css and html are best un-coupled by creating generic presentational class selectors like “.left” or “.horizontal”, the point made in http://www.onderhond.com/blog/work/leaving-out-css-type-selectors is that:

“When we are writing css we are styling components, and these components should be addressed only through their adequate html equivalents. In most cases, this means leaving the type selector off as it is simply too generic to be of any value.”

The example, replacing “ul.breadcrumb”, where a type selector, “ul”, is unneccessary with the semantic class selector “.breadcrumb”, is a real-world case where css and xhtml can be unlocked by applying css to the specificity of a class with semantic information instead of to the generic (x)html element.

Jason Zipperer

July 23, 2008 8:00 AM

Something I haven’t seen yet in this discussion that I hope might help bring us together, is the question of whether one should teach ‘best practice’ or ‘real practice’.

When you are preparing for a driver’s test, you won’t be told that you can drive 5mph over the speed limit without being pulled over. They teach you to drive the speed limit. However, anyone who has been behind the wheel of an automobile knows that this is something that can be done fairly reliably.

All sites have ‘blemishes’ in their code that make them less than ‘ideal’, but I think it would be problematic to just lower the bar in order to affirm their shortcomings.

telga

July 23, 2008 8:50 AM

@Jason

“Something I haven’t seen yet in this discussion that I hope might help bring us together, is the question of whether one should teach ‘best practice’ or ‘real practice’.”

I really think what is at stake here is an assault on Web standards and by implication, best practices: if enough ppl agree that ‘real practices’ are, practically speaking, the best for ‘real’ web sites, we end up with “the end justifies the means” as the standard, or “anything goes as long as it works, short-term” and that sounds like a very bad regress.

Best practices aren’t meant to be ‘ideal’ practices that aren’t really practiced: they’re meant to be “best”, what works best, all round.

If not the intention, then the outcome of this article, is not to bring us together, but to create the schism, ‘real practices’ vs. ‘ideal practices’; where Web standards and best practices are just for ivory towers.

Our Web Standards are de facto standards: if we depart from them as real-world, best practice standards, then another kind of standard will rule in their place, where “.horizontal is a standard”.

It seems to me we risk losing a lot.

Martin Ringlein

July 23, 2008 9:44 AM

@Jason, thanks for the comment — very well put.

Jason Zipperer

July 23, 2008 9:58 AM

While I share some of your fear for a watering-down of standards. I think you are taking it farther then I was intending.

The point that I was trying to make is that although separation of markup/presentation/behavior is the goal that we all should strive for, we all have factors that affect the end-result of our work (clients, bosses/managers, deadlines, even family/external issues). We shouldn’t be demonized for these, neither should we put them up as ‘standard practice’.

telga

July 23, 2008 1:57 PM

@jason “While I share some of your fear for a watering-down of standards. I think you are taking it farther then I was intending.”

When I said “I really think what is at stake here” I didn’t mean by “here” your comment but rather the article we are commenting on, “Smart CSS Ain’t Always Sexy CSS”, and I apologise for not being clear about that.

My point was that if you were suggesting reconciliation, it was because Mr. Ringlein’s article is definitely contentious on the subject of Web standards and best practices vs. the demands of the “reality” of, as he has puts it, “bad clients”, bad co-workers”, bad-projects, and so on. I don’t think his article is at all meant as an apology, or a plea to let hard-pressed developers, at least temporarily, off the Standards hook.

After all, its title is, provocatively if not confrontationally, “Smart CSS Ain’t Always Sexy CSS”; the claim he is making, broadly, is that it can be smarter to break Web standards and best practices than to follow them. However, if the authority and validity of Standards is just that they are ‘sexy’ or for show and not because they are really ‘smart’ all round best solutions in the real world, then the de facto standard is already what is really being practiced, what ‘really works’; and it’s only a matter of time before ‘sexy standards’ are a standard no more. A battle for Standards is happening here, in this article and these comments.

Specifically, Mr. Ringlein has argued, if I understand rightly, that using presentational class selectors makes sense now because it can be easier—at least for the novice or hard-pressed developer—to edit the html in templates and include files rather than the CSS.
However, instead of applying CSS to components like breadcrumb trails, navigation menus, archives, branding, or site-information, that are to be “addressed only through their adequate html equivalents” in order to separate css and html for purposes including editing either the html or css, we would find ourselves addressing in our style sheets mere ephemeralities like .left {float:left;}.

Practically speaking, I know that if I am going to use a class selector, I want it to add a lot more value to my client’s content than a short-lived layout. And practically speaking, I think my client cares a lot more about SEO, about findability, about exportability, about the enduring life of her content, than whether it happens to be floated left or right some time, somewhere. So out here in the real world I would say, don’t waste those valuable class selectors on mere presentation, when they are best used for semantic or structural purposes.

Jina Bolton

July 24, 2008 1:15 AM

Ooh, is this a jab (hopefully not an attack) at my article that you’ve linked (Creating Sexy Stylesheets)? Hehe. Teasing.

While I’m here… I agree with your intention, but I don’t agree with a couple things…

You said:
“‘Smart CSS’ is about having clean and light CSS that performs well when powering large entities that demand flexibility and extensibility. Keeping your CSS as minimal as possible by not being unnecessarily redundant.”

While you may feel that way about smart CSS (and for the most part, I would like to agree), the more important issue is the data… the markup should avoid having to be changed (if certain “modules” are moved from a left column to the right column, I don’t want to go in and change all those particular modules from class=“left” to class=“right”. I should just change it in the CSS. And while it might seem to you that being redundant is more work for now, it’s actually saving work from later. Markup is data. CSS only styles how that data looks. CSS is disposable. Why would I call “Sexy CSS” disposable? Redesigns happen. Styles change. The data should not have to be changed because of a redesign. This is what the CSS is for.

It is, though, all about workflow and efficiency. There are obviously some cases where even I would argue that being realistic and pragmatic is better. However, I would never, ever, ever advocate using presentational markup just to save time. Because I know that it won’t save time later. It’s laziness (in my most respectful, humble opinion).

You said:
“‘Smart CSS’ is about understanding and utilizing the true power of CSS through specificity and the cascade and not let purest philosophical debates hinder productivity when the end result should be an attempt at creating the smartest deliverable as opposed to worrying about how ‘sexy’ it might be.”

I think you’ve missed my point. Yes, I titled my article (and my presentations) Creating Sexy Stylesheets. But if you read the article, it’s not about how pretty can you make your CSS file. It’s really about how efficient and smart can you make your CSS. And making CSS lightweight does not necessarily make it smart. It’s about thinking about the future. How changes can impact development later.

Those are my only main issues I wanted to bring up. I think Norm really covered most everything else, as far as I’m concerned. Let me say one more time: I do agree with some things here. Efficiency should reign. However, thinking about the long-term and what works best should always be a consideration.

I do think it’s fantastic that you’ve posted your opinion on this site. It’s good to get people talking about this stuff. Unfortunately, not everyone is ever going to agree.

Matthew Pennell

July 24, 2008 2:12 AM

Hi Jina, thanks for dropping by. :)

Redesigns happen. Styles change. The data should not have to be changed because of a redesign. This is what the CSS is for.

Honestly, how many times have you undertaken a redesign project and not touched the HTML? That was the ideal used to sell the CSS dream, but has no basis in reality.

Niels Matthijs

July 24, 2008 4:03 AM

Funny, I used to work with the .horizontal/.vertical classes myself, but ditched them later on.

The problem with .horizontal on lists is that they don’t work like you’d expect them too. You can either nest a .vertical in a .horizontal or visa versa, but you can’t have the both of them. This is pretty confusing and kinda defeats the purpose of these classes, as your method of working won’t be very predictable anymore.

Another class I used was .leftFloat (and .rightFloat) and these contained the display=“inline” fix for IE6. It’s nice for a while but it can become bothersome if your code starts to look like this:

class=“secondNav service horizontal leftFloat” (secondary navigation of the type service navigation, displaying horizontally and floating left).

Anyway, I can relate to you article as I’ve been writing articles with a similar point of view, the thing you’re forgetting here is that css and html are not always managed by the same people (or even company). Our company is responsible for the front-end. Of course this includes html but as it needs to be implemented into a CMS, the final html structure is not our responsability. Making changes there is a lot more difficult that just sending a new css to your partners.

Cool article though, but you should’ve probably picked some better examples :)

Dave

July 24, 2008 7:04 AM

I think the article goes off the tracks on most of the key points:

“look for presentational language such as ‘header’, ‘footer’, and even ‘sidebar’.”

All three of those words have presentational and document structure connotations. Other dual-purpose words (that better refute your point): “paragraph”, “title”, “heading”, etc.

bq.“Well, just remove the class name from the HTML —I guarantee that it will be easier than removing the four to five lines of CSS, and second-guessing if any of the rules have uses other than ensuring the list was horizontal.”
bq.“One thing to note is that it is not the job of CSS to overcome the shortcomings of your development team, content management system, or internal processes. If your application under the hood isn’t being developed or maintained in a forward-thinking, flexible, and extensible manner, then smart CSS can only do so much.”

Actually, overcoming other weaknesses is a major ability of CSS — as your “guarantee” illustrates. If I have a perfectly done CMS, then I can put all kinds of crap CSS in the template since I only have to change it in that one place. If I have a bad CMS (or no CMS), then I need to take advantage of sexy semantic CSS so that I don’t have to change hundreds of html documents when the design changes.

bq.“The drive for sexy CSS sees designers stripping out as much perceived “cruft” as possible—why use #sidebar .horizontal when you can use #sidebar ul—but if we named more elements, specificity helps us target those entities.”
bq.“it is about extremely clean and light-weight CSS that powers very large websites”

So you would prefer the style of “#sidebar .horizontal”, adding 9 bytes to the CSS (and 16 bytes times {number of uses} to every HTML file) for each of your styles? If it’s about light-weight files, I’d think not. Maybe you’re a step ahead of me and use a javascript-style CSS compressor/obfuscator to turn all your extra classes and IDs into “a1, a2, a3, a4” before they go live.

entire “Creating Standards in a Web Standards World” section:
Couldn’t you do that more easily without sacrificing semantics?

#header ul.nav, #sidebar ul.nav
{/* horizontal menu styles */}

#footer ul.nav
{ /* vertical menu styles */}

Instead of editing all my HTML documents, I change two lines in one CSS file.

——

You can’t fully appreciate semantic naming until you really grok standards, separation of structure and presentation, and how you can participate in a trade-off between the amount of work you do and the amount of work everyone else has to do. Maybe I’m getting too philosphical.

Daniel C. Young

July 24, 2008 10:50 AM

Is it “smart” to pursue dogma for the mere sake of dogma? Let’s look at the principles behind why web standards was invented in the first place:

  1. It was difficult to re-design and/or add new features
  2. It was difficult to display consistently across different platforms

Today we have several solutions to choose from: CSS, CMS, Unobstrusive JavaScript, Web frameworks…

When I design my own sites, I have many choices. I’m free to write semantic code OR edit the CMS OR rename my DIVs and Classes in CSS. But we designers often have to design for other people’s sites. And we design for other people, we have to consider their objectives and meet their needs.

Many businesses prioritize getting things up fast (often sometimes at the expense of future extensibility). That’s perfectly understandable, because in their business environment that’s how they obtain competitive advantage.

So we simply make a cost-benefit analysis between the benefit of getting something up right now, versus the cost of having to fix it in the future.

In the end, what is “smart” is aligning your design philosophy to the business needs of your clients.

Jeff Croft

July 24, 2008 11:04 AM

Honestly, how many times have you undertaken a redesign project and not touched the HTML? That was the ideal used to sell the CSS dream, but has no basis in reality.

Exactly. This is the point that needs to be made. The concept of never touching the HTML and only modifying the CSS to complete a redesign is a flat-out pipe dream in 99% of real-world cases. And so help me God, if you try to call the CSS Zen Garden a real-world case… :)

That having been said, complete separation of HTML and CSS is a noble goal and something we should strive for. The closer we can get, the easier things will be come redesign time. But, in the end, it’s important to remember that our job is to create great web sites and applications that work well for all parties involved (users, developers, designers, management, etc.). If using web standards and best practices are a means to that end (and most of the time, they are), awesome. If they’re not, find another means to that end. Period.

Smith

July 24, 2008 11:22 AM

I’d just like to respond to this comment by Bradley Wright:

“Then your opinion is wrong. HTML should be optimised as it’s the only thing guaranteed to be seen by every visitor to your page, human or otherwise. And sorry, but using float-right as a class name is even more ridiculous than using right. Why not just put the styles in a style attribute and be done with it?”

I can’t imagine the arrogance of you, to claim that someone else’s opinion is wrong. And it’s quite ridiculous of you to say that he might as well use an inline style if he’s going to apply those class names. I thought in an effort to have a sensible discussion about the topic, the very least you could do is stop acting like you’re ignorant. But I guess that’s too much to ask for.

Tiff Fehr

July 24, 2008 12:36 PM

With 99+ (will I be #100?) comments on this thread, it is very clear that

  1. this is a contentious topic that tends to bring out zealots
  2. lots of people thought this argument was done a long time ago, while others believe the complexities have been glossed over
  3. we spend too much time talking about the ideals behind CSS & content/style-separation rather than realities.

Daniel C. Young, I’m not picking on your solid comment, but I think this is telling:

When I design my own sites, I have many choices. … But we designers often have to design for other people’s sites.

I would argue there’s a group missing:

  1. designer’s own work, which of course is spotless, gleaming standard (I mock because I love)
  2. client/business work, which must conform to a thousand compromises and deadlines and usually ends up just a bit south of ideal
  3. long-term, deeply involved work that evolves with the skills of the individual or team supporting it, where old decisions still haunt the markup and new trendy styles and technologies struggle to gain full control.

And I’m sure we could come up with a 4th or 5th, too.

This article is most relevant to the last group(s), but that’s getting lost in the easier arguments about ideals. This comment thread shows that we prefer to avoid the much more difficult problem of building smart-maybe-sexy CSS for giant, messy, long-lived projects. Instead we opt to bicker over simplistic, freelance-oriented ideals and examples. I don’t think there is much guidance offered to people working on standards-stupefying projects. It is very difficult to articulate such problems in short form, not to mention come to the universal conclusions we expect from web standards. It is a massively under-served audience, in part because of the immature negativity thrown at anyone who’s example includes flawed markup.

It’s probably not this thread, but I’d really like to see that conversation in this community.

Jina Bolton

July 24, 2008 5:01 PM

@Matthew

You said: “Honestly, how many times have you undertaken a redesign project and not touched the HTML? That was the ideal used to sell the CSS dream, but has no basis in reality.”

Obviously. Sure, a little bit of markup does inevitably happen. What I was stating was the goal, not a mandate. But there’s no reason you shouldn’t try to avoid it if possible. Why set yourself up for more work by using presentational classes, when you could save yourself some time by using semantic class names?

Jeff Croft

July 25, 2008 9:01 AM

But there’s no reason you shouldn’t try to avoid it if possible. Why set yourself up for more work by using presentational classes, when you could save yourself some time by using semantic class names?

Absolutely. If using the semantic class names saves you work (and usually, it does), then by all means, do it. But, I do think there are cases (for example, using a CSS framework like Blueprint’s grid components) wherein using semantic class names instead of presentational ones actually adds time, not saves it. Martin has outlined a few cases where it might be easier to make a couple quick markup changes than make a bunch of CSS changes. These situations do exist, even if they don’t come up that often.

The bottom line is that we always ought to be using whatever works best. And by “works best,” I mean provides the best experience to users, works well in all user agents, is clean and machine-readable, is as accessible as possible, and makes the lives of developers as easy as possible.

If something meets those goals, I frankly couldn’t care less if it’s done according to “best practices” or not. To me, the best practice is meeting those goals. Usually, web standards and the related best practices we’ve been taught are the best ways towards those goals. But, if you find a situation where they’re not, then by all means, don’t be afraid to deviate!

telga

July 25, 2008 12:20 PM

@tiff

“this is a contentious topic that tends to bring out zealots”

I think that attempting to isolate or neutralise people by calling them extremists or “zealots” is, as some earlier commenters have remarked, more what we would expect from The Daily Mirror, not from Digital Web. How is it that voicing a legitimate and pressing concern, that encouraging breaking Web standards and best practices helps break them as Standards and best practices (the best, all round), is tantamount to being a zealot? Using presentational selectors is widely considered a hallmark of bad practice: it is the topic that is extreme, not support for standards and best practices.

“lots of people thought this argument was done a long time ago, while others believe the complexities have been glossed over”

As I said earlier, Mr. Ringlein has argued, if I understand him rightly, that using presentational class selectors makes sense now because it can be easier—at least for the novice or hard-pressed developer—to edit the html in templates and include files rather than the CSS. I certainly don’t think the complexities of unlocking css and html, for gains in efficiency and flexibility including editing either the css or the html, are to be glossed over. As Mr. Matthijs , a front-end developer in the thick of things, points out in his recent article on css selectors which carefully considers those instances in which the html is changed rather than the CSS, “When we are writing css we are styling components, and these components should be addressed only through their adequate html equivalents …A styled component has the exact same semantic meaning as the html element” or, its adequate html equivalent. As he shows, by using semantics we can most efficiently and flexibly de-couple our css and html, not by using presentational classes which cannot approximate or function as the adequate html equivalents of components; no more than adjectives or verbs can function as nouns.

http://www.onderhond.com/blog/onderhond/leaving-out-css-type-selectors

“we spend too much time talking about the ideals behind CSS & content/style-separation rather than realities…I don’t think there is much guidance offered to people working on standards-stupefying projects.”

It is precisely the determination evident in this article and its author’s and Digital Web staff’s comments to create a divide or schism between the ‘ideals’ of css best practice and ‘reality’, between standards and “standards-stupefying projects”, where there was nothing like (consider the lead developer for Yahoo! Europe’s comments), that leads to, indeed, a great deal of talking about the creation of that schism. I’ll say again, Using presentational classes has been considered bad practice, a hallmark of bad practice, for a long time.

@jeff croft “If something meets those goals, I frankly couldn’t care less if it’s done according to “best practices” or not. To me, the best practice is meeting those goals.”

It seems to me that here is a case of the outcome of adapting to ‘realities’, in the narrowest kind of consequentialism, where the end justifies the means.

Jeff Croft

July 25, 2008 1:24 PM

It seems to me that here is a case of the outcome of adapting to ‘realities’, in the narrowest kind of consequentialism, where the end justifies the means.

You got it. Glad my point came across loud and clear.

Tiff Fehr

July 25, 2008 3:46 PM

@telga You misunderstood what I called zealotry. I was not referring to what standards people have advocated in this thread. I was concretely referring to how people express their points—the too-frequent negative, knee-jerk attitudes in this and many conversations around the web that are crafted to avoid empathy and supportive teaching. When people frame responses with a superior attitude is not contributing to a discussion of any nuance or productive energy. Seeing such attitudes can really demoralize someone just starting to embrace standards, and unfortunately I think that’s been the net effect in this discussion, rather than depth.

Just so we’re totally clear, I in no way mean to single you out. That being said, it is worth noting that the staff of Digital Web comments as readers ourselves, and at minimum we try to keep the conversation civil. I personally think that asserting in comments that we have editorial motives in labeling anyone is both unfounded and not helpful to the topic at hand. Let’s talk about how give coherent examples of semantic web standards in complex projects since that seems to be a challenge, rather than over-reading.

telga

July 26, 2008 3:06 PM

“ it is worth noting that the staff of Digital Web comments as readers ourselves… I personally think that asserting in comments that we have editorial motives in labeling anyone is both unfounded and not helpful to the topic at hand”

As a long-time fan of Digital Web, which I believe is widely regarded as a repository of authoritative articles by respected experts, based on best practice, I don’t think I am your only reader, and certainly not your only commenter, to be surprised at your publishing “Smart CSS Aint Always Sexy CSS”, and to be even more astonished at the apparent support of the article by the editorial staff ( “.horizontal can be a standard”). It seems to me that many of your readers may have concluded that there has been a sea change in editorial policy at Digital Web (whether or not editorial change reflects personal ones). I suggest it would be very helpful to your readership to know what Digital Web’s current editorial policy is with regard to Web standards and best practices and what we can expect in the future?

“Let’s talk about how give coherent examples of semantic web standards in complex projects since that seems to be a challenge”

Here is a topic of keen interest that potentially moves us forward on the sound understanding that, as Ms. Bolton said, “the more important issue is the data”; unlike the advocacy of presentational selectors which is, surely, a dead end.

Tiff Fehr

July 27, 2008 12:20 PM

@telga Your characterization of Digital Web is flattering in the sense of prestige, but I think it is off-base. Perhaps Matthew or Nick would disagree, but we do not have any reason to bill the Magazine as “authoritative” or as advocating any particular best practices over others. We try to reflect the web standards (and not-so-standard) community, and that is all—if we come across as a helpful resource for web standards, well, that’s due to the quality of our authors, their topics and the reader participation brought to Digital Web.

Matthew’s and my support for this article (as readers more so than staff) has been clear throughout our comments on this thread. I would make an educated guess that both of us (as well as other staff members) are happy see this article get such a strong response, because it is a helpful conversation1 for anyone who’s web-standard path is convoluted.

Simply put, the involvement of the community via comments and counter-article debate is the authoritative aspect of the Magazine. Assuming we’ll enforce some world-view about web standards to our readers is not correct. The inherent mission of the web standards community is to help educate others about the merits of standardized coding. I don’t believe it should posture as an authoritative body with time-honored methods and approved solutions. Some of the negative attitudes in this thread indicates to me that maybe the community is tired of being collaborative educators and would rather (cattily) argue code samples like they’re doctrine.

If the community doesn’t like the article’s points, help shape it in the comments to be relevant guidance to newbies and those confused over the issue. Pointing fingers at Digital Web as if we have an agenda is unhelpful (though we do enjoy hearing how other people think of the magazine, good or bad).

1 I do want to thank you for an abstract side-effect from your response—it does point out to me that by separating our articles and comments, we put an unintentional-but-perhaps-meaningful block between readers & comments. Combining them to one page would better emphasize that the comment discussion is as a valuable as the article.

Matthew Pennell

July 27, 2008 2:12 PM

Telga,

Digital Web does not have an “editorial policy with regard to web standards” per se. The volunteer editorial/management staff is made up of practicing web professionals, who are dealing with the same issues, decisions, and arguments as you are every day. The decision whether or not to run an article is not based on some mythical ‘gold standard’ of web design — we are not the W3C or even the WaSP — we simply publish weekly articles that we hope either educate, inform, or challenge our fellow web professionals.

Martin Ringlein is, for want of a better word, an “A list” designer/developer, and as such his opinion on CSS best practice is one that we can expect our readers to find interesting — personally, it is not a subject that I have seen written about recently, and I thought it was one deserving of attention and debate. The sheer volume of comments that the article has attracted (both positive and negative) show that the topic is not as cut-and-dried as some may think.

I hope to be able to bring you another article in the near future that takes a look at management of large sites’ CSS in detail.

Matthew Pennell
Editor in Chief

PS: If you would like to influence editorial “policy”, we are always looking for volunteers at DW. :)

Anon

July 29, 2008 10:36 PM

Seems like an ignorant viewpoint. Couldn’t agree more with the others when they say it should have been called how to cut corners, when you really don’t understand semantic naming.

minimal design

July 31, 2008 11:40 AM

I tried to explain why this approach is wrong in an earlier comment… I tried again, with more practical examples, but it got way too long so it’s on my site, in case you’re interested:

http://minimaldesign.net/articles/read/smart-css-is-inherently-sexy

Erika Meyer

August 2, 2008 2:44 PM

I didn’t know about the “sexy” stylesheet movement (and didn’t see any references), so I googled “sexy stylesheets” and came up mostly with some pretty basic common-sense articles by a designer named Jina Bolton.

I never read any “books” on CSS. I learned mostly from the spec and from hacking other stylesheets. And I learned not to call things “red” the hard way. :) Which btw, is WAY more presentational than “header” which actually indicates some sort of function and structure. “horizontal” seems somewhere in the middle of those two, but whatever. Who cares what conventions any particular coder uses, as long as what you are doing on a particular style sheet works for your project and will be understandable as possible to future people working on the project.

I don’t quite understand the point of the article, beyond “think for yourself,” and “think in context.” IMO if a designer or coder can’t do that, their issues run a lot deeper than their code. And good luck to them.

Krzysztof Maczyński

August 4, 2008 7:10 AM

What an appalling idea! And arguments unconvincing at all. header, footer and sidebar (or aside as a synonym gaining popularity) are semantic names! Rendering a header at the top (or right, or left, depending on the block progression direction) may be considered a presentational hint for visual media. Otherwise you should categorise thead and tfoot as presentational too. Does rendering thead at the bottom (may be sensible in e.g. tabbed interfaces) affect its semantics of being a table header?

Jamie

August 4, 2008 11:32 AM

I’m a little late to the party, but after reading the thread and the criticisms posted by Patrick Griffiths I decided to check out his website, htmldog.com. How ironic that someone who is arguing for strict semantic CSS identifiers uses class and ID names such as “antiintro”, “pp”, “cl”, “hh”, “hart”, “hex”, “r2”, “jelly”, etc. His website source is a great example of how NOT to name your CSS elements.

DaveMo

August 4, 2008 5:16 PM

Man, a guy trys to express an opinion on a subject that definitely does NOT have a cut and dried solution and he gets roasted. Someone pointed it out earlier but a lot of this stuff is just Ad Hominem.

@Martin: regardless of whether I agree with your own approach to this issue or not I thank you for at least taking the time to share your opinion and how it affects your personal workflow. If there is anything I know about webdesign and standards, it’s that I don’t know it all and my personal workflow is constantly evolving.

To those pining about the fact that DW would let this (seemingly) unprofessional article grace it’s hallowed servers: get over yourself. I believe it was pointed out earlier that DW doesn’t hold itself to some almighty standard before it accepts articles for publication. Stimulating discussion regarding best practices and personal workflow in the web development field is always good stuff. Take what you like from the articles and don’t feel obligated to take everything at face value.

Simon Frost

August 11, 2008 4:00 AM

Broadly, I agree with you. Standards can help with the broad philosophy of designing/building a website, but I find if you try to adhere to them too strictly, you start running into problems and even find contradictions.

In my view, standards are a great help when designing websites, but they can also be a hindrance if you follow them too closely or too literally.

Gabe da Silveira

August 12, 2008 12:57 PM

There is a thesis in here somewhere that I agree with, but unfortunately I think the words “smart vs sexy” and a ranty tone made it hard to digest for people who don’t already get it. Still, some great discussion here overall. A big source of this debate comes from how primitive CSS really is, leading to painful decisions. My interpretation of the fundamental argument occurring here is:

Should you write fewer re-usable classes with more “presentational” names, or a greater number of “semantic” classes? The answer is it depends. You have to look at each individual case to answer that question. It’s easy to argue against the former because that’s how things were done pre-CSS (ie. font tags everywhere), and so it’s painfully clear the amount of bloat that accumulates. On the other hand, if you always strive to make class names uber-semantic it leads to bloated CSS. Mark Norman Francis made a great point as to the necessity of this to avoid unintended consequences when the CSS is modified. He’s right to an extent—sometimes writing out more code improves maintainability, but realize that the exact same argument can be used for peppering your HTML with font tags.

The bottom line is, anyone who thinks they have the universal answer to that question is wrong. Talented individuals will have different practices based on their experience and the project at hand. The most maintainable code can’t be created based on theory alone, fundamentally it requires knowing where the code actually will change. The fact is every line of code is a tradeoff that will make some changes easier and some changes harder. People who don’t want to accept that turn into architecture astronauts. That’s bad enough for programmers using powerful languages, but for front-end developers using HTML and CSS it’s just plain sad.

Web Designer Guy

August 23, 2008 12:21 AM

Since you mention spacer.gifs (they always make me smile…ok I was there too for a while) this video may amuse:

This wasted bandwidth

Tiff Fehr

September 15, 2008 4:59 PM

Closing comments on this thread due to spam. I’m sure Martin would appreciate followups to him directly, or use our “Contact Us” form and we’ll forward your thoughts along to him.

Thanks to all who joined the discussion on this one!

Sorry, comments are closed.

Media Temple

via Ad Packs