[FEATURE] Presets for fluid types and spacing

[oemer-aran]

In order to build meaningful design systems it is desired to limit the options a developer can choose from.

Example: Instead of having to write ~text-xl/3xl or ~pt-3/6 it is more desired to have presets like ~text-h1 and ~pt-sm. Alternatively "shorthands" with just one value instead of start and end values could make also sense.
E.g:

• ~text-xl : Will produce same as ~text-xl/3xl)
• ~pt-3: Will produce same as ~pt-3/6

Proposed API to add Presets:

export default {
  // ...
  theme: {
    // ...
    fluid: ({ theme }) => ({
      presets: {
        fontSize: {
          // array describes start and end values
          xl: [theme("fontSize.xl"), theme("fontSize.3xl")],
        },
        spacing: {
          3: [theme("spacing.3"), theme("spacing.6")],
        },
      },
    }),
  },
  plugins: [fluid({})],
};

It would be nice to have some great defaults for this as well.
Do you think something this is possible or too complex?

I love this library and it's probaby is the best when it comes to fluid types and spacing in tailwind. I think this feature can make it even more awesome.

Tailwind Utopia is doing something similar with: fl-text-xl

Current undesired solution

For typography it works kind of good with @apply:

@layer utilities {
  // can't use ~ in css class names
  .text-h1 {
    @apply ~text-xl/3xl;
  }
}

But for spacing it will be very cumbersome, since you have to define it for all possible spacing attributes like padding, margin, gap, etc. And using @apply is generally highly discouraged.

[barvian]

Hey, thanks for the write-up. I thought about adding this a while back but I decided against it for a few reasons:

1. It feels a little out of scope. The normal Tailwind recommendations that would apply to non-fluid approaches i.e. text-xl lg:text-3xl (including the @apply approach you mentioned) also apply here
2. It's ambiguous. If you have a DEFAULT value in your theme, something like ~text-2xl could mean ~text-2xl/DEFAULT or the 2xl fluid preset.
3. It's dependent on fluid utilities being expressed in one class i.e. ~text-2xl/3xl. I might need/want to break up the classes for Tailwind v4.

I'm curious to hear your thoughts 👋

[oemer-aran]

Thank you for the quick response!

1. It feels a little out of scope. The normal Tailwind recommendations that would apply to non-fluid approaches i.e. text-xl lg:text-3xl (including the @apply approach you mentioned) also apply here

I get your point. And I agree with the docs here actually. But I think the fluid classes should not be compared to the static classes from default tailwind. So instead of comparing ~text-xl/3xl with text-3xl lg:3xl, I would compare it to something like colors:

• ~text-xl can be compared to text-red-500
• ~text-xl/3xl can be compared to text-red-500/50

So instead of treating the end part as mandatory, it makes sense to have sensible defaults sometimes. I know for colors it's an obvious choice to use opacity: 1 as the default, but imagine you would always have to write text-red-500/100.

2. It's ambiguous. If you have a DEFAULT value in your theme, something like ~text-2xl could mean ~text-2xl/DEFAULT or the 2xl fluid preset.

Does it even make sense to have DEFAULT for a typography? Tailwind is using text-base, so it's always named and there is no DEFAULT. I am not sure if this is a relevant scenario?

In contrary: For colors DEFAULT it makes sense, since you have a base structure consisting of two values: {color}-{shade}, e.g. red-100, red-200, red-300 etc. But for Typographies you only have 1 base value, which is the name of the typography, like base, xl etc.

3. It's dependent on fluid utilities being expressed in one class i.e. ~text-2xl/3xl. I might need/want to break up the classes for Tailwind v4.

Not sure what exactly will change in Tailwind v4, but by "break up the classes" do you mean something like ~text-start-xl ~text-end-3xl? I can understand your desire to have a really flexible system, and I am totally in favor of that. That's why we all love tailwind so much.

Conclusion

Hope I could bring accross my points well! If you think presets are not possible to implement without paying in flexibility, I would also dismiss this feature request. In my naive view I think you can build the presets on top of the flexible base system and also on library-level, using previously mentioned propsed API. Maybe not with existing typographies like xl but my-h1 or my-h2. Same for the spacing classes.

To go even further (and out of scope): Fluid classes would be more like a replacement instead of an addition to the current system. I would prefer that fluid classes become the default with pt-1 and if you need static values you would have to do something like pt-fixed-1. Fluid will be the future IMO. It makes much more sense than breakpoint insanity.