Atomic classes looks ugly, why do yahoo use it?

[jitendravyas]

This is an example code of a button from http://sports.yahoo.com/ which is using http://acss.io/

<button 
class="Bdrs(4px) Bdtw(0) Bdw(1px) Bgr(rx) Mstart(5px) Bxz(cb) C(#fff) Ff(ss)! 
Fz(15px) two-btn_Fz(13px) Lh(32px)! Mend(0)! My(0)! Miw(92px) 
Px(14px) Py(0) Ta(c) Td(n) Va(t) Zoom Bg(searchBtnBg) 
Bxsh(customShadowSearchButton)" id="search-button">
Search
</button>

This button code could be something like this with semantic classes

<button 
class="btn btn-blue" id="search-button">
Search
</button>

It looks very readable compared to atomic classes button and also that button add more bytes to the page too.

[thierryk]

To better understand the reasoning behind ACSS (Atomic CSS powered by Atomizer), one needs first to realize the many challenges that a company like Yahoo! needs to tackle: the many different sites (200+), the many different tech stacks, the many different teams, the many different designs (including "RTL" interfaces), etc.

In such environment, improving performance and easing maintenance are top priorities—and Atomic CSS delivers on both counts.

Looking at the <button> example you've listed, one could think:

• this is ugly like hell,
• changing some styling for that button means to edit the markup which means to go against the Separation of Concern principle,
• what do all these classes mean? How can somebody learn all that?
• this is bloating the markup.

Now let's say you are a Yahoo! engineer working on the "Universal Header" (UH for short, the top banner on yahoo! sites) team. You are in charge of making that big ass component that is the UH work across the many web sites Yahoo! owns. Web sites built on various tech stacks, based on different script directions (RTL/LTR), different release cycles, different CSS resets, etc. (and there is also the case of "third-party" styles being injected into pages by "crappy" ads).

Before ACSS, devs would ship different CSS assets to cater for those different web sites. On that one, they'd need to overwrite the padding of <button>; on that one, they'd need to change the color; etc. And if the brand color changed, they'd need to go edit and release the hundred of CSS files they had in their code base. And of course, all that CSS they shipped came on top of what the page itself (the host for the UH component) loaded. And they were also very good at namespacing everything to prevent styles from bleeding onto those pages and at the same time protect themselves from styles from those pages. And think of new hires required to style something under such conditions. Having to go through hundred of styles sheets attached to different components, with various naming conventions. Having to search through the entire codebase for a particular class or rules. Being unable to tell what's obsolete and what's not.

With ACSS now, the team barely ships any CSS as there is no need to attach a style sheet to their component - that styling is declarative, it's in the markup. There is no need for them to namespace their styling in fear of breaking something else on a page they do not "own". And of course, they do not need to worry about ACSS styles from host pages either.

With ACSS now, engineers can do various edits without wondering how specific their styling needs to be to "stick". And if they need to change something like brand color for example, then they don't even have to release anything, because that is not something they own, it can be done with a single config - which once created is available to any ACSS classes using that "variable".

To be honest, unless you're working in a very hostile environment like the UH team at Yahoo! does, you can't really appreciate all the benefits of ACSS.

The narrative for these devs using ACSS now is quite different:

• It is ugly like hell! So what?
• we need to make change to the markup instead of various styles sheets and be careful of not breaking anything? Yes!
• we do not understand what all these classes mean! Hu? New hires can guess most of those classes from day one. They are engineers after all, they should be able to easily learn something that simple.
• It is bloating the markup! Nope, it is not, to the contrary.

A couple of other important points when it comes to new hires:

• there is no need to worry about the "codebase",
• there is no need to worry about breaking something on the page (styling is scoped to the component),
• there is no need to worry about creating CSS bloat (because devs don't write new rules, they mostly re-use existing ones).

[renatoi]

Personally, I think that the beauty of the web is that the shipping code can be readable by humans. But that’s also the worst part of it, since a machine needs to read it too. That's why the web is filled with tools today to improve performance while also making sure development/shipping code is still human enough.

So although a lot of people think that the atomic classes are cryptic, I believe that Atomizer, which is not the only tool for Atomic CSS, is the middle ground between the two.

For example, We've been talking about another tool that would compile to ACSS based on normal classes (with restrictions).

For example:

<button class="btn btn-blue" />

and

.btn {
    padding: 12px;
    background: lightgray;
    border: 1px solid gray;
}
.btn:hover,
.btn:focus {
    color: white;
    background: darkblue;
}
.btn-blue {
    color: blue;
}

would output:

<button class="a b c d:h d:f f:h f:f g" />

.a {
    padding: 12px;
}
.b {
    background: lightgray;
}
.c {
    border: 1px solid gray;
}
.d:h,
.d:f {
    background: darkblue;
}
.f:h,
.f:f {
    color: white;
}
.g {
    color: blue;
}

So the shipping HTML code is still using the ACSS architecture, but it's not really readable by humans anymore although you can still understand it by looking at the inspector. What becomes better in terms of readability is the development, since you would still develop in conventional CSS syntax and organize your files the way you want. A debug build could even not generate atomic classes at all so that you could just look at the HTML and recognize the markup by looking at it. But again, the shipping code is going to be cryptic for perf reasons.

ACSS.IO should offer both solutions. If you don't care that your shipping code is readable, then go this approach, otherwise, go to Atomizer.