On the Growing Popularity of Atomic CSS

Share this:

Even if you consider yourself a CSS expert, chances are that at some point on a large project you've had to deal with a convoluted, labyrinthine stylesheet that never stops growing. Some stylesheets can feel like a messy entangled web of inheritance.

Spaghetti Monster

The cascade is incredibly powerful. Small changes can have large effects, making it harder to know what the immediate consequences will be. Refactoring, changing, and removing CSS is seen as risky and approached with trepidation as it's difficult to know all the places it's being used.

One thing that is often hard to articulate with new tooling is when, exactly do you start to reach for this? The answer is rarely (if ever) immediately and in all situations.

One of those situations, in my limited experience, is on large teams with large codebases. The feeling is that the CSS can get far too large and team members essentially become afraid of it, and the CSS becomes jokingly-but-accurately “append-only”.

Along comes a tool that delivers on a promise of shipping far less CSS and in a way that (after a learning curve) nobody is ever afraid of again… I can see the appeal.

Atomic CSS keeps things simple

I no longer had to think about how to organise my CSS. I didn't have to think about what to name my 'components', where to draw the line between one component and another, what should live where, and crucially, how to refactor things when new requirements came in.

Atomic CSS offers a straightforward, obvious, and simple methodology. Classes are immutable - they don't change. This makes the application of CSS predictable and reliable as classes will always do exactly the same thing. The scope of adding or removing a utility class in an HTML file is unambiguous, giving you the confidence that you aren't breaking anything else. This can reduce cognitive load and mental-overhead.

Naming components is notoriously difficult. Deciding on a class name that is both meaningful but also vague enough to be reusable is time-consuming and mentally taxing.

There are only two hard things in Computer Science: cache invalidation and naming things.

– Phil Karlton

Coming up with the appropriate abstractions is hard. Naming utility classes, by contrast, is completely straightforward.

Atomic classes speak for themselves. Their intent and effect are immediately obvious. While littering HTML with countless classes may look cluttered, HTML is much easier to reason about than an impenetrably gargantuan and incomprehensible wall of tangled styles.

In a mixed-ability team, perhaps involving backend developers with limited interest and knowledge of CSS, there's less chance of people messing up the stylesheet.

Taken from ryanair.com - a whole load of CSS all doing one thing.

Dealing with stylistic variation

Utility classes are perfect for dealing with small stylistic variations. While design systems and pattern libraries may be all the rage these days, what this approach recognizes is that there will continuously be new requirements and variations. All the talk about component reusability often isn't reflected in the design mocks that get passed your way. While visual and brand consistency is good, the wide variety of contexts on a large website make some variation inevitable and justified.

What if we want a component to differ from another in only one single small way. If you've adopted a BEM naming convention, the modifier classes may well get out of hand - countless modifiers that often do only a single thing. Lets take margins as an example. The margins of a component are unlikely to remain universally consistent for a component. The desired spacing depends not only on the component but also its position on a page and its relation to its surrounding elements. Much of the time designs will contain similar but non-identical UI elements, which are arduous to deal with using traditional CSS.

A lot of people dislike it

How is Atomic CSS different from inline styles?

This is the question always asked of atomic CSS by its critics. Inline styles have long been deemed a bad practice, rarely used since the early days of the web. Critics aren't completely wrong to equate atomic CSS to inline styles because they both suffer from the same major pain point. Here's an example: What if we want to change everything with a .black class to be navy instead? We could do this:

.black {
color: navy;
}

That's obviously a terrible idea.

Text editors are sophisticated things these days. It feels somewhat hazardous, but it would be simple enough to use find and replace to change all instances of the .black class with a new .navy class. The real problem is when you want to change only certain instances of .black to be .navy.

In traditional approaches to CSS, adjusting the styling of a component is as easy as updating a single value in a single class in a CSS file. With atomic CSS this becomes the tedious task of searching through every piece of HTML to update every instance of said component. However advanced code editors become, there's no getting around this. Even if you're separating your markup into reusable templates, this is still a major drawback. Perhaps this manual labour is worth it for the simplicity of this approach. Updating HTML files with different classes may be tedious but its not difficult. (Although there have been times when I have temporarily introduced stylistic inconsistency by missing certain instances of the relevant component when manually updating.) If a design changes, chances are you'll need to hand-edit classes from all over your HTML.

While atomic CSS shares inline styles big drawback, they aren't a retrograde step into the past. Utility classes are better than inline styles in all kinds of ways.

Atomic CSS vs. Inline Styles

Atomic classes allow abstraction, inline styles don't

With atomic classes, it is possible to create abstractions that would be impossible with inline styles.

The first two examples shown above would require a manual find-and-replace in order to update styling were the design to change. The styles in the third example can be adjusted in a single place within a stylesheet.

Tooling

Sass, Less, PostCSS, Autoprefixer… The CSS community has created a lot of useful tools that weren't available for inline styles.

Brevity

Specificity

This is a contentious point. If a class or inline style only does one single thing, chances are you want it to do that thing. Some people have even advocated using !important on all utility classes to ensure they override everything else. Similarly, proponents of inline styles see its inability to be overridden (by anything other than !important) as a selling point - it means you can be sure the style will be applied. However, a class alone is specific enough to override any base style. The lower specificity of atomic classes compared to inline styles is a good thing. It allows more versatility. Were all used to changing classes on JavaScript to change styles. Inline styles make this harder.

Classes in stylesheets can do things inline styles can't

Inline styles do not support media queries, pseudo selectors, @supports, or CSS animations. Perhaps you have a single hover effect you want to apply to disparate elements rather than to only one component.

Simple reusable media query rules can also be turned into a utility class. Its common to use a classname prefix for small, medium and large screen sizes. Here is an example of a flexbox class that will only apply on medium and large screen sizes:

@media (min-width: 600px) {
.md-flex {
display: flex;
}
}

This wouldn't be possible with an inline style.

Perhaps you want a reusable pseudo-content icon or label?

.with-icon::after {
content: 'some icon goes here!';
}

Limiting choice can be a good thing

Inline styles can be anything. This freedom could easily lead to design anarchy and inconsistency. By predefining classes for everything, atomic CSS can ensure a certain amount of stylistic consistency. Rather than ad libbing colours and values from an infinite amount of options, utility classes offer a curated set of predefined options. Developers choose from this limited set of single-purpose utility classes. This constraint can both eliminate the problem of an ever-growing stylesheet and maintain visual consistency.

Take the box-shadow as an example. An inline style will have an almost limitless amount of options for offset, spread, color, opacity and blur radius.

With an atomic approach, CSS authors can define the preferred style, which is then simply applied, without the possibility of stylistic inconsistency.

<div class="box-shadow">stuff</div>

Atomic CSS is not all or nothing

There's no doubt that utility class frameworks like Tachyons have grown in popularity. However, CSS approaches are not mutually exclusive. There are plenty of cases where utility classes aren't the best option:

If you need to change a lot of styles for a particular component inside of a media query.

If you want to change multiple styles with JavaScript, it's easier to abstract that into a single class.

Utility classes can coexist with other approaches. Its probably a good idea to define base styles and sane defaults globally. If you keep duplicating the same long string of utility classes, chances are the styles should be abstracted into a single class. You can mix in component classes, but do so only when you know they will be reused.

Taking a component-first approach to CSS means you create components for things even if they will never get reused. This premature abstraction is the source of a lot of bloat and complexity in stylesheets.

Looking at the newest release of Bootstrap, a whole host of utility classes is now offered, while still including its traditional components. Increasingly, popular frameworks are taking this mixed approach.

Share this:

Comments

Atomic classes speak for themselves. Their intent and effect are immediately obvious.

I’m not sure I would agree with this assertion. I think Atomic CSS (like most naming conventions) has a learning curve. The shorthand that Atomic CSS uses tends to reduce the declaration to as few letters as possible; if you’re not already familiar with the naming convention it may be indecipherable.

For a person familiar with Atomic CSS these are clear and coherent because you already have context on which to base your interpretation. The only thing not immediately clear is what real value ‘4’ or ‘2’ translate to.

For someone who hasn’t really been exposed to this naming style there is nothing immediately readable. I could forgive a novice for overlooking these completely and assuming they were generated by some backend application for secondary purposes like targeting elements by class.

Agreed. What would you call a class for applying box shadow? I assume bs-… But then what do you call the class for border-style??

These convention systems are, at the end of the day, just conventions and at some point a team has to decide on them and no two teams will decide alike. The learning curve between this or another system doesn’t really seem any more or less difficult.

I think utility classes need to very generic in use. The idea of .px-2 seems to imply a padding on the x of 2 pixels, or some other totally trivial style thing.

In my experience, utility classes usually are best used in two layers. If they are part of a framework, they just affect very generic things, like widths, positions, layouts. And there are very few of them, thus limiting the learning curve.

If they are part of a site style, then they are custom to the site, and therefore the learning curve is short because they focus on the needs of that current site.

Trying to combine both general framework styles and custom site themeing into the same batch of CSS is, in my opinion, one of the extreme downsides of frameworks like Bootstrap and the biggest addition to the learning curve.

But, in the long run, everything has a learning curve, and supposedly it should make development faster/smoother once past the curve. So ymmv in any chosen system.

In my own projects I tend to use longer CSS class names specifically to avoid this sort of ambiguity. To use your box-shadow example I would probably apply a naming convention like this:

._ui-effect--boxshadow {
box-shadow: 0 4px 4px rgba(0,0,0,0.25);
}

And that first portion (_ui-effect) would ‘house’ all of my design enhancements that were universal to the interface I was creating. For my purposes it ticks all the boxes: It’s clear what its scope is (UI), what it does (applies a box shadow), and can be combined with other classes to enhance whatever element upon which it is applied.

Ok, so who else here remembers the days of CSS1 and (pre-x)html when tags were a thing. ALOT of work has been done in the last decade to improve the separation of concerns and DRYness of web languages. While I can see merits to this approach it feels like it flies in the face of of all the work that’s been done and ignores the whole point of modern web standards.

I feel like the last subheading really is the proper use-case for atomic css – namely not as an overall framework, but rather as a tool to keep in our toolboxes for when we hit one of those inevitable edge cases that bloats your css.

IMO design patterns are just that, patterns, and should be used and ignored with discretion and as the project deems it necessary.

Feels like there were two things going on. One was the need for utility type classes to position things that weren’t in the original design spec for whatever was being made. I get this, along with acknowledgement that sometimes a pattern may qant to flex, other times not based on its content.

To actually build pattern designs entirely from these classes within the html though… That just seems clumsy and exhaustive.

I’ve actually used the approach oncw this year on a project and found myself forever tripping over what a pd10 was. Was it padding x&y, just y, just x, was there now going to be a separate one for each? At that point I conckuded this was a really wasteful approach.

Until, that is, I started using them as pure design utility to change the shape of a unique pattern. Problem then was its unique nature made me question where to use ID instead.

“Perhaps this manual labour is worth it for the simplicity of this approach. Updating HTML files with different classes may be tedious but its not difficult.”

No, it is not worth it.

It might be clichè now to blame it on the millenials, but nobody in their right mind with a two-decade experience in frontend (when it was called being a webmaster), would resucitate the font tag as utility classes and call it an approach. Why would we sacrifice design consistency and semantics to follow what has always been a bad practice? We don’t need to go back to those awful places modern web standards took us away from. It’s like someone longing for The Dark Ages to make a comeback.

I’ll give Atomic CSS adepts ~5 years to realize what a terrible mistake they’ve made. Then they’ll come up with a fancy name and a slideshow for using web standards as they were meant to be used.

I think the biggest problem with articles like this is that they seem to imply a dramatic shift in the CSS world, when in reality, they are simply describing a phenomenon that has already existed for years.

I have “atomic” classes that just set defined widths, position inline-block, and a few others and that’s it. They are very useful in app environments, and I have had them for many years. But I am not going to move all my styles over to this.

Also, I don’t use atomic style classes for actual visual styling, I think that is where your concern may actually be, and mature CSS devs won’t paint themselves into a corner no matter what the “trends” are.

So, take everything with a grain of salt. These authors have to consider how to share information while both exclaim it’s virtues and not over doing the effects on the industry. But I think your comments are the sour to their sweet, it’s necessary for a balanced view.

This has been my approach. Generally I follow a BEM naming scheme, however there will always be a small collection of utility classes for one-off modifications of elements, ex, .mt-0 for margin-top: 0 !important;

I’ve gravitated more and more towards PostCSS for projects, but iotaCSS has totally inspired me with its namespaced utility class names and responsive configuration. Anybody else use it?

I also wanted to say that for the past year or two I’ve started nearly all projects following the https://sass-guidelin.es/#the-7-1-pattern structure and using BEM. This has you creating discrete components, but also has a folder for page-specific styles. Especially thinking about margins as with the example above, I’m not convinced that page-scoped styles aren’t an A-OK solution to slightly modifying components in different contexts.

Utility classes can coexist with other approaches. Its probably a good idea to define base styles and sane defaults globally. If you keep duplicating the same long string of utility classes, chances are the styles should be abstracted into a single class. You can mix in component classes, but do so only when you know they will be reused.

That! This is where tools like SASS, LESS, PostCSS can come into play.

I initially started using Tachyons, but then wrote up a mixin that outputted the same pattern. Now I’m seeing repeatable patterns when creating components that I’m expanding the mixin to allow multiple properties. This requires discipline to not deviate too far from the method but still affords me the same flexibility and speed of coding, and finally the output size of the CSS file stays small.

You can adopt concepts but do not treat them as a rule, let’s say like language functions.

One more thing. !important in CSS, due to inlining or otherwise, even inlining alone… is one heck of a regression. It bothers me that either still come up.

Just my own experience speaking here (not scientific, merely anecdotal): I use atomic css techniques (I roll my own: https://github.com/internetErik/atomic-scss) and I’ve been using them for about five years. I also use BEM names for some semantics, however I hardly have actual styling behind these classes besides some things at breakpoints. The semantic names are more useful for readability and easy selecting of code.

In my personal experience using these techniques I haven’t had to deal with any of the traditional pitfalls of css. Additionally, team members, even when skeptical at first, try it and start using it on their own projects.

One important experience I have with atomic is that there are people who hate it a lot, and seem to go out of their way to make people who use atomic feel like they are inexperienced and that in the past lessons were learned and now inexperienced developers are making the same mistakes again. I often don’t think this is put as sensitively as it should be for new developers, nor do I think it is true. I use atomic css and I’ve been making websites since before CSS was available (bgcolor=, etc), and I’m sure this is also the case for many others who use atomic css (or styled components, and so on). I’m sure there are new developers trying atomic css, and I don’t think they need to be talked down to.

The one good thing of this article is that it states clearly what are the drawbacks of Atomic CSS.
Styling a page is trying to translate a design into code. Of course you apply a certain margin here, a padding there, a font-size in another place, etc. But if you really want to translate this design, you may give a class to a “box” and in this class, apply many different attributes: margins, paddings, borders, font styles etc. And this gives you the idea that design is not just a margin, but a collection of things.
Some people say BEM is ugly because of lengthy names, and repetitions, but if you use only atomic classes, its so much worse! and when you read the collection of atomic classes, you have to read every single class to figure out what is applied at the end, and maybe know the website to realise that, Oh, on this particular block, we don’t apply this margin that we generally apply everywhere.
When with BEM you would probably have one class, and a modifier saying “particular situation” to handle this difference.
But I agree that “utility classes” are actually usefull sometimes and can definitely make use of “!important”. But you should almost always be able to do without. At least you should try ;-)

I’m looking forward to see how Atomic CSS authors deal with the Grid spec. I cannot see it working. Maybe with floats, and Flex-faux-float-grids and col-xs-whatever but not Grid, not without limiting it’s capabilities.

So, I am big believer in the right tool for the right job. And I honestly can’t tell if zealots are wrecking good ideas used improperly, but I think most CSS techniques overlap and have special use or general use cases, but rarely (or never) both.

Here’s a general approach to Grid I love. But I don’t use it everywhere, I use it very controlled environments with lots of form layouts that benefit from this.

It’s useful for form construction mainly. I haven’t used it for much else. But I can’t say if this fits “atomic css” by definition, but it seems to. And I certainly can’t think of an easier way to do this using any other methods.

I imagine Grid can be seen in a different way to what has come before. Methods that describe the utility such as col-2fr are bound to fail, for instance what happens when a utility for a row/col combo in a specific co-ordinate on an implicit grid is needed?

Grid has huge potential, however it will be limited by the imaginations of it’s users.

…what happens when a utility for a row/col combo in a specific co-ordinate on an implicit grid is needed?

Then you make something that fits the requirements. But that doesn’t automatically mean that all the situations that are solved quickly and easily by a utility are invalidated.

You seem to be falling into the common trap that every solution must be universal and perfect, and that’s how we get holy wars.

Use the right tool for the job. Utility classes work wonders for most common needs cases, not custom needs. Arguments against utility classes on the basis of edge use cases fails a common sense approach to problem solving.

I think this will get solved over time as we experiment more with grid itself to begin with. Even if it isn’t solved 100%, that doesn’t prevent using a combination of atomic and some other methodology to use grids to their full potential. Perhaps atomic will be able to handle the whole thing, but I suspect that I’ll be using atomic for common cases, and falling back to my BEM classes when things get more complicated (or if the api for atomic css would be too difficult to learn).

IMHO atomic css concept is very misunderstood. When i first time saw the syntax i was scared… by the time i realized its easy to remember name of utility clasess… Most of atomic haters overview the fact u do not use atomic for styling every element with 20 classes. I find very effective to define generic base styles (typo, colors ect) styles used across the project… and in some specific scenario u can apply UTILITY classes… to be honest get desired state in like 2-3 classes at maximum…so ur html isnt growing much…

This is one of those tabs vs spaces things. I personally do a heap of this in my css red-text, blue-text classes etc. Same if you have 3-4 font sizes etc so <h2 class="red-txt alt-font-a ft-sz32"> to me is a simpler way to see the CSS.

Clients like it too, if they need to see the CSS in the HTML editor in the CMS it is quazi English. I went to college with a lad who would write bizzare things in the classes to keep himself sane. Classes like sideshow-bob I dont think there is a right answer assuming your not writing terrible code.

I’ve tried working like this in the past, mostly with framework classes from Bootstrap. The reason I gave it up is because of style leaking.

That is, my classes clashed with each other. One would inadvertently influence another on a child element and throw off the layout. It got to the point where I was reading through the HTML to figure out how the classes combined to produce the wrong layout.

After building a website using atomic I came to the conclusion that it was hard to maintain and confusing. Every time you looked at the HTML you’d have construct a model of what each element was supposed to do. Mobile overrides were frustrating and led to bloat in both CSS and HTML.

After some tinkering I came to the conclusion that a hybrid approach is possible. Take for example centering something vertically in a div. Here’s the classic way of doing it:

I want to be open to this approach, but pretty much all my work, ever, has been on building web applications whose markup I control but whose styling I don’t control. In other words, single codebases that get used by many companies, each with their own themes (sometimes developed by third parties).

It would be an absolute nightmare to have a separate HTML template file for each client just for the sake of changing the atomic classes. There’s often a lot of logic, accessibility markup, or metadata in the base templates; it’d be a maintenance headache to go into each client’s theme folder to update the templates if you ever needed to change your approach or change the data model.

It surprises me that nobody talks about theming. For this use case, it seems that the approach that CSS Zen Garden made popular is not only the only tenable approach, but the only possible approach.

A few years ago I heard a few people debating whether we should focus on re-usable css that can be applied to a variety of markup and make it all look consistent versus re-usable markup that can easily be restyled. I never understood why they chose whichever path they chose because nobody ever described the reality of the projects they were working on. I suspect they were all webdev bootcamp students who had yet to build anything really complex.

While the context you speak of may be true (may not, depending on what the poor backeneders like doing), not everyone has a different team (or even person) to implement css and the html. I use atomic css and I write both the css and html for projects I work on. Maybe if you’re working on a project you prefer using another approach, but I don’t see how this means that atomic css is a terrible idea. Care to explain more?

The class=’color-dark’ breaks down as soon as you’d want to implement a night-scheme parallel to the normal one.
I think this technique will very easily miss out on the adaptable possibilities css gives you, like media queries. (But also on the quirks of css – it shifts the desing over onto the writers of the components / html which may or may not be a good thing.)

There may be some benefits to this in certain cases, but I do not think it will lead to the best, most adaptable or most maintainable designs overall.

As a user of atomic css I’m interested in this maintainability question. This is because I switched over to atomic css (probably about 5 years ago) to avoid maintainability issues, and I haven’t looked back.

It seems that there are different kinds of maintainability (and maintainability of different portions of a project).

Then there are certain problems like: Client has a component, and now they want to use this component someplace else – oh, but in this case we want it to be different in these subtle ways.

Without atomic css you will probably have to update css and html, whereas with atomic you will just need to update html. For both approaches you will have to pick between adding conditional logic, or duplicating code (or a combination?). With duplication of css (which all goes in the cascade) I think you introduce a greater risk of bugs, also the cascade doesn’t make doing conditional logic very easy (compared to if you’re using a html templating library, or a js framework like react), and the way you ‘read’ the conditionals in css isn’t obvious for future maintainers (you basically need to depend on naming conventions).

I always use a mixed approach depending on the needs of the project. If a project requirement is that a site needs to be able to be themed, then it is also necessary to determine the extent of the theming. If the themeing has to be as extensive as css garden (where basically everything but the markup can be expected to change), then I would use BEM (or a similar approach) to class names completely. On the other hand, if only the colors and fonts (including font-size) of things would have to change, then I would use BEM along with atomic css. To take a third case, if in fact there is no themeing for a project (which is frequently the case for me) then I will create BEM class names for semantic reasons, but really the majority of the work will be done via atomic css.

While these are the approaches I’d take, I think the last one would probably have the lowest cost for maintenance on my particular team.

What do you think? What context differences may change some of the answers you’d give to this stuff?

Yup. Keep them separate. Atomic css in HTML across multiple (>2) breakpoints. Good luck with that. Absolute nightmare. How about SASS with includemedia? You can also use includemediaexport to get access to your breakpoints in JS.

I wonder if there are only two styles on CSS: doing the work of designing a grammar and language for your product’s (style) needs specifically, indifferent to whether this way of speaking can be translated to other products, or, trying to solve more than one persons/company’s needs.

For me atomic css sounds like (and in practice has been) an approach I can indifferently apply to any project I work on (be it a website or an app) that uses atomic css (the css is portable).

Something like BEM – as a design system – also is applicable to every project. However, whenever I move to a new project I always end up writing a new set of bem classes (the specific css isn’t portable).

In practice I find that both of these approaches are useful to use at once (some portable css and some non-portable)

If I’m building one-off application that only has to make sense to my local team, and we have been careful in our branding, product design and visual style, and have a clear idea of all the visual terms that will need to be presented (and hence styled), how they are grouped and relate to each other can be planned using a grammar that only we need to understand, and atomic CSS will likely make sense there, benefiting from the simplicity and lean-ness of avoiding the redundancies/generalizations of “for everyone ever designing anything” style strategy.

atomic css bloats your html, and it is almost like writing inline styles…

<div class="box flex box-shadow bt10 lt35 pad border-none...>

I rest my case.

Web component’s approach is much more readable – even if you don’t use web-components. custom tags (without upgrading to custom-elements) are displayed as by browser and they are supported back to even IE8.

example:

<div.....>

css:

side-menu {
display: flex;
float: left;
width: 15em;
....
}

Another approach is to use [role=”side-menu”].

This way chaining roles makes your css both readable and your HTML ready for automation tests even when you move things around.

I cut my teeth in the days of bloated tag soup HTML. I was very resistant to Sullivans’s proposals for OOCSS because of the clutter being reintroduced into my markup. I later came to the realization that markup does remain pristine forever. Redesigns will often require one to change and adjust the markup so relented to the idea that having numerous classes to apply styles was not such a bad thing.

Now I look at what some of our React devs are doing just to create a box using Tachyons and I can’t help but protest once again. How is it better to style a box with 16 class names setting things like margins, paddings, dimensions, positioning, border, border radius, box shadow etc. better than using one class name that sets the same styles?

Perhaps our devs are taking things to extremes but I foresee a lot of pain in the not-too-distant future when a new redesign comes along and those hundreds of components will need to be modified to accommodate the new design.

It’s kind of funny, I see the argument made for Atomic CSS because “I noticed I was writing ‘margin’ a ton in my CSS so making it one class just makes sense!” – and then they end up with the same amount of ‘m-0’ classes in their HTML.

I love reading everyone’s thoughts and opinions on Atomic CSS, when to use it or when not to use it, ect., and I’m not even sure myself if I could use it on a project fully from start to finish, I’ll have to try it and see how it goes. I do see advantages of quickly editing one element, but then global changes could be a nightmare unless you’ve set it up component based, would would make the most sense.

I want more articles and discussions on it, from people who use it on the Yahoo team, and why it was done for such a large site and team.

– and then they end up with the same amount of ‘m-0’ classes in their HTML.

And this is exactly where I think Atomic style classes are used improperly. I don’t think they have any value in styling content this way.

I think atomic classes are great for utilities, not design. This would solve the issues of massive style changes affecting random parts of the site. But consider an atomic class to create simple columns, opacity hover effect, icon systems, etc…

For people that want to learn or improve their CSS, and how to optimise maintainability, these are not good examples at all. I don’t know how Atomic CSS can consider itself beginner friendly, because I would not use that horrendous result in my training materials.

If HTML has class names that are essentially shortcuts for inline styles, then it’s wrong, and I don’t care how popular it is becoming.

Atomic CSS also calls itself lean, because it only includes the styles that are actually used in the project. I cannot write class="js-stream-ad-noview js-stream-ad Wow(bw) Pos(r) Mx(a) Mt(-1px) Bxz(bb) Bgc(#fff)" and think ‘yes, now I’m getting somewhere, this is so much leaner!’.

Looking at the ‘successful’ implementations in the wild. It’s not lean, it’s huge, and so is the HTML that uses it, saying Atomic CSS has ‘no bloat’ is an outright lie! I’ve never seen HTML or CSS so ridiculously bloated in my 15 years of full time web development.

Another thing I worry about, with all this promotion of architectures and frameworks based on their popularity…

I did a lot of recruiting earlier this year, for my own development centre and also for others. We were looking for highly-skilled front end developers, capable of helping resource any project in a multinational consultancy firm regardless of framework or architecture, so core skills in HTML, CSS and JavaScript were highly sought after for this recruitment drive, fluency in all three was essential.

Front end developers with a preference for CSS architectures interviewed terribly, (even worse, a preference for application frameworks like Angular or React) they had insufficient depth of knowledge even in the fundamentals, and therefore lacked the versatility we needed to be able to place them at our client locations.

You would think experience of a ‘popular’ framework, library, or architecture would look good on your CV, but after a few months we discovered the opposite was true. For such candidates, we could predict the knowledge gaps, and save ourselves time in the technical interview by asking those questions first.

The HTML will make or break your site. Keep it simple, use the appropriate elements designed for the task. Congratulate yourself on avoiding the majority of accessibility issues.

Does your site still function without the JavaScript? How does it look without the CSS? If either of these experiences are impossible, then you have designed your website to please the wrong person; yourself.

Back to HTML, the most important thing. Do you ever validate it? Is validation part of your development life-cycle? Why not? The W3C validator can be downloaded as an executable JAR, it’s easier than it has ever been.

Let’s assume you want to reliably produce valid HTML. How can you generate valid HTML so reliably even in large volumes? Well, you sure shouldn’t be hand coding it. I don’t.

At the moment, I’m using markdown for most website copy, and for more complicated components, like forms, I have components that procedurally produce the HTML in a consistent way. The whole development process is intentionally constrained to produce uniform HTML, I deliberately have minimal control.

The power of CSS is that you can apply styles to your web pages consistently, you can have multiple visual designs without making a single modification to the HTML. Redesigns and rebrands are trivial. Therefore, Atomic CSS has no place (and neither does BEM, or any other form of classitis).

CSS has great power, yet so many use it with gleeful abandon of responsibility.

Atomic CSS is not simple. It makes well-crafted HTML impossible. Keep it simple.

I’m trying to think where I would definitely know for sure I wanted other areas of a website to be two-columns. Maybe definition lists, then I would want all definition lists to be two columns, given that consistency is probably desirable. Hmm.

I’m more likely to have a reusable way of displaying fancy listings, where each item has a border with a drop-shadow or something fashionable, and I would like similar styling for lists of products, users, appointments, whatever. I would usually do something like:

<ul class="product listing">...</ul>

The reusable listing styling would be applied using the .listing selector, and any styles specific to product listings, would be applied using the .products selector.

Sure, class="grid" looks tempting for reuse but it’s actually an anti-pattern, because you’re embedding the currently-desired visual design into your HTML. Which would be really bad, because there tends to be no such thing as a permanent or final visual design.

I’ve been on a few sizeable re-branding projects for companies that changed ownership, merged with other companies, or were just migrating old systems to their new, modern look and feel. These customers needed wholesale look & feel changes to their websites and web applications, with minimal risk to breaking actual functionality.

The systems with the most semantic markup were the easiest. I remember one particular project where the HTML was coupled to the visual design we considered it impossible to achieve the redesign without overhaul of the actual application, at an unacceptable risk and expense.

Suppose some of the situations where you used class="grid" are no longer required to be grids? How are you going to identify all the instances of class="grid" that are to be changed and those that are to remain unaffected, if the HTML hasn’t been semantically written?

You could be lucky and only have 20 instances of class="grid" in your entire code base. That’s probably a manageable amount of analysis to carry out. But what if there are 200, 2,000 or 20,000?

Vanderson, your particular grid example is only 5 lines of code. I’d rather use multiple selectors in only 1 place in the css or even duplicate those sames lines in multiple places (via mixins) over using .grid in several places in the html. But that is only my preference based on the 70+ projects I’ve worked on over the last dozen years because most of those projects needed to be done fast and the fastest solution for us was to re-use pre-existing html and just restyle it.

I’m not saying my way of working is better than any other.

That is the problem with all the articles like this. Somone had a super hard job and used a technique that worked well for that case and then proclaims everyone should do everything their way on ever project. Ignores the fact that everyone’s reality is different. What is best for Yahoo might not be what is best for Facebook. What is best for Google might not be what is best for Twitter. What is best for Twitter.com (does not use Bootstrap) might not be what is best for Twitter’s internal corporate applications (does use Bootstrap).

What I wish articles like these would do is say “If your situation is this and this and this, boy have I got a great suggestion for you…”

When creating a form for your web page, you should only write a simple, bare minimum specification of that form, in my opinion. How that specification is converted into HTML is a development issue, because it should be automatic, not manual.

There really is no opportunity to introduce dozens of custom classes to the HTML generated from that. But that’s how I like things, every form within a website intentionally has consistent layout and style, since we regard consistency to be a good thing, and so do our users.

If there is a good case to have a form on the site that looks different from the others, then the element containing the form would be a good thing to use for the distinction, in the CSS rules. For example:

So, I solved the problem with a descendant selector, as an example, but I think that’s quite alright, because I’m using CSS! – Unlike CSS ‘architectures’ (or as I like to refer to them, CSS avoidance schemes).

I completely agree that you should not put “visual design” in your html. It’s a class name, not inline styles. You are arguing against inline styles here. (ie, React)

I’m trying to think where I would definitely know for sure I wanted other areas of a website to be two-columns.

I will repeat old, old wisdom, use the right tool for the job. Just because you can’t see a good use for it doesn’t mean there isn’t one.

Sure, class=”grid” looks tempting for reuse but it’s actually an anti-pattern, because you’re embedding the currently-desired visual design into your HTML. Which would be really bad, because there tends to be no such thing as a permanent or final visual design.

I’ve been doing this for many years now, and I have seen multiple times what was once the written in stone rule “never do this”, get’s repealed later. So I stopped listening to dogma like this and I use the right tool for the job now.

When was the last time you saw a menu in a Windows or MacOS app have to completely alter their layout of drop down menus? See, there is a place for a class called “menu”, because there just are universal things that can gain value from this long term design processes.

Also, I didn’t name the class “grid”, I just did that for simplicity of example, perhaps it triggered a holy naming war here.

Would it matter if I called it “2-colum-thingmabob”? Consider the CSS zen garden, not every project has the budget or the long term goal of perfect theming, nor is that even in the specs.

Sometimes in seems that discussions like this devolve into how the perfect CSS should be written, and any practical methods are shouted down because of potentially blind zealotry or just your “personal experience” says it’s bad.

Inline styles were “evil” not long ago, and this site, a bastion of knowledge on CSS on the internet seems to fully support it now.

So, I say, ignore the dogma, zealots and ideology, and use the right tool for the job.

Suppose some of the situations where you used class=”grid” are no longer required to be grids? How are you going to identify all the instances of class=”grid” that are to be changed and those that are to remain unaffected, if the HTML hasn’t been semantically written?

Find and replace. It’s never been a problem. I’ve worked on multiple hundreds of thousands of lines of code. Hundreds of websites sharing libraries. Data with content in it. It’s just not that big of a deal.

You could be lucky and only have 20 instances of class=”grid” in your entire code base. That’s probably a manageable amount of analysis to carry out. But what if there are 200, 2,000 or 20,000?

If there’s a budget, it get’s changed no matter what. If not, it gets lived with. Easy peasy.

Also, years ago I learned a lesson from a guy that owned a company that made software for military satellites, massive projects, and he said every so many years, they just had to scrap a lot of their code and rebuild things.

You can only tweak, repair and manage a system for so long before having to start over. If you’ve ever worked on a big enough project for long enough, you will see that no strategy is perfect. Everything needs to be redone.

It’s never simple to embed your visual design into your HTML.

Sure it is. It all depends on the specs for the project. Surely you aren’t claiming that .grid is a horrible class name for a one page website for my brother’s dog? That’s absurd, who gives a whip what class name is used there? So your critiques must be classified as only relevant either to your experiences, your work style, or projects with the types of clients you work with, etc…

Being absolute about a naming convention (which is all that Atomic CSS is) leads to a form of self imposed blindness to the right tool for the right job.

I would defer to your judgement whether or not it would work for you in your projects. But it doesn’t mean it’s not the absolute best and perfect solution for others.

I’m talking about the value of well crafted HTML and how that’s incompatible with modern ‘CSS avoidance schemes’. I consider writing inappropriate HTML impractical, and I have outlined the main reasons why.

If you think in some cases, the cost of impractical HTML is bearable, great! If you think that such schemes are actually practical and preferable, then we will never agree. If they’re the right tool, somebody somewhere is doing the wrong job.

I would rather USE (not design or develop) a site with well crafted HTML, for example, where a drop down field was actually a SELECT element and not some half-baked JavaScript-dependant widget.

Why does it matter? Because I’m so fed up with using websites that are broken because they didn’t keep things simple. It happens far too often, usually when I’m registering, booking or paying for something, i.e. actually trying to get something done in real life.

Incidentally, Internet Explorer changed their drop downs in IE10, nothing drastic, but enough for people to notice… for the benefit of touch users, apparently. So it happens, and if you stick to appropriate HTML, your site will automatically pick up such enhancements.

I was arguing against everything visual in the HTML, not only inline styles, class names like “grid” or “2-column-whatever” are equally inappropriate. “menu” is fine, that states what the structure is, without saying anything about how it will be visually represented, so I’m afraid I have no objection there, but it seemed like you thought I would?

I’m often working on projects where it’s unavoidable to use some form of layout markup, I’d rather be embarrassed and apologetic about it, than to convince myself it’s perfect and the best thing since sliced bread, otherwise you will never find a better way.

I don’t care what people do on their pet projects, indeed they can do what they like. But I do care what people evangelise on popular educational websites, whether promoting techniques that are responsible for poor user experience (e.g. inappropriate HTML), or may lead to code that’s difficult to maintain, long term.

No, you cannot simply search-replace class="grid" if some of them need changing and some do not. Each particular match requires independent analysis to determine if it needs to be changed. It’s an unnecessary cognitive drain, the larger the set, the less manageable it becomes.

Having the budget for fixing the technical debt which is no fault of the customer is where businesses fail, long term. If a customer doesn’t have the budget for their trivial design change, you will lose that customer.

All it takes is a competitor to explain how difficult it is to maintain things built that way, and before you know it, you have a reputation for being too expensive, not building things properly (cutting corners), or too slow to react to simple customer requests. And your competitor will be the one doing the scrapping and rebuilding, not you.

Yes, of course my critiques are based on my own experience. As it happens, I’m currently working on such a rewrite project we have taken from a competitor, so it’s no wonder, really!

It seems like for the past 6 years the conversation around doing css right has been dominated by a small elite group of people whose use case tends to be a single design language (that is constantly evolving) spread over less than a dozen very long lived products with large teams and large budgets.

I clearly see how certain techniques benefit the likes of Twitter, Facebook, and Yahoo.

But where are the css experts from small agencies where every week is a brand new project (or a brand new skin over an existing product)? I need to hear about what is working well in their workflow because they do what I do, what most of the world does, and most of us will never work at the likes of Twitter or Yahoo.

I’m talking about the value of well crafted HTML and how that’s incompatible with modern ‘CSS avoidance schemes’. I consider writing inappropriate HTML impractical, and I have outlined the main reasons why.

Well crafted html is not incompatible with anything.

There is no such thing as inappropriate HTML. It’s just a markup language.

If your experience compels you to write things in a certain way, by all means do so. But to declare your beliefs as the one true way for all the billions of html documents ever created or ever will be created is an absurdity.

I applaud your desire to be a great craftsman. But not everyone can make masterpieces, some of us paint houses. And doing the less glamorous and perfect work is an honorable living.

I’m talking about the value of well crafted HTML and how that’s incompatible with modern ‘CSS avoidance schemes’. I consider writing inappropriate HTML impractical, and I have outlined the main reasons why.

Classes have nothing to do with HTML per se. Those are strings inside an attribute. Regardless of what one chooses to include in there it will not create “inappropriate HTML”.

If you think in some cases, the cost of impractical HTML is bearable, great! If you think that such schemes are actually practical and preferable, then we will never agree. If they’re the right tool, somebody somewhere is doing the wrong job.

What is impractical? If it is deemed preferable by authors then it must be “more practical” – at least to them (please see my point below about the user).

Why does it matter? Because I’m so fed up with using websites that are broken because they didn’t keep things simple. It happens far too often, usually when I’m registering, booking or paying for something, i.e. actually trying to get something done in real life.

Classes don’t create broken experiences, styles do.

I was arguing against everything visual in the HTML, not only inline styles, class names like “grid” or “2-column-whatever” are equally inappropriate. “menu” is fine, that states what the structure is, without saying anything about how it will be visually represented, so I’m afraid I have no objection there, but it seemed like you thought I would?

“menu” is fine but “grid” is not? Why that? Could you point me to some specs/recommendations/articles that prove it is best practice (not common practice) to use semantic classes?

I’m often working on projects where it’s unavoidable to use some form of layout markup, I’d rather be embarrassed and apologetic about it, than to convince myself it’s perfect and the best thing since sliced bread, otherwise you will never find a better way.

When it comes to CSS there is no one-size-fit-all, no best method. It all depends on the project (its requirements, the teams involved, etc.).

I don’t care what people do on their pet projects, indeed they can do what they like. But I do care what people evangelise on popular educational websites, whether promoting techniques that are responsible for poor user experience (e.g. inappropriate HTML) or may lead to code that’s difficult to maintain, long term

Poor user experience? How so? Once again, classes are meaningless for the user; all that counts are the styles attached to them.

No, you cannot simply search-replace class=”grid” if some of them need changing and some do not. Each particular match requires independent analysis to determine if it needs to be changed. It’s an unnecessary cognitive drain, the larger the set, the less manageable it becomes.

Nowadays, with components, changing styles does not mean changing many classes across a code base; and that’s even more true with dynamic Atomic CSS libraries (à la ACSS) or with custom properties.

Incompatibility is bidirectional, but if it was directional, then no, well crafted HTML is compatible with everything, that’s my whole point.

Absolutely there is such thing as inappropriate HTML! Only today I overheard a developer ask about styling a button to look like a link, the CSS he was given provided classes to do that but he was struggling with the alignment.

This is not OK. A button styled to look like a link will never have the same context menu as a real link. You can’t right-click these pretend links and ‘Open link in a new window’ or ‘Copy link address’. Expected behaviour is missing.

Opera has different keyboard shortcuts to navigate links than buttons, pretend links are unexpectedly skipped.

Screen readers have the ability to generate a list of links found on a page, for quick navigation, pretend links are absent.

The CSS provided a way to style buttons to look like links, this is a good example of having the right tool for the wrong job, and why ‘visual’ class names are just as inappropriate as inline styles, and since class names in the HTML and only referred to by CSS, it’s the HTML that’s inappropriate.

CSS has the over-abused convenience to select elements based on class names. The misconception that class names are synonymous with style is the root cause of the problem. Since selection by ID has long been out of favour, classes are the new ID, in specificity terms, except classes are more versatile than IDs.

Because of this, we find ourselves arriving at unmanageable HTML/CSS in more varied ways. The ‘innovative’ solutions seem to have overlooked the fact that we are victims of our overuse of class selectors, so they fail to actually solve any problem, they only shift it.

Nobody should think it absurd that I recommend using HTML in a way that doesn’t hinder user experience in unanticipated ways. I strongly feel it’s the developers doing the ‘less glamorous’ work that have the most to benefit from ignoring whatever is fashionable or popular, keep things simple and stick to what works.

Classes have nothing to do with HTML per se. Those are strings inside an attribute. Regardless of what one chooses to include in there it will not create “inappropriate HTML”.

…then you don’t understand the word ‘class’. I’ve already covered what classes are for: The class attribute is for author classification of HTML elements where the semantics of the elements or attributes alone is not sufficient. Again: https://css-tricks.com/semantic-class-names/

If the HTML needs revisiting because you want it to look different, then, in (not only) my opinion, it’s inappropriate because the author-classification of the HTML elements shouldn’t change just because the look and feel does.

Classes don’t create broken experiences, styles do.

I was not talking about classes or styles, but inappropriate HTML in all its forms. It’s the needless complexity that creates broken experiences.

“menu” is fine but “grid” is not? Why that? Could you point me to some specs/recommendations/articles that prove it is best practice (not common practice) to use semantic classes?

Menu does not imply layout, it will still be the menu if it is pop-up, pull-out, horizontal, vertical, anything, it’s a menu.

Grid implies layout. I bet in a good responsive layout it would at some threshold cease to be a grid. Grid is not what the thing is, so it’s not the class of the element. So why is it a grid? Let’s suppose it’s because it’s a calendar or gallery, then the class of the element would be ‘calendar’ or ‘gallery’, not ‘grid’.

If you have to modify your HTML to change its style, you do not have good separation of concerns.

When it comes to CSS there is no one-size-fit-all, no best method. It all depends on the project (its requirements, the teams involved, etc.).

Indeed, yet I’ve worked on many different web teams for decades, and web developers that work equally confidently with both HTML and CSS are surprisingly rare, and another reason why the separation of concerns is important.

Poor user experience? How so? Once again, classes are meaningless for the user; all that counts are the styles attached to them.

Web application developers are users of the CSS, they are the true consumers of the CSS architecture. They need to produce HTML that is compatible with the CSS. In this sense, if you think classes are allowed to be meaningless, that spells disaster.

It is not appropriate for a CSS developer to offload the difficulty of their job to the HTML developers and burden them with unnecessary complexity. Especially when HTML developers tend to outnumber CSS developers on a project. It’s not productive to make the wrong people do the hard work.

The team structure I’m currently dealing with consists of several dozen projects with several hundreds of web application developers, distributed in offices across the country. I am just one of those web application developers.

There is small, virtual team of about 4 designer/developers that are responsible for governing the front end coding standard across all teams, they maintain the CSS, and ultimately, therefore, determine how the HTML needs to be written. I have little involvement with this team, other than the fact that I have to use their output.

So my arguments are in the context of the poor HTML author that would be inflicted with bad naming conventions, expected to produce meaningless meta-content just to get their web application looking acceptable. The CSS developers would have done a neglectful job and failed to understand their true audience.

In traditional web development, the CSS developer needs to own the burden of making the HTML author’s job easy. Even if they’re the same person; anything that works at scale should still work for small cases.

Meaningful (or semantic) class names are more easy to understand, code review, search, remember, communicate, predict, document, everything. If you think this is only the blinkered opinion of a lunatic HTML developer then I despair for the future of our kind.

Nowadays, with components, changing styles does not mean changing many classes across a code base; and that’s even more true with dynamic Atomic CSS libraries (à la ACSS) or with custom properties.

This is absurd. Changing styles should not mean changing ANY classes across a code base at all, this has been the case for quite some time, not just nowadays, not even with components. I’m not saying it’s avoidable, but the risk of it happening should always be considered and avoided if forseen.

It’s less true with Atomic CSS, you cannot change the look and feel of any element without changing its class.

If you have to modify your HTML to change its style, you do not have good separation of concerns.

Hypothetical Situation: Change a gallery from a row display to a grid display.Atomic CSS method: Change or add class to “grid” of a parent DIV on the gallery on the page.Your suggestion: Change the styles for the class “gallery”.

What happens when you have 10 galleries on a site and they all have to look different? I deal with this regularly. Atomic CSS to the rescue. Easy, simple, 1 class name change and done.

Yet, you suggest we don’t touch the HTML to keep it pure? Maybe I am missing something. Sometimes, and I am getting close to saying most times, a site is small enough that there simply are no issues with overlapping concerns.

It is not appropriate for a CSS developer to offload the difficulty of their job to the HTML developers and burden them with unnecessary complexity.
…
The team structure I’m currently dealing with consists of several dozen projects with several hundreds of web application developers, distributed in offices across the country.
…
Changing styles should not mean changing ANY classes across a code base at all

It sounds pretty clear you work on big multi-person teams with large sites on large code bases. Where my group works on very small to medium size sites with 100 pages or less. With maybe 10 pages of html templates with few class names in them at all, the rest is content from the client or modules with mustache templates.

You are working on Porsches and Ferraris we are working on commuter cars. To declare that we are required to use the most advanced long term approach with the most costly method of building is simply wrong.

We can use a bolt instead of a rivet, we can weld where you would glue. We can use aluminium where you would use carbon fiber. Where you have a team of people with separations of duty for a project that spans months. Our site is due in a week, and we have 3 people to build it.

Now, tell me I need to hire a dedicated CSS and HTML dev, when there are people that can do both perfectly fine. It’s likely your business spends more money in meeting time then ours does building an entire site.

Sorry, you are just wrong to think your ideas are universally true. They may be great and perfect in your world. But Atomic CSS is the absolute best solution for many cases for us.

And even if the the class is “grid” and shows up as a single column on a phone, it’s still a grid. Just a grid with 1 column.

…then you don’t understand the word ‘class’. I’ve already covered what classes are for: The class attribute is for author classification of HTML elements where the semantics of the elements or attributes alone is not sufficient. Again: https://css-tricks.com/semantic-class-names/

Well, I had a real customer request once, on a personal side project (whole website is less than 10K), when users signed up from a partner site, they wanted the look and feel of the sign up process to match the partner’s brand. When they signed up from another partner, it had to match their brand instead. Today it now supports 12 different partners, each with matching branding – yet the HTML is not different at all.

Keeping things simple, having separate concerns, works at any scale, there is no project too small, you can’t have workflow issues from following best practice, because if you did, then it’s obviously not best practice.

You are working on Porsches and Ferraris we are working on commuter cars. To declare that we are required to use the most advanced long term approach with the most costly method of building is simply wrong.

I see it the other way round. We are working on the commuter cars, I mean, mass production of boilerplate services, division of labour by specialism. This is deskilling because it results in many developers with limited HTML skills and no CSS skills. The HTML patterns are dictated by the very few CSS developers. It’s very much a production line environment.

These economies of scale forbids costly methods of building, every large global outsourcing company is only interested in reducing time to production and increasing shareholder profits, the only measure is man hours. There’s no place for costly methods, it all has to be streamlined otherwise we miss deadlines, incur penalties, lose business to the ruthless competition.

Now, tell me I need to hire a dedicated CSS and HTML dev, when there are people that can do both perfectly fine.

I never said the CSS and HTML developer cannot be the same person.

Sorry, you are just wrong to think your ideas are universally true.

I also have side projects as a one man band and small teams, we organise hack days regularly for example, and the same ideas work equally well. I haven’t experienced anything that disproves their universality.

I’ve seen many frameworks and architectures marketed in the past, all starting from the premise of solving problems that usually only exist in bad implementations.

When there is anything good in a framework or architecture, it tends to get incorporated into a standard with native implementation soon after. I don’t see anything in Atomic CSS that is a likely candidate for standardisation, and I see no support for Atomic CSS among the people working on the relevant standards, but I have seen quite a lot of opposition.

Where you have a team of people with separations of duty for a project that spans months.

More like years, even decades, when you factor in support contracts and maintenance. This is why we cannot just ship something out the door and forget about it, and why the approach is important.

There will be people with a wide spectrum of abilities revisiting the code in such systems for the unforeseeable future. The income from maintenance and support is more profitable than initial production, if you use a flexible approach in the first place.

Our site is due in a week, and we have 3 people to build it.

If you’re in the business of build it, ship it, take the money and run, there’s no need to champion against best practice in public, just get on with that.

And even if the the class is “grid” and shows up as a single column on a phone, it’s still a grid. Just a grid with 1 column. Or are you saying there is no such thing as a 1 column grid?

A grid of any dimensions is still describing layout and giving no meaningful substance to the nature of the content within it.

@Thierry Koblentz

That article you link to is over 6 years old.

So? Does good advice lose value over time? Do we also need to stop believing Pythagorean Theorem? It’s ancient! There must be a better way by now! Oh please…

Either you didn’t read the article past its publication date, or you didn’t find anything else wrong with it.

I’d already read your article, as it happens, and I found no counter argument. I don’t know if you’ve noticed, but you have no evidence that semantic class names are harmful, a terrible idea, and to be avoided at all costs.

The part about restyling needs fixing, if you think restyling is limited to yesterday old style, today new style, then you missed the point. Restyling means it’s possible to support multiple styles simultaneously. The ‘nobody ever needs that’ argument doesn’t fly. Print Style Sheets?

You also assert that BEM is popular (it isn’t) and use that as proof! That’s the problem with those of us that are too immersed in our own industry, we are subjected to most of the marketing. Popularity is only proof of marketing. Are all number 1 songs timeless masterpieces? Unfortunately not, despite being the most popular song at the time.

As a HTML developer on the receiving end of a CSS designer that once decided to ‘try BEM’, as soon as he saw the HTML developers’ reaction to what was now expected of them, he realised what a bad idea it is to over-classify the HTML. Making life easy for the wrong person; himself.

CSS design is like designing an API. Whoever is authoring the HTML needs to use the CSS design’s ‘API’. Unfortunately it seems a lot of CSS developers also author the companion HTML and are therefore oblivious to this distinction, and will never reap the benefits.

Why would you make such a terrible API to work with? Because CSS is painful? To keep the CSS lean? To simplify specificity? These are not responsibilities of the poor HTML author in the same way as you wouldn’t design such a poor API.

So? Does good advice lose value over time? Do we also need to stop believing Pythagorean Theorem? It’s ancient! There must be a better way by now! Oh please…

An advice—no matter how good it is—is not the same as a theorem, isn’t?

Either you didn’t read the article past its publication date, or you didn’t find anything else wrong with it.

You may want to read about a fallacy called “Appeal to Antiquity / Tradition”.

Anyways, I’ll stop here as I believe you think I’m arguing to convince you that Atomic CSS is great and that the SoC principle is harmful when in fact I’m not. Honestly, I really do not care what you think, what I care about is that people who read these comments understand that most of your arguments are baseless and that they should not rely on any of that to make their own opinion.

5 years ago we started with a static library (like what Tachyons does today). It dramatically reduced bloat and sped up development (2 big wins) but devs were frustrated by the limitation of what was available to them (note that that approach is great to enforce a styles guide—when there is one). To address this concern we came up with ACSS (https://acss.io) which is a dynamic library that allows authors to use pretty much any style they want, and that includes the use of media queries, combinators, pseudo-classes, etc.

Bonus #1: the tool writes/deletes CSS on the fly—which produces even less bloat than a “static” library. The Yahoo! sites that completely switched to Atomizer use less than half of the CSS they use to rely on.

Lee Kowalkowski said already everything important. I have no idea why the approach of separated concerns is so unpopular. It works completely fine on small and big sites.
If you want to work with utility classes, than use a preprocesser, like I mentioned before.

Please stop bloating the web with presentational markup, libraries and frameworks, just because you are used to it. It does not make your work faster.

I would so much like all you „I-do-it-how-it-most-convenient-for-me“- guys to live in Germany, like I do, where you have to pay 60,- $ for 6 gbyte, when you use your cellphone.

Unless you don’t want to pay my telephone bill and share my slow loading web please stop this I do what’s best for me developing behavior.

Lee Kowalkowski said already everything important. I have no idea why the approach of separated concerns is so unpopular. It works completely fine on small and big sites.

The issue is not that Separation of Concern (SoC) is unpopular, it is the fact that some people cannot accept the idea that many devs out there are doing well without following the SoC to the “T”. People in favor of Atomic CSS do not say everybody should switch to it, they only share their experience saying it works well for them. To the contrary, people who “worship” the SoC can’t stop criticising Atomic CSS, without even really knowing what it is about or what it can do. For example, Lee Kowalkowski says:

Well, I had a real customer request once, on a personal side project (whole website is less than 10K), when users signed up from a partner site, they wanted the look and feel of the sign up process to match the partner’s brand. When they signed up from another partner, it had to match their brand instead. Today it now supports 12 different partners, each with matching branding – yet the HTML is not different at all.

I guess he never realized that Atomic CSS classes could be partner-color, partner-background-color, partner-fontSize, partner-whatever? Such approach solves the “challenge” Lee describes (not changing the HTML).
In any case, Atomic CSS proponents do not say using semantic classes is a sin; they also rely on the SoC principle whenever it makes more sense. The idea is to use the best tool for the job. I think it’s better to understand both approaches and make an educated choice rather than sticking to the SoC principle and calling everything else bullshit.

Please stop bloating the web with presentational markup, libraries and frameworks, just because you are used to it. It does not make your work faster.

Bloating the web (markup?)? Do you have data about this? Because I do, and it’s simply not true (depending on the library). Not only that but you have higher string repetition following a Atomic CSS approach than a SoC approach (since the former promotes a lot of redundancy) which leads to a much better compression ratio.

Most importantly, since there is less CSS to download, web sites load faster which translates into a better user experience.

I would so much like all you „I-do-it-how-it-most-convenient-for-me“- guys to live in Germany, like I do, where you have to pay 60,- $ for 6 gbyte, when you use your cellphone. Unless you don’t want to pay my telephone bill and share my slow loading web please stop this I do what’s best for me developing behavior.

This argument is baseless. Yahoo! switched to Atomic CSS and save 55% of its CSS. I don’t know how people can ignore the benefits of Atomic CSS with bandwidth gains of this magnitude.

Anyways, if you like the SoC principle and it’s the best way to go for you then that’s great, use that and only that, but please don’t tell devs who use Atomic CSS they don’t know what they are doing, because all it shows is how little you know about the methodology.

I just don’t understand, how to answer here, so sorry for any inconvenience, @Thierry Koblentz, I just copy your answer to my post in here:

Lee Kowalkowski says:

Well, I had a real customer request once, on a personal side project (whole website is less than 10K), when users signed up from a partner site, they wanted the look and feel of the sign up process to match the partner’s brand. […] 12 different partners, each with matching branding – yet the HTML is not different at all.

You are aware, that he was writing this, because in the post before @Vanderson said, that theming is only efficient, when using presentational markup. He just answered, that presentational markup is not necessary for this. But I think Lee can clear this up by himself, he doesn’t need me for this.

I guess he never realized that Atomic CSS classes could be partner-color, partner-background-color, partner-fontSize, partner-whatever? Such approach solves the “challenge” Lee describes (not changing the HTML).

That is exactly, what I meant, when I asked to stop bloating the web.

Especially when working with micro data you actually have more hooks for your css than ever necessary.

In any case, Atomic CSS proponents do not say using semantic classes is a sin;

So go ahead: use them! And we can stop the discussion right here ;-)

they also rely on the SoC principle whenever it makes more sense.

As I and obviously Lee understand HTML5, SoC always makes sense. More than this. SoC gives sense or let’s say meaning to plain text documents. Again in other words (taken from the wcag): Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

The idea is to use the best tool for the job.

From which point of view? Accessibility? User experience? Or developer experience?

Most importantly, since there is less CSS to download, web sites load faster which translates into a better user experience.

You really want to tell me, that minimized, compressed, cachable CSS files are a bigger problem, than dozens of partner-xxx classes added to meaningful HTML5 documents?

Anyways, if you like the SoC principle and it’s the best way to go for you then that’s great, use that and only that, but please don’t tell devs who use Atomic CSS they don’t know what they are doing, because all it shows is how little you know about the methodology.

I’m afraid, I won’t stop telling that it’s a developers responsibility to deliver HTML5 documents, that fit the needs of every user. I know, that it is possible to make accessible websites with bootstrap (to name a framework I had to use before). But I rarely see accessible bootstrap sites. Earlier I just suspected, that developers that use systems like atomic css just want to make their work easier. Today I know it. At least that’s true for the vast majority…

And I already said it twice in this thread: go ahead using your beloved naming conventions. But use a preprocessor to get the best of both worlds. See, I’m not telling you to stop doing it. I just ask you to do it right…

some people cannot accept the idea that many devs out there are doing well without following the SoC to the “T”

It doesn’t matter to me how people do their development if they just want to get a job done, they could use Wix for all I care.

The fact that sub-standard approaches exist and people find they can make them work is not the issue, the issue is that such approaches have serious problems as already explained, fail to deliver on their promises as I will explain later, and yet they still get airtime on sites like CSS-Tricks, which people rely on to better their knowledge and skills, and trust such resources are a reliable source of authority. Evidently, that bothers me a lot.

That hardly solves it. Tomorrow, a new partner brand may require some new properties like a border, and I would need to change the HTML. Unless I add a partner- class for every CSS property in existence, just in case, so no thanks.

Bloating the web (markup?)? Do you have data about this? Because I do, and it’s simply not true

Is that how HTML bloat is measured? On the average class attribute length? I think that’s a little too conveniently biased. Perhaps a different view on the HTML bloat a CSS convention causes is the total number of characters in all class attributes as a percentage of the total number of characters in all opening tags. I think this is more indicative of HTML authoring effort. I wrote a very crude script to measure this: https://jsfiddle.net/bavfqk6d/9/embedded/result/

Those percentage are the amount of characters the HTML author is spending on class attribute values, when writing any HTML opening tag. I.e. the amount of bloat in the HTML as a result of the approach to CSS.

[…] Most importantly, since there is less CSS to download, web sites load faster which translates into a better user experience.

If you’re measuring website load speed on the thing that gets downloaded on the users very first visit only, you have it backwards. The CSS is cached by the browser, but now every HTML page is bigger, the rest of the experience is slower.

This argument is baseless. Yahoo! switched to Atomic CSS and save 55% of its CSS. I don’t know how people can ignore the benefits of Atomic CSS with bandwidth gains of this magnitude.

CSS bandwidth gains are negated if you make every HTML document consume more bandwidth as a result. When Yahoo’s users wade through their emails or whatever most Yahoo users do, that traffic is additional HTML and ideally zero additional CSS.

So, use Atomic CSS for worse user experience?

Honestly, I really do not care what you think, what I care about is that people who read these comments understand that most of your arguments are baseless and that they should not rely on any of that to make their own opinion.

That’s rather rude actually. People should consider everything that experienced people think. None of my objections are baseless, otherwise you wouldn’t have skipped them and instead focused on irrelevancies such as the difference between a theorem and sound advice.

I said I’d not reply to your future comments but I cannot resist pointing out how “inappropriate” your HTML is:

<label>Paste a HTML document: <textarea></textarea></label>

There is no actionable button, the event is attached to the label. So yes, that is inappropriate HTML because that creates a bad user experience (users don’t know what to do after pasting their code in the textarea). Most importantly it is not accessible to keyboard users.

Anyway—contrary to what you say and try to demonstrate with your script—the “bloat” related to classes is limited to characters inside class attributes. Everything else is irrelevant because not related to the method being discussed in this article.

Do you see the problem here? Your script suggests that the “Atomic CSS” method (.a, .b, .c, .d) creates twicest bloat than a “semantic” approach (.feature) even though in both cases the classattribute contains the exact same number of characters (including whitespace).
Yes, new data is better than old data, but only if the former is accurate.

PS:

Using a component approach it is as easy to add a “partner” class in your component as editing a styles sheet. Actually, the former will not invalidate the user cache as there is a good chance it won’t force you to publish a new CSS file, so there is that too.
TTFB (Time To First Byte) is critical. People may not visit your “other” pages if they don’t even wait for your landing page to load).
There is no such things are “reloading other pages” on Yahoo!, that’s not how things work.

It’s a fiddle, I already confessed it was crude. It was for me, I just thought I’d share my method.

There is no actionable button

A button is a good idea! I did already think that having one would be easier to use, but I was too late, because I had already shared it. Since JS Fiddle versions its URLs, there was nothing I could do, except contemplate how even more websites seem to make my life difficult!

the event is attached to the label.

It’s attached to the textarea. It would not work if it was attached to the label.

The textarea event would continue to work with or without a button. The button is good for usability, even if it literally does nothing. I have a nasty habit of only doing the bare minimum.

So yes, that is inappropriate HTML because that creates a bad user experience (users don’t know what to do after pasting their code in the textarea).

Good, at least we agree that inappropriate HTML is bad, happy to illustrate.

I may have published it before it was perfect, we pretend that’s acceptable these days. Fortunately for us there are no high-profile articles linking to it and singing its praise.

Most importantly it is not accessible to keyboard users.

I’m a keyboard user, and it works, just tab out of the textarea. I hope we’re going to discuss something that’s truthful soon, or relevant.

Anyway—contrary to what you say and try to demonstrate with your script—the “bloat” related to classes is limited to characters inside class attributes.

I think this is somewhat shortsighted. That’s not bloat, that’s something else, I don’t even know what that is.

Bloat is how much additional markup is there in total. Using CSS to its full potential, you can use classes sparingly in your HTML. CSS avoidance schemes unfortunately use classes liberally, this is bloat.

Regardless of whether either measurement is perfect (neither are, I admit), the trend in my results still showed that websites with over-engineered approaches to styling had a bigger proportion of class attribute values in the HTML markup.

Websites that use classes sparingly have less bloat than those that use them as if they’re going out of fashion (wishful thinking). It’s that simple.

My method for measuring bloat penalises liberal use of classes, irrespective of what other HTML is present. I thought that would be a better measure.

If you rewrite the same HTML to use a different approach to styling, the difference in measurement would show the difference in bloat better than averaging class attributes, which does not show anything meaningful.

Unfortunately I don’t have time to rewrite other people’s bad HTML, or ruin my own, so I just went for a good spread of websites until I got bored, frankly.

Your method ignores using classes liberally, so it does not measure bloat at all. In fact, I’m not sure what it proves. It certainly does not address the question of shifting bloat from CSS to the HTML in the FAQ.

Everything else is irrelevant because not related to the method being discussed in this article.

It’s being overlooked in the article, that’s the benefit of the comment section, where things that are overlooked can be discussed.

It’s one of the virtues of using sites like CSS-Tricks, there’s often more to learn from the comments, other points to consider, and maybe receive a balanced view.

TTFB (Time To First Byte) is critical.

Yes, that’s called latency, and not influenced by the approach to CSS at all. Nor was it being debated unless I’m mistaken.

There is no such things are “reloading other pages” on Yahoo!, that’s not how things work.

I can imagine there may exist other ways to get HTML half-full of class attributes into a web page without fetching it all from a server, but that sounds like a lot of effort just to fix something that probably wasn’t an issue in the first place.

Most web developers are not Yahoo developers or working on anything so needlessly complex. Even if it is possible to work around the side effects of bloated HTML, the technique would be out of reach of your average web developer.

However, your average web developers have a nasty habit of copying what they see, without appreciating whether or not it actually does what they want.

Utility classes are so popular, because it is easy to work with them without using this big grey mass between your ears.
I agree, that there is not the one and only perfect System. Of course sometimes it looks ridiculous, when People Show Code like this from ryanair. But if you want the facebook button to get back its border-radius, the laughing will stop.
In this Code I see, that there must be an border-radius as a generally design idea. And there are exceptions of this idea. I think the design concept could be not completeley thought through, if so many exceptions are needed. So the Problem is maybe not the CSS concept. With Things like this it is always difficult to deal with. And it will mess up any Code and its concept, if you get a lot of exceptions while already coding. Looking at the ryanair-code, I think a lot of the Things, from which you remove the border, could Need a HTML-class. All social media Buttons for example. So Things would get much easier. I is unlikely, that a designer wants to remove the border-radius from only one social media button, right? And it makes sense in meaningful way to Group These Buttons.
If you Need Utility classes I highly recommend to put them in your pre-processor for keeping the HTML clean. Like so:

For me it is the best way to literally Combine the best of both worlds: clean, meaningful HTML and readable, reusable CSS/SASS – as a matter of fact I do not Need preprocessors for anything else since we have css classes and grid and Flex..

Like every other “framework”, “library”, “utility” it will always be subjective. While a lot of sites/frameworks use this is because of the “rapid” ability to create a site. The other thing it does is make every site look pretty much the same.

Systems like Bootstrap and Tachyons are great for prototyping but I think for custom websites it’s not a great idea. The main reason is because most are very opinionated and force you to conform to their styles or overwrite them which can be a painstaking process leading to code bloat, specificity issues, etc.

For instance with component based you make a change in the stylesheet and it updates the component everywhere. If you’re a “beginner” or not using any sort of build system and you want to change an element that is in multiple places you’ll have to change the class in multiple places. Not maintainable IMHO for larger sites.

At the end of the day it’s about who can go to market first with the idea with the most cost-savings which is why these things exist. It’s all short term and not really any thought about long term solutions, which I get because web changes so much, but you can be on the line and go either way if you need to.

Because much CSS is autogenerated, along with “html pages”, I’m not sure readability (by humans) is really necessary. Losing the assumption that style declarations must be readable might help spur new thinking.

This comment thread is closed. If you have important information to share, please contact us.

Related

How do you stay up to date in this fast⁠-⁠moving industry?

A good start is to sign up for our weekly hand-written newsletter. We bring you the best articles and ideas from around the web, and what we think about them.

👋

CSS-Tricks* is created, written by, and maintained by Chris Coyier and a team of swell people. It is built on WordPress and powered up by Jetpack. It is made possible through sponsorships from products and services we like.