Cargo Cult CSS

I'm starting to see a pattern here about "presentational CSS class names": considering the superficial presentation layer and not the underlying meaning that links consistent design elements. There's a language to design, and it's a hell of a lot more than "this button should be green".

"They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds."

There's a whole series of unasked questions going on there:

* Why is the button blue - what led to that conclusion?

* Why is green the right colour?

* What about the other buttons, are they all the right colour? If so, why. If not, why?

* Why does the style guide for the site not specify this properly? (You have a style guide, right? Your CTO and designer did present you with an up-to-date, style guide, right?)

Asking these questions leads you to the semantic understanding of why buttons are supposed to exhibit specific characteristics. It's the WHY that's important, not the WHAT.

CSS excels when there's a requirement for consistency in design, and there's a style guide. When your requirements are a superficial "this button must be green" and you don't stop to ask why, then you've already sacrificed the semantic aspects of the documents you are supposed to be vocal about.

Also, how difficult is it to find what stylerule is causing the button to be blue. Right click on the button, click "Inspect this element in Firebug", in the CSS Inspector find the CSS rule that specifies the colour as blue. Look at the CSS selector itself - does it describe the semantic reason why the presentation is coloured blue? With that understanding of the semantic basis of the button being blue, you have an answer WHY the button is blue.

So now you need to understand why the button is supposed to be green. Get that explained to you, and now you have a good idea of the semantics you need to express, or reuse, a CSS rule that will cause the button to be rendered in Green.

This is where semantic class names win hands down, it tells you the WHY of styles. Without the WHY you don't have a basis for explaining why the button is blue, and no clear inkling of why now it should be green. And absolutely no idea which other buttons on the site are the wrong colour.

And that's about as far away as you can be from a consistent style guide, and presentational accuracy. If everything is ad-hoc, then nothing is consistent.

> I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong

This is definitely something I'd like to do as well, but I wanted to focus on the areas I found problematic first and foremost. I may post a follow-up based on the feedback I've received.

> Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead

As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.

> I imagine that's just because you'd rather see better looking html than you would see better looking css.

I'm actually interested in both :)

> You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics.

What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented

> My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds.

Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.

This is an argument I had with myself a few years ago, when OOCSS started becoming popular. Ultimately, what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine. There's a bunch of articles out there on the new semantics, you can look them up as I can't be bothered to link to them.

Ultimately, though, the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore. The web has evolved in use to include web apps and other forms of media, so our principles must evolve as well. It seems silly to cling to past definitions as immutable when we work in a field that changes drastically nearly every year.

Also, anyone who advocates using a selector like "ul.members li a" and then complains about the maintainability issues of using non-semantic classes when an update needs to be made should really reconsider their hypocrisy. Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.

The reality is that any change in the UI big enough to warrant updating the markup is going to warrant updating the CSS, and vice versa. Worrying about making them completely separate is impractical and will just cause you to waste time in development.

If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Do not create crappy selectors. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide. Use something like KSS to link between the style guide and the CSS. There's no excuse for using bad selectors in the name of ease of on-boarding.

> What are ‘presentation semantics’? I think this is a corruption of the concept of semantics. Semantics are what a thing is, or means, or does; not how it is presented

Semantics just means to give something meaning. Presentation semantics (http://en.wikipedia.org/wiki/Presentation_semantics) are just marking up the data to declare your intent for how you would like it to be presented.

> As I said, I don't believe this is an appropriate approach for a medium which has no absolute, definitive interpretation. A website isn't how it looks, because how it looks will differ depending on how you access it. The only absolute truth when talking about websites is the semantic purpose of the markup underlying it, because purpose is universal: a navigation element is a navigation element regardless of whether it's being displayed on a TV, a desktop browser, a smartphone, or being read out by a screen reader.

A HTML document is just text. Technically adding links, particularly navigation, is just presentation markup. As you said, it's up to the interpreter to make sense of that markup. The basis of your argument is that presentational markup is bad though, so I'm left unconvinced here.

> Changing how you structure the CSS in your application based on the whims of people whose area of expertise isn't CSS sounds like a nightmare scenario to me. If you're bootstrapping with a small team I can understand wanting to have everyone being able to contribute, but you should also be able to recognise what the limitations of their skills are. In the example you give, I would be using my web developer tools / inspector etc. to find out the origin of the erroneous property. If you're using a preprocessor there are source maps that can help with identifying how a rule was built. I certainly wouldn't conclude it's easier to use a presentational class name just so that my CTO could understand the code.

I'm concluding that presentational class names are easier to fix for the regular small changes that come down the pipe in our project. Even if you're regularly making big presentational changes to your entire site, then you'd need something a little more abstract, like using a class to declare an element as a button instead of the direct color it should be, but like I'm said, the argument against presentation markup is still unconvincing in the face of simple maintenance.

> what I determined is that there's a new definition of what "semantic" means in front-end architecture. Semantic doesn't just describe the content anymore, it describes the function as well. So using classes like "module-box" or whatever is perfectly fine.

Semantics describes a thing, but classes like ‘module-box’ don't convey any meaning beyond presentation. If you think that ‘module-box’ is semantic, then I have a whole bunch of classnames based on colours to sell you…

> the "separation of concerns" was a good principle to use when the web was a bunch of documents meant to provide content. It isn't that way anymore.

The virtues of this approach have very little to do with the web; it's a concept that pre-dates it, so it's hard to justify it having been invalidated simply by advances in web technology. Besides, a web ‘application’ is equally composed of semantic components just as much as a document is; part of the reason HTML5 came about was to reflect the kind of elements used in modern web pages.

> Using selectors like that (aside from being slow performing) completely tie the markup to the presentation. Hell, if all you did was update the list to an ordered list instead of an unordered one you'd have to update the CSS as well.

This suggests that your workflow starts with CSS and you then build markup to fit it, which his sounds completely backwards to how I approach things. You don't tie your markup to how it is presented: you declare how you want to present the markup your app is built upon. Also, if you change the markup to something with a completely different meaning (an ordered list is meant to have a different purpose than an unordered one) then of course it follows that you'd have to update the CSS, although there's no reason why those changes need be onerous or difficult.

The whole selector performance debate is old and dead, by the way: http://calendar.perfplanet.com/2011/css-selector-performance....

> If you're concerned about the discoverability of the code to a new developer, DOCUMENT IT. Create a UI style guide that implements all of the major UI components and have the developer reference the style guide.

A style guide is a fine starting point regardless of how you want to approach your CSS, but documentation isn't the only way to aid discoverability of code. Selectors that communicate context and purpose can be very helpful for this too.