mirror of
https://github.com/tailwindlabs/tailwindcss.git
synced 2026-03-20 03:04:17 +00:00
A utility-first CSS framework for rapid UI development.
https://tailwindcss.com/
7482d47a54This PR adds support for canonicalizations for `tracking-*` utilities. This one is a bit of a funny one, if you take a look at the linked issue, there is a beautiful table: | Utility Name | Value | Arbitrary Value | Throws Suggestion | | - | -: | - | - | | tracking-tighter | -0.05em | tracking-[-0.05em] | ✗ | | tracking-tight | -0.025em | tracking-[-0.025em] | ✗ | | tracking-normal | 0em | tracking-[0em] | ✗ | | tracking-wide | 0.025em | tracking-[0.025em] | ✗ | | tracking-wider | 0.05em | tracking-[0.05em] | ✗ | | tracking-widest | 0.1em | tracking-[0.1em] | ✓ | It doesn't really make sense to _why_ only the `tracking-widest` one is properly suggested here. Until you look a little bit closer. Turns out that `-tracking-tighter` is equivalent to `tracking-wider`, `-tracking-tight` is equivalent to `tracking-wide` and so on. The way the canonicalization works internally is by generating a signature for a given utility class. If two utilities have the exact same signature, we can consider them the same. In this case `tracking-widest` and `tracking-[0.1em]` have the same signature. One of the rules we have internally is that if we find more than one replacement utility then we don't really know what to do, so we bail. Because if you get `foo` or `bar`, which one do you pick? If we refer to this above table again, the moment we want to canonicalize the `tracking-[-0.05em]` we get two suggestions: `tracking-tighter` and `-tracking-wider`, since we don't know what to do, we bail and we don't suggest anything. So the reason that `tracking-widest` _was_ suggested is just because we don't have a `-tracking-tightest`. How do we fix this? Well, since we have `tracking-*` and `-tracking-*` utilities, I wanted to deprecate the `-tracking-*` ones for named utilities (where the values come from your theme) because that doesn't really make sense. However, we have this exact pattern documented here: https://tailwindcss.com/docs/letter-spacing#using-negative-values Which means that I can't just deprecate those utilities. <img width="723" height="511" alt="image" src="https://github.com/user-attachments/assets/164b659b-abe9-4f6e-a176-701dd7ea505a" /> Instead, I added a different rule which says that if you get multiple possible replacements, then we prefer the "positive" one, the one without the `-`. Also added some additional checks to make sure that if you get `foo`, `-bar`, `baz`, that we also bail because we know that we should prefer `foo` or `baz` over `-bar`, but we don't know if we should pick `foo` or `baz`... This additional rule does solve the original issue, and we already prefer possible values over negative values in other places (related to bare values). Fixes: https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1558 ## Test plan 1. Existing tests pass 2. Added regression tests to make sure that the table from above _does_ get canonicalized correctly into the expected values. |
||
|---|---|---|
| .github | ||
| crates | ||
| integrations | ||
| packages | ||
| patches | ||
| playgrounds | ||
| scripts | ||
| .gitignore | ||
| .prettierignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| LICENSE | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| rust-toolchain.toml | ||
| turbo.json | ||
| vitest.config.ts | ||
A utility-first CSS framework for rapidly building custom user interfaces.
Documentation
For full documentation, visit tailwindcss.com.
Community
For help, discussion about best practices, or feature ideas:
Discuss Tailwind CSS on GitHub
Contributing
If you're interested in contributing to Tailwind CSS, please read our contributing docs before submitting a pull request.