Currently the list of npm modules on the tachyons home page is manually declared. We could probably dynamically generate this list using either the gtihub or npm api.

Not sure if you care but i had been using tachyons with ruby-sass by importing the main tachyons sass file. Recent updates seem to have broken media queries.

I dont think ruby-sass compiles @media(--breakpoint-not-small)

For now i am just using the pre-compiled compiled css, but it would be nice if compatibility with ruby sass could be kept.

See https://github.com/tachyons-css/tachyons/blob/master/src/_skins.css

For the fieldset correction, is padding intended to be 0.35em or rather 0.25em? If we’re assuming 16px em scaling by default, 0.35 leads to a sub-pixel value of 5.6px, while 0.25 rounds out to 4px. This would also seem to match the other values in the rest of the CSS more closely.

https://github.com/mrmrs/tachyons/blob/master/css/tachyons.css#L189

fieldset {
  border: 1px solid #c0c0c0;
  margin: 0 2px;
  padding: 0.35em 0.625em 0.75em; }

Hi,

In my project i have to deal with SVG icons.

I did that

.s-black svg{
    fill: black;
}
.s-white svg{
    fill: white;
}
.s-gray svg{
    fill: #333333;
}
.s-lightgray svg{
    fill: #777777;
}
.s-red svg{
    fill: red;
}

thought you may have interest !

I'm really inexperienced with loading css via npm, just need a little bit of example documentation on how I might do that? You say in your docs that it's an option to use npm to install tachyons modules, but there's no mention of how to actually then use it.

Can I simply:

main.js

require('tachyons-widths');

Do I need some special config with webpack? css-loader?

Thanks for any help, just need pushed in the right direction. Library looks interesting!

"More documentation and examples will be coming."

Hey @mrmrs, what are the plans according to the documentation?

I still doesn't feel really comfortable with its "Click on a link, checkout one module, go back"-concept. I would prefer a way of have a better insight of the modules first or even have a complete module overview with expanding code examples or something.

Sometimes people highlight form fields on error / success and that can change the readability of placeholder text. Come up with some potential solutions for this.

Is there a particular reason for having these rules versus only having the transition property on the .link rule?

.link:link,
.link:visited {
  transition: color .15s ease-in;
}
.link:hover   {
  transition: color .15s ease-in;
}
.link:active  {
  transition: color .15s ease-in;
}
.link:focus   {
  transition: color .15s ease-in;
}

As seen above, it evidently isn't a recurring theme. Thus, why is there that little black box to the right of the actual example? Was this intentional?

This will avoid a lot of duplication in the CSS modules build script and allow template changes to propagate.

Reproduce:

1. Go to http://tachyons.io/docs/typography/scale/
2. Try to click "Debug" or "Images" in the Footer

There is now a tachyons slack channel. We should add a link to the form that auto invites you to the readme file, probably near the top.
@amirahaile - any interest in tackling this? Link is:

http://tachyons-slack-invite.herokuapp.com

Currently it's one long script

"scripts": {
  "start": "tachyons src/tachyons-border-style.css > css/tachyons-border-style.css && tachyons src/tachyons-border-style.css --minify > css/tachyons-border-style.min.css && tachyons src/tachyons-border-style.css --generate-docs --package=../../package.json > readme.md"
}

But, we should really break it out into composable parts

"scripts": {
  "css:build": "tachyons src/tachyons-border-style.css > css/tachyons-border-style.css",
  "css:build:min": "tachyons src/tachyons-border-style.css --minify > css/tachyons-border-style.min.css",
  "docs": "tachyons src/tachyons-border-style.css --generate-docs --package=../../package.json > readme.md",
  "start": "npm run css:build && npm run css:build:min && npm run docs"
}

It will make each script more digestible and extendible since one might not always want to run all scripts in one go.

I was attempting to use the photo grid/item list example and was testing on mobile when I discovered that the text doesn't show on iOS when using the <article> tag instead of the <a> tag which I have found to work. A reason for this maybe that iOS Safari just sucks or that :target hasn't been used in the CSS.

Help and fixes would be appreciated.

Hi @mrmrs!

Some cool tools like npm-css and postcss-import require a index.css to import as node modules, what do you think to add this file to all tachyons?

A SUITCSS example with component-grid.

If you need some help let me know 😄

Each module should have the current version number of that module dynamically updated.

See bottom chunk at https://github.com/hongkonggong/tachyons/blob/master/src/_colors.css

Basically – the padding and margin properties already use small, medium, large etc. values. Why not apply that to the widths and heights as well? The size rem values are the same, and it's not like a width of "2" or "3" is inherently meaningful anyway ("3" doesn't mean 3rem).

https://github.com/johnotander/immutable-css

Probably best done via an npm script:

{
  "scripts": {
    "lint": "immutable-css src/"
  }
}

The docs link to http://tachyons.io/docs/themes/images/
I guess it should be http://tachyons.io/docs/general/images/ ?

Currently, all the Sass files are bundled together in the same directory. Do you have any thoughts on the pros and cons of that approach versus separating them into multiple directories?

Also, I find that prefixing the classes in each category helps to differentiate between the types of classes being used - e.g. "u-cf" for a clearfix utility. While scanning html, this makes it easier to see at a glance how a component is built. You can tell quickly whether the classes are single responsibility classes, utilities or components. It also helps with any naming conflicts that might arise between classes.

Hello!
I followed the instructions in the readme, and gulp finished the default task with no errors – but it still doesn't serve anything on :3000. It just says "Webpage not available" I was just wondering if I'm doing wrong or if gulp is being silly.

Really stoked to play around with Tachyons. Cheers!

It would be nice and useful to create a new module that would leverage Flexible Box Layout capabilities.

line 1956 of tachyons.css has $silver

Ruby sass compiler also chokes on this but can be worked around by declaring a $silver

See #72

Relevant CSS*: _spacing.css
*Though the conventions used there may be used elsewhere that I haven’t seen

I find the n/xs/s/m/l/xl/xxl/xxxl naming conventions used here a little unwieldy, and hard to differentiate at a glance (which can be useful when debugging/refactoring/just plain reading the code). We used a similar pattern in a previous iteration of our shared CSS library at my work, so this comes from a place of personal frustration (though, of course, YMMV).

For example, if I’m quickly scanning through a template or component, seeing something like:

<div class="ptxxl pbxxxl phxl">Much padding wow</div>

…it becomes hard to immediately discern how much padding is being applied on each dimension. You end up having to count xs.

Though not original (credit to stubbornella here, I believe), I’ve found using a numbered approach to be way faster to read (and easier to type correctly, where I might miss typing an x in the existing pattern). For example:

<div class="pt3 pb4 ph2">Much padding wow</div>

This results in shorter class names that are faster to read and understand. Providing you know how the scale works, I also finder it faster to write down in classes the design I have in my head. I want twice the padding on the bottom as the top in the above example, so I just add 1 to the previous value (as each integer increases the spacing by a factor of 2). I end up pausing to think less.

With the above example, I also find using 0 instead of n (none) to play better with the nomenclature — property and dimensions are always letters, increments are always integers.

bootstrap.min.css is included in the gh-pages branch of the css/ directory.

https://github.com/tachyons-css/tachyons/tree/gh-pages/css

This also seems to be the branch that is provided via $ npm install tachyons. I noticed bootstrap in there after installing via npm while writing a response to #78.

This will allow every module to be processed on its own (encapsulation 👯 ), while still allowing for a global variable config via a tachyons-variables module.

So, for example, the following source CSS

.b--blue {
  border-color: var(--blue);
}

Will be turned into

.b--blue {
  border-color: var(--blue, #0074d9);
}

See tachyons-css/tachyons-border-colors#1

Hi,

there are 2 broken links in this page,
at the bottom,
Debugging and Images

their links are relatives to the page instead of absolute to the site.

Every module should have the file size dynamically updated based on what is up to date on npm registry.

See below "/* Focus states for keyboard navigation" at https://github.com/hongkonggong/tachyons/blob/14bc66da244516788d4fb80e5bf277b3455565d7/src/_visibility.css

Hello there,
I just started to using your toolkit, which is really nice. But couldn't figure out why width size classes named in two letter .wi but height is in one letter? Isn't he-{n} or .w-{n} is much easier to learn the lib. Sorry if it's an odd question. Thanks.

The border radius class for circles is missing from the code supplied on the documentation page for border radius:

I don't know if this is intentional or not but it is also missing from all branches in src/_border-radius.css.

The only place where I can find it is through a search which came up with this

To fix or not to fix? That is the question.

I would love to install tachyons via bower.io. Any chance, this will be added?

Could each package/module be built as as a standalone css file so i could use bower / asset pipeline to include just paddings?

How is having class="mw-50" different from style="max-width: 50%"? Same goes for the majority of classes I looked through in the css file. I cannot think of a difference other than a cosmetic one. I would argue that the latter is easier to read and remember, and just as easy to type with the right text editor plugins.

You have precisely the same disadvantages:

• You tightly couple your document structure and your style guide and therefore make it much more difficult to maintain. (Imagine doing a complete redesign of a website built with tachyons, or a css-zen-garden where the template was built with tachyons)
• You lose the flexibility to change the properties of multiple related elements at the same time:
• You clutter up your DOM with styling directives

Yo community! The README.md here States the following:

A Note on Class Names

As tachyons started out as an experiment in css performance - many of the names were programmatically generated using vim macros based on the content of the properties and values they represent. As I have begun to work on tachyons more and use it in the wild, I've begun to codify common classes to things that my brain naturally leans towards remembering. I like unix a lot and subscribe to naming conventions like cp over copy for common classes that I use frequently.
That being said I think the naming in Tachyons needs work and I am open to hearing peoples feedback on things they like and also the things they don't like. Once Tachyons is a little more finished I will be generating different 'flavors' of the framework that use different naming patterns. One version being a more verbose class naming system that seems to be aligned with what many people prefer.

So, I would like to spark a conversation here on what could be some future class naming conventions.

Just open the link you will see the bug: line-height doc page

Device: iPhone5s, iPhone6
Browser: Safari

This could be more mis-understanding things, but in the Measure page docs it says GARAMOND SET TO 4REM/64PX AT 30EM

But when I look at the code making up the example text it is set to 2rem.

Is there some caclulation Im not taking into account or are the docs incorrect?

I often like to use util classes for word-break: break-word and text-overflow: ellipsis for handling overflowing text for long usernames, etc. in small list view contexts. I propose adding some sort of util class collection similar to the following:

.wb-bw {
  word-break: break-word;
}

.to-ell {
  text-overflow: ellipsis;
}

Also, if you don't want to support this in the base Tachyons, perhaps we could add it as an optional module @mrmrs?