Tachyons: Add Recommendations on Class/Declaration Order to Docs. (was: "Best Practice for Order of Class Names")

[timpish]

Can we establish and document a recommendation/best practice around how order classes? Do I put box first (display, padding, margin) or type, or skin, etc.? What about when writing for media queries and states? I know there are some best practices out there with regards to declaration order within components but those are around CSS methodologies that functional CSS is moving away from so maybe we need an fCSS approach to align the order of our multiple classes?

[ooloth]

I'm interested in this, too! I'd love to hear some advice on how to order the classes and/or visually separate them (e.g. with extra spaces? symbols?) so they are easier to spot at a glance.

[lallmon]

I order them alphabetically, that way I know where to look for a property that may be missing, or may be causing problems. It's also super simple.

[luizbills]

I try in this order: http://basscss.com/v7/docs/guides/basics/#order

[timpish]

Concentric CSS looks promising:

• Explanation
• Repo

[lallmon]

@luizbills Thats pretty logical. I find that similar to Linting, unless it can be enforced programmatically, most of the time, it's not gonna happen in a bigger codebase.

[timpish]

@LucasKA Can linters even rearrange class order? For anything non-atomic, that would probably be a disaster.

@luizbills That's a start, but Brent does not expand on what is a very general explanation. If we start with typography, for example, what's first, second, etc? In print work, font, font style, font size/lead is common terminology, e.g., "Helvetica Neue Light Italic 10/12." In Tachyons markup,

…here we see a limitation with lib's line height options. 120-140% is common for body copy leading, yet to hit that we must use lh-title as lh-copy is @1.5 (new issue)

Looking at the Tachyons components examples, I cannot find any standard or pattern. I think creating one that is used consistently throughout the docs, examples and in our practices can only strengthen the project and its adoption. Maybe it's possible to create a Tachyons-centric linter?

[timpish]

Another approach: How to organize CSS @ 9elements…and check the references

[mrmrs]

I'm way behind on publishing an FAQ which will touch on this. At most it would be a series of things to consider but I think declaring something a best practice would be fairly audacious as mileage will vary with various teams. I've taken a lot of feedback on this subject matter over the years. Common feedback from people:

• Most people are apprehensive about this question before using tachyons. One of main perceived drawbacks in general is, readability, maintainability of atomic/multi class style regardless of framework.
• A lot of people find themselves gravitating to their own pattern pretty quickly that aligns with how they think about styling. Common to have layout or typography or skin classes first.
• After getting comfortable with tachyons people find order doesn't affect scanability as much as they'd expect
• Most people would like an automated system for class ordering. Some don't take too much effort to enforce rigid order but try to stick to rough structure that make sense to them

I think it's important to remember that when it comes to development workflow and readability (which can be intertwined more than we recognize), some people might had different mental models so what works well for you and your team might not work well for another team.

@timpish for print work 120-140% are common values for leading. On the web, most accessibility references I've seen have said to keep line-heights for body copy between 150-200%. I have tried to build a design system that aims to make it easy to account for a variety of common accessibility issues that come with typography (color contrast, type size, measure) and so I've tried to select a line-height value that falls within the recommended range. Per the w3c

Many people with cognitive disabilities have trouble tracking lines of text when a block of text is single spaced. Providing spacing between 1.5 to 2 allows them to start a new line more easily once they have finished the previous one.

Ref: https://www.w3.org/TR/WCAG20-TECHS/C21.html

That being said - the values in tachyons are just reflective of a jumping off point I find useful. If you'd like to change the existing values or add additional values for your own project that you find work well I encourage you to fork tachyons and customize it to make it reflect the snippets you commonly use. The collection of values are more of a smart set of defaults than a list of rules carved out in concrete.

[lallmon]

@timpish I dunno. They are just strings so I'm sure it could be done.

My point is, in larger codebases if the rules aren't as simple as possible, they have to be enforced mechanically or they tend not to be enforced at all. Or have just the most pedantic of committers.

I originally tried to write my tachyons classes as a "sentence describing what it looked like", since writing is my background and I thought it was "elegant".

I quickly realized that it could mean different things to different people and then expression became involved. And expression should be through the Thing you are building, not the class string.

Mostly when debugging a component, you are quickly looking to add/delete/change one or two properties, so the sentence method was not viable or scannable.

Alphabetical is a quick index. It also helps you find duplicate classes in rapidly prototyped components.

[timpish]

Adam/Lucas,

Thanks for your replies. You both make excellent points, the most salient of which (to me) is that individuals and teams think and work differently; and that imposing a "best practice" might be considered presumptuous. I've, therefore renamed the post to align with the author's goal to make recommendations about class/declaration order in an FAQ or elsewhere in the docs.

Funnily, I jumped on the 9Elements method (above) and quickly discovered as I robotically applied it to preexisting markup that it just didn't feel right. It did not fit my mental model. Similar to your experience, Lukas, as you attempted to apply writing principles to class order!

Adam, thanks for directing me to the W3/WCAG reference on line height. As it's a separate topic and I have more questions (and more to say) on it, Ill extract it into a new issue.

[timpish]

List of points/resources mentioned in this issue (and more).
CAVEAT: most of the following define the order of multiple declarations within a single class definition, which exactly what Tachyons delivers us from:

• alphabetical (though this can be wildly inconsistent with functional/atomic/utility class/immutable CSS (what the heck are we calling it?), e.g., font and color classes, etc.
• http://basscss.com/v7/docs/guides/basics/#order
• http://rhodesmill.org/brandon/2011/concentric-css/
• https://github.com/brandon-rhodes/Concentric-CSS/blob/master/style3.css
• http://9elements.com/css-rule-order/
• https://google.github.io/styleguide/htmlcssguide.xml#Declaration_Order
• https://css-tricks.com/poll-results-how-do-you-order-your-css-properties/
• https://github.com/necolas/idiomatic-css#declaration-order
• http://codeguide.co/#css-declaration-order
• http://maxdesign.com.au/jobs/sample-format/css-declaration.htm
• http://csscomb.com/online/
• http://cssguidelin.es/

[lallmon]

@timpish I'm not sure what you mean on the Alphabetical side note? You mean some name their classes differently (.f1 in tachyons .h1 in BassCSS)?

Also, this goes back to part why I use Tachyons in the first place, _to remove the cognitive overhead of authoring CSS_. Alphabetical removes the cognitive overhead of a philosophical style string.

Do you wanna write CSS/organize strings, or do you want to ship products?

[timpish]

@LucasKA I simply mean that, with alphabetical, due to things like font and color _class names_ that you'll never have cognitive load-free, scan-able patterns as you would with classic CSS declarations, e.g.,
<p class="avenir f4 mt2 pb3 purple"> vs. <p class="dark-gray f4 mt2 pb3 roboto">

vs.

.class {
    color: color doesn't matter;
    font-family: name doesn't matter;
    margin-top: 2px;
    padding-bottom: 3px:
}

That's why I think a class order approach that is unique to Tachyons—functional/atomic/utility class/immutable CSS (what the heck are we calling it?)—might be…well…in order.

[lallmon]

@timpish I see where you are going and thats fair enough. At the same though it only applies to those two cases really, because the rest are shorthand for property names.

Normally when you debug these, it's because something 'looks' off. "Why is this purple?" Go to p in the string, and delete it. Add red

Anyway, I usually opt for 'caveman' approach after everything is said and done.

[timpish]

@LucasKA Maybe therein lies a solution, e.g., font > color > alphabetical?

<p class="avenir purple f4 mt2 pb3"> vs. <p class="roboto dark-gray f4 mt2 pb3">

[lallmon]

@timpish I didn't mean to impose anything on your flow, whatever works for you and your team is best.

[enociz]

I think it's important to go in the order that you may build it.

I, personally, would start with layout (so spacing, flexbox layouts, etc.), and then move onto styling: fonts, sizes, colours etc. I think Concentric shows this best.

[timpish]

@LucasKA No worries, Lucas. Don't have a flow yet with Tachyons/fCSS, hence the discussion.

@enociz Thanks, Enoch!

[timpish]

Suggestion (based on convo had here): recommend alphabetical per Google guidelines AND modify Tachyons source to prepend color names with "c-…" and font families with "ff-…", e.g.,

<div class="bg-navy c-gold f4 ff-avenir mt2 pb3">

[lallmon]

Can't say I hate that.

[sebastienbarre]

Same here, prefixing colors with c- would be a nice help.

[tylernford]

I'm in favor of prefixing colors as well. I'm ordering classes alphabetically and having colors in the same spot would be nice.

[mrmrs]

I'll leave it up to the various sections of Tachyons communities to establish ways that they find structuring markup to be helpful. I am reticent to provide any official 'best' practices as I don't believe in an empirical best practice in this context. Definitely think it's obviously helpful for some to structure some guidelines around this sort of thing for some but feel that's a decision that should be left up to the user.

[Bebersohl]

I created an eslint plugin to enforce the order of classes in tachyons if anyone is interested:
https://github.com/Bebersohl/eslint-plugin-tachyons-jsx