Scalable and Maintainable CSS Approaches

http://cwebbdesign.tumblr.com/post/23666803241/scalable-and-maintainable-css-approaches

by cwebbdesign • 14 years ago

41 15 14 years ago

cwebbdesign.tumblr.com

The approaches laid out seem reasonable, but it's hard not to feel as if the web dev community has moved on to using LESS and SASS as a means of addressing some of the same issues.

philipwalton2• 14 years ago

These approaches are not incompatible with SASS/LESS. If anything, learning them is more important now that we have preprocessors.

roryokane• 14 years ago

If that's the case, I would be interested to see a tutorial on OOCSS that assumes you're already using Sass, and skips explaining the parts of OOCSS that Sass already solves. I hadn't really taken OOCSS seriously because I thought Sass solved everything that OOCSS did.

cwebbdesign2• 14 years ago

I agree that preprocessors can address some of the issues that OOCSS sets out to address. At the same time I think that an over reliance on preprocessors can result in the same set of problems. Preprocessing can easily result in bloated, highly repetitive CSS and deeply nested selectors.

I personally love using SASS and in fact (as mentioned by philipwalton) find it highly compatible with OOCSS. However, as with any tool, I advocate for thoughtful and critical implementation. I tend to suggest that anytime the final CSS file contains a large amount of repetitive styles or deeply nested selectors it's time to consider refactoring.

i_like_robots• 14 years ago

Developers are always going to combine approaches to what best suits them. Using abstract, extendable naming conventions and abstracting out each module/widget into separate files organised into folders for compilation via LESS or SASS is an ideal combination for me. I think every front-ender needs to pick and choose ideas from multiple methodologies, otherwise there will always be issues with maintainability when building large sites.

More important than any one methodology is consistency and documentation, no one wants to pick up a project with 'genius' abbreviated class names without some example markup!

jasonrr2• 14 years ago

This is something I've been thinking a lot about recently, and while all of these approaches solve some problems I think the requirement for maintainable CSS is a fundamentally different approach to the purpose of CSS. Once you make the mental switch from "CSS is the stuff that I do to make the things that I build look right" to "CSS is a component of everything I build" it becomes easier to see what I mean. It's not about "I need to be able to reuse this font size" as much as it is "I want to reuse this widget when I am display text in this way on any page".

In other words, if you want to build something maintainable, start thinking about all the ways you can help people not write custom CSS at all.

Also, LESS and SASS at their core do little to help with this problem, and can even hurt you with unintentional specificity (due to nesting) that hurts reusability. Mixins help you think "reusability" but they can really easily be misused in ways similar to how people are misusing CSS right now. This is by no means an attack on LESS/SASS, which I love. It is just a reaction to working on a large project that is making the switch and seeing the fallout.

lbotos• 14 years ago

I'm not sure I follow. Are you advocating writing "classless" CSS? Could you elaborate as to what you mean by "not write custom CSS"? I don't mean to be pedantic but CSS of any kind is "custom". I think you are advocating OOCSS techniques but trying to call them something else. (No offense)

jasonrr2• 14 years ago

I am saying that you can follow OOCSS coding practices and still wind up with a ton of really great abstracted styles that you don't reuse. That is because most people look at OOCSS and only see the "this is how you write proper CSS" and don't realize that most of the work is around planning and communicating. How many of the folks using OOCSS have a style guide of some kind that they are sharing to let people know what exactly is available to be reused?

This article focused on the first part and even compares different approaches, but misses the point that OOCSS is advocating a process overhaul, not just a change to the way that you write CSS.

When I say help people not write custom CSS, I am referring to reuse. Writing the code the right way is of course a pre-requisite, but from experience, not nearly enough.

ilaksh• 14 years ago

They invented a solution for scalable and maintainable UIs many, many years ago. Its called a widget.

jacobr2• 14 years ago

I find that a combination of SMACSS and a lot of shared helper classes (left, right, center, size-<n>, ...) really helps with maintainability.

I don't get the DRY CSS approach of wanting to avoid changing HTML. CSS changes are much more expensive, as they can affect the design on unrelated pages (especially if you don't write modular CSS), which means more testing.

And are there any real world use cases or benefits of "semantic class names"? If not, and if you think they hurt maintainability, why would anyone advocate them?

rimantas• 14 years ago

  > And are there any real world use cases or benefits of
  > "semantic class names"?

Yes. Class names tell what the stuff is, CSS rules tell how to style it. Once you see blue 14px text on the left which has class "red-12px-right" you are enlightened.

jacobr2• 14 years ago

"Class names tell what the stuff is" is not a "real world use case or benefit". In an HTML document, the defined vocabulary is the HTML elements and some attributes. Class names are styling hooks, with the exception of microdata.

'red-12px-right' is a stupid class name (and a strawman). A better example would be 'heading-primary', instead of a "semantic" approach like '.news h2 { }' (which could have the same styles as '.blogs h1' and '.members h3'...)

Scalable and Maintainable CSS Approaches

Related Stories