[Feedback] When to use which CSS methodology

[simurai]

When to use which CSS methodology

Published: November 27 2016

👀 Read post
💬 Leave feedback below
✏️ or edit the post.

[jitendravyas]

performance is also a factor in deciding which methodologies to use. page weight, non-cached first pain time etc.

[giuseppeg]

+1 @simurai! I would have mentioned ShadowDOM too :)
Also this is an interesting idea – similar to CSS Modules but lets you use any kind of selector.

[jitendravyas]

Under section

I want to get started with a prototype .

I think you are comparing Libraries with approaches. TACHYONS or BASSCSS are libraries based on Atomic CSS methodology (ACSS too) and can be used with a small or big project, multi-dev or single dev.

And I guess maybe in this section you mention TACHYONS or BASSCSS only because you have used them or prefer them, Frameworks like Bootstrap, Foundation also comes under the prototype case as per your explanation.

[LeeKowalkowski]

The only reason I can think of using chained selectors is if you have no access to the markup.

Woah, markup FIRST! Design your HTML semantically-rich, without any classes (e.g. you'd be wise to prefer aria-selected="true" over BEM's "--active"). Then when you're styling, leave the HTML alone, and work with something that has more chance of gracefully degrading should the CSS be unavailable.

Have some empathy for the HTML author! I would rather enjoy writing page after page of 'write once, use anywhere' clean, class-free HTML, and take advantage of the cascading part of cascading style sheets. Than write yet another HTML snippet suffering from class overload, just to avoid the cascade.

Seems lately people are resorting to CSS frameworks because they don't want to learn CSS itself (only its properties). Every time somebody invents a CSS framework, they create something that is effectively a brand new language over the top of CSS. This is effectively 'CSS Avoidance'.

The class attribute belongs to HTML, not CSS. Semantically you should be in the habit of designing coarse-grained classification of your HTML elements, and not manically labelling every single element just to flatten CSS specificity. Usually, a simple class name on a parent element, is enough, and I love keeping things simple.

Elements should be classified sparingly based upon the reason why this element is so special, how common are such elements, and can another author easily predict its usage? I.e. which elements will require this class and which will not, what are the rules?

CSS frameworks are responsible for the most hideous, hard to maintain, hard to reuse HTML we have ever seen.

[simurai]

@giuseppeg I would have mentioned ShadowDOM too :)

Added 👍

@jitendravyas I think you are comparing Libraries with approaches.

Yeah, that's a good point. I guess I mentioned it to make it easier to understand what “single purpose class” means. We could link to a blog post instead, maybe this one? And to be consistent, we then should also remove JSX, JSS and try to find posts that explain the CSS-in-JS approach.

[simurai]

@LeeKowalkowski I think what you described works very well for the "single page or a simple site" group. And also if the design doesn't need too much styling. But if the project gets more complex the same HTML elements get used in different ways and they also have to look different. Then using classes instead keeps selectors simple and less chance of running into side effects.

[LeeKowalkowski]

@simurai I think this is a myth, created by people who think they've worked on complex pages or sites, when maybe they haven't had any enterprise, multi-million pound corporate or government project experience, at all.

Complex sites with hundreds of developers and content authors (few of which have much HTML or CSS expertise), responsible for the maintenance of dozens of apps and tens of thousands of pages - all referencing the same corporate CSS files - maintained by a handful of CSS developers (sometimes not even plural).

Such myths are possibly the product of experiencing 'too many cooks' or lack of communication between CSS developers, lack of guidance for content authors and application developers, and other anti-pattern that CSS Frameworks don't address. I believe making your HTML complicated in the name of simplifying your CSS is such an anti-pattern, which gets worse for large projects.

If anything, using a CSS framework requires even more communication/documentation otherwise the project prefers to add more CSS to compensate for design inconsistencies, catering for too many possible versions of similar things. Which leaves application developers and content authors not knowing what HTML to use, or when.

For truly large-scale, enterprise CSS projects, supporting tens of thousands of pages produced by very large teams, the HTML must be fixed and documented in the form of a pattern library, and that HTML needs to be as simple and easy to write and maintain as possible. You cannot litter the HTML with classes as many CSS frameworks do, when you have not-so-literate people working with the HTML. Otherwise they will file issue after issue, and your small team of CSS maintainers will spend all their time debugging what the developers and content authors have tried to produce.

So, I'm sorry, I do not see that large-complicated projects require these HTML-polluting CSS frameworks. The way I see it, is that such CSS frameworks make projects large and complicated in the first place.

[simurai]

Ok, this post got deleted again, see bc9c240 for the reasoning.