Adding utility classes for Clamp(), Max) & Min() in tailwind CSS.

[itse4elhaam]

I believe that Tailwind CSS can benefit from the addition of new classes that use clamp(), min(), and max() functions. These functions can provide more flexibility and efficiency in implementing responsive designs for typography, padding, and containers.

1. clamp(): This function allows you to set a range of values for a property, and the browser will choose the best value based on the context. Here are some specific examples of how it could be used in Tailwind CSS:

/* Define a font size that scales between 16px and 24px */
.text {
  font-size: clamp(16px, 2vw, 24px);
}


/* Define a container width that scales between 640px and 960px */
.container {
  width: clamp(640px, 80vw, 960px);
}

/* Define a minimum and maximum padding for a box */
.box {
  padding: clamp(10px, 5%, 20px);
}

2. min(): This function allows you to set a minimum value for a property. Here are some specific examples of how it could be used in Tailwind CSS:

/* Set a minimum padding of 20px */
.box {
  padding: min(20px, 5%);
}

/* Set a minimum width for a button */
.btn {
  min-width: min(200px, 50%);
}

3. max(): This function allows you to set a maximum value for a property. Here are some specific examples of how it could be used in Tailwind CSS:

/* Set a maximum line height of 1.5 */
.text {
  line-height: max(1.5, 120%);
}

/* Set a maximum width for an image */
.img {
  max-width: max(400px, 80%);
}

By using clamp(), min(), and max(), you can achieve responsive designs more efficiently and with fewer lines of code. For example, consider the following code without these functions:

.text {
  font-size: 16px;
}

@media (min-width: 640px) {
  .text {
    font-size: calc(16px + ((100vw - 640px) / 20));
  }
}

@media (min-width: 1024px) {
  .text {
    font-size: 24px;
  }
}

By using clamp(), you can achieve the same result with a single line of code:

.text {
  font-size: clamp(16px, 2vw, 24px);
}

In conclusion, the addition of clamp(), min(), and max() functions to Tailwind CSS can provide a more streamlined and effective approach to implementing responsive designs for typography, padding, and containers. By including these new classes, Tailwind CSS can stay at the forefront of CSS development and continue to meet the needs of developers in an ever-evolving web development landscape.

[alekspanteli]

That is a very good idea!

[adamwathan]

Hey! Any ideas on APIs for this that would be better than what you can currently do with arbitrary values?

text-[clamp(16px,2vw,24px)]

[itse4elhaam]

It works but the naming convention is an issue. Secondly, it would be far better if they were added to Tailwind as utility classes.
More Coders will be encouraged to use it.

We can make something like text-clamp-1 => (16px 2vw, 24px) and increment it accordingly.
Just like it goes with shadow-md, shadow-lg, and shadow-xl.

[ethernal]

@adamwathan regarding your question

What’s wrong with the syntax I shared above, which currently works?

The only thing I would love to see (as someone who wants to start using TW for real) is documentation explaining how to use it. Or better support for space inside these functions. Mine was failing due to me using spaces in arbitrary values. It's not obvious in the beginning.

[mhsnook]

Hey! Any ideas on APIs for this that would be better than what you can currently do with arbitrary values?

text-[clamp(16px,2vw,24px)]

@adamwathan I came here looking for exactly this syntax, thank you! But I do want to approach the question:

tl;dr: I'd like clamp to look a bit like the gradient utilities: from-sm:gap-8 to-lg:gap-16

For me what's difficult about clamp I think is not the syntax (you're doing great, TailwindCSS) but the mental model of clamp itself. Say I want to add some padding or a gap that's at least 2rem on small devices and at most 3.5rem on larger ones; okay great -- now I have to get out the calculater app to calculate what percent of 600px is 2rem and then with that %-age how wide will the screen/container/div be when it hits the upper limit and does that seem right to me or do I want to open up google sheets and do some f(x) = mx+b stuff over here 🤔

It's a pretty big mental hoop to jump through, and it means that my clamp statements are hitting their maxes and mins at different points from one another all through my site, and things are growing and shrinking at different rates, which isn't so bad with the reliably fluid values that clamp ensures, but feels like I'm taking a big leap of faith here, not actually knowing at any given moment which of my clamps is being governed by which values.

But it occurs to me that the way I want to define clamps is kind of similar to how tw deals with color gradients, (and how you have the via-other-color and from-30% and to-80% so we can control how gradual the transition is). This is easier for me to reason about, and it's progressively-detailed (I don't need to add the to-xx% and from-yy% or the via- midpoint). So I imagine what I really want is something like...

from-sm:gap-8 to-lg:gap-16 or (because I am loving container queries these days) @from-sm:gap-8 @to-xl:gap-16

And somehow I would like to be able to refer to my immediate parent element too (because clamp makes working with a simple % so nice), either with arbitrary sizes or with the same size-categories the container queries use, e.g. idk maybe:

-from-[600px]:gap-8 -to-[1000px]:gap-14 or -from-sm:gap-8 -to-[800px]:gap-14

(I know there's no parent-query for when a parent div is a certain size but these values wouldn't be going into the CSS; they'd be used by the compiler to figure out what mx+b expression to use for the middle value to it meets the min and max at the appropriate points.) You could even use the same gradient via- syntax, like this:

from-sm:gap-8 via-lg:gap-16 to-4xl:gap-20

This would set a gap that would grow pretty quickly from small to large breakpoint, and then very slowly after that. A bit like the gradient syntax: from-blue-200 via-blue-600 to-blue-700 changes more toward the beginning than it does toward the end. I often want to size content areas like this, with e.g. clamp(96%, ???, 720px) or from-sm:width-[96%] to-lg:width-[720px]. In this case the units aren't the same but I think you could still compute the equation needed to meet both ends.

Perhaps for someone like me, a useful thing aside from this magical clamp syntax would something with intellisense so I could hover over my xl:gap-24 and have it say "this is 6 rem (96px) when the device is 1024px, which is 9.375vw" -- then I would probably write the class, do the hover, and then use gap-[min(6rem,9.375vw)] or gap-[clamp(4rem,9.375vw,6rem)]. This would help!! But it still wouldn't get me the consistency I'm looking for, because I won't know for any given element/clamp expression when/at what width the min value is kicking in vs when the middle expression is being used.

Edit: If you're using values like REM and CH where you don't know their pixel value at compile time, you can still compute the middle equation!, e.g. from-[20ch]:px-[1ch] to-[60ch]:px-[4ch] -- even with pixel-less CH units you know this thing has to grow by 3ch over the course of 20ch expansion, so the equation would become clamp(1ch, 7.5vw - 0.5ch, 3ch) -- even if I don't know how big the client's character height will be! neato.

[mhsnook]

Upon further reading: It looks like fluid.tw has already done a lot of this work! I think their syntax is maybe a little too automagical (~p-6/10 -- what? and looks like this would break the line-height suffix, like text-base/8). That said, they do offer a more explicit format ~md/xl:~text-base/2xl which in the gradient-style form (above comment) would be from-md:text-base to-xl:text-2xl. I think the gradient-looking one is nicer but I will probably give fluid a try and see -- maybe I'll change my mind!

But with fluid's syntax as a prompt, if you wanted to have site-wide defaults for maxes and mins you could always do something suuuuuper simple like: text-sm--2xl -- so the -- is sort of letting me know "there's a gap here; tailwind will fill it in with a clamp expression." Or maybe I want to revisit my original suggestion even with explicit breakpoints and say: text-sm:base--lg:2xl. Or still use the gradient-style syntax but with site-wide maxes and mins and write from:text-sm to:text-xl.

That is very slick, and pretty explicit. I think with this syntax I would use this stuff all over the place and never look back. And because it would have to enforce rules about length calculability (or at least comparability to the breakpoint units) the compiler could also add fallbacks for the middle range which are halfway in between.

For a very different kind of explicit-ness, you could do something even dumpier and have it be: max-sm:text-base--lg:text-xl -- in this final example, the two strings on either side of the double-dash are both valid, complete tailwind classes that mean exactly the same thing as the resulting clamp for the above- and below- breakpoints, which obviously has some benefits!

After all this I still prefer the using this gradient approach and don't mind that it requires us to learn that we are doing something new, because we are doing something new. So my final answer is, I think the ideal clamp API would be to set top and bottom breakpoint sizes in tailwind config, and then write from:gap-4 to:gap-8, or to provide custom breakpoints like from-sm:gap-4 to-lg:gap-8. Either way, I've now given you some 4 or 5 different answers but they are all the same: the ideal API would just ask us for 2 breakpoints and 2 lengths, and calculate the middle expression for us.

p.s. it's also possible that a technique like this one could allow the use of length values that can't be known or compared at compile-time (headsup @barvian), but I can't quite verify that confidently and have hit my limit for clamp-thinking today. Time to go write some of my own code, and give fluid a try!

[razaanstha]

I created something called fluid-clamp a while ago as it was really hard to maintain a lot of values like these "text-[clamp(16px,2vw,24px)]" in lots of components. I also used to use a lot of values from vw calculation tools to keep things precise so it scales between those specific sizes as possible and the values were sometime too long and getting out of hand and hard to maintain.

I've been using fluid-clamp in a lot of my projects to remove the complexity by adding just the min and max values removing the mid values with just text-[clamp(2rem,@fluid(),4rem)] and the best thing is it works with all the spacing properties like padding, font size, margin, insets and so. Its postcss based package but it would be really helpful to know if we have something that eases this natively in Tailwind 4.0?

[razaanstha]

The syntax should look something like this: fluid.tw

[yairEO]

why? its not an ideal syntax. it was just a temporary hack.
I'm sure there is a better syntax still

[yairEO]

Adding some good use-cases examples:

https://www.smashingmagazine.com/2024/10/css-min-all-the-things/?ref=dailydev

[dvzrd]

Revisiting this discussion for v4. Has anyone tried fluid-tailwind plugin with latest version? I'm not sure I like the syntax since it abstracts the existing utility class values. As pointed out above, ~p-6/10 is confusing and suggests a modified ratio value rather than a scale.

Seems like this feature would make the most sense being a custom variant that can be used on top of existing utilities (i.e. fs:p-4, fs:text-md, fs:border-2, etc). Anyone tried to solve this with css or is this use case too complicated for a pure css solution?

For example, here's a basic fluid scale function mapped to a variable:

@layer properties {
  :root {
    --fs-min-w: 30rem;     /* 480px minimum viewport width */
    --fs-max-w: 160rem;    /* 2560px maximum viewport width */
    --fs-min-fs: 1.375rem; /* 22px minimum font size */
    --fs-max-fs: 2.75rem;  /* 44px maximum font size */
    --fs-min-ts: 1.2;      /* 1.2 minimum type scale */
    --fs-max-ts: 1.25;     /* 1.25 maximum type scale */
  }
}

@theme inline {
   --spacing-fs: clamp(
      var(--fs-min-fs),
      calc(
        /* Base rem value */
        var(--fs-min-fs) + 
        /* Viewport width percentage */
        ((var(--fs-max-fs) - var(--fs-min-fs)) / (var(--fs-max-w) - var(--fs-min-w))) * 100vw
      ),
      var(--fs-max-fs)
    );
  }

I think the viewport width formula needs to be developed further to account for edge cases (i.e negative numbers, etc). Adding some variety to exclude font sizes and type scales would help with that. Making this work with existing utilities is what I'm not sure about because the docs don't really provide much details about creating complex utilities and variants. From what I understand so far, I would need to override the --spacing variable with a clamp calc using existing modifiers and values for spacing, borders, gap, text, etc (anything that uses px or rem values). I just don't know if --value and --modifier is available inside @custom-variant or only inside @utility

For example, take this variant:

@custom-variant fs {
  --spacing: var(--spacing-fs);

  @slot;
}

Can I nest other functions inside to override some of the utils? (i.e. reduce the scale for borders, using type scale and font sizes for text, etc).

Something like this for example (pretty sure this is wrong):

@custom-variant fs {
  @utility border-* {
    --fs-min-fs: calc(--modifier(number) - var(--spacing, 0.25rem));
    --fs-max-fs: calc(--modifier(number) + var(--spacing, 0.25rem));
    --spacing-fs: clamp(
      var(--fs-min-fs),
      calc(
        /* Base rem value */
        var(--fs-min-fs) + 
        /* Viewport width percentage */
        ((var(--fs-max-fs) - var(--fs-min-fs)) / (var(--fs-max-w) - var(--fs-min-w))) * 100vw
      ),
      var(--fs-max-fs)
    );
    border-width: --value(--spacing-fs, --spacing-*, [*]);
  }

  --spacing: var(--spacing-fs);

  @slot;
}

Any thoughts on the best path forward for a css solution or does it make more sense to stick to js for something like this?

---

I based the clamp function on this fluid type scale calculator: https://utopia.fyi/type/calculator/?c=480,22,1.2,2560,44,1.25,5,2,&s=0.75|0.5|0.25,1.5|2|3|4|6,s-l&g=s,l,xl,12
For non-text spacing, the function can be a lot simpler since font sizes and type scale would not be needed for most spacing utils.

[yairEO]

fluid-tailwind doesn't work on TW v4: barvian/fluid-tailwind#66

[wongjn]

I don't think variants is the right approach, as they are more for modifying the selector. Think :hover, :focus, @media etc. Whereas here, the clamp() values all go into a property's value. Really, we'd have a system for more "parameters", such as how gradients or filters work. This means that it would need to be spread out over several class names. See #17275 (comment) for an example of something I cooked up before.

[dvzrd]

@wongjn That makes sense, and that example helps. I think I can use the modifier to change the scale or skip steps in the scale instead of setting the breakpoints as long as I preset the breakpoints in the --spacing-fs clamp variable. That way I can use a single utility to set a clamp value instead of 2

By the way, can you explain how modifiers work? There's different types of modifiers such as number, integer, ratio, percentage but how does @utility detect each type?

For example, if I have a color variable with a number (i.e. --color-base-1), does the utility consider the 1 as an integer modifier? Im guessing using something like --p-4.5, the .5 would be a number modifier and 4 the vaue or is 4.5 the value and theres no modifier?

From what Im understanding, hyphens (-) and (/) in the utility namespace separates values from modifiers from the class (i.e. color, spacing)

How would ratio and percentage modifiers work exactly? Does it depend on which utility you're using? Are modifiers only restricted to numerals for custom utilities or can you use a color as a modifier?

---

For example, take this utility to set full box colors:

@utility box-color-* {
  --alpha: calc(--modifier(integer, number) * 1%);
  border-color: --alpha(--value(--color-*-foreground, [*]) / 20%);
  background-color: --alpha(--value(--color-*, [*]) / var(--alpha, 100%));
  color: --value(--color-*-foreground);
}

There's a few edge cases where this wouldn't work if you don't have the proper variables set in your theme (i.e. primary-foreground). For that I can create some fallbacks so thats alright. However, the problem is when there's a scale of colors (i.e. base-1, base-2, etc), then it tries to set the foreground color as base-1-foreground. Is there a good way to handle this edge case with existing --modifier functions or would I need to create a custom color variable for box (i.e. --color-box, --color-box-border, --color-box-foreground) to control each one separately?

Seems like only theme variables are available inside a functional @utility, is that true or is it any variable as long as its defined before the utility layer? Where can I find all the available tailwind variables in the source code? For example, border utility responds to --border-width-*, does it also have --border-color-*?

[wongjn]

can you explain how modifiers work?

See the documentation: https://tailwindcss.com/docs/adding-custom-styles#modifiers

There's different types of modifiers such as number, integer, ratio, percentage but how does @utility detect each type?

There's built-in heuristics in Tailwind's class name scanner that detects the type.

For example, if I have a color variable with a number (i.e. --color-base-1), does the utility consider the 1 as an integer modifier? Im guessing using something like --p-4.5, the .5 would be a number modifier and 4 the vaue?

There is no modifier here. The modifier is the portion after the slash (/) on a class name. For example, for text-red-500/20, the modifier is 20.

How would ratio and percentage modifiers work exactly?

However you want them to work in the custom utility. The value is substituted as-is into the --modifier() location.

Does it depend on which utility you're using?

Yes.

Are modifiers only restricted to numerals for custom utilities or can you use a color as a modifier?

A color can be used as a modifier: https://play.tailwindcss.com/nh9NP5eUv2?file=css

[dvzrd]

Wanted to leave an update based on what was discussed above. Thanks for helping out again @wongjn, really appreciate it.

First, here's a fluid typescale utility using clamp for font sizes:

/* @example - <p class="ts-16/20">fluid typescale text</p> */
@utility ts-* {
  --min: --value(integer, number);
  --max: --modifier(integer, number);
  --min-ts: 1.25;
  --max-ts: 1.333;
  --min-vp: 480; /* 30rem */
  --max-vp: 2560; /* 160rem */
  
  /* Calculate the fluid typescale */
  --scale-diff: calc(var(--max-ts) - var(--min-ts));
  --vp-diff: calc(var(--max-vp) - var(--min-vp));
  
  /* Calculate the viewport unit multiplier */
  --vi-multiplier: calc((var(--max) - var(--min)) / var(--vp-diff));
  
  /* Calculate the base offset */
  --base-offset: calc(var(--min) - (var(--vi-multiplier) * var(--min-vp)));
  
  /* Calculate font sizes in rem */
  --min-font-size: calc(var(--min) / 16 * 1rem);
  --max-font-size: calc(var(--max) / 16 * 1rem);

  @supports (font-size: clamp(1rem, 1vi, 1rem)) {
    font-size: clamp(
      var(--min-font-size),
      calc((var(--vi-multiplier) * 100vi) + (var(--base-offset) / 16 * 1rem)),
      var(--max-font-size)
    );
  }

  @supports not (font-size: clamp(1rem, 1vi, 1rem)) {
    font-size: var(--min-font-size);

    @media screen and (min-width: var(--breakpoint-sm)) {
      font-size: calc((var(--vi-multiplier) * 640 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-md)) {
      font-size: calc((var(--vi-multiplier) * 768 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-lg)) {
      font-size: calc((var(--vi-multiplier) * 1024 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-xl)) {
      font-size: calc((var(--vi-multiplier) * 1280 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-2xl)) {
      font-size: calc((var(--vi-multiplier) * 1440 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-3xl)) {
      font-size: calc((var(--vi-multiplier) * 1520 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-4xl)) {
      font-size: calc((var(--vi-multiplier) * 1680 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-5xl)) {
      font-size: calc((var(--vi-multiplier) * 1920 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-6xl)) {
      font-size: calc((var(--vi-multiplier) * 2240 + var(--base-offset)) / 16 * 1rem);
    }

    @media screen and (min-width: var(--breakpoint-7xl)) {
      font-size: var(--max-font-size);
    }
  }
}

I added some fallbacks based on the breakpoint settings I have in my theme (didn't test it though). Some limitations I ran into with css calc was needing to hardcode the min max viewport vars, I couldn't reuse the --breakpoint vars from theme because calc needed a number value to calculate the viewport difference.

I think it's a good start, but it could be a lot better if it also worked with existing text utilities. I'll come back to it later when I have a use case. There's a limit to how can be done with just a single modifier in css.

Also, here's a box color utility I came up with in case someone was interested, since it was brought up in this discussion.

/* @example: <div class="box-color-yellow-500/black border p-4">black and yellow box</div> */
@utility box-color-* {
  --alpha: calc(--modifier(integer, number) * 1%);
  --color: --value(--color-*, [*]);
  --color: --modifier(--color-*, [*]);
  border-color: --alpha(oklch(from --value(--color-*, [*]) calc(l * 0.8) c h) / var(--alpha, 100%));
  background-color: --alpha(--value(--color-*, [*]) / var(--alpha, 100%));
  color: oklch(from var(--color) calc(l + (100% + l) / 2) c h);
  color: --value(--color-*-foreground);
  color: --modifier(--color-*, color, [*]);
}