Why Atomizer (acss.io) didn't use more readable class names?

[thierryk]

Question from @jitendravyas

or Atomic classes looks ugly, why do yahoo use it?

[thierryk]

These were more or less the features/benefits we wanted to gain from the ACSS syntax:

• It needed to facilitate parsing so we could make many things possible, like:
  • declaring any unit and/or value,
  • using combinators for contextual styling,
  • using pseudo-classes and pseudo-elements,
  • using media queries,
  • using RTL/LTR-agnostic classes,
  • and more...
• It needed to produce short strings which:
  • are faster to type (this was very important to us since using Atomic CSS means writing many, many, many classes),
  • create less bytes in Styles Sheets and markup
• It needed to help devs "guess" what style was associated with each class (the reason why we used something similar to Emmet abbreviations)

Dynamic libraries are a whole different ball game

It is much more complex to create classes meant to be parsed by a tool (see dynamic libraries like ACSS or Blowdrycss) than classes for static libraries. This is because tools used by dynamic libraries must rely on specific patterns to help express rich styles (contextual styling, media queries, pseudo-classes, etc.) through syntax alone. Static libraries do not have such constraints.

What does readable mean anyway?

Let's take a look at various syntaxes for the sake of comparison:

Declarations	Tailwind CSS	Blowdrycss	Basscss	Tachyons	ACSS
margin: 1rem	.m-4	.margin-1rem	.m2	.ma3	.M(1rem)
text-align: center	.text-center	.text-align-center	.center	.tc	.Ta(c)
font-weight: 900	.font-black	.font-weight-900	-	.fw9	.Fw(900)
width: 100vw	.w-screen	.width-100vw	-	-	.W(100vw)

I may be a bit biased, but it seems to me that the ACSS and Blowdrycss classes better associate with their corresponding style (property: value). In that sense, those classes seem to be more "readable".

Notes:

• Blowdrycss offers aliases that work as abbreviations (i.e. .fw-900).
• Basscss does not have a class for font-weight: 900 it only has a .boldclass.

When "not readable" is actually more readable

Let's consider negative values, units, percentage, and decimal points:

Declarations	Tailwind CSS	Blowdrycss	Basscss	Tachyons	ACSS
margin: -1rem	.-m-4	.margin-n1rem	.mxn2	.na3	.M(-1rem)
font-size: 25px	.text-2xl	.font-size-25	.h2	.f3	.Fz(25px)
width: 50%	.w-1/2	.width-50p	.col-6	.w-50	.W(50%)
line-height: 1.5	.leading-normal	.line-height-1_5	.line-height-4	.lh-copy	.Lh(1.5)

With ACSS, we use - for minus, we use explicit units (i.e. px), we use % for percentage, and we even use . for decimal point. How crazy is that?

Note:

• the "abstraction" offered by static libraries has no relevance here since Atomizer (and Blowdrycss?) can do that as well (i.e. .Fz(2xl)).
• "basscss" does not have a class for negative margin on all sides , so I'm showing their class for negative left/right margins.
• "blowdrycss" uses p for "percentage" so I'm not sure what one needs to use for point.

Readable versus Guessable

Readable is not the same as guessable. For example, it may be easy for one to understand what .uppercase does, or even what .lowercase does, but do these names help you guess which class should be used for text-transform: none?
Anyone? Anyone?

In my opinion, helping devs figure things out by themselves is a better approach because they only need to learn a mnemonic pattern rather than a new vocabulary. In other words, I think it's better to have a tool (i.e. a strict "syntax") to be able to mentally construct classes by oneself (ACSS/Blowdrycss) than to have to learn a slew of arbitrary names (i.e. .float-right, .right, .fr, etc.).

Did you guess?

I asked above what should be the class to be used for text-transform: none in the context of classes like .uppercase and lowercase. Let's see the syntax for that across the same few libraries:

Declarations	Tailwind CSS	Blowdrycss	Basscss	Tachyons	ACSS
text-transform: uppercase	.uppercase	.text-transform-uppercase	.caps	.ttu	.Tt(u)
text-transform: lowercase	.lowercase	.text-transform-lowercase	-	.ttl	.Tt(l)
text-transform: none	.normal-case	.text-transform-none	-	.ttn	.Tt(n)

I think it is correct to assume that even though the classes .uppercase and .lowercase are the most "readable" (in the general sense), they are also the ones that do not help devs predict which class they should use for text-transform: none. This is why I think it is important that the naming convention/syntax helps people use a class without the need to learn about it first.

Note:

• "Blowdrycss" also offers .uppercase and .lowercase aliases.
• "Basscss"'s .caps adds letter-spacing too.

---

And there is this:

Without knowing anything about ACSS i was able to grok exactly what each class meant. Neat.

— Ryan Seddon (@ryanseddon) December 1, 2017

[xialvjun]

Why not just emmet syntax:

Declarations	Tailwind CSS	Blowdrycss	Basscss	Tachyons	ACSS	Emmet(fuzzy search)
margin: -1rem	.-m-4	.margin-n1rem	.mxn2	.na3	.M(-1rem)	.m-1r
font-size: 25px	.text-2xl	.font-size-25	.h2	.f3	.Fz(25px)	.fz25
width: 50%	.w-1/2	.width-50p	.col-6	.w-50	.W(50%)	.w50p
line-height: 1.5	.leading-normal	.line-height-1_5	.line-height-4	.lh-copy	.Lh(1.5)	.lh1.5

Readable versus Guessable

Yes, Emmet(fuzzy search) is less readable than acss, but do we really need readable?

We, well at least me, were writing styles with the browser opening. Besides, we can have a vscode extension just like tailwindcss to help us.

I'll give an example to show why readable is not enough:

I want font-size: 16px, so I try Fs(16)(I forgot font-style cause I don't care about it), got nothing. Then where should I search to get correct syntax Fz(16). If there is an editor extension just like Tailwind CSS IntelliSense , things will be good. I can try the full css syntax font-size: 16px so the extension can notify me its correct syntax is Fz(16).

But if we need an editor extension anyway, less readable can be a not that bad thing.

[thierryk]

we can have a vscode extension just like tailwindcss to help us.

Do you know about this extension? And what about this one from @pankajparashar?

In any case, our syntax follows Emmet syntax (and that's why we use "Fz" for font-size). The main difference with the examples you cited is that we are relying on explicit units: 1rem vs. 1r, 50% vs. 50p, etc. This is because we think it helps people take educated guesses. We wanted to reduce the complexity of the vocabulary by limiting the use of abbreviations and keeping conventions simple and to a "minimum".

[xialvjun]

There is another difference which is I don't want the parentheses. @ziven27 has also talked about the symbol to split property and value. I think we can easily identify the property name and value even without symbolic division. Eg: w50p c#f00, well, there are also cases like chsl(120,100,100) cred should be c-hsl(xxx) c-red. So I think if value starts with number like w50p, we don't need a seperator; otherwise like c-red, we split the property name and value with -.

[thierryk]

I think we can easily identify the property name and value even without symbolic division [...] So I think if value starts with number like w50p, we don't need a seperator; otherwise like c-red, we split the property name and value with -.

I think you need to look at the big picture and ask yourself what happens with negative values (i.e. -100), or with custom properties (i.e. --aspect-ratio), or with breakpoints in our cases (--sm). What happens then when the - character is not supposed to be consider as a delimiter but relates to something else?

It is important that the syntax allows authors to create a rich vocabulary, and I don't think that's possible by minimizing the class to an extreme (i.e. w50p, m5, c-red, etc.).

[renatoi]

When we were initially designing atomizer class name syntax we went through all these iterations and found problems listed above by @thierryk along the way. Truly the parenthesis is the one that made most sense and did its job for being predictable and familiar to programmers.

[ziven27]

why not use : to split property and value like:

    <style>
        .w\:50\%{
            width: 50%;
        }
        .c\:red{
            color: red;
        }
    </style>
    <div class="w:50% c:red">
        Hello world
    </div>

[thierryk]

We chose to use : for pseudo-classes. Here are 2 examples from the doc:

<div class="D(n):h"></div>

and

<div class="foo:h_D(n)"></div>

[ziven27]

Thx for your answer.

Maybe I'm used to use static css class like:

.df{ display:flex; }
.fs12{font-size:12px; }

It will stop me if have to code with parentheses on each class.
That means I have to two times more code.

[thierryk]

That means I have to two times more code.

With more code comes more power! ;)