A new default spacing scale

[GermanJablo]

I've been thinking about the following tweet from @adamwathan about the default spacing scale:

And I think it's a great idea.

I open this thread to propose that this can be achieved (1) without failing to provide a subset of recommended measures and (2) without causing a large breaking change.

The idea would be that p-x generates padding in rem equivalent to the amount of px that x represents. That is, if you want to have a 16px padding you should make p-16 instead of p-4. If you want to use a "strange" value you should still use square brackets (e.g. p-[17px]).

In the case of continuing to use the same current scale*, the conversion would be equivalent of putting this in your theme.spacing:

spacing: {
  '0': '0px', // instead of 0
  '1': '1px', // instead of px
  '2': '0.125rem', // instead of 0.5
  '4': '0.25rem', // instead of 1
  '6': '0.375rem', // instead of 1.5
  '8': '0.5rem', // instead of 2
  '10': '0.625rem', // instead of 2.5
  '12': '0.75rem', // instead of 3
  '14': '0.875rem', // instead of 3.5
  '16': '1rem', // instead of 4
  '20': '1.25rem', // instead of 5
  '24': '1.5rem', // instead of 6
  '28': '1.75rem', // instead of 7
  '32': '2rem', // instead of 8
  '36': '2.25rem', // instead of 9
  '40': '2.5rem', // instead of 10
  '44': '2.75rem', // instead of 11
  '48': '3rem', // instead of 12
  '56': '3.5rem', // instead of 14
  '64': '4rem', // instead of 16
  '80': '5rem', // instead of 20
  '96': '6rem', // instead of 24
  '112': '7rem', // instead of 28
  '128': '8rem', // instead of 32
  '144': '9rem', // instead of 36
  '160': '10rem', // instead of 40
  '176': '11rem', // instead of 44
  '192': '12rem', // instead of 48
  '208': '13rem', // instead of 52
  '224': '14rem', // instead of 56
  '240': '15rem', // instead of 60
  '256': '16rem', // instead of 64
  '288': '18rem', // instead of 72
  '320': '20rem', // instead of 80
  '384': '24rem' // instead of 96
}

Responses to possible objections:

1. I want a set of recommended measurements, I don't want to have to decide between 12 or 13 pixels.

I think this is the main objection I found on Twitter.

As I mentioned, doing this wouldn't imply that you have infinite options for any length, like the [ ] brackets work. We could use a set of sizes as now without square brackets (for example: p-16), but we would require square brackets for values outside the recommended scale (for example: p-[17px]).

2. This would be a breaking change

Yes, but it could be made much milder in two ways:

1. An option could be added in the tailwind configuration to continue using the current system, so those who do not want to make the change could opt out.
2. A codegen for easier migration.

3. It is easier to choose a value that does not exist because the "gaps" or "distances" are greater.

I've been using tailwind for quite some time, and I still need to use intellisense to put valid values.

I think this argument would be more valid if the current scale had been completely 1 in 1 and without gaps (even after 12). It is 1 in 1 in the range 1-12, 2 in 2 in the range 12-16, and 4 in 4 in the range 16-96. And you're still going to need intellisense when typing the value, because I highly doubt people remember that 44 equals 176px, for example.

The current default spacing scale has the worst of both worlds, since it does not allow you to "guess" the next valid value without intelligense as it is not 1 in 1, nor does it allow you to know the value it represents without using intellisense as it is not a real representation, as I am proposing.

4. You can now do that, by overriding the spacing scale in the settings.

Yes, but that would mean using a different spacing system than the entire community. Any component in the entire ecosystem that I wanted to copy and paste wouldn't work.

Tailwind is increasingly becoming the de facto standard for styling. It would be a shame if such an important library didn't use the best spacing system simply because of the pain of the change.

Benefits:

• One could understand the code automatically without having to use hover + intellisense to know the actual size.
• *A more practical set of measures could be used. I was reading Adam's book Refactoring UI, and he talks about how spacing scaling should consider increments relative to their neighboring values. It doesn't make sense that the next recommended value after 16px is 20px (25% increase), when the next value of 240px is 256px (6.7% increase).
• AI like chatGPT are not good at math, and when you ask them to convert CSS to Tailwind they get confused because of the arbitrary spacing scale.

[GermanJablo]

A few things about the second point under the heading "Benefits."

That means that a spacing system should be a geometric progression.
Using '2' as the common ratio is very convenient since it gives us integers: 2, 4, 8, 16.... But the numbers are very spaced out.

We could use the common ratio 2^(1/4). This would make every 4 numbers have a power of 2 (very similar to the current system).
The problem with this is that we would have irrational numbers (many decimals), quite inconvenient...

So what we can do is use a common ratio of 2, and between every 2 numbers add 3 additional and equidistant numbers.

I would do this for numbers from 8 onwards since for previous numbers you do not need as many divisions with decimal numbers.

The list that remains and the one I am using is like this:

spacing: {
  '0': '0px',       // instead of 0     (2^0)
  '1': '1px',       // instead of px    (2^1)
  '2': '0.125rem',  // instead of 0.5
  '4': '0.25rem',   // instead of 1     (2^2)
  '6': '0.375rem',  // instead of 1.5
  '8': '0.5rem',    // instead of 2     (2^3)
  '10': '0.625rem', // instead of 2.5
  '12': '0.75rem',  // instead of 3
  '14': '0.875rem', // instead of 3.5
  '16': '1rem',     // instead of 4     (2^4)
  '20': '1.25rem',  // instead of 5
  '24': '1.5rem',   // instead of 6
  '28': '1.75rem',  // instead of 7
  '32': '2rem',     // instead of 8     (2^5)
  '40': '2.5rem',   // instead of 10
  '48': '3rem',     // instead of 12
  '56': '3.5rem',   // instead of 14
  '64': '4rem',     // instead of 16    (2^6)
  '80': '5rem',     // instead of 20
  '96': '6rem',     // instead of 24
  '112': '7rem',    // instead of 28
  '128': '8rem',    // instead of 32    (2^7)
  '160': '10rem',   // instead of 40
  '192': '12rem',   // instead of 48
  '224': '14rem',   // instead of 56
  '256': '16rem',   // instead of 64    (2^8)
  '288': '18rem',   // instead of 72
  '320': '20rem',   // instead of 80
  '384': '24rem'    // instead of 96
} 

which as you can see is exactly the same scale that tailwind currently has except removing the numbers 36, 44, 144, 176, 208, 240 and 288.

Those 7 values seem to be "extra", and that is the reason why inconsistencies occur like the one I mentioned that the value after 16px is 20px (25% increase), when the next value of 240px is 256px (6.7% increase) .

[adamwathan]

Thanks for the thoughtful write-up! This is definitely something I'm thinking about for Tailwind CSS v4 but that's the earliest we could do it because it would be a very significant breaking change, and even then I'm not sure the benefit would be enough to warrant the damage it would do to the ecosystem 😕 Every video, blog post, example components, etc. would all be broken/out of date immediately, which is a really serious cost even if it's how I wish the spacing scale were designed in hindsight.

Not totally out of the question though, will think through it more some time next year when v4 is closer 👍

[alex-krasikau]

v4: introduce experimental.pixelScale
v5: pixel scale by default.

Next.js gathers usage data, helping them make informed choices about transitioning to the new API. I understand the privacy concerns, but without this data, making significant changes is worrisome because it's done without clear information. Even if a poll is done on Twitter, it would only reflect the opinions of a small group of Tailwind users.

[GermanJablo]

Hey @adamwathan, seeing that v4 is approaching, I want to return to this discussion.
Have you formed any new opinions?
If you want, I can offer my help, for example programming a migration codegen, writing an explanatory release/migration article, or anything that may be useful :)

[stillingdesign]

I just started using Tailwind (coming from UniformCSS). This is my biggest gripe so far.

Some kind of "opt-in" would be nice, though being able to overwrite is fine by me for now, too! (thanks for writing all of these @GermanJablo!)

[rijk]

For reference, this is now possible in v4: https://x.com/adamwathan/status/1855592067029737512

[GermanJablo]

Yes, I saw that, but:

1. it doesn't use a subset of allowed tokens. Any value is valid.
2. it doesn't use rem, but px.
3. I personally won't use a scale other than the official one. A breaking change would affect all users, it's true. But over time it wouldn't happen that the examples in one place don't work in another.

[GermanJablo]

@adamwathan First of all, thanks for the amazing work with Tailwind v4! It is full of awesome new features. ❤️

If you'll allow me a little unsolicited feedback, there is one change that I consider a step backward:

One of Tailwind's greatest strengths has always been the restriction on spacing tokens. While it is true that I can extend or overwrite the system as I wish, the problem now is that AI tools will start to be trained with arbitrary spacing values, such as mt-27.5, since that is now an accepted default.

Having a default set of tokens offers several benefits:

• It facilitates design decision-making.
• It promotes greater visual consistency.
• It promotes fewer classes used and thus reduces the bundle size.

The pattern of using brackets for custom values was already an elegant and sufficient solution. I am not sure if this decision is still subject to change, but, if possible, I would like to suggest the following:

Keep a spacing system with no more tokens than v3.
Encourage those who need more granularity to use something like what they proposed in the blog:

@theme {
  --spacing: 0.25rem;
}

I understand that it is not always possible to satisfy all requests, but I feel it is important to highlight these points. Thank you very much for taking the time to consider it, and again, congratulations on this great release! 🚀

EDIT: I found the PR where the new change was made: #14857
according to which the reasons for the change were:

1. I personally found it very difficult to know which values actually existed at the higher end of the scale without IntelliSense

That's a fair point. But either way you can almost always use intellisense and ultimately I think it's still a tradeoff that doesn't outweigh the benefits of having a spacing system.

in practice even when working with a skilled designer like Steve who helped design Tailwind's default spacing scale, I'd very often need to break out of it to implement a design, and trying to round to a value that was in the scale made the design worse, not better.

Yes, I don't always follow the standard measurements either, but using brackets once in a while is not death. +90% of the time the v3 tokens are sufficient.

[nWacky]

I watched the design systems course by Figma

As far as I understand, tailwind provides base tokens (all colors, all spacing values, no custom typography like headline fonts, etc) and ability to generate utility classes.

Then you can build your application using those.

After a while additional things may be needed.

For example, if there is a font that can be used for headlines, it should be added to tailwind config.
Then the same font class can be reused in multiple places.

Once the app has a primary color (or multiple primary colors per section, for example), they can be added to tailwind config too.

I think the same process would have to be applied to spacers from now on.

Design tokens are like global constants in code: if a value means something and can be reused, it can be added to one place.

Tailwind config viewer can be used to view custom values from tailwind config.

GitLab pajamas has their own spacing scale.
They added classes like gl-p-0, gl-min-w-15 to their tailwind config file. (GitLab UI tailwind config viewer)

Or classes like gl-border-4, gl-border-8 for borders.

I did a quick search.
There are styled component libraries, like Shuriken UI, Volt UI (both seem to be MIT) and Tailwind plus, Nuxt UI (paid ones).
Some of them provide their own colors, border radiuses, etc.

I think it could be useful to have a default tailwind config or a checklist on what to add somewhere for non-designers (like me) to be able to get started using a design system quickly, and then replace things if needed

[stillingdesign]

I think it could be useful to have a default tailwind config or a checklist on what to add somewhere for non-designers (like me) to be able to get started using a design system quickly, and then replace things if needed

I'm a designer (by trade) but am pretty fluent with web development, too. Without any overrides/config, Tailwind's out-of-the-box values are pretty solid. For instance, the default font-sans or font-mono is what a lot of industry leading products use to set font-family without any overrides. In designer terms (or "Atomic" design), these types of things would be the core "Atoms" or "Design Tokens" of a design system.

Within my own configs, I typically abstract off of the foundational system to limit what's available—this helps with visual consistency. Primarily, this is setting up a more limited color palette (using a naming convention I prefer). From, there, it's mostly setting up components outside of CSS as I lean toward design systems that offer flexibility vs. guardrails.

The way I have thought about Tailwind is more like a "Design token system". From there, using component libraries or UI frameworks built on top of Tailwind pre-assemble the higher levels of a design system. As a designer, I typically build these from scratch—though.

TLDR; below. I've tried simplifying my standard config down to the basics—note this is opinionated/preferential and a lot of people will likely disagree with how I've done this 😂. The sites I make with it usually look alright and load fast, so 🤷‍♂️ ... Most of what I've removed to simplify just extended the available values (like repeatedly used calcs() and what not).

@import "tailwindcss";

/* Core colors */
:root {
    --lch-black: 0 0 0;
    --lch-white: 1 0 0;
    /* Can be used for button/cta background color */
    --lch-primary: 0.54 calc(var(--chroma) + 0.25) var(--hue);
}

/* Light mode colors */
:root[color-scheme="light"] {
    --hue:262; /* in case you want to shift hue between light and dark */
    --chroma:0.01; /* in case you want to shift chroma between light and dark */
    /* Generally useful */
    --lch-theme:        1 var(--chroma) var(--hue);
    --lch-inverse:      0 var(--chroma) var(--hue);
    --lch-stacklight:   1 0 0;
    /* UI element background colors */
    --lch-shadow:       0.935 var(--chroma) var(--hue);
    --lch-background:   0.955 var(--chroma) var(--hue);
    --lch-middleground: 0.980 var(--chroma) var(--hue);
    --lch-foreground:   0.990 var(--chroma) var(--hue);
    --lch-highlight:    1.000 var(--chroma) var(--hue);
   /* UI element border color (use with opacity) */
    --lch-edge:         0.000 var(--chroma) var(--hue);
    /* Text colors */
    --lch-detail:       0.450 var(--chroma) var(--hue);
    --lch-content:      0.250 var(--chroma) var(--hue);
    --lch-headline:     0.050 var(--chroma) var(--hue);
    /* Link colors (can be used for button/cta background-color too) */
    --lch-link:         0.50 calc(var(--chroma) + 0.25) var(--hue);
    --lch-linkhover:    0.40 calc(var(--chroma) + 0.25) var(--hue);
    /* More generally useful colors */
    --lch-error:        0.50 0.35  000;
    --lch-caution:      0.63 1.00 106;
    --lch-success:      0.50 0.46 182;
    --lch-accent:       0.70 0.40 282;
    --lch-tertiary:     0.54 0.40 218;
}

/* Dark mode  colors */
:root[color-scheme="dark"] {
    --hue:262;
    --chroma:0.01;
    --lch-theme:        0 var(--chroma) var(--hue);
    --lch-inverse:      1 var(--chroma) var(--hue);
    --lch-stacklight:   0.28 var(--chroma) var(--hue);
    --lch-shadow:       0.00 var(--chroma) var(--hue);
    --lch-background:   0.05 var(--chroma) var(--hue);
    --lch-middleground: 0.10 var(--chroma) var(--hue);
    --lch-foreground:   0.15 var(--chroma) var(--hue);
    --lch-highlight:    0.17 var(--chroma) var(--hue);
    --lch-edge:         1 var(--chroma) var(--hue);
    --lch-detail:       0.70 0.02  calc(var(--hue) - 4);
    --lch-content:      0.85 0.01  calc(var(--hue) - 8);
    --lch-headline:     1.00 0  calc(var(--hue) - 12);
    --lch-link:         0.72 calc(var(--chroma) + 0.3) var(--hue);
    --lch-linkhover:    0.80 calc(var(--chroma) + 0.2) var(--hue);
    --lch-error:        0.70 0.24 352;
    --lch-caution:      0.75 0.85 102;
    --lch-success:      0.65 0.30 182;
    --lch-accent:       0.70 0.40 282;
    --lch-tertiary:     0.70 0.40 222;
}

@theme {

    /* Fonts */
    --font-sans: "Inter", ui-sans-serif, system-ui, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";

    /* Reset breakpoints • My preference */
    --breakpoint-*: initial;
    /* Breakpoints */
    --breakpoint-sm: 48rem;
    --breakpoint-md: 68rem;
    --breakpoint-lg: 96rem;

    /* Spacing reset • YOLO 😂 */
    --spacing: 0.0625rem;

    /* Reset aspect  • My preference  */
    --aspect-*: initial;

    /* Reset color  • My preference  */
    --color-*: initial;
    /* Colors */
    --color-primary:      oklch(var(--lch-primary));
    --color-black:        oklch(var(--lch-black));
    --color-white:        oklch(var(--lch-white));
    --color-theme:        oklch(var(--lch-theme));
    --color-inverse:      oklch(var(--lch-inverse));
    --color-stacklight:   oklch(var(--lch-stacklight));
    --color-shadow:       oklch(var(--lch-shadow));
    --color-background:   oklch(var(--lch-background));
    --color-middleground: oklch(var(--lch-middleground));
    --color-foreground:   oklch(var(--lch-foreground));
    --color-highlight:    oklch(var(--lch-highlight));
    --color-edge:         oklch(var(--lch-edge));
    --color-detail:       oklch(var(--lch-detail));
    --color-content:      oklch(var(--lch-content));
    --color-headline:     oklch(var(--lch-headline));
    --color-link:         oklch(var(--lch-link));
    --color-linkhover:    oklch(var(--lch-linkhover));
    --color-error:        oklch(var(--lch-error));
    --color-caution:      oklch(var(--lch-caution));
    --color-success:      oklch(var(--lch-success));
    --color-accent:       oklch(var(--lch-accent));
    --color-tertiary:     oklch(var(--lch-tertiary));
}