There's many CSS methodologies out there, and I hate them all. Some more (tailwind & al.) and some less (BEM, OOCSS, etc.). But at the end of the day, they all have flaws.

People use these approaches for good reasons, of course, and many of the problems addressed are ones I have also encountered. So in this post, I'd like to write down my own guidelines for how I keep CSS organised.

This isn't a fully described CSS methodology that anyone could just start using. Maybe it could be turned into one with some extra work, but the purpose of this post is simply to show how I make these decisions when writing CSS.

Builtin Elements

As a rule of thumb, I try to use builtin element types as much as possible, and with as little extra fluff as possible.

Having a need for a thousand different types of button is a sign that there might be something wrong with the design on a deeper level, so while in some cases I get the appeal of CSS being inert until framework-specific classes are used, in most cases I see it as ideal when a button is just Click Me! and looks like a button without any further magic.

div.btton should turn into button

Custom Elements

Not all design elements have a semantically fitting HTML equivalent, and for these cases, I usually resort to custom elements.

I haven't seen many instances of custom element names being used without any accompanying javascript, but it has proven to be a surprisingly solid choice for writing clear HTML that also looks the way I want.

Entirely separate elements in terms of design are also more likely to, over time, develop requirements that can only be implemented with JavaScript, which leaves you with a clear path to implementing those that doesn't need any changes in the HTML nor the CSS.

div.vsep should turn into vertical-separator

Classes

Classes should work as modifiers of the existing node name, rather than entirely new element types, and often have similar but different effects on different element types.

A dangerous button is a button.danger

Attributes

Some ways of modifying elements aren't simple on/off switches that classes are useful for, but behave more like key-value pairs.

In these cases, custom attributes with matching selectors have proven to be the best option almost every time I've used them. Unlike hyphenated classes, they show on a syntax-level which is the attribute and which is the value, making it easier for editors to highlight them, easier for the human eye to quickly parse, and easier to interface using JavaScript.

For those of us who still have hope that the attr() function might one day make its way into CSS for more than just content, this is also an extra layer of future-proofing.

IDs

IDs are, by definition, unique inside the document. As such, any rule targeting a particular ID will be limited and may require refactoring if it later turns out there should be more than one element of this type on the lage after all.

As such, IDs should be used sparingly and only when it makes no sense to ever have more than one element in one document.

The benefits over classes in both a practical and readability sense are rather small, so erring on the side of classes is usually the best idea when no clear 1-to-1 relation between element and styling can be identified.

Inline CSS

Any real-world application will at some point have elements that simply require individual tweaking in order to make them more aesthetically pleasing in the context they appear in.

In these cases, the style attribute is the way to go. Any reason why using it is considered bad practice applies to any sort of inline-styling, including utility classes. The problem isn't the attribute, it's mixing styling and markup.

The one difference between style and class for inlining styles is that one indicates purpose, allows using plain CSS and is mostly universal, while the other isn't.

Put simply, width: 100px has a universally defined meaning, whille .width-100 could mean anything.

Utility Classes

In very rare occasions, element-specific styles get so complex that inlining them explicitly would harm readability, or is even impossible (for example if it requires media queries).

In these cases, utility classes are basically the only option, even if they're ugly.

In an ideal world, these could be handled separately from specific mixin classes, and I have even considered using prefixing to more easily tell them apart, but ultimately haven't found a good way to make these not be ugly.

I like the idea of prefixing utility classes with a to represent that they add some sort of functionality to the element, in contrast to normal classes, that specify what type of an element is.

Red floating button

And that was about it. Of course, no two projects are the same, and sometimes rules have to be bent a little to remain practical, but overall, that's my framework for deciding how to make a thing on the screen look a certain way.

What are your thoughts? Do you hate it? Do you think it makes sense? Let me know in a comment ?