v5 Suggestions

[mrmrs]

After so much time on v4 I have a fairly good idea of what I want to do with version 5, but I'm open to suggestions as well. This is an issue to track said suggestions from the community.

[garrensmith]

I would love to see more components. Ideally we could build out the components so that we have nice libraries to use with React, Ember and other libraries as well.

[lachlanjc]

Related: tachyons-css/tachyons-lists#3

[mrmrs]

@lachlanjc not really the type of thing I am interested in for v5. More interested in pushing forward documentation, performance, and making sure the design system is as cohesive as possible. Class names are quite trivial and can be customized by end users to fit their needs if they don't work for them.

[lachlanjc]

@mrmrs Agreed, they are pretty trivial (just wanted to mention it as a possible breaking change). Sorry I haven't been able to work on the new docs recently…I'll be getting back to it.

[lachlanjc]

Some things I think we could look at for v5/beyond

Docs & guides

• Grid docs. Tachyons doesn't take a conventional approach to grids (e.g col-6 and col-9), but instead relies on max-widths/centering, the widths module, the new flexbox module, etc. For people starting to use Tachyons I think this isn't explained super well yet, so maybe create a guide (separately from the regular module docs) about grids?
• Contributing. Both to the docs and the real modules, we don't have a great guide on contributing yet. On the docs from, the new architecture should make a lot more sense for editing than the current one (since it requires complex build steps), so that should help.
• Module docs/examples for flexbox and colors

Modules

• Allow for importing specific breakpoints (not sure of the implementation details)
• By default, don't build -m and -l breakpoints into all the modules. In some places, it seems incredibly unlikely you'd want to change properties based on screen size (i.e text transform). Tbh, almost the only places I've used m and l are with spacing and type scale. So with the regular build we could omit them, and then include the generated code in the Github repo in case people wanted it for their specific use case. Smaller file size too.
• Rename -ns breakpoint to…something else 😜 (it’d be good if we didn’t have a “negative variable”/have to explain it.) Other frameworks use -xs or -sm at small sizes…not sure what we could use here though, since it’s for “larger than small”

Misc

• Moving components to CodePen? One of the biggest advantages of Tachyons (imo) is how you can design in the browser so quickly, but the current components require you to use the web inspector or else set up a project, import/build/integrate sometimes over a dozen modules, paste in the html, and iterate there. CodePen would let people quickly try changing little things and I think better showcase Tachyons' abilities. Plus the community/social side of CodePen would spread it to more people.
• Add Tachyons docs link to each repo's description/URL field on GitHub/npm. Small thing but there’s no quick access right now (esp. because the docs url structure isn’t very predictable)
• Search the docs? Obv there’s Google and ⌘-F, but I find myself using the search on React’s docs a lot (they use Algolia)

Kind of a long list…let me know whatever your thoughts @mrmrs 😀

[chenghanlee]

agreeing garrensmith and lachlanjc:

1. Would love to see additional documentation on components, especially on best practices for creating forms and menus.
2. Would love to see additional guides on grids. Coming from bootstrap --> basscss, I am still trying to wrap my head around grids without using columns.

[kentor]

translucent -> opaque hovers (opposite of dim):

e.g.

.hover-o-10 { opacity: .1 }
.hover-o-10:hover { opacity: 1 }

etc

[mrmrs]

@kentor will add something along those lines for 4.5.0

[ixley]

@lachlanjc I agree with your reco to apply breakpoints more sparingly. An alternative for the ns slug could be to use -gts and -lts alongside plain ol' -s. Greater than and less than are appropriate descriptors for breakpoints, where -gts = min-width: [s-breakpoint], -lts = max-width: [s-breakpoint - 1px], and -s could either default to (min-width: [s-breakpoint]) and (max-width: [m-breakpoint - 1px]) OR could simply be the default for greater-than (min-width) media queries (depending on whether you want more options or simple conventions for combining).

[btnwtn]

I would like to propose dropping the -ns, -m, and -l suffixes and introduce using @ to denote responsive modifiers. I took this idea from CSS Wizardry's BEMIT article, implemented the idea at my workplace, and it has worked wonderfully for us.

It is easier to quickly parse and understand a string of class="p0 pb2@l m0 mt4@m" than class="p0 pb2-l m0 mt4-m". I think Harry worded it a bit better than me:

The @ is a human readable and logical way of denoting conditional states. It allows developers to learn about any potential permutations or appearances that the piece of UI in question might have, just at a glance.

The only potential downside that I can see is that we would have to escape the @ in source, like so:

.m0\@l {
  /* ... */
}

[mrmrs]

@btnwtn Thanks for the suggestion, I'm glad you're having success with this with your team. Understand why some people like this but I think the downside you mentioned is quite significant and goes against some core Tachyons principles. Because of this, we won't be adding any class names that contain characters that need to be escaped.

[ajusa]

@btnwtn I actually really like that idea. While it makes sense for mrmrs to not incorporate it, I think it would be possible to create a fork with just that change that is always updated with the newest release of Tachyons.

I'll edit this when I have a working fork with the "@" in .

[billaddison]

For the breakpoint nomenclature, I'd suggest:
-a (all)
-s (small)
-m (medium)
-l (large)

Knowing the media queries are mobile-first, you'd know that "-a" is a bottom-up query which can be overridden by -s, -m or -l. Although you'd never explicitly use the "-a" class, it creates context for understanding the other three classes.

[mrmrs]

@billaddison thanks for the suggestion. We won't be changing these extensions as that would be a breaking change. For v5, we'll be dropping -ns and moving -m to a min-width only query.

[dfosco]

@mrmrs does dropping -ns means we would need to use both -m and -l classes in an element to target all desktop screen sizes?