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

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?

Why are double-dashes in br--top, b--black, absolute--fill etc.?

I copied the syntax in my library: https://github.com/fab1an/react-native-tachyons, but I'm not sure if I'd not rather lose the double-dashes.

Was there a reason for this naming?

Regarding #70

• Added df modifier to the Display module, to set display: flex; on elements, upgrading them to be flex containers. Also, updated docs file for this module with this new addition.
• Created src/_flex.css source stylesheet module, enlisting several properties and modifiers to compose simple (and complex) flex box layouts.
• Created docs file for this new Flex module, enlisting thorough examples of several implementations and use cases.

Things to consider:

• Naming Conventions. From the module's name to the chosen modifiers, flex properties are many and not all of them are necessary related to each other, so it could get a little tricky.
• Granularity. Whether we really want to incorporate all of these flex box rules, or just a subset, so as to achieve simple layouts.

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.

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!

Many of the changes introduced by Normalize 6 were disruptive. The project maintainer now believes that to have been a mistake. Normalize 7 has reverted those changes. (There's a long issue thread about the reasons here: https://github.com/necolas/normalize.css/issues/664)

This commit shows what changed in Normalize 7: https://github.com/necolas/normalize.css/commit/b4a8fdaf8321093b1e3cad612fb76cf2b7d3275d

Can we update to Normalize 7?

Hello,

I've been using tachyons on my current project and found it really helpful in prototyping and editing an existing UI. One thing I did not manage to grasp yet is the best maintainable way to share a common set of classes accross elements.

Let's say, all the buttons in my app are .link.white.dib.ba.br2.ph3.pv2.ttu.tracked.underline-hover. How should I handle the possible variations (like size changing for CTA, colors for various actions) while still being able to easily change, say, the border-radius of all buttons at once?

The various solutions I tried so far all have drawbacks and I cannot settle on one. Here is what I tried so far:

1. Copy-pasting the class list on each element. This works, but is cumbersome. I cannot quickly prototype by changing the style of all buttons at once (which defeats one of the main advantages of the lib), as I'll have to edit them all one by one. I also take the risk of forgetting one somewhere.
2. Using a templating language in my HTML to include a partial that contains the whole HTML element with the correct classes already applied. Something like =partial('button'). This adds a new layer of complexity (especially if I want to add other classes to that element).
3. Adding a new .button class with old-school CSS definitions. I then lose the whole scaling system as I'm back writing width and font-size in px or rem again.
4. Adding a new .button class just like above, but using SCSS and @extend .link to inherit from the .link class. This is the approach I like the best so far, but I've run into specificity issues induced by the order in which CSS classes are written preventing me from overwriting properties with new Tachyons CSS classes added on the element.

How do you do on your own projects?

I followed the useful video guide, Tachyons - Setting up a new project, and I've hit a problem.

When I run npm start it fails at:

npm run build:watch

Further down it tells me:

Error: ENOENT: no such file or directory, stat 'C:\***\tachyons\run' at Error (native)

I've the latest (stable) versions of node and npm installed. Is this a genuine bug or have I missed something embarrassingly obvious?

Creating an issue to track our discussion in Slack. I will continue to update this issue as more ideas arise.

Pros

• We can release new type scale addons that are a collection of variables
• Adds more configurability without writing new CSS
• Fallbacks keep things clean var(--some-var, 4rem);

Cons

• Complexity
• More difficult for beginners
• Opinionated is sometimes good, configuration can snowball out of control easily
• Other frameworks have had issues maintaining variables

Related Reading

• http://jxnblk.com/writing/posts/rethinking-variables-in-css/

I think it would be a great addition if Tachyons had the class:

.hover-b--{color}

Is there a reason for not including this?

My use case is to make a button to change its border color on hover.

Updating seanoshea.me from http to https after a redesign. Even though the HTML doesn't include tachyons classes directly, it relies on tachyons in sass placeholder selector format, which then @extend semantic class names using gulp-sass-extend-shorthand. See the main.scss file in the project repo.

Changes

• adds row-gap and column-gap to gap.css

Motivation

Having row and column gap classes are very useful for flexbox layouts. Currently there is support for changing row and column gap together but not separately which felt like an oversight. 🙂

Change

• reverts the v/h to y/x spacing notation change (back to ph2 or mv3 for example).

Motivation

• how v4 handles spacing works well
• the x and y are confusing
  • e.g. px3 doesn't have anything to do with pixels which, even for the initiated, is confusing

• fixes inline docs with -ns or -n instead of -s
• fixes some small styles that were incorrectly suffixed with -ns
• removes * from .cf { *zoom: 1; }
  • * was a typo in original blog about the clearfix hack

hi guys, i was having a look at the components and noticed that images are missing from the demo at least on these pages below. can someone confirm?

https://tachyons.io/components/marketing/iphone-app/index.html https://tachyons.io/components/layout/flag-object-collapse/index.html https://tachyons.io/components/layout/four-column-collapse-two/index.html https://tachyons.io/components/layout/flag-object/index.html https://tachyons.io/components/layout/flag-object-top/index.html https://tachyons.io/components/layout/flag-object-bottom/index.html

screenshot :

dev tools return a 404 as shown.