-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why Atomizer (acss.io) didn't use more readable class names? #5
Comments
These were more or less the features/benefits we wanted to gain from the ACSS syntax:
Dynamic libraries are a whole different ball gameIt 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:
I may be a bit biased, but it seems to me that the ACSS and Blowdrycss classes better associate with their corresponding style ( Notes:
When "not readable" is actually more readableLet's consider negative values, units, percentage, and decimal points:
With ACSS, we use Note:
Readable versus GuessableReadable is not the same as guessable. For example, it may be easy for one to understand what 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. Did you guess?I asked above what should be the class to be used for
I think it is correct to assume that even though the classes Note:
|
@thierryk Thanks a lot for your detailed explanation. Makes so much sense now! |
That's all correct with the premise that W3C styles spec is absolute truth and properties there are what people/devs need the most. In other words, it's belief that standard specifiers are the most knowledgeable out there and disposed towards users. But if that was true there wouldn't be any need in wrapping/translating libraries, starting from jQuery. Practice shows that their priorities principle was and is regularly violated. So users naturally seek for more natural ways. Eg. tachyons comes from typographic background (Tschichold et al.), tailwind comes from Refactoring-UI background etc. So from these standpoints acss may seem less readable. |
No description provided.
The text was updated successfully, but these errors were encountered: