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.

[abinxzh]

@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.

[lachlanjc]

@NanaLan Hey! I see what you're going for, but I'm not convinced that using characters that need to be (very confusingly, in the case of :) escaped is better than what we're using right now. I think red:hover is harder to type in the HTML/JS than red-hover, plus it needs these odd methods of escaping in the CSS (that are very much not friendly to a beginner dev/new Tachyons user).

Feel free to fork with that method (we encourage all kinds of variants!), or just use those extensions in your own projects, but I don't think we should add those to Tachyons. @mrmrs?

[levibostian]

I am seeing a bit of discussion here talking about improving the docs. I am thinking back to when I first started using Tachyons and what would have helped me get into it more.

1. A getting started guide. The homepage now goes over what Tachyons is, why to use it, and that's all great. A "getting started" guide (aka: get up and running with Tachyons) is almost complete in the site because it's bits and pieces are laid all over the place. A formal doc to getting started would help new users get up and running nice and quick.

• Video explaining why Tachyons is awesome. Demonstrating it. In the Slack community, we repeat each other a lot talking about why we love Tachyons. We are all people who already use it so it's easy for us to see all this. If there is a way to capture what we all agree on and share that with new people, that would help them to understand why to use Tachyons.
• Getting started kinda like Babel's setup where it helps you get up and running with Tachyons. I bring up Babel because it shows off what Babel can do while also helping you get going with it. Tachyons has a CDN link, a SASS library, you can get it from npm, etc. A way to show this off right away is nice. Then, help new people by advertising the components section, Slack community, etc. Help them to understand the ecosystem quickly.

2. How Tachyons does mobile support. I came from Bootstrap (as I know many people come to Tachyons from) and I was looking for the grid system module of Tachyons to find out, there isn't one. I am lucky to have access to my buddy @mrkhdly that walked me through how to do mobile support in Tachyons using db, dib, w-30.fl, w-70.fl, etc. Perhaps put this in the getting started guide as well. Links to a couple blog posts for "coming from bootstrap?" to help walk people through it.

3. Add search in the docs. Yes. I already use the crap out of: https://roperzh.github.io/tachyons-cheatsheet/ so why not put that functionality into the official docs?

---

Something else I would love to see more of is the incorporation of design into Tachyons. I am a developer at heart but I have learned design concepts and have become a much better designer because of Tachyons. Having Tachyons provide design best practices is awesome. The docs having some design concepts built in is awesome. If there are ways we can help devs and designers become better designers, that would be pretty amazing of an accomplishment. You have already done it for me. I am wondering how we can do that for others.

Along with that, how can we make devs and designers better at accessibility? Contrast in a site is an example.

---

A few other random notes.

1. I don't use the components often. I like them for inspiration, but I do not use them directly. I used them much more when I was learning Tachyons to say, "Oh. That is how you do that in Tachyons" (yes, even though Tachyons is just plain ol CSS, I learned I was pretty bad at CSS!).
2. I have the entire Tachyons lib installed on all of my sites. I have not broken it down by module via npm installing before. I simply install Tachyons SASS and use webpack with uncss to break it down for me.

[GiorgioMartini]

Will v5 be backwrds compatible with v4 ? and will we have to do a lot of refactoring if we want to upgrade to v5 ?

[tvler]

Here are some small classes I've had to add to my tachyons project that I think would be beneficial for the library:

.overflow-scrolling-touch { -webkit-overflow-scrolling: touch; }
.b--currentColor { border-color: currentColor; }
.bg-currentColor { background-color: currentColor; }
.touch-action-none { touch-action: none; }
.top-100 { top: 100%; }
.right-100 { right: 100%; }
.bottom-100 { bottom: 100%; }
.left-100 { left: 100%; }

I'm especially interested in the currentColor additions. I know that we can compile the library with a different color palette, but for small projects where I'd just make the class .custom-blue, making use of currentColor would be very helpful. Thanks for the awesome library!

[ctjhoa]

Some additions that I found useful for my project:

// RESIZE
// Useful for textarea
.resize-h { resize: horizontal; }
.resize-v { resize: vertical; }
.resize-none { resize: none; }

// SVG
// Mix with tachyons color you can apply tachyons color to svg
.fill {
    fill: currentColor;
}

// OVERFLOW WRAP
// Very useful when you deal with a lot of text
.overflow-wrap {
    overflow-wrap: break-word;
    word-wrap: break-word;
}

// WHITE-SPACE
// Very useful when you deal with a lot of text
.pre-wrap {
    white-space: pre-wrap;
}
.pre-line {
    white-space: pre-line;
}

// ABSOLUTE POSITION 100%
.top-100    { top:    100%; }
.right-100  { right:  100%; }
.bottom-100 { bottom: 100%; }
.left-100   { left:   100%; }

// ABSOLUTE POSITION 50%
.top-50    { top:    50%; }
.right-50  { right:  50%; }
.bottom-50 { bottom: 50%; }
.left-50   { left:   50%; }

// BORDER-ONLY
// Useful to create separator or material design input like
@mixin generate_border_only($name, $position) {
    $positions: "top", "right", "bottom", "left";

    .b#{$name}--only {
        @each $p in $positions {
            @if($p == $position) {
                border-#{$p}-style: solid;
                border-#{$p}-width: 1px;
            } @else {
                border-#{$p}-style: none;
                border-#{$p}-width: 0;
            }
        }
    }
}
@include generate_border_only("t", "top")
@include generate_border_only("r", "right")
@include generate_border_only("b", "bottom")
@include generate_border_only("l", "left")

// VISIBILITY
.v-hidden { visibility: hidden; }

// POINTER EVENTS
.pe-none { pointer-events: none; }

I do not understand clearly the naming convention but you can pick whatever you like

[radubrehar]

Currently, .vh-25, .vh-50, .vh-75, .vh-100 have no vw - width equivalent - would be nice if they did.

Also, for .min-vh-100 should have also variations for 25vh, 50vh, 75vh. Also have clases for min-vw - min-width

In fact, would be nice if we had vw and vh classes for multiples of 10, besides the multiples of 25 there already exist

[dumconstantin]

Here's my take on responsive:

screens: {
    'ns': '30em',
    'm': '48em',
    'l': '60em'
  }

with m widthout an upper-bound.

[luizbills]

Better box-shadow. Inspiration: https://tailwindcss.com/docs/shadows

[cmnstmntmn]

what's the fuss about tailwindcss? it's ugly and hard.

[proyb6]

Support -xl for logical resolution of 67.5em aka 1080px (width) and common screen width.

[matthewmorek]

@proyb6 Since -l already target's 60em, I think -xl should target a viewport more substantial, such as 75em or above (80em comes to mind as a good breakpoint, in both 1280px and 1440px variants, depending on the base font-size).

[onetrev]

This is going to cause some people to freak out probably as there is an old guard defensiveness about this, but I would suggest breakpoints should actually be migrated to be px based and not em. One good explanation why.

[luizbills]

@onetrev safari 10 usage is just 0.09%. Even ie8 has more.

[onetrev]

Sorry @luizbills, I was more so suggesting a move to px based breakpoints (combined with explicit root px size) because it's just a better and more modern way now that all browsers support zoom properly (not because of Safari 10 support).

Using 'em' is just a hold over habit from the old days. So you see new projects like Tailwind use px instead of em. It's kinda odd and much less clear to say you want a break point at 67.5em, when what you actually want is to break at exactly 1080px.

[proyb6]

@onetrev I read the article before.

That’s not a major effort to change with the generator you can customise to your needs and serve a compressed static file in brotli to improve user experience.

[j-greig]

Is there any update on when v5 might be available? Thanks! :)

[bresson]

Any interest in fluid / responsive typography?

[cupcakearmy]

More granular flex grow, shrink and basis would be awesome!

[jeremykohn]

Proposal: Add classes to help standardize class names

Generally, Tachyons class names include:

1. Larger numbers to indicate larger values
2. Hyphens for literal values, and unhyphenated numbers for nonlinear size scales

For example:

.h-25 { height: 25%; }
.h-50 { height: 50%; }
.h-75 { height: 75%; }
.h-100 { height: 100%; }

and

.h1 { height: 1rem; }
.h2 { height: 2rem; }
.h3 { height: 4rem; }
.h4 { height: 8rem; }
.h5 { height: 16rem; }

This is a good thing. With standard conventions, classes are easier to learn and remember.

However, some classes are confusing because their names do not follow the general pattern:

1. font-size: Class f1 is largest and f7 is smallest, and there are additional classes for very large font sizes: f-6 (headline) and f-5 (subheadline)
2. font-weight: Class names fw1 through fw9 do not include hyphens or literal values, even though they proportionately represent font-weight: 100 through font-weight: 900

Solution:

Add new Tachyons classes.

The new classes will use a naming scheme that is consistent with the rest of Tachyons, and will replace certain inconsistently named existing classes.

Details:

First, replace the numbered font-size classes with one simple unified sequence, fs1 through fs9, in which larger numbers indicate larger font sizes.

Existing class names	Replacement class names
f1 (large) through f7 (small)	fs1 (small) through fs7 (large)
f-5 or f-subheadline	fs-subheadline
f-6 or f-headline	fs-headline

Also, rename the font-weight classes:

Existing class names	Replacement class names
fw1 through fw9	fw-100 through fw-900

Finally, to ensure that prefixes are consistent, make these replacements as well:

Existing class name	Replacement class name
fs-normal	fstyle-normal
normal	fw-normal

Result:

Property	Old prefix	New prefix
font-size	f	fs
font-style	fs	fstyle
font-weight	fw or no prefix	fw

Each new class name is different from all existing class names, so there are no conflicts with existing Tachyons code.

For backwards compatibility, the old classes would remain available. However, they would be deprecated and possibly removed in a later version.

[jeremykohn]

Proposed changes submitted as a PR.

Expanded type scale for font-size, with self-consistent naming and an additional font size (4rem):

Class names	font-size value	Previous class names
fs1	.75rem	f7
fs2	.875rem	f6
fs3	1rem	f5
fs4	1.25rem	f4
fs5	1.5rem	f3
fs6	2.25rem	f2
fs7	3rem	f1
fs8	4rem	(None)
fs9, fs-subheadline	5rem	f-5, f-subheadline
fs10, fs-headline	6rem	f-6, f-headline

Expanded scale for font-weight, with self-consistent naming and an additional font weight (1000):

Class name	font-weight value	Previous class name
fw-100	100	fw1
fw-200	200	fw2
fw-300	300	fw3
fw-400	400	fw4
fw-500	500	fw5
fw-600	600	fw6
fw-700	700	fw7
fw-800	800	fw8
fw-900	900	fw9
fw-1000	1000	(None)

New names for font-weight classes:

Class names	font-weight value	Previous class name
b, fw-bold	bold	b
fw-normal	normal	normal

And finally, new names for font-style classes:

Class names	font-style value	Previous class name
i, fstyle-italic	italic	i
fstyle-normal	normal	fs-normal

Thus, in new class names, the prefix fs is for font-size and fstyle is for font-style.

The new classes all have different names from Tachyons v4 classes, so they would not conflict with existing code.

PR: #636

[dotku]

would like to have dn-s for display none on small/mobile screen

[jzwood]

I vote to remove IE specific hacks, e.g.

.cf { *zoom: 1; }