[ian1321]

I used this technique in my previous startup. I even had shell scripts that generated my LESS files.

One of the driving philosophies was that when one saw a CSS class, they should easily be able to find it's definition in the source. Another driving philosophy was that one should easily be able to determine what the class is doing.

This lead to classes like `u-centered`. The `u` tells me it's in the utils.less file. Classes starting with `l-` were layout classes, `t-` text classes, etc..

I had classes like this:

u-{max,min}-width-{xxs,xs,s,m,l,xl,xxl}

t-white

u-bg-red (red background)

t-h3

l-container-{xxs,xs,s,m,l,xl,xxl}

You get the picture.

(The nice thing about xl and xs is that you can keep adding x's as you need.)

I found it to be very effective. I understand the arguments that it kind of defeats the purpose of CSS, but I think CSS is pretty easy to mess up, and this give you a solid, consistent structure to work with.

Of course, I didn't follow this style 100%. There were some cases where it just made sense to use a more semantic style, but I found those case to be few and far between.

[wvenable]

Seems like a waste of time when you can just do style="background: red;". You're not adding anything to CSS you're just renaming and enumerating all the style attributes and values.

I think it makes sense in small doses but I think once you're using shell scripts to generate all these combinations you've lost the plot.

[ian1321]

There's a big difference between class="u-bg-red" and style="background: red;". The big difference being that the class make it so that it is first-class application idea.

And I think that may be one of the larger points here. CSS can be simple, and using techniques like this forces it to stay that way. You have to take a step back and understand what we're trying to do as engineers. I would argue that being able to quickly understand code (e.g. the context to understand a line of code is small) should be a top priority of most software project.

[wvenable]

"u-bg-red" vs. "backround:red" is just the same thing aliased. If you were to introduce an actual concept like "warning" or "error" that was red that would be different.

[ian1321]

You are correct from one point of view. But, the point I was making was that the class definitions for bg color can be contained within a single file in your application. Using `style` is completely different in that anything is possible. This is a big deal, as cutting down on possibilities/simplifying is a very important process in software engineering.

[wvenable]

> But, the point I was making was that the class definitions for bg color can be contained within a single file in your application.

But that doesn't matter because it's not an abstraction. If you have 10 HTML files and 1 CSS file, you can make a class called "warning" and have it be a background color red you've simplified those HTML files because you have less style information in the HTML.

But if you are using classes like "bg-red" or "pt-10" then you're not actually reducing the style content of your 10 HTML files. You've just renamed a style to a class. Sure you've reduced some possibilities but you've actually made the situation worse because now you have 11 files with style information. You've added new names for basic styles which adds even more complexity.

If you take that idea of reducing style possibilities to the logic extreme then you wouldn't be using classes like "bg-red" and "pt-10" anyway. You'd just do what everyone already does with CSS and abstract your styles appropriately.