This PR updates all of our x/y named utilities (like `px-*`, `my-*`,
`inset-y-*`, `scroll-px-*`, etc.) to use logical properties like
`padding-inline` instead of separate `padding-left` and `padding-right`
properties.
We held off on this originally for a while because `inline` doesn't
really mean _horizontal_ like the "x" in `px-*` implies, but I think in
practice this change is fine — I'm comfortable with "x" meaning "in the
inline direction" and "y" meaning "in the block direction" in Tailwind.
This is technically a breaking change if anyone was depending on the
fact that `px-*` for instance was always explicitly setting
`padding-left` and `padding-right` even when building something in a
vertical writing mode, but I kinda doubt there's a single real project
on the internet that will actually be affected, so not too worried about
it.
If someone _really_ wants to set `padding-left` and `padding-right` they
can always use `pl-4 pr-4` instead of `px-4`.
Nice thing about this change is it produces quite a bit less CSS.
To test this change, I re-generated all of the snapshots and made sure
none of the generated utilities changed position or anything in the
output (initially they did before I updated `property-order.ts` to add
some missing properties).
I also created a little demo locally in the Vite playground to test
things manually and make sure I didn't make any obvious typos or
anything that could slip through the snapshots:
<img width="1223" alt="image"
src="https://github.com/user-attachments/assets/0e9854ba-2b5b-4c8c-87b6-6eb7b7da84f2">
<details>
<summary>Show code for playground demo</summary>
```jsx
import React from 'react'
export function App() {
return (
<div className="p-12 gap-10 grid grid-cols-2 items-start">
<div className="grid grid-cols-1 gap-10 justify-start">
<div className="space-y-6">
<p className="font-semibold mb-6">Border Width</p>
<div className="border-x w-48 h-12 flex items-center justify-center">border-x</div>
<div className="border-y w-48 h-12 flex items-center justify-center">border-y</div>
</div>
<div className="space-y-6">
<p className="font-semibold mb-6">Border Color</p>
<div className="border-2 border-x-red-500 w-48 h-12 flex items-center justify-center">
border-x-red-500
</div>
<div className="border-2 border-y-red-500 w-48 h-12 flex items-center justify-center">
border-y-red-500
</div>
</div>
<div className="space-y-6">
<p className="font-semibold mb-6">Padding</p>
<div>
<div className="px-8 bg-yellow-300 inline-flex items-center justify-center">px-8</div>
</div>
<div>
<div className="py-8 bg-yellow-300 inline-flex items-center justify-center">py-8</div>
</div>
</div>
</div>
<div className="grid grid-cols-1 gap-10 justify-start">
<div className="space-y-6">
<p className="font-semibold mb-6">Margin</p>
<div>
<div className="bg-red-400 inline-flex">
<div className="mx-8 bg-yellow-300 inline-flex items-center justify-center">mx-8</div>
</div>
</div>
<div>
<div className="bg-red-400 inline-flex">
<div className="my-8 bg-yellow-300 inline-flex items-center justify-center">my-8</div>
</div>
</div>
</div>
<div className="space-y-6">
<p className="font-semibold mb-6">Inset</p>
<div className="relative bg-red-400 w-48 h-48">
<div className="inset-x-8 absolute bg-yellow-300 inline-flex items-center justify-center">
inset-x-8
</div>
</div>
<div className="relative bg-red-400 w-48 h-48">
<div className="inset-y-8 absolute bg-yellow-300 inline-flex items-center justify-center">
inset-y-8
</div>
</div>
</div>
</div>
</div>
)
}
```
</details>
I didn't manually test the scroll padding or scroll margin utilities
because they are more annoying to set up, but I probably should.
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
This PR implements some changes to the way we sort typography utilities,
inspired by #14715.
Prior to this PR, utilities like `text-balance`, `break-words`, and
`text-center` were sorted very early, even before things like border
utilities:
```html
<div class="text-balance break-words border-2 border-blue-500 text-center indent-5 text-2xl font-medium capitalize leading-6 tracking-tight text-red-500 underline"></div>
```
This PR changes the sort order to co-locate these with other typography
utilities which feels a lot more natural:
```html
<div class="border-2 border-blue-500 text-center indent-5 text-2xl leading-6 font-medium tracking-tight text-balance break-words text-red-500 capitalize underline"></div>
```
I've also made some small adjustments to how other typography properties
are sorted based on pairing with @reinink and just deciding what felt
the most intuitive to us and matched the order we'd likely type things
in manually.
To test this change I temporarily added a new test to `sort.test.ts` to
make sure the classes were sorted in the expected order:
```js
[
// Input
'text-red-500 text-center capitalize text-2xl break-words text-balance underline font-medium tracking-tight leading-6 indent-5',
// Expected
'text-center indent-5 text-2xl leading-6 font-medium tracking-tight text-balance break-words text-red-500 capitalize underline',
],
```
Didn't keep the test around because there's no real logic to test here
(it just matches the order in the `property-order.ts` file) and we don't
have any other tests like this.
I've also made some minor unrelated changes here like deleting legacy
properties from `property-order.ts` that are never used, and fixing a
typo where we wrote `work-break` instead of `word-break`.
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
I've tweaked the changelog with suggestions from @adamwathan to improve
clarity around what the actual changes are.
I also renamed `compoundWith` back to `compound` — I felt that it made
sense at the time but keeping the old name definitely feels better the
more I think about it.
This PR updates our arbitrary value decoder to:
- No longer require an escaping for underscores in the first parameter
of `var()`. Example:
```
ml-[var(--spacing-1_5,_1rem)]
```
- Ensures that properties before an eventual `url()` are properly
unescaped. Example:
```
bg-[no-repeat_url(./image.jpg)]
```
I will ensure that this properly works for the migrate use case in a
follow-up PR in the stack.
## Test Plan
Added unit tests as well as tests for the variant decoder. Additionally
this PR also adds a higher-level test using the public Tailwind APIs to
ensure this is properly propagated.
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
Resolves#14772.
This PR fixes an issue where utilities like `ps-2` were sorted earlier
in the generated CSS than `px-3`, causing `ps-2` to not override `px-3`
as expected.
This happened because `px-3` uses `padding-left` and `padding-right`,
and `ps-2` uses `padding-inline-start`, and in `property-order.ts` we
sort those properties as follows:
```js
...
'padding',
'padding-inline',
'padding-block',
'padding-inline-start',
'padding-inline-end',
'padding-top',
'padding-right',
'padding-bottom',
'padding-left',
...
```
Since `padding-left` and `padding-right` both appear later than
`padding-inline-start`, the `px-3` utility is sorted later in the CSS
since all of its properties are later in the sort order than all of
properties in `ps-2`.
To fix this, I'm using our internal `--tw-sort` property to tell
Tailwind to sort the `px-3` utility as if it used `padding-inline` to
ensure that it's sorted earlier in the CSS.
This PR applies this same fix for the `padding` utilities,
`scroll-margin` utilities, and `scroll-padding` utilities. No changes
have been made to the `margin` utilities because we were already
handling this correctly there.
Here you can see that `pl-2` overrides `px-6` as you'd expect:
<img width="1041" alt="image"
src="https://github.com/user-attachments/assets/fb330536-2131-4de8-a584-62edf380148f">
…and now with the change in this PR, `ps-2` also overrides `px-6` as
you'd expect:
<img width="1043" alt="image"
src="https://github.com/user-attachments/assets/c6799416-9c80-4fd5-bce4-ea1e4da53968">
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
This PR is an internal refactor to improve the way we handle at-rules.
Essentially we check for the `@` symbol and bail early if that's not the
case.
We also improve the way `@media` is being handled by first checking for
`@media`, and then handle all the params separately.
Last but not least, we also inverted the `@theme` check condition such
that it is handled the same way we handle everything else.
This PR fixes an issue where JS configuration theme properties with dots
or slashes in them would not migrate correctly. E.g.:
```ts
import { type Config } from 'tailwindcss'
module.exports = {
theme: {
width: {
1.5: '0.375rem',
'1/2': '50%',
}
}
}
```
This should convert to:
```css
@theme {
--width-1_5: 0.375rem;
--width-1\/2: 50%;
}
```
_Note: We will likely change the `--width-1_5` key to `--width-1\.5` in
a follow-up PR._
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
When we implemented the CSS import resolution system, we found out a
detail about CSS imports in that files without a relative path prefix
would still be relative to the source file. E.g.:
```css
@import 'foo.css';
```
Should first look for the file `foo.css` in the same directory. To make
this cost as cheap as possible, we limited this by a heuristics to only
apply the auto-relative imports for files with a file extension.
Naturally, while testing v4 on more templates, we found that it's common
for people to omit the file extension when loading css file. The above
could also be written as such:
```css
@import 'foo';
```
To improve this, we have two options:
- We either remove the heuristics, making every `@import` more expensive
because we have to check for relative files.
- We upgrade our codemods to rewrite `@import` statements to be
explicitly relative.
Because we really care about performance, we opted to go with the latter
option. This PR adds the codemod and removes the heuristics so we
resolve CSS files similar to how you would resolve JS files.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
This PR fixes two issues related to how we tread JS theme keys in combination with CSS theme values:
1. When applying JS theme keys to our `Theme` class, we need to ensure they are escaped in the same way as reading CSS theme keys from CSS are.
2. When JS plugins use the `theme()` function to read a namespace that has values contributed to from the CSS theme and the JS theme, we need to ensure that the resulting set contains only unescaped theme keys.
For specific examples, please take a look at the test cases.
This PR updates all of our OKCLH colors to use `0` instead of `none` due
to weird behavior in Chrome where using `color-mix` with colors using
`none` produces unexpected results:
<img width="1110" alt="image"
src="https://github.com/user-attachments/assets/2272e494-500b-4f75-b5c1-d41c714f0339">
Both `none` and `0` behave as expected in Safari and Firefox so
suspecting this is a bug in Chrome rather than spec'd behavior.
Fixes#14740
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
This PR fixes an issue where `theme(…)` calls that contain a `.1`
weren't correctly converted to `var(--spacing-1)`. The reason for this
is that `.1` has some special meaning in cases like
`fontSize.xs.1.lineHeight` where it should be converted to
`--font-size-xs--line-height`, not `--font-size-xs-1-line-height`.
To solve this, we make sure to only apply the `--` check if the `1`
occurs somewhere in the middle instead of at the very end.
With this change, the following migrations will happen correctly:
```diff
- [--value:theme(spacing.1)]
+ [--value:var(--spacing-1)]
```
```diff
- [--value:theme(fontSize.xs.1.lineHeight)]
+ [--value:var(--font-size-xs--line-height)]
```
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
This PR will optimize and simplify the candidates when printing the
candidate again after running codemods.
When we parse a candidate, we will add spaces around operators, for
example `p-[calc(1px+1px)]]` will internally be handled as `calc(1px +
1px)`. Before this change, we would re-print this as:
`p-[calc(1px_+_1px)]`.
This PR changes that by simplifying the candidate again so that the
output is `p-[calc(1px+1px)]`. In addition, if _you_ wrote
`p-[calc(1px_+_1px)]` then we will also simplify it to the concise form
`p-[calc(1px_+_1px)]`.
Some examples:
Input:
```html
<div class="[p]:flex"></div>
<div class="[&:is(p)]:flex"></div>
<div class="has-[p]:flex"></div>
<div class="px-[theme(spacing.4)-1px]"></div>
```
Output before:
```html
<div class="[&:is(p)]:flex"></div>
<div class="[&:is(p)]:flex"></div>
<div class="has-[&:is(p)]:flex"></div>
<div class="px-[var(--spacing-4)_-_1px]"></div>
```
Output after:
```html
<div class="[p]:flex"></div>
<div class="[p]:flex"></div>
<div class="has-[p]:flex"></div>
<div class="px-[var(--spacing-4)-1px]"></div>
```
---
This is alternative implementation to #14717 and #14718Closes: #14717Closes: #14718
This PR fixes an issue where spaces in a selector generated invalid CSS.
Lightning CSS will throw those incorrect lines of CSS out, but if you
are in an environment where Lightning CSS doesn't run then invalid CSS
is generated.
Given this input:
```html
data-[foo_=_"true"]:flex
```
This will be generated:
```css
.data-\[foo_\=_\"true\"\]\:flex[data-foo=""true] {
display: flex;
}
```
With this PR in place, the generated CSS will now be:
```css
.data-\[foo_\=_\"true\"\]\:flex[data-foo="true"] {
display: flex;
}
```
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
With the changes in #14672, it now becomes trivial to actually resolve
the config (while still retaining the reset behavior). This means that
we can now convert JS configs that use _functions_, e.g.:
```ts
import { type Config } from 'tailwindcss'
export default {
theme: {
extend: {
colors: ({ colors }) => ({
gray: colors.neutral,
}),
},
},
} satisfies Config
```
This becomes:
```css
@import 'tailwindcss';
@theme {
--color-gray-50: #fafafa;
--color-gray-100: #f5f5f5;
--color-gray-200: #e5e5e5;
--color-gray-300: #d4d4d4;
--color-gray-400: #a3a3a3;
--color-gray-500: #737373;
--color-gray-600: #525252;
--color-gray-700: #404040;
--color-gray-800: #262626;
--color-gray-900: #171717;
--color-gray-950: #0a0a0a;
}
```
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This PR updates all of our gradient utilities to interpolate using OKLCH
by default instead of sRGB. This results in a smoother transition
between colors that preserves saturation throughout the gradient, rather
than hitting the dreaded dull gray zone in between your color stops.
Here are a few examples comparing sRGB (top) to OKLCH (bottom):
<img width="736" alt="image"
src="https://github.com/user-attachments/assets/57a158b6-a3a2-4eda-813e-1b596c7d4b3a">
We only apply a default interpolation mode when _not_ using arbitrary
values with the gradient utility.
Simplified but clear:
```css
.bg-linear-to-r {
background-image: linear-gradient(to right in oklch, var(--gradient-color-stops));
}
.bg-linear-[to_right] {
background-image: linear-gradient(to right, var(--gradient-color-stops));
}
.bg-linear-[to_right_in_hsl] {
background-image: linear-gradient(to right in hsl, var(--gradient-color-stops));
}
```
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
This PR adds support for linear gradient angles as bare values, like
this:
```
bg-linear-45 => linear-gradient(45deg, …)
```
We already support this for [conic
gradients](https://github.com/tailwindlabs/tailwindcss/pull/14467), so
this makes these utilities more consistent.
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Prior to this PR we were providing fallback values for certain CSS
variables in our gradient utilities that just weren't necessary and
didn't do anything.
For example `bg-linear-to-r` was generating this:
```css
.bg-linear-to-r {
--tw-gradient-position: to right;
background-image: linear-gradient(
var(--tw-gradient-stops, to right)
);
}
```
…but `background-image: linear-gradient(to right)` is not valid CSS and
is thrown out by the browser.
This PR removes these fallback values entirely since there is nothing
sensible to fall back to anyways — you need to combine these utilities
with the `from-*`/`to-*` utilities or provide the complete gradient as
an arbitrary value for things to make sense.
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
This PR updates all of the colors in our default theme to use OKLCH
instead of RGB and increases the overall chroma to take advantage of the
wider color gamut.
Just a first draft based on @danhollick's initial work — expecting these
will be further refined before a stable release as we continue to test
them.
<img width="628" alt="image"
src="https://github.com/user-attachments/assets/2de1bfca-fddd-47f9-b609-39f26abdee41">
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
This PR adds a codemod to convert `theme(…)` calls to `var(…)` calls. If
we can't safely do this, then we try to convert the `theme(…)` syntax
(dot notation) to the modern `theme(…)` syntax (with CSS variable-like
syntax).
### Let's look at some examples:
**Simple example:**
Input:
```html
<div class="bg-[theme(colors.red.500)]"></div>
```
Output:
```html
<div class="bg-[var(--color-red-500)]"></div>
```
---
**With fallback:**
Input:
```html
<div class="bg-[theme(colors.red.500,theme(colors.blue.500))]"></div>
```
Output:
```html
<div class="bg-[var(--color-red-500,var(--color-blue-500))]"></div>
```
---
**With modifiers:**
Input:
```html
<div class="bg-[theme(colors.red.500/75%)]"></div>
```
Output:
```html
<div class="bg-[var(--color-red-500)]/75"></div>
```
We can special case this, because if you are using that modifier syntax
we _assume_ it's being used in a `theme(…)` call referencing a color.
This means that we can also convert it to a modifier on the actual
candidate.
---
**With modifier, if a modifier is already present:**
Input:
```html
<div class="bg-[theme(colors.red.500/75%)]/50"></div>
```
Output:
```html
<div class="bg-[theme(--color-red-500/75%)]/50"></div>
```
In this case we can't use the `var(…)` syntax because that requires us
to move the opacity modifier to the candidate itself. In this case we
could use math to figure out the expected modifier, but that might be
too confusing. Instead, we convert to the modern `theme(…)` syntax.
---
**Multiple `theme(…)` calls with modifiers:**
Input:
```html
<div class="bg-[theme(colors.red.500/75%,theme(colors.blue.500/50%))]"></div>
```
Output:
```html
<div class="bg-[theme(--color-red-500/75%,theme(--color-blue-500/50%))]"></div>
```
In this case we can't convert to `var(…)` syntax because then we lose
the opacity modifier. We also can't move the opacity modifier to the
candidate itself e.g.: `/50` because we have 2 different variables to
worry about.
In this situation we convert to the modern `theme(…)` syntax itself.
---
**Inside variants:**
Input:
```html
<div class="max-[theme(spacing.20)]:flex"></div>
```
Output:
```html
<div class="max-[theme(--spacing-20)]:flex"></div>
```
Unfortunately we can't convert to `var(…)` syntax reliably because in
some cases (like the one above) the value will be used inside of an
`@media (…)` query and CSS doesn't support that at the time of writing
this PR.
So to be safe, we will not try to convert `theme(…)` to `var(…)` in
variants, but we will only upgrade the `theme(…)` call itself to modern
syntax.
Imagine the following setup:
```css
/* src/input.css */
@import "tailwindcss";
@config "../tailwind.config.ts";
@theme {
--color-red-500: #ef4444;
}
```
```ts
/* tailwind.config.ts */
export default {
theme: {
colors: {
red: {
600: '#dc2626'
}
},
extend: {
colors: {
400: '#f87171'
}
}
}
}
```
Since the theme object in the JS config contains `colors` in the
non-`extends` block, you would expect this to _not pull in all the
default colors imported via `@import "tailwindcss";`_. This, however,
wasn't the case right now since all theme options were purely _additive_
to the CSS.
This PR makes it so that non-`extend` theme keys _overwrite default CSS
theme values_. The emphasis is on `default` here since you still want to
be able to overwrite your options via `@theme {}` in user space.
This now generates the same CSS that our upgrade codemods would also
generate as this would apply the new CSS right after the `@import
"tailwindcss";` rule resulting in:
```css
@import "tailwindcss";
@theme {
--color-*: initial;
--color-red-400: #f87171;
--color-red-600: #dc2626;
}
@theme {
--color-red-500: #ef4444;
}
```
## Keyframes
This PR also adds a new core API to unset keyframes the same way. We
previously had no option of doing that but while working on the above
codemods we noticed that keyframes should behave the same way:
```css
@import "tailwindcss";
@theme {
--keyframes-*: initial;
@keyframes spin {
to {
transform: rotate(361deg);
}
}
}
```
To do this, the keyframes bookeeping was moved from the main Tailwind
CSS v4 file into the `Theme` class.
_I’m not sure super of the API yet but we would need a way for the
codemods to behave the same as out interop layer here. Option B is that
we don't reset keyframes the same way we reset other theme variables_.
This PR makes sure that you cannot use `@apply` inside `@keyframes`.
While some utilities can be used in `@keyframes`, the moment you
introduce a variant, that's not going to work anymore because they need
to operate on selectors which `@keyframes` don't have.
This PR now removes all usages of `@apply` in `@keyframes`.
This PR fixes an issue where bare values in the `font-stretch` utility
such as `font-stretch-50.5%` compiled. But for bare values, we want
these values to be positive integers only so that we don't have too many
special characters.
If you want to use `50.5%`, you can still use `font-stretch-[50.5%]` as
a utility.
Inside the `theme(…)` function, we can use the `/` character for
applying an opacity. For example `theme(colors.red.500 / 50%)` will
apply a 50% opacity to the `colors.red.500` value.
However, if you used a variable instead of the hardcoded `50%` value,
then this was not parsed correctly. E.g.: `theme(colors.red.500 /
var(--opacity))`
_If_ we have this exact syntax (with the spaces), then it parses, but
some information is lost:
```html
<div class="bg-[theme(colors.red.500_/_var(--opacity))]"></div>
```
Results in:
```css
.bg-\[theme\(colors\.red\.500_\/_var\(--opacity\)\)\] {
background-color: color-mix(in srgb, #ef4444 calc(var * 100%), transparent);
}
```
Notice that the `var(--opacity)` is just parsed as `var`, and the
`--opacity` is lost.
Additionally, if we drop the spaces, then it doesn't parse at all:
```html
<div class="bg-[theme(colors.red.500/var(--opacity))]"></div>
```
Results in:
```css
```
This means that we have to handle 2 issues to make this work:
1. We have to properly handle the `/` character as a proper separator.
2. If we have sub-functions, we have to make sure to print them in full
(instead of only the very first node (`var` in this case)).
Quick follow-up to #14659 base don @thecrypticace's idea:
- This behavior is no longer added to the types of the Plugin API to be
consistent with v3
- When the plugin argument is used as a function, we now warn the first
time
Something we noticed while testing the codemods on one of our codebases
is that the callback passed to the `theme` function properties doesn't
only expose some properties like `colors`, but it's also a function
itself.
```ts
/** @type {import('tailwindcss').Config} */
export default {
theme: {
extend: {
colors: (theme) => {
// The `theme` is a theme function _and_ the object...
console.log(theme('spacing.2'), theme.colors.red['500'])
return {}
},
},
},
plugins: [],
}
```
E.g.: https://play.tailwindcss.com/eV7Jgv17X1?file=config
---
h/t to @RobinMalfait for the issue description
While working on some fixes for #14639 I noticed that the following v3
configuration file would not load properly in v4:
```ts
import { type Config } from 'tailwindcss'
export default {
content: ['./src/**/*.{js,jsx,ts,tsx}'],
theme: {
extend: {
colors: ({ colors }) => ({
gray: colors.neutral,
}),
},
} satisfies Config
```
The reason for this is that we did not pass the `colors` property to the
callback function. Since we have colors available now, we can easily add
it.
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
A few theme keys have changed in v4 relative to v3:
- `screens` -> `--breakpoint-*`
- `colors` -> `--color-*`
- `animation` -> `--animate-*`
- `borderRadius` -> `--radius-*`
- `boxShadow` -> `--shadow-*`
When using the `theme()` function we wouldn't pick up values from the
CSS for some of these. Likewise, when loading a v3 config not all of
these would be pushed back into the CSS theme and they should've been.
This PR addresses both of these problems.
This PR implements the first version of JS config file migration to CSS.
It is based on the most simple config setups we are using in the
Tailwind UI templates Commit, Primer, Radiant, and Studio.
The example we use in the integration test is a config that looks like
this:
```js
import { type Config } from 'tailwindcss'
import defaultTheme from 'tailwindcss/defaultTheme'
module.exports = {
darkMode: 'selector',
content: ['./src/**/*.{html,js}'],
theme: {
boxShadow: {
sm: '0 2px 6px rgb(15 23 42 / 0.08)',
},
colors: {
red: {
500: '#ef4444',
},
},
fontSize: {
xs: ['0.75rem', { lineHeight: '1rem' }],
sm: ['0.875rem', { lineHeight: '1.5rem' }],
base: ['1rem', { lineHeight: '2rem' }],
},
extend: {
colors: {
red: {
600: '#dc2626',
},
},
fontFamily: {
sans: 'Inter, system-ui, sans-serif',
display: ['Cabinet Grotesk', ...defaultTheme.fontFamily.sans],
},
borderRadius: {
'4xl': '2rem',
},
},
},
plugins: [],
} satisfies Config
```
As you can see, this file only has a `darkMode` selector, custom
`content` globs, a `theme` (with some theme keys being overwriting the
default theme and some others extending the defaults). Note that it does
not support `plugins` and/or `presets` yet.
In the case above, we will find the CSS file containing the existing
`@tailwind` directives and are migrating it to the following:
```css
@import 'tailwindcss';
@source './**/*.{html,js}';
@variant dark (&:where(.dark, .dark *));
@theme {
--box-shadow-*: initial;
--box-shadow-sm: 0 2px 6px rgb(15 23 42 / 0.08);
--color-*: initial;
--color-red-500: #ef4444;
--font-size-*: initial;
--font-size-xs: 0.75rem;
--font-size-xs--line-height: 1rem;
--font-size-sm: 0.875rem;
--font-size-sm--line-height: 1.5rem;
--font-size-base: 1rem;
--font-size-base--line-height: 2rem;
--color-red-600: #dc2626;
--font-family-sans: Inter, system-ui, sans-serif;
--font-family-display: Cabinet Grotesk, ui-sans-serif, system-ui, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
--border-radius-4xl: 2rem;
}
```
This replicates all features of the JS config so we can even delete the
existing JS config in this case.
---------
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
We forgot to pass `options` from `addComponents` to `addUtilities` and
from `matchComponents` to `matchUtilities`.
This didn't affect anything using addComponents but anything that used
`matchComponents` wouldn't have worked 😬
Discovered `matchUtilities(…)` wasn't populating intellisense on v4 when
working on Tailwind Play earlier today. This PR fixes this so plugins
using matchUtilities also have intellisense suggestions.
We currently have three different implementations of the
`resolveThemeValue()` Theme method:
1. The _core_ version which only resolves based on the exact CSS
variable name. This is the v4-only version.
2. A _compat light_ version which attempts to translate a dot-notation
keypath to a CSS variable name.
3. A _full compat_ version which resolves the legacy theme object which
is used whenever a `@plugin` or `@config` is added.
Unfortunately, there are some issues with this approach that we've
encountered when testing the CSS `theme()` function while upgrading
Tailwind Templates to v4 using our upgrading toolkit.
1. The _compat light_ resolver was trying to convert `theme(spacing.1)`
to tuple syntax. Tuples require a nested property access, though, and
instead this should be convert to `theme(--spacing-1)`.
2. We currently only load _full compat_ version if `@plugin` or
`@config` directives are used. It is possible, though, that we need the
full compat mapping in other cases as well. One example we encountered
is `theme(fontWeight.semibold)` which maps to a dictionary in the
default theme that that we do not have an equivalent for in v4
variables.
To fix both issues, we decided to remove the _compat light_ version of
the `theme()` function in favor of adding this behavior to an upgrade
codemod. Instead, the second layer now only decides wether it can use
the _core_ version or wether it needs to upgrade to the _full compat_
version. Since typos would trigger a _hard error_, we do not think this
has unintended performance consequences if someone wants to use the
_core_ version only (they would get an error regardless which they need
to fix in order to continue).
Fixes an issue reported by the React Aria Components team here:
https://github.com/adobe/react-spectrum/issues/7160
Basically `hidden="until-found"` behaves very differently than `hidden`
and doesn't actually use `display: none`, so we don't want to apply the
behavior we apply for the regular `hidden` attribute.
This PR fixes two issues we found when testing the candidate codemodes:
1. Sometimes, core would emit the same candidate twice. This would
result into rewriting a range multiple times, without realizing that
this change might already be applied, causing it to swallow or duplicate
some bytes.
2. The codemods were mutating the `Candidate` object, however since the
`Candidate` parsing is _cached_ in core, it would sometimes return the
same instance. This is an issue especially since we monkey patch the
prefix to `null` when migrating prefixed candidates. This means that a
candidate would be cached that would be _invalid relative to the real
design system_. We fixed this by making sure the mutations would only be
applied to clones of the `Candidate` and I changed the `DesignSystem`
API to return `ReadOnly<T>` versions of these candidates. A better
solution would maybe be to disable the cache at all but this requires
broader changes in Core.
This PR makes the internal `@at-root` API private. Before this PR you
could use `@at-root` in your own CSS, which means that it was part of
the public API. If you (accidentally) used it in variants, you could
generate CSS that was completely broken.
This now introduces a new private `AtRoot` node (similar to the recently
introduced `Context` node) and can only be constructed within the
framework.
