As Atomic CSS (also known as Functional CSS) has been gaining in popularity, some confusion has occurred about similar related terms. The goal of this article is to clarify this terminology.
There are other projects that use the term Atomic, including Atomic Web Design by Brad Frost. Atomic CSS is a completely separate concept from these.
Let’s start by defining Atomic CSS:
Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function.
There are different ways to write Atomic CSS (see variations below). One example would be this:
.bgr-blue {
background-color: #357edd;
}
The term “Atomic CSS” was coined by Thierry Koblenz in his foundational article “Challenging CSS Best Practices” in October 2013.
Some people started referring to this approach as “Functional CSS” some time later. Though there have been cases in the past where Functional CSS has been used to describe something else, today the terms Functional CSS and Atomic CSS are used interchangeably.
While Atomic CSS has been the title of an open source project which originated with Thierry’s original article, the term itself applies to the architectural philosophy, not any one particular variation (see below).
Variations of Atomic CSS
Static
Many people write Atomic CSS much like they have always written CSS. It is common to use a preprocessor to generate a library of classes with set variations that define a unit-based design system for spacing, color, typography, etc.
The advantage to this style is that because it is familiar, it has a lower barrier to entry, and is more easily understood by those who are not well-versed in CSS.
Programmatic
The Programmatic approach to Atomic CSS involves using a build tool to automatically generate styles based on what it finds in the HTML.
For example, given this:
<!-- Programmatic Atomic CSS Example -->
<div class="Bgc(#0280ae) C(#fff) P(20px)">Lorem ipsum</div>
The following CSS would be generated:
.Bgc\(#0280ae\) { background-color: #0280ae; }
.C\(#fff\) { color: #fff; }
.P\(20px\) { padding: 20px; }
This flavor of Atomic CSS uses the syntax of a function call with parameters. As demonstrated by the open source ACSS project, which uses Atomizer to programmatically generate styles, it is no longer necessary to write CSS whatsoever. Stylesheets that are generated during the build process are fully optimized with no unused styles of any sort.
Longhand/Shorthand
The longhand style favors more readable class names (see Expressive CSS and Solid), while shorthand favors brevity (see Tachyons and Basscss).
/* Shorthand Atomic CSS Examples */
.bg-blue { background-color: #357edd; }
.f1 { font-size: 3rem; }
.ma0 { margin: 0; }
/* Longhand Atomic CSS Examples */
.bgr-blue { background-color: #357edd; }
.background-blue { background-color: #357edd; }
.backgroundcolor-blue { background-color: #357edd; }
.text-h1 { font-size: 3rem; }
.text-3rem { font-size: 3rem; }
.text-huge { font-size: 3rem; }
.fontsize-1 { font-size: 3rem; }
.marg-0 { margin: 0; }
.margin-0 { margin: 0; }
/* Programmatic Shorthand */
Bgc(#357edd) { background-color: #357edd; }
/* Programmatic Longhand */
bgrBlue(#357edd) { background-color: #357edd; }
backgroundBlue(#357edd) { background-color: #357edd; }
backgroundColorBlue(#357edd) { background-color: #357edd; }
Related Terms
Utility Classes
Utility classes (also referred to as Helper Classes) are easily understood, single function classes that help with common styling patterns (e.g. .clearfix, .hidden).
Many CSS architectures rely on utility classes (e.g. grids, spacing, typography) but do not necessarily fully embrace the concept of Atomic CSS.
Immutable CSS
An aspect of Atomic/Functional CSS where utility classes are never to be modified, thus producing highly dependable results.
Immutability plays an essential role in the proper execution of Atomic CSS architecture. Without it, you risk this:
.black {color:navy;}
Atomic CSS is about shifting complexity away from stylesheets and into HTML. When design changes occur in a Atomic CSS project, it is best if you have well-structured HTML templates so that, for example, you can use an editing tool to quickly change Bgc(colorOne)
to Bgc(colorTwo)
wherever you may need to.
Breakpoint Prefixing
This technique is a way to allow utility classes to override styles at different breakpoints to make implementation of responsive web design simple and efficient.
/* Examples of breakpoint prefixing */
.grid-12 /* Full width by default */
.m-grid-6 /* 2 column at medium screen sizes */
.l-grid-4 /* 3 column for large screen sizes */
Getting Started
Below is a list of places you can go to begin, depending on which variation you prefer.
- For Atomic Aces: Atomic CSS Quick Start or What is Atomic CSS (video)
- For Library Likers: Intro to Tachyons (video)
- For Daring Designers: Cooking with Design Systems
- For Refactoring Rebels: Full re-write in 10 days with Tachyons and Functional CSS (case study)
- For Reactive Reactors: Tachyons and React and CXS
Additionally, here are some foundational articles that are worth reading:
“In The Wild”
Atomic CSS has gained in popularity particularly among those who use it for rapid prototyping and, on the other end of the spectrum, for large scale ongoing front end projects.
- Yahoo!
- Solid by Buzzfeed
- Shed by TED
- Marvel App Styleguide
- Tachyons Gallery
Thank you to Thierry Koblenz for his feedback on this article and hard work over the years!
No support for CSS Grid in Atomizer yet.
Thanks for nice article!
We’re quite fond of atomic CSS too, and since we moved to it, I never looked back.
Here is our take on subject: Ekzo, where atomic approach meets BEM methodology.
It’s worth to check Ekzo in context of Kotsu, since this starter kit better shows basics and usage approaches.
I must note that in my experience atomic CSS might be painful choice for large projects if website doesn’t use good templating language and doesn’t encapsulate everything into components. It might seem like very repetitive, with long, hard to understand class attributes scattered all over the place.
In component-based approach all this “CSS” logic always carried with component. So, if you need to change something, you just edit atomic classes in that component, and magic happens.
Not to parrot what others say on this topic, but how is this much different from inline styling?
The naming convention describes individual CSS properties, with no context to the situation it’s being used in. Classnames describing their values is asking for trouble when it comes to future maintenance (as you mention in the black:navy example). It sounds like design changes require a mass find/replace operation on the HTML side instead of the CSS side, unless I’m understanding this concept wrong?
Won’t this system also cause excessive front end strain in interactive scenarios where elements may be animated, styled based on state, or require specific responsive behaviour?
Unless I’m missing something, this feels like a big step backwards.
My favorite discussion of how this is different than inline styles can be found in a discussion on Tachyons, a popular Atomic CSS project:
https://github.com/tachyons-css/tachyons/issues/12
Inline CSS has extremely high specificity, doesn’t support @ rules, pseudo selectors, or pseudo elements. Atomic doe author somewhat similarly to Inline styling however.
Correct. You’ll find no semantic class names here (unless you’ve setup some helper classes).
It may seem counter-intuitive at first blush; but it’s actually quite the opposite. The
black: navy
example was an example of what NOT to do. Immutability is foundational to a working Atomic setup. Future maintenance is essentially nonexistent with Atomic on the CSS side of the fence. In the markup, you simply change which classes you need to make whatever you’re working on to look differently.As for the global replacement, this hasn’t been my experience at all… especially not when using Atomic inside of front-end frameworks like React where I just need to change the Atomic inside a single component. If you manage to get a high degree of reuse out of your BEM like classes, then this could definitely be an area of concern for you. But even when I was using BEM, I got very little reuse out of my semantic class names and found myself adding additional class names instead while refactoring for fear of breaking something, somewhere.
Nope, unless I’m misunderstanding you. How would Atomic be any different than using any other type of class based convention in these areas?
Ailwyn, I totally agree with you.
As an example of an area this method may trip up: using CSS animations to transition from a neutral state to a focused state. For the sake of example, how would you handle things like background colour changes, hover state colours, border/outline changes? Those simple tactile feedback states seem rather convoluted to add under atomic CSS.
If your application has visual modifiers to further promote the state of a part of the page (as a simple example: a delayed train may appear in orange), how can you easily add/subtract the large number of individual styles without majorly reworking the classes?
If design changes are pushed through class changes, and not CSS changes, what is to stop redundant CSS piling up over time?
Each transition/animation is it’s own atomic class, as are the individual properties. The convoluted piece isn’t solving the above issues in Atomic, it’s just settling on your naming convention. For example, let’s say we wanted to transition between two background colors and two text colors on focus. Here’s an example of how you could do it in plain ole Atomic CSS (no tooling). With the made up convention below, I use shorthand property identifier, value, and then a pseudo class letter identifier as my naming convention.
CSS
.BgcDarkGray { background-color: #111; }
.BgcWhiteF:focus { background-color: #fff; }
.CWhite { color: #fff; }
.CBlackF:focus { color: #000; }
.TrsAll { transition: all .115ms ease-in-out; }
HTML
<button class="BgcDarkGray BgcWhiteF CWhite CBlackF TrsAll">Click Me!</button>
The neat part about all of the libraries and tools around Atomic is that you don’t need to come up with your own naming convention if you don’t want too (you probably don’t). Authoring is honestly the most difficult part about Atomic, so I definitely recommend checking out some of the tools/libraries.
All pseudo classes, elements, @rules, etc. would be handled in the same manner as the example above. I could have an H suffix for “Hover” or I could use an
@MqMinW60em
suffix for apply this rule only when this rule is in a window that’s at least 60em’s wide. The resulting CSS for dark gray at min-width 60em would look like this:CSS
@media (min-width: 60em) {
.BgcDarkGray@MqMinW60em { background-color: #111; }
}
Again, not difficult to handle, just requires you to think through how you want to name everything.
The classes for every property you’ll use in your app will exist. It’s up to you to apply whichever ones are necessary for the state of your app at this time. Let’s say I need to show an error message on an API request failure. The neutral state HTML may look something like this (I’ll use Atomizer classes in this example):
HTML
<output class="D(n) Ta(C) Fz(1.25em) C(#111)"></output>
Then an error occurs, the message needs to display and show the text in red… so the HTML would become
HTML
<output class="Ta(C) Fz(1.25em) C(#f00)">There was a problem!!</output>
I’m only ever applying the classes I need to achieve the look I’m going for. I just remove/add classes as needed.
The fact that Atomic CSS classes are unique and immutable. They never change and they’re never redefined. Only the CSS properties you need should have Atomic classes. Atomic is the CSS convention antithesis to redundancy.
So how is this better than just using inline styles? A lot of these examples feel to me like they’d have a lot of the same brittleness that comes with re-defining all of your styles on every element, with the added overhead of having your styles in both your classnames and your CSS file.
Inline Styles don’t support @ rules, pseudo selectors, or pseudo elements. Further, they have extremely high specificity (which may or many not be what you want).
Think of the many benefits of Immutability and Functional Programming in your JavaScript. Now apply that thinking to your CSS. That’s what Atomic gives you in a nutshell.
If you’re dealing with a small project by yourself, there may not be much of a benefit. But as you scale (both in scope and team size), Atomic really starts to shine, especially with the tooling available for it. The resulting CSS will be smaller and you’ll save yourself completely from refactoring.
I have no horse in this race, other than just fascination in watching developer tooling and trying to understand it the best I can.
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.
Does that mean I’m going to start using it on every project and expect you to as well? Nah.
disclosure: one of the shed.css authors here.
You nailed exactly what prompted us to approach this method, the “append-only” CSS trope. Even in a “proper” BEM codebase, once an app or site gets to a certain size, things become challenging. After much discussion we opted to try a functional approach on TED.com. After 10 months, 9 product launches, and on-boarding 3 front-end devs, we’ve found that a functional approach to CSS fulfills its promises.
I think if you use it for a short time, you’ll fall in love so hard that you’ll be using it on every new project because it solves real problems at any scale.
Rephrasing https://twitter.com/j9t/status/851462393204940804, the issue with Atomic CSS is that it may just want to ignore maintainability, but it comes off as not understanding it.
I think it worth to add that as every tool, it should be used wisely and not excessive.
For instance, if you’re noticing pattern in chaining of small utility classes — encapsulate it into understandable pattern class, like Object (example).
Your specific component getting too much styling and should express difficult relations between inner items? Times to encapsulate it into Component class, otherwise your devs will get hard times understanding all relations and why exactly you used some specific utilities.
The last point is, in fact, quite important. Expressing relations between items is weak point of atomic CSS, and the one who uses it should always remember it.
Great run John!
I’ve been captivated by Atomic CSS since first playing around with Atomizer and currently use it in several projects at work. Initially we used Atomizer but we’ve since switched over to a tool I wrote called Pre-Style (which is a CSS-in-JS variant that lets you author inline and spits out atomic classes at build time).
The immutability has drastically cut down our refactor time and by using tools like Atomizer/Pre-Style it means that our stylesheets are only ever as big as we need them and never bigger.
Needless to say, Atomic CSS comes highly recommended by this dev!
Some of those class names make me sad. “.text-3rem” is collapsing functional and visual specs. What if that element needs to be 3.375rem? 2.975rem? USE. SEMANTIC. NAMES. If that’s a subhead, for example, call it .subhead or .text-subhead if that’s appropriate for the project.
Same for things like .bgrBlue. If the background for that element needs to change to a shade of green, you now have to not only update the color definition, you need to update your markup or live with the ridiculous situation where .bgrBlue is actually green.
This is what I worry about.
I probably align more closely with this way of thinking and working for most of my projects than I do to Atomic ideas, but I’m curious about and open to other approaches. Closemindedness and attacking other ideas with emotion and yelling is worse for the web than any class name.
I don’t think I attacked anyone here nor do I think I’m being close-minded so I’m not sure where that came from.
I don’t see why Atomic and semantic class names are necessarily at odds but forced into choosing one or the other I’ll opt for semantic all the time. Maybe it’s that I work solo or with, sometimes, one other dev so I don’t run into the issue of huge projects with lots of developers but I’d rather segment things by namespace and end up with ‘duplicates’ (i.e. .component1 .subhead and .component2 .subhead vs .subhead3rem).
It came from calling a class name “sad” and STATING. THINGS. WITH. ALL CAPS.
Yes! Scoping opinions to your experience is much more valuable. That’s where I’m at. I work alone and on small-ish teams. The web is a big place and we all face unique challenges.
What are the benefits of using semantic class names vs. functional ones?
They don’t help our apps run faster or benefit end-users in any way. They don’t improve accessibility or SEO. As far as I know, semantic class names are really just meta-data for developers so they know what to change in the corresponding CSS.
If that’s the case… then what’s really wrong with choosing a more functional, immutable approach to CSS, especially one that proves to be more efficient than it’s semantic counterparts?
You wouldn’t run into this scenario following the Atomic convention. Atomic classes are immutable. .bgrBlue would be blue and would always be blue; .bgrGreen would be green and would always be green. If you wanted to change the background color, you’d swap class names on the element itself in the markup. This immutability principle gives Atomic based tooling the ability to strip out any CSS that’s no longer used at build time, resulting in CSS that only has the atomic classes needed for your site.
So it’s the exact same as inline styling? What if you have 12 buttons on a page which are supposed to be accented? Instead of fixing a
button-accent
class you replace 12 occurrences ofbackground-blue
withbackground-green
?I guess I am missing something because this doesn’t seem very convenient.
If you’re curious about why some are choosing this methodology, I’d recommend these 2 articles:
Full re-write in 10 days with tachyons and functional CSS: A case study
https://hackernoon.com/full-re-write-with-tachyons-and-functional-css-a-case-study-part-1-635ccb5fb00b
Building and Shipping Functional CSS
https://medium.com/@cole_peters/building-and-shipping-functional-css-4f29b947bcb9
Or do
.bgrBlue .bgrAddYellow
to get green. :P Just kidding.Honestly, I agree with you totally. The idea of components and using atomic parts to avoid too much dependencies makes sense. The idea of using classes for single properties (unless they are something like
.hidden { display: none; }
) doesn’t really make much sense at all.Nor is it that much better than inline styling.
I understand (and actually use) a little bit of “color related” classes when working on mobile hybrid apps (PhoneGap) if the framework gives them. But these rarely go beyond a single
layout-red
class on the HTML element or something of that sort and changing that class to a different one of the same theme changes everything. That would be a situation where it could make sense.Hi Rick,
You may want to read this article: http://cssmojo.com/opinions_of_leaders_considered_harmful/
It discusses the importance of “SEMANTIC NAMES”…
yes, i too used this Atomic CSS for one of my client project https://www.scislides.com. let me share my opinion about it, its a great tool but hard to manage at the same time especially in large projects.This Atomic CSS helped me in for the use of handy things such as media queries, contextual styling and pseudo-classes though.
This is interesting as it’s exactly the opposite as I might have suspected. 1) Hard to manage on a large project. 2) Useful for things like Media Queries, which I think would be weirdly unintuitive to manage with just class names.
Looking through that site’s CSS (unless it’s been updated since you’ve worked on it) I think you’ve misunderstood a big part of how to implement atomic CSS.
I don’t have an opinion either way on which one is best but your opinion on how hard a tool it is to manage would be heavily coloured by you not implementing it correctly.
Your CSS is mostly module based with a small sprinkling of atomic.
I still wonder how you could implement this concept into WordPress. Breaking down the template into smaller components which could also include subcomponents sounds like pretty good, but I haven’t found a good example for that in WordPress yet.
First and foremost, thanks for the article.
I’ve got one question which goes unaddressed though—actually, it’s never addressed when talking CSS methodologies so this is no biggie.
How do you deal with accessibility? e.g.
-ms-high-contrast
,inverted-colors
orlight-level
(MQ Level 4, should they be implemented at some point)I’ve never found anyone willing to answer this question for some reason but I’d really like to get some feedback about this.
With Atomic all MQ’s are handled the same way.
In Atomizer, you define media queries in the
atomizer.config
file. So you could specify ainvc
(or whatever you want) media query and then use it like so:class="Bgc(blue)--invc"
which says this element should have the background color of blue when the inverted media query is active. Atomizer handles the the writing of the actual CSS for you.With other tools you can author it inline like so (React example):
All instances of that media query would be merged together and all properties inside said media query would have their own Atomic class. All Pre-Style blocks would be written to an external CSS file.
TL;DR – The short of it is, Atomic is typically one selector per property, whether that’s a typical class selector, a pseudo selector/element, or inside of a media query.
One possibility would be to handle them in a similar way to breakpoint prefixing (e.g. use a class like .dim-text-black to set the text color to black for dim light level).
A bit of shameless self promotion, but I’d just like to add a new one that I recently built called hydrogencss. Mostly for use with CSS Modules but could be used with other things too. https://github.com/eddiemoore/hydrogencss
Good thing about it I feel is you can include as little or as much of it as you want.
For some reason I find
.black{color:navy}
less offensive than not being able to change in one sweep every instance of said black. Problems like that can be solved by simple renaming things to make them more understandable. Instead of selector “black” it could be “color-default”.I just don’t see any profits from using it. CSS was created exactly so we could make broad changes with little writing.
Using
.color-default
,.color-primary
,.color-secondary
as selectors instead of.black
is a perfectly acceptable way to do Atomic CSS.I agree. I like using things like “color-primary” and “color-secondary” or “bg-color-primary” and “bg-color-secondary” to allow it to be flexible and still easy to modify with a simple changes.
In reply to @Lazza (couldn’t reply to thread)
It’s authored similarly, but the inner workings of doing
class="BgcBlue"
vs.style="background-color: blue;"
are very different. I’ve outlined a few of those in other comments.Accented how exactly? If you want to change the
background-color
of a button, just use a different class. The underlying CSS classes don’t change, they’re immutable. So<button class="AccentBlue">Click Me</button>
becomes<button class="AccentGreen">Click Me</button>
. If you’re using plain old vanilla HTML with no templating, partials, server-side includes, then yea.. you’ll have to manually replace all 12 occurrences. But let’s be honest… what’s more common: Replacing 12 button’s background colors at once (Holy indecisive designer Batman) or needing to make one of those buttons different from the rest? Atomic absolutely excels at the latter. So much so, that you’ll never have to worry about making breaking CSS changes again. If it’s frequently the former, then Atomic may not be a good solution for you or your team.If you want to author a CodePen to show what you mean I’d be happy to do a Atomic version to illustrate what I’m saying here.
It’s my personal take that Atomic CSS prioritizes the end-user over developer convenience. However, tools like Atomizer, Pre-Style and libraries like Tachyons and Basscss make authoring in Atomic much better.
Haha! :)
Why does the concept of “atomic parts” or really just keeping things “DRY” make sense for components (or HTML and JS) but not your CSS? Reusability means less code repetition, which means smaller files, which means faster loading times.
Should you switch to Atomic solely for the minor perf benefits? Probably not. You’d be better off just removing an image from your application. But those perf benefits are gravy on top of a very, very maintainable Sundae. The immutability factor means I can come back to a project a year later and make sweeping styling changes to a group of components without needing to worry about breaking anything, anywhere. You don’t get that assurance with semantic class conventions unless you abandon any sense of reusability altogether. Further, I get all the specificity handling benefits of BEM.
Thanks for your answer.
Generally, if I want to change how buttons look on my website I don’t want to change one button, I want to change all of them, unless one is special. CSS was invented to avoid repetition and separating style from content.
I don’t want to tie a “colorful” class to elements because changing every occurence of it is going to be a nightmare. What if a company changes it’s primary color from blue to red? Am I going to replace all the classes on every
.color-blue
element or am I just going to redefine a single, semantic,.color-accent
class?TBH I’d prefer the latter. :)
I don’t see how these things relate to what CSS approach you use. You can write a WordPress template with all kind of server side stuff and use proper semantic CSS. If you are talking about using PHP to
<?php print_correct_accented_color_class_name_here(); ?>
instead of writingclass="accented"
it seems to me this is like trying to defeat the purpose of CSS in order to recreate it on the server. Or with CSS preprocessors, that are just nice (but superfluous) abstraction tools that produce normal CSS in the end.In reply to @Lazza
CSS was invented 20 years ago. Its original goal relates to concerns that have since evolved/morphed. As I discussed in this article, the Separation Of Concern is now a moot point for many devs.
In my opinion, one cannot understand the benefits of Atomic CSS without first accepting that it is “okay” to change styles outside of styles sheets. And the comment from Michal seems to prove my point:
:-(
Thierry, I understand that since you coined the term Atomic CSS you think it’s the best idea ever and one should not try to criticize it, but I’d say let’s keep a quite tone.
Maybe, depends on what “outside” means. For sure you are not going to be “more right” if you write something in bold. :) If by “outside” you mean adding a weird
class='text-centered'
maybe we should go back to the whole presentational HTML tags idea and resurrect<center>
… or even add more. Yay to<h1 color='red'>
I guess?I’ll keep the CSS but you can keep the unsemantic markup if you like to.
Evolution is a thing, regression to what we were using before (as the “visual” tags mentioned before) is another thing. Isn’t it weird that most people using Atomic, BEM, or whatever have to end up using preprocessors, compilers or other shenanigans to rebuild the semantic aspect of CSS that was lost when using one of those approaches?
This doesn’t mean using Atomic CSS is illegal or that someone will get mad at you. It’s just using CSS in a very weird way, completely different from what it was designed for. Less convenient. More similar to inline CSS which is also not very good in several cases.
It also doesn’t mean it’s always a bad idea. I can think of a couple situation where it could be a good idea. I can also think about a couple situation where I would use (or have used) inline CSS (which is almost the same) but yeah… one should be careful. Use sparingly. ;)
Your article is smartly titled “Opinions of Leaders Considered Harmful” and it then goes on in a very long text where you act as a leader giving a harmful opinion. There is also a bit of ad hominem here and there used to attack the arguments of basically all the other people, which is not a very good approach IMHO.
We could also discuss how you define best practices (which derive from how CSS was built and how it works and simplifies style maintenance) as simple “opinions”, but… rain check.
Also the concept of Atomic CSS adding classes related to presentation in the markup seems to suggest you expect a specific markup to be styled in only one way at the same time (clearly not the case as one can have a print stylesheet or a mobile stylesheet, but I digress).
What you wrote about Atomic CSS works very well for “old CSS”, too:
In reply to Lazza
Nope! And if you take time to read my articles about it you’ll find out this is not the case. Or you could simply check my reply to @unleashit in a comment below, in which I say: “Not saying here that Atomic CSS is the best thing to use, just giving you feedback about your assumptions”.
It shows as bold to denote emphasis.
What happened to your “let’s keep a quite tone.”?
A very short read that explains the differences:
https://acss.io/frequently-asked-questions.html#how-is-atomic-css-different-than-using-inline-styles-
In the case of ACSS, one would not do what’s suggested in this article (“changing
Bgc(colorOne)
toBgc(colorTwo)
) simply because ACSS allows devs to use “variables” via a config file. In such case, one would use a class likeBgc(color-primary)
across one’s entire project and then change the color in one place—the config file.This sounds a lot like using:
.background-primary {
background-color: colorOne;
}
But reinventing the wheel via config files, preprocessors and stuff.
In reply to @Lazza
I think you’re missing the point. A config, or a pre-processor, allows to replace color values across the board inside style sheets instead of changing classes in the markup—as often suggested.
.background-primary {
background-color: colorOne;
}
.color-primary {
color: colorOne;
}
.border-primary {
border-color: colorOne;
}
Does this fit in with the topic of client-side “application logic” being developed by front-end/design folks because it’s client-side?
It makes me feel like it’s an attempt at making CSS “easy” for people who don’t understand CSS (like maybe programmers/server-side devs who are now working on the front-end because of frameworks like Angular).
I’m sure there’s lots of front-end devs who have bent over backwards recently to get better at JavaScript etc, can we not ask for the same for our CSS?
I wish we could go back a few steps and keep programming as programming and UI development as UI development.
I sometimes wonder where the web is going with all this.
CSS and (SCSS/LESS) is simple and easy to follow. This is just adding another layer which doesn’t benefit the person who uses it – the designer!
What do you mean @Colin? Our design team uses functional css. I’d argue that it’s easier for a designer to change a classname from “red” to “dark-red” than it is for them to look at the markup, see that it’s a
.Button.Button--primary
, find the corresponding file, look forcolor: red
in the.Button
element, if it isn’t there, look in.Button--primary
, change it there, check the whole app to make sure they didn’t change something they didn’t intend to (aButton--primary
elsewhere).Thanks John for writing this.
Just a footnote. I think techniques like these stir passion because the see sort of a battle ground between the old way of KISS, and the new wave of engineers who’ve recently become interested in the front end who are bringing along their (sometimes) over engineered ideas. Dramatic as the word “battle ground” may sound, these new voices are the ones that the industry pays attention to and for the better or the worse, are likely to become the expected practices of the present/future. I’m all over composition and functional programming, in “programming”. But I do think its a bit dangerous to try and subject CSS and the theme layer to all of these constructs. I’m sorry, but Atomic CSS unnecessary and an over engineered idea.
It’s not that I don’t have an open mind, it’s just that I think its wrong and basically came about as a result of teams who were unhappy with CSS because either a) they don’t understand it well or b) they didn’t have the right collaborative systems in place, or didn’t enforce them or c) they feel personally satisfied by taking bold steps to solve problems even if the new solution creates a new set of problems greater than were originally present.
IMO, CSS is far from perfect. Why should we need Sass/Postcss/Bem? I just think people should spend their time working for improvement to CSS itself (and browser uptake) rather than stopgap solutions like this. Sorry, I really don’t want to have to change the markup in 500 React component files because I want a different color button. To me that’s ridiculous. If you’re that scared of mutating your CSS, I suggest therapy :p (and better training in CSS).
No, the idea does not come from “a new wave of engineers who’ve recently become interested in the front-end“; I’m not part of the new wave and have no engineering background. On the other hand, I believe I have a good grasp of CSS.
Regarding b) I’d say it’s the opposite, Atomic CSS facilitates workflows as it does not require to follow strict rules (i.e. namespacing). Same for c) Atomic CSS addresses a different set of problems (i.e. bloat/performance) which—for some—may be more important…
Not saying here that Atomic CSS is the best thing to use, just giving you feedback about your assumptions.
Hi Thierry, first of all my intent is not to be confrontational. I can see you’re passionate about this, and I just had a chance to read your Smashing article and get some more context. Even if you didn’t have an engineering background, you are/were working with a company (like other major tech companies) who is constantly biting at the bit to try to do something, ANYTHING they can think of to increase efficiency and better compete. Do you tell your shareholders we’re going to do “more of the same” in order to meet their revenue goals? This reality is more of the macro picture of why the backend engineers now do CSS, and why the front end has changed so much in recent years.
That’s not to say I think change is bad, or a lot of good hasn’t happened. There’s been a ton of neat stuff. On the other hand, some of the ideas not so much… in my opinion especially around CSS. Of course I care about performance. I actually think the problem you’re trying to solve has resulted in part by popularity of component based development which has meant a lot of CSS gets repeated. Personally, I like to utilize a combination of BEM or CSS modules, along with a healthy amount of the dreaded global CSS. I have worked on pretty large codebases with multiple engineers editing css (none as large as Yahoo I admit, but there aren’t many that are). It is a challenge, but with a good disciplined system and everyone involved having a good understanding of the box model, specificity, etc. I don’t think it’s much more bloated than Atomic CSS. Don’t forget the amount of code you’re adding to the markup. Maybe there is some savings if you get everyone doing the super minimalist shorthand version, but what’s the trade off? The markup is terribly hard to read, it’s awkward to type, no css linting, no emmet (ahh some stop the press right here!), no use of the vast armada of css frameworks, libraries, online pattern libraries, css from old projects, etc.
Unless/until you can change the whole industry to use this, it will make my life and many other’s life more difficult when they have to encounter it. Sorry if that sounds negative, but I think there are other and better ways to save 20 or so k besides this. I’m not against you, but I have a right to my opinion just as you do.
I despair. What on Earth is happening in the world of Web? It’s as if everybody has gone insane!
Do these guys ever do any serious work? Large projects are not those with lots of style. Large projects are those with lots of content, styled consistently, delivering a brand.
What crazy authors are changing the way they use HTML every new project? Not me. For example, my beloved, trusty, reusable form module that spews out the HTML for my forms so I don’t have to write HTML forms manually. It’s doing the hard work for me, reducing errors, ensuring accessibility, etc. I’m sure I’m not the only web professional that relies on components for generating their HTML, many people edit mark down and not HTML, for example. Anyway, do I edit this HTML if I want a form with a different design? No! Why would I do that? That would be totally insane!
If I wanted to use atomic CSS, I would have to do exactly that. That’s a major waste of time, and an inappropriate use of HTML and CSS. If you’re considering atomic CSS, you’re doing something wrong, and about to make it worse.
I think the reason for the big disconnect is that it depends if you are more of a designer or more of a frontend developer.
When I came across this topic a year ago, I also didn’t understand the difference between this and inline styes. Especially since I was the only designer on the team.
However, as my skillset changed, and I started to do more on the programming side, I began to understand how beneficial ACSS is. In addition, I started to work on larger teams and more complex projects.