Feature Request: Custom class names

[Dobby89]

Is it possible to provide a way to override the various class name definitions for each property?

For example, I'd like to use:
.font-colour-black instead of .text-black
.line-height-none instead of .leading-none

I imagine you could have a new object in the configuration file which could look something like below, which would override the default class name prefixes.

classPropertyPrefixes: {
    'text': 'font-colour',
    'leading': 'line-height'
},

UPDATE 6th Nov 2017: Maybe adopt the naming convention used by Emmet https://docs.emmet.io/cheat-sheet (scroll down to the CSS section)?

[dumconstantin]

This is just what I was thinking today when considering to migrate from tachyons to tailwind.

I've grown accustomend to the terse syntax and would like to use lh instead of leading or black instead of text-black.

One of the things that I liked about this approach is that you remove an extra step in getting what you want e.g. I'm not writing css anymore with property and value, I'm just focusing on getting the value at the htm endpoint.

However, as much as I'd like this, I'd vote against it either as a feature or encouraged by tailwind.

Tailwind made some design decision when choosing this API and should work towards enforcing it and giving rationale for why this is ths middle point between overspecifying and cryptic language.

Besides this point, there's an obvious misalignment that's bound to happen with the documentation making the developer and teams experience sour.

To conclude, I think this feature isn't such a good idea and its best to adjust to the new syntax or to suggest specific changes to the API to shape it towards its ideal form.

[Dobby89]

@dumconstantin I agree with the potential issues caused by differences between the official docs and a custom implementation.

Class naming schemes is always going to be opinionated. I personally favour more verbose class names, but I would be happy to follow a more well established convention such as https://docs.emmet.io/cheat-sheet (scroll down to the CSS section). At least then, there's a standard can be followed for future class names.

[MichaelDeBoey]

I totally agree with @dumconstantin's conclusion, but I can also see why this feature could be useful for some people.

If I had to vote I'd vote for @dumconstantin conclusion for sure 🙂

[adamwathan]

We thought really hard about this during the many arguments we had about naming some of the core classes, but ultimately decided to say no to this, at least for now, for a couple of reasons:

1. As mentioned above, the documentation wouldn't be accurate anymore for any teams who customize the class names and that would be frustrating.

2. Moving between Tailwind projects would be more difficult, since the naming could change so drastically. This is already a bit of a problem because of how customizable the suffixes are for classes that have modifiers (like font weights, font families, text sizes, and a million other things), and supporting completely customizing the class names would really take it over the edge. Despite how customizable Tailwind is designed to be, I still want to enforce some degree of opinion and consistency between projects, otherwise it's not really a framework anymore.

With the current naming scheme, we tried really hard to strike a balance between being terse when possible, but also clear and unintimidating. I think there's a lot of people out there who are comfortable with frameworks like Bootstrap, Foundation, or Bulma (myself included) who feel the pains of trying to customize highly opinionated frameworks like that but are really put-off by the learning curve of cryptic naming schemes used by tools like ACSS or Tachyons. We want Tailwind to feel welcoming to those people and be pretty easy to understand without having to learn a whole VIM-like layer of shortcuts on top of CSS, so keeping things a bit more verbose feels like the right choice.

That said, I still think this is something we can reconsider down the road, but it's a super low priority topic right now and I definitely wouldn't want to support it before we are able to do fancy things like documentation generation from someone's config file.

[dumconstantin]

An update on this.

I tried for the past month to adapt to Tailwind's naming scheme coming from a Tachyons background. It's been nice but I miss the terse syntax which, for whatever reason, comes more natural to me.

So I tried tonight to recreate the Tachyons naming schema using Tailwind as a generator and it seems to be working fine.

Basically I've defined the naming schema in defaultConfig.stub.js
https://github.com/dumconstantin/tailwindcss/blob/d66adfe0cb345f7a8a15e709fcef5f576bcd4c0b/defaultConfig.stub.js#L877

This is then referenced in the class generators and replaces the hard coded versions. There's no impact on the Tailwind API whatsoever but brings about more flexibility.

Is this something you might pursue? If so, I can help in getting the test suite up-to-date with this feature.

[teddybradford]

I would love having something like what @dumconstantin proposed as part of Tailwind. It would make transitioning a project from an existing utility framework (or no framework) to Tailwind much, much easier.

[chrisdmacrae]

Weighing in on someone working on a huge government project. I want Tailwind, but can't use it because our existing framework has utilities with a convention already.

Would love to be able to make Tailwind match this convention, so I could plug it into the project and extend and override our utilities programmatically.

I believe an alias-based approach would alleviate both of your concerns -- let us provide templates for creating aliases for the default utilities, so that margin for example would become:

.mt-0,
.margn-top-0 {
  margin-top: 0;
}

This, coupled with PurgeCSS, would lead to just as lean CSS, but would provide teams with the flexibility they need.

[pixelastic]

Adding my voice here as well. Coming from a Tachyons and Vim background I really like the terse syntax, it helps keep me in "the zone" when writing the CSS. Longer class names are more error-prone when typing.

I didn't feel like the Tailwind naming convention was either easier/harder to learn than the tachyons' one.

I've always seen Tailwind as a utility generator, not a utility framework in that it allows me to define my own colors and scales and I would expect it to also allow me to override some of the naming convention to fit existing conventions one project might have.

I also understand that this might reduce the benefit of having one set of classes you can remember and re-use on other projects, but if there would be a way to generate documentation/styleguides based on those configurations, that would be perfect.

[adamwathan]

You can actually do this now with the plugin system by disabling an existing module and adding your own plugin that generates the same styles using a different naming convention.

Here's an example of a Tailwind config file that replaces all of the default margin utilities with Tachyons-style naming:

let tailwindConfig = require('tailwindcss/defaultConfig')()

tailwindConfig.modules.margin = false

tailwindConfig.plugins.push(({ addUtilities, config }) => {
  const utilities = Object.keys(config('margin')).map((k) => {
    return {
      [`.ma${k}`]: {
        marginTop: config('margin')[k],
        marginRight: config('margin')[k],
        marginBottom: config('margin')[k],
        marginLeft: config('margin')[k],
      },
      [`.mv${k}`]: {
        marginTop: config('margin')[k],
        marginBottom: config('margin')[k],
      },
      [`.mh${k}`]: {
        marginRight: config('margin')[k],
        marginLeft: config('margin')[k],
      },
      [`.mt${k}`]: {
        marginTop: config('margin')[k],
      },
      [`.mr${k}`]: {
        marginRight: config('margin')[k],
      },
      [`.mb${k}`]: {
        marginBottom: config('margin')[k],
      },
      [`.ml${k}`]: {
        marginLeft: config('margin')[k],
      },
    }
  })

  addUtilities(utilities)
})

module.exports = tailwindConfig

You could totally write a Tachyons plugin for Tailwind that disables all of the built-in modules and just uses Tailwind as a generator for the Tachyons classes.

Your tailwind.js file would end up looking like this:

module.exports = require('tailwindcss-tachyons')({
  margin: { ... },
  padding: { ... },
  heights: { ... },
  // Etc.
})

It's obviously a non-trivial amount of work to do this but that's the only way to do it right now. No concrete plans to support this any other way at the moment; again not entirely opposed to it, just not committing to it now.

[pixelastic]

Thanks, that's pretty useful actually and is definitely powerful enough for my use-cases!