[Feedback Requested] Renaming the leading and tracking utilities

[adamwathan]

Following up on the discussions in #664 and #665, I wanted to create a separate thread to get feedback on the overall idea and the motivation behind it.

One of the big problems I'm trying to solve for Tailwind 1.0 is that I want the core plugin names to be as consistent as possible as well as as guessable/intuitive as possible. You can see a bunch of the work I have done towards that in this pull request: #656

The framework behind the new core plugin naming is:

1. Use singular terminology, not plural. It should be "the border color plugin", not "the border colors plugin".
2. Match the CSS terminology unless there's a really good reason not to. That's why the "text sizes" plugin is now the "font size" plugin, but "text colors" is "text color" since "color" could be confusing alongside the existing "colors" key that defines your entire color palette.

I hate that in Tailwind 0.x some things are plural, some are singular, some match CSS, and some don't. It feels like there is no naming system at all, just a hodge podge of random bullshit.

For this reason, I really want to rename the leading and tracking plugins to lineHeight and letterSpacing respectively.

Now to clarify, the plugin name is the key you use to customize the values for a utility in both the theme (root level in 0.x), variant (modules in 0.x), and corePlugins (n/a in 0.x) sections of your config file.

That is to say that in this example config (1.x format)...

module.exports = {
  theme: {
    opacity: {
      '0': '0',
      '50': '.5',
      '100': '1',
    },
  },
  variants: {
    backgroundSize: ['responsive'],
  },
  corePlugins: {
    objectFit: false,
  }
}

...opacity, backgroundSize, and objectFit are examples of plugin names.

On to the challenging part...

I really want the keys in the theme section to be plugin names, so that they are the same keys you would use in the variants and corePlugins sections.

Put another way, I don't want users to customize their fonts by changing theme.fonts but change which font family variants are generated by changing variants.fontFamily.

That's why in 1.x, fonts are specified in theme.fontFamily, even though fonts might feel like a more natural name for that key in that particular context:

// 🚫 Bad, fonts and fontFamily are used by the same
// plugin but it's not obvious or explicit

module.exports = {
  theme: {
    fonts: {
      heading: { ... },
      body: { ... },
    },
  },
  variants: {
    fontFamily: ['responsive'],
  },
}


// ✅ Good, both sections use the same key so the relationship is clear

module.exports = {
  theme: {
    fontFamily: {
      heading: { ... },
      body: { ... },
    },
  },
  variants: {
    fontFamily: ['responsive'],
  },
}

However, something feels extremely crappy about customizing the leading-* and tracking-* classes under lineHeight and letterSpacing keys:

module.exports = {
  theme: {
    // 🚫 Unintuitive if class name is `leading-*`
    lineHeight: {
      none: '0',
      copy: '1.5',
      heading: '1.25',
    },

    // 🚫 Unintuitive if class name is `tracking-*`
    letterSpacing: {
      none: '0',
      copy: '1.5',
      heading: '1.25',
    },
  },
  variants: {
    lineHeight: ['responsive'],
    letterSpacing: ['responsive'],
  },
}

If you have already learned to type class names like leading-tight in your HTML and come to your config file to tweak or add a new value, my gut feeling is that you are much more likely to try adding a leading key to your theme than you are a lineHeight key. This is magnified by the fact that in 1.0, your config file will be empty by default, and you will have to add the lineHeight key by hand the first time you want to customize it.

However, if leading-tight was something like lh-tight or lines-tight, it seems a lot less unintuitive that changes should be made under a lineHeight key rather than a leading key.

So here are the questions I have...

(I'm using leading/line-height for all of these examples, but all of this applies equally to tracking/letter-spacing as well.)

1. Is it actually just fine for a plugin name to be completely different from the class names it generates?

   Is it really a problem that to add new leading-* classes you need to customize the lineHeight key in your config file? Some other plugins are sort of like this already (the borderRadius plugin generates rounded-* classes, although I'm considering changing that as well).

2. Is it actually just fine for the plugin to be called leading instead of lineHeight, so we can just leave everything as-is?

   What if the keys to control variants and values for line-height are leading to match the class name? Is that really weird? It breaks rule Update defaultConfig.js #2 of the naming convention for plugins which is to match CSS unless there's a really good reason not to, but maybe that's not the end of the world? My fear with doing that is that it sets a precedent that plugin names are just picked based on what feels best instead of having any sort of guessable convention, which I worry will make me want to re-examine all of the other existing plugin names as well.

Basically right now I see two options:

1. Rename the leading-* and tracking-* classes to something more like lh-*/lines-* and letters-*, so that using lineHeight and letterSpacing for the plugin names feels more intuitive.

2. Keep the classes as leading-* and tracking-*, but also name the plugins leading and tracking even though it breaks my plugin naming system.

Am I wrong for believing these are the two best choices? Does it make more sense to mix the leading and lineHeight terminology, where the classes are leading and the config keys are lineHeight?

Should I step back even further and re-examine whether or not the keys in theme actually have to/should match the keys in variants? Put another way, is this actually as bad of an idea as I think?

module.exports = {
  theme: {
    // Values are customized under the `fonts` key
    fonts: {
    heading: { ... },
    body: { ... },
    },
  },
  variants: {
    // Variants are customized under the `fontFamily` key
    fontFamily: ['responsive'],
  },
}

There's already a bit of asymmetry there since background colors, text colors, and border colors will be customized using the colors key 95% of the time, and padding and margin will be customized using the spacing key.

Somebody please help me 😂

[dillingham]

I think in favor of onboarding css authors to this new approach with less friction, traditional css concepts like line-height should not be renamed. I still even after reading all these discussions don’t know which is tracking or leading off the top of my head. But that may just be me 🥴

To me: line-2 | letter-3.5 | word-2 seems simplest, tethered to css, easiest to learn and remember

plugin	property	tailwind
LetterSpacing	letter-spacing	letter-1
LineHeight	line-height	line-3.5
WordSpacing	word-spacing	word-2

also singular as it may apply to a single line

[justgage]

Just a random person here, but one thought I have is that in my A/B testing plugins they would generate more than one classname (anti-pattern? maybe) and I could imagine that there's more complex examples as well. So I think the name of the plugin and the CSS classes shouldn't necicarily have to be tied, although it would be nice, so long as the names weren't too long. In the case of line-height, I think it's fine that it's shorter because it should be (please use line-height everyone) used very often.

Have you considered putting the configuration inside the plugin section as well? Like passing in arguments to the functions of the plugins? I do like the current structure but maybe this would also help with the "not sure if this config applies to this thing" problem. 🤷‍♂️

[simonhunt]

I agree with @dillingham - I like that the Tailwind classes closely match the CSS names. My experience is that using Tailwind has actually made me better/quicker at writing pure CSS. As such I'd definitely support moving over to line-height and letter-spacing as class names and also support the idea of using radius (should it be border-radius?) rather than rounded.

Is there any scope for allowing users to customise these names using aliases? So that, for example, I could change line-height to lh (or back to leading) in my config file if I wanted to?

[kevinleedrum]

I vote for lineHeight and lh-* because it is a standalone set of values for one CSS property, so it should match CSS. However, I think people will understand the need for "shared" values under one key like spacing since it's for both padding and margin. And yes, the variant keys should always match imo.

If it's a question of making breaking changes for current users vs. making changes that help new users adopt tailwind, I think the current users will forgive you because they've already seen the light.

[neilcamm]

In my opinion, developers have built up "muscle memory" from the repetition of writing traditional css, so renaming line-height to leading is just adding a mental speed bump.

[driesvints]

Now that's I've read up on these typography terms I've changed my original position and I'm now convinced we should keep the tracking and leading naming. They're the correct terms and stand exactly what they're meant for. The fact that the CSS equivalent is named differently is an implementation detail.

It doesn't matter that they're named different because people will learn and adapt. They'll come accustomed to them and not look back after a while. So I'd go with option 2. Also the least amount of work for you.

[mattdfloyd]

lineHeight and letterSpacing for the plugin names feels intuitive because they are building up a set of the corresponding css values. I like leading-* and tracking-* classes because they are implementing and describing the theme's design details.

[sandren]

I don't think we are giving Tailwind developers enough credit.

It wasn't hard for them to learn what line-height and letter-spacing mean so I don't think it should be too difficult to also learn that leading and tracking are the semantically correct terms and that the CSS working group should have, but failed to use the correct terminology.

If learning the terms "leading" and "tracking" are the steepest part of the learning curve, then Tailwind has truly achieved greatness! 😄

Based on that, my answer to both question 1 and question 2 is that "it's fine!", but I would also add that we should entertain a third option: using leading and tracking for class names and lineHeight and letterSpacing for plugin names.

There is no reason why there can't be internal consistency between class names (reflecting what the class does) and internal consistency between plugins (reflecting the CSS declarations used), but not precise consistency between the two. Forcing precise consistency between the two would only make the day-to-day workflow of Tailwind much more time consuming. No one wants to type out margin-top- instead of mt- just because the plugin name is technically margin.js.

Basically the goal of matching the CSS terminology is noble, but that doesn't mean there shouldn't be exceptions. I think leading, tracking, and rounded should be exceptions because those names more accurately reflect what the classes do. These class names are exactly what you should expect from "a utility-first CSS framework for rapid UI development."

[adamwathan]

Thanks for the feedback everyone, I've decided I'm going to keep the class names as leading-* and tracking-* but change the plugin names to lineHeight and letterSpacing.

What helped me get more comfortable with that idea was realizing that we already use "Letter Spacing" and "Line Height" as the page titles in the documentation for those classes, so really I had sort of already decided I was fine with them not mirroring the class names 😅

So this means there will be no breaking change at all in terms of your markup, you'll just have to tweak a couple of keys in your config file 🎉

[OwenMelbz]

I know this is closed, and maybe off topic so I apologize for that!

But using the plugin system can you make the prefixes configurable?

That way people can change them to what they like? I know I always get confused with “justify-between” to do a “space-between” for flex, so giving them an option to modify?

No idea how complicated, or annoying that is for you. But just a thought :)

[phegman]

Something like #11626 could potentially help engineers that are more familiar with the CSS name