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?

[mrmrs]

@dfosco nope, -m would then be equivalent to what -ns is now.

[enociz]

@mrmrs I guess that makes a lot of sense (especially if you haven't grown very used to the 'previous' method). My only concern would be that it'd take a while for some to change all their -ns's to -m's. I guess that's why you should use vim 😉...

[sebastienbarre]

~~Minor, but maybe add a f7 font scale (e.g. 12px) ? I realize you can customize/rebuild tachyons.css to make f6 smaller, but I was attempting to make badges recently, and f6 at 14px is too big. Most (if not all) the badges I've seen in other frameworks use 12px (see examples for Ant, Semantic UI, uikit, Material Design Lite, Material UI).~~

.f7 {
  font-size: 0.75rem;
}

Thank you.

UPDATE: it's in 4.7, woop woop.

[mrmrs]

@sebastienbarre have been debating adding it as it seems heavily used.

[sebastienbarre]

Maybe add media queries for viewport/screen aspect ratios?

Say I build a full-bleed cover page (aka bg-center cover), with contents below the fold, and my photo is originally 3x2 (aka from a full frame camera). This looks pretty good on laptops, desktops, or iPad horizontally, because the aspect ratio is similar. I might lose some pixels on the horizontal edges, but proportionally not that many. On a phone with a 9x16 aspect ratio though, this end up cropping a large part of the photo to fill the whole screen vertically. If that photo is important (say, the best picture of the interior of a house), I may want to try a different version for that cover page, targeted at "vertical" aspect ratios, to make sure most of the picture is there. Just a use-case.

[mrmrs]

@sebastienbarre Think that should be handled with custom css. Adds too much weight to account for orientation queries and last I checked (although could be incorrect now) they aren't as reliable as queries based on widths.

[thangngoc89]

I don't know if this is the right place to say it but thank you for making this awesome project. I'm purely a developer with zero design skills. At day work, I usually work with designers and I admire them. I tried to mess With CSSand designing but it was bad.

I learnt about tachyons about a month ago and it literally changed my life. I'm now don't have to touch a single css line but stills produce decent looking product. Thank you so much.

But as a developer whi are obcessed with speed, embeding the whole tachyons stylesheet is kind of redundant when you are only use a portion of it.

So I challenge myself to build a build system to reduce the size of tachyons based on each project.

Here is my ideas:

• A babel plugin to extract all class names from JSX (I'm usig React but this can be apply to anythig elsr) to a giant array of used class names.
• with the list, I can make a custom postcss plugin to remove all unrelated selector.

No working version yet but I want to give a head up first.

[lachlanjc]

@thangngoc89 That's great to hear! Thanks for posting. If you'd like, you can join our Slack team to chat with other users/contributors: http://tachyons-slack-invite.herokuapp.com/ 💬

Also, there's an open PR for a custom build tool already in progress over here: tachyons-css/tachyons-css.github.io#46 It's not finished, but if you want to, maybe you could contribute there? 🛠

[thangngoc89]

@lachlanjc I think that's not what I'm having in mind. My goal is to export css that tailored for each project. Only used selector will be included. For ex: if you only use "red" in you site, the other colors would be discarded.

[subic]

@thangngoc89 Depending on your build process purifycss might be what you are looking for.

[thangngoc89]

@subic thanks.I'll look into it

[ooloth]

Thanks so much for Tachyons! It's awesome.

One addition I'd love to see are the "flex-grow", "flex-shrink" and "flex-basis" properties. Sometimes it would be useful to set them differently than the included ".flex-auto" and ".flex-none" allow.

For example, when using ".justify-between" with three flex items, it would be helpful to be able to set the flex-basis of each item to zero so that differences in the widths of each item don't throw off the centering of the middle item.

[thangngoc89]

@ooloth there are some suggestions already http://codepen.io/dangayle/pen/NbmWza

As I have read in every flexbox tutorial, you should not specify "flex-grow", "flex-shrink" and "flex-basis" seperately, just use the "flex" shorthand syntax. It shorter (for sure) and less error-prone since "flex" will override all of those 3 properties.

[btnwtn]

@thangngoc89 it should be worth noting that flex: 1 doesn't produce the same results in IE11 and some older, but still popular, versions of Safari.

[mrmrs]

@thangngoc89 If you only want to send necessary css/styles down the wire - I have found a declarative approach to be better suited for that. Removing unused css can be brittle in my experience. And it seems like kind of an anti-pattern anyways. If you are using react / jsx it's pretty easy to use something that allows you to keep a design system like the one in tachyons, while also allowing you to only declare needed styles for a given component / view. http://github.com/jxnblk/cxs is my favorite but aphrodite, stylematic, and many others will allow for comparable solutions. Tachyons is great but if you do want the absolute minimum of css - I'd suggest using a css in js solution.