wrapper/tailwindcss
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
tailwindcss/CHANGELOG.md

4089 lines
255 KiB
Markdown
Raw Normal View History

v4 changelog (#13131) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-03-07 14:26:35 -05:00
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
Drop warning from browser build (#18732) Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-08-15 00:20:19 +08:00
### Changed
- Drop warning from browser build ([#18731](https://github.com/tailwindlabs/tailwindcss/issues/18731))
Suggest bare values for `flex-*` utilities (#18642) Fixes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1426 We weren't suggesting things like `flex-1`. This adds that. I'm not sure if we want to suggest more `flex-<number>` values though. I've added 1–12 but am open to changing this.
2025-07-30 10:48:26 -04:00
Don't transition `visibility` when using `transition` (#18795) We introduced an accidental breaking change a few months ago in 4.1.5 with #17812. We added `visibility` to the property list in `transition` which unfortunately only applies its change instantly when going from invisible -> visible. I've checked `display`, `content-visibility`, and `pointer-events` and they apply their change instantly (as best I can tell) when transitioning by default. And `overlay` only "applies" for discrete transitions so it can stay as well. The spec has this to say about [animating `visibility`](https://www.w3.org/TR/web-animations-1/#animating-visibility): > For the visibility property, visible is interpolated as a discrete step where values of p between 0 and 1 map to visible and other values of p map to the closer endpoint; if neither value is visible then discrete animation is used. This means that for visible (t=0) -> hidden (t=1) the timeline looks like this: - t=0.0: visible - t=0.5: visible - t=0.999…8: visible - t=1.0: invisible This means that for invisible (t=0) -> visible (t=1) the timeline looks like this: - t=0.0: invisible - t=0.000…1: visible - t=0.5: visible - t=1.0: visible So the value *is* instantly applied if the element is initially invisible but when going the other direction this is not the case. This happens whether or not the transition type is discrete. While the spec calls out [`display` as working similarly](https://drafts.csswg.org/css-display-4/#display-animation) in practice this is only the case when `transition-behavior` is explicitly set to `allow-discrete` otherwise the change is instant for both directions. Fixes #18793
2025-08-25 14:30:56 -04:00
### Fixed
- Don't transition `visibility` when using `transition` ([#18795](https://github.com/tailwindlabs/tailwindcss/pull/18795))
Discard `matchVariant` matches with unknown named values (#18799) This PR fixes two issues: - When a variant is defined by `matchVariant` it could match unknown values but not apply the variant (because it's unknown). This would result in a utility being output that is the _same_ as a bare utility without variants but a longer name. These were intended to be discarded but weren't done so correctly. - Similarly, when we encounter a known value but its not a string the same thing would happen where we'd output a utility without applying the variant. This was also intended to be discarded. Basically given this code: ```js matchVariant( "foo", (value) => `&:is([data-foo='${value}'])`, { values: { DEFAULT: "", bar: "bar", obj: { some: "object" }, }, } ) ``` And this HTML: ```html <div class="foo-bar:bg-none foo-[baz]:bg-none foo-baz:bg-none foo-obj:bg-none"></div> ``` This CSS would be produced: ```css @layer utilities { .foo-bar\:bg-none { &:is([data-foo='bar']) { background-image: none; } } /* this one shouldn't be here */ .foo-baz\:bg-none { background-image: none; } /* this one shouldn't be here */ .foo-obj\:bg-none { background-image: none; } .foo-\[baz\]\:bg-none { &:is([data-foo='baz']) { background-image: none; } } } ```
2025-08-26 10:21:15 -04:00
- Discard matched variants with unknown named values ([#18799](https://github.com/tailwindlabs/tailwindcss/pull/18799))
- Discard matched variants with non-string values ([#18799](https://github.com/tailwindlabs/tailwindcss/pull/18799))
Show suggestions for known `matchVariant` values (#18798) Given this variant: ```js matchVariant( "foo", (value) => `&:is([data-foo='${value}'])`, { values: { DEFAULT: "", bar: "bar", baz: "bar", }, } ) ``` We weren't listing `foo-bar` and `foo-baz` in IntelliSense. This PR fixes that.
2025-08-26 10:25:35 -04:00
- Show suggestions for known `matchVariant` values ([#18798](https://github.com/tailwindlabs/tailwindcss/pull/18798))
Don't transition `visibility` when using `transition` (#18795) We introduced an accidental breaking change a few months ago in 4.1.5 with #17812. We added `visibility` to the property list in `transition` which unfortunately only applies its change instantly when going from invisible -> visible. I've checked `display`, `content-visibility`, and `pointer-events` and they apply their change instantly (as best I can tell) when transitioning by default. And `overlay` only "applies" for discrete transitions so it can stay as well. The spec has this to say about [animating `visibility`](https://www.w3.org/TR/web-animations-1/#animating-visibility): > For the visibility property, visible is interpolated as a discrete step where values of p between 0 and 1 map to visible and other values of p map to the closer endpoint; if neither value is visible then discrete animation is used. This means that for visible (t=0) -> hidden (t=1) the timeline looks like this: - t=0.0: visible - t=0.5: visible - t=0.999…8: visible - t=1.0: invisible This means that for invisible (t=0) -> visible (t=1) the timeline looks like this: - t=0.0: invisible - t=0.000…1: visible - t=0.5: visible - t=1.0: visible So the value *is* instantly applied if the element is initially invisible but when going the other direction this is not the case. This happens whether or not the transition type is discrete. While the spec calls out [`display` as working similarly](https://drafts.csswg.org/css-display-4/#display-animation) in practice this is only the case when `transition-behavior` is explicitly set to `allow-discrete` otherwise the change is instant for both directions. Fixes #18793
2025-08-25 14:30:56 -04:00
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
## [4.1.12] - 2025-08-13
Suggest bare values for `flex-*` utilities (#18642) Fixes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1426 We weren't suggesting things like `flex-1`. This adds that. I'm not sure if we want to suggest more `flex-<number>` values though. I've added 1–12 but am open to changing this.
2025-07-30 10:48:26 -04:00
Don't consider the global important state in `@apply` (#18404) Fixes #18400 In v3 when you used `important: true` it did not affect `@apply`. However, in v4 it does and there's no way to make it *not*. This is definitely a bug and would be unexpected for users coming from v3 who use `@apply` and `important` together. Basically, the following code, along with the detected utility `flex` in source files… ```css @import 'tailwindcss/utilities' important; .flex-explicitly-important { @apply flex!; } .flex-not-important { @apply flex; } ``` … would output this: ```css .flex { display: flex !important; } .flex-explicitly-important { display: flex !important; } .flex-not-important { display: flex !important; } ``` But it's expected that `@apply` doesn't consider the "global" important state. This PR addresss this problem and now the output is this: ```css .flex { display: flex !important; } .flex-explicitly-important { display: flex !important; } .flex-not-important { display: flex; /* this line changed */ } ``` If you want to mark a utility as important in `@apply` you can still use `!` after the utility to do so as shown above. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-06-27 11:55:15 -04:00
### Fixed
- Don't consider the global important state in `@apply` ([#18404](https://github.com/tailwindlabs/tailwindcss/pull/18404))
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
- Add missing suggestions for `flex-<number>` utilities ([#18642](https://github.com/tailwindlabs/tailwindcss/pull/18642))
Fix trailing `)` from interfering with extraction in Clojure keywords (#18345) ## Summary In a form like, ```clojure (if condition :bg-white :bg-black) ``` `:bg-black` will fail to extract, while `:bg-white` is extracted as expected. This PR fixes this case, implements more comprehensive candidate filtering, and supersedes a previous PR. Having recently submitted a PR for handling another special case with Clojure keywords (the presence of `:` inside of keywords), I thought it best to invert the previous strategy: Instead of handling special cases one by one, consume keywords according to the Clojure reader spec. Consume nothing else, other than strings. Because of this, this PR is a tad more invasive rather than additive, for which I apologize. The strategy is this: - Strings begin with a `"` and ends with an unescaped `"`. Consume everything between these delimiters (existing case). - Keywords begin with `:`, and end with whitespace, or one out of a small set of specific reserved characters. Everything else is a valid character in a keyword. Consume everything between these delimiters, and apply the class splitting previously contained in the outer loop. My previous special case handling of `:` inside of keywords in #18338 is now redundant (and is removed), as this is a more general solution. - Discard _everything else_. I'm hoping that a strategy that is based on Clojure's definition of strings and keywords will pre-empt any further issues with edge cases. Closes #18344. ## Test plan - Added failing tests. - `cargo test` -> failure - Added fix - `cargo test` -> success --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-06-30 18:23:38 +02:00
- Fix trailing `)` from interfering with extraction in Clojure keywords ([#18345](https://github.com/tailwindlabs/tailwindcss/pull/18345))
Detect classes inside Elixir charlist, word list, and string sigils (#18432) Fixes #18431 The `~W(…)` syntax in Elixir is a _sigil_. It's basically another way to write strings, arrays of strings, etc… The syntax lets you use a handful of surrounding brackets like `~W(…)`, `~W[…]`, `~W{…}`, `~W"…"`, etc… to let you write lists without necessarily having to escape characters. In v3 our extractor was able to pick these up but in v4 Oxide does not. I've added a preprocessor for Elixir files so we can modify the code before our main extractor sees it. Now things like this: `~W(text-white bg-gray-600)` will get turned into ` ~W text-white bg-gray-600 ` which can easily be processed by our extractor. The sigils we support are: - `~s` / `~S` (strings) - `~w` / `~W` (word lists) - `~c` / `~C` (charlists) We're specifically detecting the use of `(…)`, `[…]`, and `{…}` as using quotes already works today. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-07-02 16:01:13 -04:00
- Detect classes inside Elixir charlist, word list, and string sigils ([#18432](https://github.com/tailwindlabs/tailwindcss/pull/18432))
Track source locations through `@plugin` and `@config` (#18329) Fixes https://github.com/tailwindlabs/tailwindcss-forms/issues/182 Inside JS plugins and configs we weren't tracking source location info so using things like `addBase(…)` could result in warnings inside Vite's url rewriting PostCSS plugin because not all declarations had a source location. The goal here is for calls to `addBase` to generate CSS that points back to the `@plugin` or `@config` that resulted in it being called.
2025-07-03 11:20:54 -04:00
- Track source locations through `@plugin` and `@config` ([#18345](https://github.com/tailwindlabs/tailwindcss/pull/18345))
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
- Allow boolean values of `process.env.DEBUG` in `@tailwindcss/node` ([#18485](https://github.com/tailwindlabs/tailwindcss/pull/18485))
Ignore consecutive semicolons in the CSS parser (#18532) Fixes #18523 I swear I'd already landed this but apparently not.
2025-07-14 11:44:31 -04:00
- Ignore consecutive semicolons in the CSS parser ([#18532](https://github.com/tailwindlabs/tailwindcss/pull/18532))
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
- Center the dropdown icon added to an input with a paired datalist by default ([#18511](https://github.com/tailwindlabs/tailwindcss/pull/18511))
Add support for Slang template (#18565) ## Summary Slang is basically a Slim template language for Crystal language, so the very same Slim parser works fine. Slim template: https://github.com/slim-template/slim Slang template: https://github.com/jeromegn/slang ## Test plan Create a simple slang file with some tailwind-css and check if the CSS is being extracted: ```slim doctype html html head title This is a title body.min-h-screen header.stick.top-0.z-10 section.max-w-4xl.mx-auto.p-4.flex.items-center.justify-between h1.text-3xl.font-medium This is a slang file ``` To test it, get any slim template, rename the extension to .slang Fixes #17851 --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-07-17 15:10:19 -03:00
- Extract candidates in Slang templates ([#18565](https://github.com/tailwindlabs/tailwindcss/pull/18565))
Show more specific error for functional-like but invalid utility names (#18568) Fixes #18566 The behavior is by design but the error message could definitely be improved.
2025-07-18 12:31:19 -04:00
- Improve error messages when encountering invalid functional utility names ([#18568](https://github.com/tailwindlabs/tailwindcss/pull/18568))
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
- Discard CSS AST objects with `false` or `undefined` properties ([#18571](https://github.com/tailwindlabs/tailwindcss/pull/18571))
- Allow users to disable URL rebasing in `@tailwindcss/postcss` via `transformAssetUrls: false` ([#18321](https://github.com/tailwindlabs/tailwindcss/pull/18321))
Fix false-positive migrations in `addEventListener` and JavaScript variable names (#18718) This PR fixes 2 false-positives when running the upgrade tool on a Tailwind CSS v3 project converting it to a Tailwind CSS v4 project. The issue occurs around migrations with short simple names that have a meaning outside if Tailwind CSS, e.g. `blur` and `outline`. This PR fixes 2 such cases: 1. The `addEventListener` case: ```js document.addEventListener('blur', handleBlur) ``` We do this by special casing the `addEventListener(` case and making sure the first argument to `addEventListener` is never migrated. 2. A JavaScript variable with default value: ```js function foo({ foo = "bar", outline = true, baz = "qux" }) { // ... } ``` The bug is relatively subtle here, but it has actually nothing to do with `outline` itself, but rather the fact that some quote character came before and after it on the same line... One of our heuristics for determining if a migration on these small words is safe, is to ensure that the candidate is inside of a string. Since we didn't do any kind of quote balancing, we would consider the `outline` to be inside of a string, even though it is not. So to actually solve this, we do some form of quote balancing to ensure that it's _not_ inside of a string in this case. Additionally, this PR also introduces a small refactor to the `is-safe-migration.test.ts` file where we now use a `test.each` to ensure that failing tests in the middle don't prevent the rest of the tests from running. ### Test plan 1. Added dedicated tests for the cases mentioned in the issue (#18675). 2. Added a few more tests with various forms of whitespace. Fixes: #18675
2025-08-12 15:48:35 +02:00
- Fix false-positive migrations in `addEventListener` and JavaScript variable names ([#18718](https://github.com/tailwindlabs/tailwindcss/pull/18718))
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
- Fix Standalone CLI showing default Bun help when run via symlink on Windows ([#18723](https://github.com/tailwindlabs/tailwindcss/pull/18723))
Add --border-color to divide theme keys (#18704) ## Summary In Tailwind 3 the border colors were able to be used with `divide` utilities. I made it so that's true for Tailwind 4. ## Test plan Just used `pnpm run tdd` and making it fails then making sure it passes. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-08-13 10:44:44 -04:00
- Read from `--border-color-*` theme keys in `divide-*` utilities for backwards compatibility ([#18704](https://github.com/tailwindlabs/tailwindcss/pull/18704/))
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
- Don't scan `.hdr` and `.exr` files for classes by default ([#18734](https://github.com/tailwindlabs/tailwindcss/pull/18734))
Prepare 4.1.11 (#18397)
2025-06-26 12:43:17 +02:00
## [4.1.11] - 2025-06-26
### Fixed
Add heuristic to skip candidate migrations inside `emit(…)` (#18330) Fixes #18318
2025-06-17 12:49:33 -04:00
- Add heuristic to skip candidate migrations inside `emit(…)` ([#18330](https://github.com/tailwindlabs/tailwindcss/pull/18330))
Update changelog
2025-06-18 12:38:54 -04:00
- Extract candidates with variants in Clojure/ClojureScript keywords ([#18338](https://github.com/tailwindlabs/tailwindcss/pull/18338))
Document `--watch=always` in the CLI (#18337) Closes https://github.com/tailwindlabs/tailwindcss.com/issues/1835 We had this in v3 as an undocumented option. We still have it in v4 but it's not documented under the CLI usage but should be. This PR adds this. **before** <img width="803" alt="Screenshot 2025-06-18 at 09 41 40" src="https://github.com/user-attachments/assets/c3becf11-e31d-4355-9d23-bddd0b2fc4a6" /> **after** <img width="1152" alt="Screenshot 2025-06-18 at 09 41 20" src="https://github.com/user-attachments/assets/4f61a156-680d-4f39-b92d-7f0f63270689" />
2025-06-19 14:52:47 -04:00
- Document `--watch=always` in the CLI's usage ([#18337](https://github.com/tailwindlabs/tailwindcss/pull/18337))
feat: add Vite 7 support to the @tailwindcss/vite plugin (#18384) Closes #18381 * [Changelog for Vite 7.0.0 (2025-06-24)](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#700-2025-06-24) Starting from Vite 7, Node 18 support will be dropped, which doesn't really affect Tailwind. It might be worth mentioning in the documentation that the recommended minimum Node versions are 20.19 and 22.12. Vite 7 is only available in ESM format, which is also not an issue. Vite's browser support aligns with the v4 guidelines: ``` Chrome 87 → 107 (tw: 111) Edge 88 → 107 (tw: 111) Firefox 78 → 104 (tw: 128) Safari 14.0 → 16.0 (tw: 16.4) ``` * [Vite 7 - Browser Support](https://vite.dev/guide/migration.html#default-browser-target-change) * [Tailwind CSS v4 - Browser Support](https://tailwindcss.com/docs/compatibility#browser-support) So, at first glance, there's nothing more to do except enabling support for these versions. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-06-24 18:31:17 +02:00
- Add support for Vite 7 to `@tailwindcss/vite` ([#18384](https://github.com/tailwindlabs/tailwindcss/pull/18384))
Prepare v4.1.10 (#18290)
2025-06-11 22:26:51 +02:00
## [4.1.10] - 2025-06-11
Fix missing space around `-` when using `%` regression (#18289) This PR fixes a regression we shipped in v4.1.9, when using arbitrary values and injecting spaces around operator. When you use `w-[calc(100%-var(--foo))]`, you expect that this generates valid CSS: ```css width: calc(100% - var(--foo)); ``` But due to a regression, we generated: ```css width: calc(100%-var(--foo)); ``` Which is invalid CSS. This is because the algorithm we used to know when we had to inject a space around the `-` didn't take the `%` sign into account. We also didn't handle uppercase units like `123PX` properly. This PR fixes both issues. ## Test plan 1. Added a regression test for the `%` 2. Added a regression test for uppercase units like `123PX` Fixes: #18288
2025-06-11 22:18:14 +02:00
### Fixed
update changelog drop the `:`
2025-06-11 23:21:39 +02:00
- Fix incorrectly generated CSS when using percentages in arbitrary values with calc (e.g. `w-[calc(100%-var(--offset))]`) ([#18289](https://github.com/tailwindlabs/tailwindcss/pull/18289))
Prepare v4.1.9 (#18285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-06-11 15:57:38 +02:00
## [4.1.9] - 2025-06-11
Improve upgrade migrations (#18184) This PR fixes 2 issues with the migration tool where certain classes weren't migrated. This PR fixes those 2 scenarios: ### Scenario 1 When you have an arbitrary opacity modifier that doesn't use `%`, but is just a number typically between `0` and `1` then this was not converted to the bare value equivalent before. E.g.: ```html <div class="bg-[#f00]/[0.16]"></dv> ``` Will now be converted to: ```html <div class="bg-[#f00]/16"></dv> ``` ### Scenario 2 Fixes a bug when a CSS function was used in a fallback value in the CSS variable shorthand syntax. In that case we didn't migrate the class to the new syntax. This was because we assumed that a `(` was found, that we are dealing with a CSS function. E.g.: ```html <div class="w-[--spacing(1)]"></div> ^ This indicates a CSS function, we should not be converting this to `w-(--spacing(1))` ``` But if a function was used as a fallback value, for example: ```html <div class="bg-[--my-color,theme(colors.red.500)]"></dv> ``` Then we also didn't migrate it, but since the function call is in the fallback, we can still migrate it. Will now properly be converted to: ```html <div class="bg-(--my-color,var(--color-red-500))"></dv> ``` ## Test plan 1. Added a test for the first case 2. Added a test for the second case 3. Also added an integration-like test that runs all the migration steps to make sure that the `theme(…)` in the fallback also gets updated to `var(…)`. This one caught an issue because the `var(…)` wasn't handling prefixes correctly.
2025-05-30 15:32:59 +02:00
### Fixed
CSS Parser: Handle string with semi-colon in custom properties. (#18251) Strings are not parsed correctly for custom properties which makes the following CSS raise an `Unterminated string: ";"` error: ```css :root { --custom: 'data:text/plain;base64,SGVsbG8sIFdvcmxkIQ=='; } ``` According to the spec, we should accept semi-colon as long as they are not at the top level. > The allowed syntax for [custom properties](https://drafts.csswg.org/css-variables/#custom-property) is extremely permissive. The <declaration-value> production matches any sequence of one or more tokens, so long as the sequence does not contain bad-string-token, bad-url-token, unmatched )-token, ]-token, or }-token, or top-level semicolon-token tokens or delim-token tokens with a value of "!". Extract from: https://drafts.csswg.org/css-variables/#syntax I was only able to reproduce with **tailwindcss v4**, the previous version seems to support this. This issue is mitigated by the fact that even if you want to use a data URL in a custom property, you would need to wrap the value in a `url()` anyway: ```css :root { --my-icon-url: url('data:image/svg+xml;base64,...=='); } .icon { background-image: var(--my-icon-url); } ``` Which works perfectly fine with the current/latest version (v4.1.8). The fix suggested is to share the same code between regular property and custom property when it comes to detect that the value is a string starting with a `SINGLE_QUOTE` or `DOUBLE_QUOTE`. I have moved the existing code in a `findEndStringIdx` which returns the position of the ending single/double quote. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-06-09 16:03:44 +02:00
- Correctly parse custom properties with strings containing semicolons ([#18251](https://github.com/tailwindlabs/tailwindcss/pull/18251))
Prepare v4.1.9 (#18285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-06-11 15:57:38 +02:00
- Upgrade: Migrate arbitrary modifiers without percentage signs to bare values (e.g. `/[0.16]` → `/16`) ([#18184](https://github.com/tailwindlabs/tailwindcss/pull/18184))
- Upgrade: Migrate CSS variable shorthands where fallback value contains function call ([#18184](https://github.com/tailwindlabs/tailwindcss/pull/18184))
- Upgrade: Migrate negative arbitrary values to negative bare values (e.g. `mb-[-32rem]` → `-mb-128`) ([#18212](https://github.com/tailwindlabs/tailwindcss/pull/18212))
Do not migrate `blur` in `wire:model.blur` (#18216) This PR fixes an issue where the `blur` in `wire:model.blur="…"` was incorrectly migrated. We solved it by marking `wire:…` as an unsafe region (`…` can be anything but whitespace). Fixes: #18187 ## Test plan Added a test with this use case --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-06-03 20:27:59 +02:00
- Upgrade: Do not migrate `blur` in `wire:model.blur` ([#18216](https://github.com/tailwindlabs/tailwindcss/pull/18216))
fix: don't break CSS keywords when formatting math expressions (#18220) Fixes #18219 ## Summary In an arbitrary value, if there's a non-numeric character both before and after a hyphen, there's no need for a space. ## Test plan `decodeArbitraryValue` will correctly format special CSS values like `fit-content`. I believe spaces are only necessary if there's a digit either before or after the hyphen. ```js decodeArbitraryValue('min(fit-content,calc(100dvh-4rem))') ``` This way, the result of the following arbitrary value will also be correct: ```html <div class="min-h-[min(fit-content,calc(100dvh-4rem))]"></div> ``` ```css .min-h-\[min\(fit-content\,calc\(100dvh-4rem\)\)\] { min-height: min(fit-content, calc(100dvh - 4rem)); } ``` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-06-10 16:38:31 +02:00
- Don't add spaces around CSS dashed idents when formatting math expressions ([#18220](https://github.com/tailwindlabs/tailwindcss/pull/18220))
Release v4.1.8 (#18164) Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-05-28 17:01:27 +02:00
## [4.1.8] - 2025-05-27
Improve error messages when `@apply` fails (#18059) This PR improves error messages when `@apply` fails. Right now it gives you a generic error message that you cannot apply a certain utility. ```css .foo { @apply bg-red-500; } ``` Would result in: ``` Cannot apply unknown utility class: bg-red-500 ``` However, there are some situations where we can give you more context about what's happening. ### Missing `@import "tailwindcss"` or `@reference` If you are in a Vue file for example, and you have the following code: ```vue <template> <div class="foo"></div> </template> <style> .foo { @apply bg-red-500; } </style> ``` Then this will now result in: ``` Cannot apply unknown utility class `bg-white`. Are you using CSS modules or similar and missing `@reference`? https://tailwindcss.com/docs/functions-and-directives#reference-directive ``` We do this by checking if we found a `@tailwind utilities` or `@reference`. If not, we throw this more specific error. ### Explicitly excluded classes via `@source not inline('…')` Or via the legacy `blocklist` from a JS config. If you then have the following file: ```css @import "tailwindcss"; @source not inline('bg-white'); .foo { @apply bg-white; } ``` Then this will now result in: ``` Cannot apply utility class `bg-white` because it has been explicitly disabled: https://tailwindcss.com/docs/detecting-classes-in-source-files#explicitly-excluding-classes ``` We do this by checking if the class was marked as invalid. ### Applying unprefixed class in prefix mode If you have the prefix option configured, but you are applying a non-prefixed class, then we will show the following error: Given this input: ```css @import "tailwindcss" prefix(tw); .foo { @apply underline; } ``` The following error is thrown: ``` Cannot apply unprefixed utility class `underline`. Did you mean `tw:underline`? ``` ### Applying known utilities with unknown variants If you have unknown variants, then we will list them as well if the base utility does compile correctly. Given this input: ```css @import "tailwindcss"; .foo { @apply hocus:hover:pocus:bg-red-500; } ``` The following error is thrown: ``` Cannot apply utility class `hocus:hover:pocus:bg-red-500` because the `hocus` and `pocus` variants do not exist. ``` ## Test plan 1. Everything behaves the same, but the error messages give more details. 2. Updated tests with new error messages 3. Added new unit tests to verify the various scenarios 4. Added a Vue specific integration test with a `<style>…</style>` block using `@apply` [ci-all] There are some newlines here and there, let's verify that they work identically on all platforms. --------- Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
2025-05-27 20:19:14 +02:00
### Added
- Improve error messages when `@apply` fails ([#18059](https://github.com/tailwindlabs/tailwindcss/pull/18059))
Do not migrate declarations in `<style>` blocks (#18057) This PR improves the upgrade tool by making sure that we don't migrate CSS declarations in `<style>…</style>` blocks. We do this by making sure that: 1. We detect a declaration, the current heuristic is that the candidate is: - Preceded by whitespace - Followed by a colon and whitespace ```html <style> .foo { flex-shrink: 0; ^ ^^ } </style> ``` 2. We are in a `<style>…</style>` block ```html <style> ^^^^^^ .foo { flex-shrink: 0; } </style> ^^^^^^^^ ``` The reason we have these 2 checks is because just relying on the first heuristic alone, also means that we will not be migrating keys in JS objects, because they typically follow the same structure: ```js let classes = { flex: 0, ^ ^^ } ``` Another important thing to note is that we can't just ignore anything in between `<style>…</style>` blocks, because you could still be using `@apply` that we _do_ want to migrate. Last but not least, the first heuristics is not perfect either. If you are writing minified CSS then this will likely fail if there is no whitespace around the candidate. But my current assumption is that nobody should be writing minified CSS, and minified CSS will very likely be generated and gitignored. In either situation, replacements in minified CSS will not be any worse than it is today. I'm open to suggestions for better heuristics. ## Test plan 1. Added an integration test that verifies that we do migrate `@apply` and don't migrate the `flex-shrink: 0;` declaration. Fixes: #17975
2025-05-16 12:53:34 +02:00
### Fixed
Improve performance of upgrade tool (#18068) This PR improves the performance of the upgrade tool due to a regression introduced by https://github.com/tailwindlabs/tailwindcss/pull/18057 Essentially, we had to make sure that we are not in `<style>…</style>` tags because we don't want to migrate declarations in there such as `flex-shrink: 0;` The issue with this approach is that we checked _before_ the candidate if a `<style` cold be found and if we found an `</style>` tag after the candidate. We would basically do this check for every candidate that matches. Running this on our Tailwind UI codebase, this resulted in a bit of a slowdown: ```diff - Before: ~13s + After: ~5m 39s ``` ... quite the difference. This is because we have a snapshot file that contains ~650k lines of code. Looking for `<style>` and `</style>` tags in a file that large is expensive, especially if we do it a lot. I ran some numbers and that file contains ~1.8 million candidates. Anyway, this PR fixes that by doing a few things: 1. We will compute the `<style>` and `</style>` tag positions only once per file and cache it. This allows us to re-use this work for every candidate that needs it. 2. We track the positions, which means that we can simply check if a candidate's location is within any of 2 start and end tags. If so, we skip it. Running the numbers now gets us to: ```diff - Before: ~5m 39s + After: ~9s ``` Much better! --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-05-19 16:41:40 +02:00
- Upgrade: Do not migrate declarations that look like candidates in `<style>` blocks ([#18057](https://github.com/tailwindlabs/tailwindcss/pull/18057), [18068](https://github.com/tailwindlabs/tailwindcss/pull/18068))
Release v4.1.8 (#18164) Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-05-28 17:01:27 +02:00
- Upgrade: Don't error when looking for `tailwindcss` in pnpm monorepos ([#18065](https://github.com/tailwindlabs/tailwindcss/pull/18065))
- Upgrade: Don't error when updating dependencies in pnpm monorepos ([#18065](https://github.com/tailwindlabs/tailwindcss/pull/18065))
Upgrade deprecated `order-none` to `order-0` (#18126) This PR adds an initial version for deprecated utilities. Right now it's hardcoded to just the `order-none` utility. This means that `order-0` and `order-[0]` will not be migrated to `order-none` anymore. We did that automatically because we prefer named utilities over bare values and arbitrary values. With this PR, `order-none` is ignored. Similarly, `order-none` will be migrated to `order-0` instead (defined in a separate migration for deprecated values). Made it a new migration instead of using the legacy migration because there all utilities still exist, but are defined differently (e.g.: `shadow`, `shadow-sm`, `shadow-xs`). This PR is also an initial version, it doesn't add any form of `deprecated` flag or feature on a per-utility implementation basis. This therefor has the side effect that if you have a custom `order-none` defined, that it will also be ignored during migrations. ## Test plan 1. Added tests to ensure the `order-0` is not migrated to `order-none` 2. Added tests to ensure `order-none` is migrated to `order-0` (if it's safe to do so, the signature is still computed to ensure the output is the same). 3. Ran this on the Tailwind Plus codebase and ensured that `order-0` is not migrated to `order-none` and that `order-none` is migrated to `order-0`. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-05-23 17:21:21 +02:00
- Upgrade: Migrate deprecated `order-none` to `order-0` ([#18126](https://github.com/tailwindlabs/tailwindcss/pull/18126))
Support Leptos `class:` attributes (#18093) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create a discussion to first discuss any significant new features. For more info, check out the contributing guide: https://github.com/tailwindcss/tailwindcss/blob/main/.github/CONTRIBUTING.md --> Fixes #18092 ## Summary Using the Svelte preprocessor for Rust files we can support Leptos `class:` attributes syntax. ## Test plan ``` pnpm t ``` --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-05-23 12:15:33 +02:00
- Support Leptos `class:` attributes when extracting classes ([#18093](https://github.com/tailwindlabs/tailwindcss/pull/18093))
Fix "Cannot read properties of undefined" crash on malformed arbitrary value (#18133) This PR fixes a crash when an arbitrary value was malformed and crashed the build. If you have a utility like `[--btn-border:var(--color-maroon)/90)]` which is malformed, it will crash the build. It might not be easy to spot but the easy is the additional `)` after the `90`. The reason this crashes is because we parse the value `var(--color-maroon)/90)` and when we see `)` we assume it's the end of a "function" which also assumes it was preceded by a `(`. This is not the case and we crash. This PR fixes that by not assuming the parsed object is available and uses `?` to be safe and only access `nodes` if it's available. I'm actually not 100% sure what the best solution is in this scenario because these candidates could (and will) be returned from Oxide so even if we throw a more descriptive error, it will still crash the build and you might not even have control over the candidate. This candidate will now eventually generate the following CSS: ```css .\[--btn-border\:var\(--color-maroon\)\/90\)\] { --btn-border: var(--color-maroon) / ; } ``` Which still looks odd, but even Lightning CSS doesn't throw an error in this case (because it's a CSS variable definition), so I think it's the best we can do. If you open your devtools you will see the weird values, so it's still debug-able. <img width="359" alt="image" src="https://github.com/user-attachments/assets/2eb48662-64de-4417-a2da-1577bf9075b5" /> Fixes: #17064 ## Test plan Manually tested the candidate that crashed it, and after the change generated the above CSS. Then used it in JSFiddle to proof it's fixed now. https://jsfiddle.net/z850ykew/ Couldn't use Tailwind Play because the candidate will cause a crash there as well 😅
2025-05-23 21:59:02 +02:00
- Fix "Cannot read properties of undefined" crash on malformed arbitrary value ([#18133](https://github.com/tailwindlabs/tailwindcss/pull/18133))
Fix migrating `mt-[0px]` to `-mt-[0px]` instead of the other way around (#18154) I was testing to upgrade tool on various random projects just to see how it behaves. Then I noticed an odd migration... This PR fixes an issue where the upgrade tool accidentally migrated classes such as `mt-[0px]` to `-mt-[0px]`. The reason for this is because we are trying to find a replacement, and the computed signature for both of them are exactly the same. - `mt-[0px]` translates to: ```css .x { margin-top: 0px; } ``` - `-mt-[0px]` translates to: ```css .x { margin-top: calc(0px * -1); } ``` Which in turn translates to ```css .x { margin-top: 0px; } ``` Notice that this is `0px`, not `-0px`. Internally we use the roots of functional utilities to find replacements. For intellisense purposes we typically show negative versions before positive versions. This then means that we will try `-mt-*` before `mt-*`. Because of the signature above, the `mt-[0px]` was translated into `-mt-[0px]`. We could solve this in a few ways. The first thing we can try is to make sure that the signature is not the same and that `-mt-[0px]` actually translates into `-0px` not `0px`. This would solve our problem of the accidental migration. However, if we _just_ sort the functional utilities roots such that the positive versions exist before negative version and rely on the fact that `-mt-[0px]` has the same signature. Then it also means that by doing that we can migrate `-mt-[0px]` into `mt-[0px]` which is even better because it's the same result and shorter. ## Test plan 1. Added a test to verify that `mt-[0px]` does not get migrated to `-mt-[0px]`. 2. Added a test to verify that `-mt-[0px]` does get migrated to `mt-[0px]`.
2025-05-26 16:29:22 +02:00
- Upgrade: Migrate `-mt-[0px]` to `mt-[0px]` instead of the other way around ([#18154](https://github.com/tailwindlabs/tailwindcss/pull/18154))
Fix Haml pre-processing crash when there is no `\n` at the end of the file (#18155) This PR fixes a Haml pre-processing issue where a crash occurs if there is no trailing `\n` at the end of the file and the code before it was considered Ruby code. This happens in situations where Ruby code was used. E.g.: ``` - index = 0 - index += 1 ``` In this situation when we see the `-` on the second line, then we will find the whole indented block and parse it as Ruby code instead. The block ands at the last `\n`, but since we reach the end of the file, there is no `\n`. Right now we incorrectly reset the internal cursor to the last known `\n` position. This means that the `start` of the Ruby block will be _after_ the `end` of the Ruby block and the Haml parser will crash. To solve this, once we reach the end of the file, we don't reset the cursor to the wrong position. Fixes: https://github.com/tailwindlabs/tailwindcss/issues/17379#issuecomment-2910108646 ## Test plan 1. Added a regression test that did fail before the fix, and doesn't anymore
2025-05-26 18:52:44 +02:00
- Fix Haml pre-processing crash when there is no `\n` at the end of the file ([#18155](https://github.com/tailwindlabs/tailwindcss/pull/18155))
Ignore `.pnpm-store` in Oxide (#18163) Fixes #18148
2025-05-27 13:02:10 -04:00
- Ignore `.pnpm-store` folders by default (can be overridden by `@source …` rules) ([#18163](https://github.com/tailwindlabs/tailwindcss/pull/18163))
Release v4.1.8 (#18164) Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-05-28 17:01:27 +02:00
- Fix PostCSS crash when calling `toJSON()` ([#18083](https://github.com/tailwindlabs/tailwindcss/pull/18083))
Allow `_` before numbers during candidate extraction (#17961) This PR fixes a bug where a class like `header_1` wasn't properly extracted because we didn't allow an `_` before a number. This PR fixes that by allowing an `_` before a number. Fixes: #17960 ## Test plan 1. Added a test to verify this works 2. Existing tests work Used the visualizer tool for this to verify that the `header_1` class is being extracted: <img width="1816" alt="image" src="https://github.com/user-attachments/assets/fdc21602-0e2b-4e4e-92a1-19c4f4f5393f" />
2025-05-09 18:29:28 +02:00
Prepare v4.1.7 release (#18040) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-15 15:31:18 +02:00
## [4.1.7] - 2025-05-15
Prepare v4.1.6 release (#17951) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-09 15:39:18 +02:00
Migrate bare values to named values (#18000) This PR improves the upgrade tool by also migrating bare values to named values defined in the `@theme`. Recently we shipped some updates dat allowed us to migrate arbitrary values (with square brackets), but we didn't migrate bare values yet. That means that in this example: ```html <div class="aspect-[16/9]"></div> <div class="aspect-16/9"></div> ``` We migrated this to: ```html <div class="aspect-video"></div> <div class="aspect-16/9"></div> ``` With this change, we will also try and migrate the bare value to a named value. So this example: ```html <div class="aspect-[16/9]"></div> <div class="aspect-16/9"></div> ``` Now becomes: ```html <div class="aspect-video"></div> <div class="aspect-video"></div> ``` ## Test plan 1. Added unit tests for the new functionality. 2. Ran this on a local project Before: <img width="432" alt="image" src="https://github.com/user-attachments/assets/ce1adfbd-7be1-4062-bea5-66368f748e44" /> After: <img width="382" alt="image" src="https://github.com/user-attachments/assets/a385c94c-4e4c-4e1c-ac73-680c56ac4081" />
2025-05-13 17:35:11 +02:00
### Added
- Upgrade: Migrate bare values to named values ([#18000](https://github.com/tailwindlabs/tailwindcss/pull/18000))
Prepare v4.1.7 release (#18040) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-15 15:31:18 +02:00
- Upgrade: Added cache to improve template migration performance ([#18025](https://github.com/tailwindlabs/tailwindcss/pull/18025))
### Fixed
- Allow `_` before numbers during candidate extraction ([#17961](https://github.com/tailwindlabs/tailwindcss/pull/17961))
- Prevent duplicate suggestions when using `@theme` and `@utility` together ([#17675](https://github.com/tailwindlabs/tailwindcss/pull/17675))
- Ensure that media queries within `::before` and `::after` pseudo selectors create valid CSS rules in production builds ([#17979](https://github.com/tailwindlabs/tailwindcss/pull/17979))
- Ensure that the standalone CLI does not leave temporary files behind ([#17981](https://github.com/tailwindlabs/tailwindcss/pull/17981))
- Ensure `-rotate-*` utilities properly negate arbitrary values ([#18014](https://github.com/tailwindlabs/tailwindcss/pull/18014))
- Ignore custom variants using `:merge(…)` selectors in legacy JS plugins ([#18020](https://github.com/tailwindlabs/tailwindcss/pull/18020))
- Ensure classes containing `.` are properly extracted from Clojure files ([#18038](https://github.com/tailwindlabs/tailwindcss/pull/18038))
- Upgrade: Fix error when using `@import … source(…)` ([#17963](https://github.com/tailwindlabs/tailwindcss/pull/17963))
- Upgrade: Change casing of utilities with named values to kebab-case to match updated theme variables ([#18017](https://github.com/tailwindlabs/tailwindcss/pull/18017))
- Upgrade: Don't migrate strings that match utility names in Vue attribute bindings other than `class` ([#18025](https://github.com/tailwindlabs/tailwindcss/pull/18025))
Migrate bare values to named values (#18000) This PR improves the upgrade tool by also migrating bare values to named values defined in the `@theme`. Recently we shipped some updates dat allowed us to migrate arbitrary values (with square brackets), but we didn't migrate bare values yet. That means that in this example: ```html <div class="aspect-[16/9]"></div> <div class="aspect-16/9"></div> ``` We migrated this to: ```html <div class="aspect-video"></div> <div class="aspect-16/9"></div> ``` With this change, we will also try and migrate the bare value to a named value. So this example: ```html <div class="aspect-[16/9]"></div> <div class="aspect-16/9"></div> ``` Now becomes: ```html <div class="aspect-video"></div> <div class="aspect-video"></div> ``` ## Test plan 1. Added unit tests for the new functionality. 2. Ran this on a local project Before: <img width="432" alt="image" src="https://github.com/user-attachments/assets/ce1adfbd-7be1-4062-bea5-66368f748e44" /> After: <img width="382" alt="image" src="https://github.com/user-attachments/assets/a385c94c-4e4c-4e1c-ac73-680c56ac4081" />
2025-05-13 17:35:11 +02:00
Prepare v4.1.6 release (#17951) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-09 15:39:18 +02:00
## [4.1.6] - 2025-05-09
Design system driven upgrade migrations (#17831) This PR introduces a vastly improved upgrade migrations system, to migrate your codebase and modernize your utilities to make use of the latest variants and utilities. It all started when I saw this PR the other day: https://github.com/tailwindlabs/tailwindcss/pull/17790 I was about to comment "Don't forget to add a migration". But I've been thinking about a system where we can automate this process away. This PR introduces this system. This PR introduces upgrade migrations based on the internal Design System, and it mainly updates arbitrary variants, arbitrary properties and arbitrary values. ## The problem Whenever we ship new utilities, or you make changes to your CSS file by introducing new `@theme` values, or adding new `@utility` rules. It could be that the rest of your codebase isn't aware of that, but you could be using these values. For example, it could be that you have a lot of arbitrary properties in your codebase, they look something like this: ```html <div class="[color-scheme:dark] [text-wrap:balance]"></div> ``` Whenever we introduce new features in Tailwind CSS, you probably don't keep an eye on the release notes and update all of these arbitrary properties to the newly introduced utilities. But with this PR, we can run the upgrade tool: ```console npx -y @tailwindcss/upgrade@latest ``` ...and it will upgrade your project to use the new utilities: ```html <div class="scheme-dark text-balance"></div> ``` It also works for arbitrary values, for example imagine you have classes like this: ```html <!-- Arbitrary property --> <div class="[max-height:1lh]"></div> <!-- Arbitrary value --> <div class="max-h-[1lh]"></div> ``` Running the upgrade tool again: ```console npx -y @tailwindcss/upgrade@latest ``` ... gives you the following output: ```html <!-- Arbitrary property --> <div class="max-h-lh"></div> <!-- Arbitrary value --> <div class="max-h-lh"></div> ``` This is because of the original PR I mentioned, which introduced the `max-h-lh` utilities. A nice benefit is that this output only has 1 unique class instead of 2, which also potentially reduces the size of your CSS file. It could also be that you are using arbitrary values where you (or a team member) didn't even know an alternative solution existed. E.g.: ```html <div class="w-[48rem]"></div> ``` After running the upgrade tool you will get this: ```html <div class="w-3xl"></div> ``` We can go further though. Since the release of Tailwind CSS v4, we introduced the concept of "bare values". Essentially allowing you to type a number on utilities where it makes sense, and we produce a value based on that number. So an input like this: ```html <div class="border-[123px]"></div> ``` Will be optimized to just: ```html <div class="border-123"></div> ``` This can be very useful for complex utilities, for example, how many times have you written something like this: ```html <div class="grid-cols-[repeat(16,minmax(0,1fr))]"></div> ``` Because up until Tailwind CSS v4, we only generated 12 columns by default. But since v4, we can generate any number of columns automatically. Running the migration tool will give you this: ```html <div class="grid-cols-16"></div> ``` ### User CSS But, what if I told you that we can keep going... In [Catalyst](https://tailwindcss.com/plus/ui-kit) we often use classes that look like this for accessibility reasons: ```html <div class="text-[CanvasText] bg-[Highlight]"></div> ``` What if you want to move the `CanvasText` and `Highlight` colors to your CSS: ```css @import "tailwincdss"; @theme { --color-canvas: CanvasText; --color-highlight: Highlight; } ``` If you now run the upgrade tool again, this will be the result: ```html <div class="text-canvas bg-highlight"></div> ``` We never shipped a `text-canvas` or `bg-highlight` utility, but the upgrade tool uses your own CSS configuration to migrate your codebase. This will keep your codebase clean, consistent and modern and you are in control. Let's look at one more example, what if you have this in a lot of places: ```html <div class="[scrollbar-gutter:stable]"></div> ``` And you don't want to wait for the Tailwind CSS team to ship a `scrollbar-stable` (or similar) feature. You can add your own utility: ```css @import "tailwincdss"; @utility scrollbar-stable { scrollbar-gutter: stable; } ``` ```html <div class="scrollbar-stable"></div> ``` ## The solution — how it works There are 2 big things happening here: 1. Instead of us (the Tailwind CSS team) hardcoding certain migrations, we will make use of the internal `DesignSystem` which is the source of truth for all this information. This is also what Tailwind CSS itself uses to generate the CSS file. The internal `DesignSystem` is essentially a list of all: 1. The internal utilities 2. The internal variants 3. The default theme we ship 4. The user CSS 1. With custom `@theme` values 2. With custom `@custom-variant` implementations 3. With custom `@utility` implementations 2. The upgrade tool now has a concept of `signatures` The signatures part is the most interesting one, and it allows us to be 100% sure that we can migrate your codebase without breaking anything. A signature is some unique identifier that represents a utility. But 2 utilities that do the exact same thing will have the same signature. To make this work, we have to make sure that we normalize values. One such value is the selector. I think a little visualization will help here: | UTILITY | GENERATED SIGNATURE | | ---------------- | ----------------------- | | `[display:flex]` | `.x { display: flex; }` | | `flex` | `.x { display: flex; }` | They have the exact same signature and therefore the upgrade tool can safely migrate them to the same utility. For this we will prefer the following order: 1. Static utilities — essentially no brackets. E.g.: `flex`, `grid-cols-2` 2. Arbitrary values — e.g.: `max-h-[1lh]`, `border-[2px]` 3. Arbitrary properties — e.g.: `[color-scheme:dark]`, `[display:flex]` We also have to canonicalize utilities to there minimal form. Essentially making sure we increase the chance of finding a match. ``` [display:_flex_] → [display:flex] → flex [display:_flex] → [display:flex] → flex [display:flex_] → [display:flex] → flex [display:flex] → [display:flex] → flex ``` If we don't do this, then the signatures will be slightly different, due to the whitespace: | UTILITY | GENERATED SIGNATURE | | ------------------ | ------------------------- | | `[display:_flex_]` | `.x { display: flex ; }` | | `[display:_flex]` | `.x { display: flex; }` | | `[display:flex_]` | `.x { display: flex ; }` | | `[display:flex]` | `.x { display: flex; }` | ### Other small improvements A few other improvements are for optimizing existing utilities: 1. Remove unnecessary data types. E.g.: - `bg-[color:red]` -> `bg-[red]` - `shadow-[shadow:inset_0_1px_--theme(--color-white/15%)]` -> `shadow-[inset_0_1px_--theme(--color-white/15%)]` This also makes use of these signatures and if dropping the data type results in the same signature then we can safely drop it. Additionally, if a more specific utility exists, we will prefer that one. This reduced ambiguity and the need for data types. - `bg-[position:123px]` → `bg-position-[123px]` - `bg-[123px]` → `bg-position-[123px]` - `bg-[size:123px]` → `bg-size-[123px]` 2. Optimizing modifiers. E.g.: - `bg-red-500/[25%]` → `bg-red-500/25` - `bg-red-500/[100%]` → `bg-red-500` - `bg-red-500/100` → `bg-red-500` 3. Hoist `not` in arbitrary variants - `[@media_not_(prefers-color-scheme:dark)]:flex` → `not-[@media_(prefers-color-scheme:dark)]:flex` → `not-dark:flex` (in case you are using the default `dark` mode implementation 4. Optimize raw values that could be converted to bare values. This uses the `--spacing` variable to ensure it is safe. - `w-[64rem]` → `w-256` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-05-02 23:18:06 +02:00
### Added
Prepare v4.1.6 release (#17951) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-09 15:39:18 +02:00
- Upgrade: Automatically convert arbitrary values to named values when possible (e.g. `h-[1lh]` to `h-lh`) ([#17831](https://github.com/tailwindlabs/tailwindcss/pull/17831), [#17854](https://github.com/tailwindlabs/tailwindcss/pull/17854))
- Upgrade: Update dependencies in parallel for improved performance ([#17898](https://github.com/tailwindlabs/tailwindcss/pull/17898))
- Add detailed logging about `@source` directives, discovered files and scanned files when using `DEBUG=*` ([#17906](https://github.com/tailwindlabs/tailwindcss/pull/17906), [#17952](https://github.com/tailwindlabs/tailwindcss/pull/17952))
- Add support for generating source maps in development ([#17775](https://github.com/tailwindlabs/tailwindcss/pull/17775))
Design system driven upgrade migrations (#17831) This PR introduces a vastly improved upgrade migrations system, to migrate your codebase and modernize your utilities to make use of the latest variants and utilities. It all started when I saw this PR the other day: https://github.com/tailwindlabs/tailwindcss/pull/17790 I was about to comment "Don't forget to add a migration". But I've been thinking about a system where we can automate this process away. This PR introduces this system. This PR introduces upgrade migrations based on the internal Design System, and it mainly updates arbitrary variants, arbitrary properties and arbitrary values. ## The problem Whenever we ship new utilities, or you make changes to your CSS file by introducing new `@theme` values, or adding new `@utility` rules. It could be that the rest of your codebase isn't aware of that, but you could be using these values. For example, it could be that you have a lot of arbitrary properties in your codebase, they look something like this: ```html <div class="[color-scheme:dark] [text-wrap:balance]"></div> ``` Whenever we introduce new features in Tailwind CSS, you probably don't keep an eye on the release notes and update all of these arbitrary properties to the newly introduced utilities. But with this PR, we can run the upgrade tool: ```console npx -y @tailwindcss/upgrade@latest ``` ...and it will upgrade your project to use the new utilities: ```html <div class="scheme-dark text-balance"></div> ``` It also works for arbitrary values, for example imagine you have classes like this: ```html <!-- Arbitrary property --> <div class="[max-height:1lh]"></div> <!-- Arbitrary value --> <div class="max-h-[1lh]"></div> ``` Running the upgrade tool again: ```console npx -y @tailwindcss/upgrade@latest ``` ... gives you the following output: ```html <!-- Arbitrary property --> <div class="max-h-lh"></div> <!-- Arbitrary value --> <div class="max-h-lh"></div> ``` This is because of the original PR I mentioned, which introduced the `max-h-lh` utilities. A nice benefit is that this output only has 1 unique class instead of 2, which also potentially reduces the size of your CSS file. It could also be that you are using arbitrary values where you (or a team member) didn't even know an alternative solution existed. E.g.: ```html <div class="w-[48rem]"></div> ``` After running the upgrade tool you will get this: ```html <div class="w-3xl"></div> ``` We can go further though. Since the release of Tailwind CSS v4, we introduced the concept of "bare values". Essentially allowing you to type a number on utilities where it makes sense, and we produce a value based on that number. So an input like this: ```html <div class="border-[123px]"></div> ``` Will be optimized to just: ```html <div class="border-123"></div> ``` This can be very useful for complex utilities, for example, how many times have you written something like this: ```html <div class="grid-cols-[repeat(16,minmax(0,1fr))]"></div> ``` Because up until Tailwind CSS v4, we only generated 12 columns by default. But since v4, we can generate any number of columns automatically. Running the migration tool will give you this: ```html <div class="grid-cols-16"></div> ``` ### User CSS But, what if I told you that we can keep going... In [Catalyst](https://tailwindcss.com/plus/ui-kit) we often use classes that look like this for accessibility reasons: ```html <div class="text-[CanvasText] bg-[Highlight]"></div> ``` What if you want to move the `CanvasText` and `Highlight` colors to your CSS: ```css @import "tailwincdss"; @theme { --color-canvas: CanvasText; --color-highlight: Highlight; } ``` If you now run the upgrade tool again, this will be the result: ```html <div class="text-canvas bg-highlight"></div> ``` We never shipped a `text-canvas` or `bg-highlight` utility, but the upgrade tool uses your own CSS configuration to migrate your codebase. This will keep your codebase clean, consistent and modern and you are in control. Let's look at one more example, what if you have this in a lot of places: ```html <div class="[scrollbar-gutter:stable]"></div> ``` And you don't want to wait for the Tailwind CSS team to ship a `scrollbar-stable` (or similar) feature. You can add your own utility: ```css @import "tailwincdss"; @utility scrollbar-stable { scrollbar-gutter: stable; } ``` ```html <div class="scrollbar-stable"></div> ``` ## The solution — how it works There are 2 big things happening here: 1. Instead of us (the Tailwind CSS team) hardcoding certain migrations, we will make use of the internal `DesignSystem` which is the source of truth for all this information. This is also what Tailwind CSS itself uses to generate the CSS file. The internal `DesignSystem` is essentially a list of all: 1. The internal utilities 2. The internal variants 3. The default theme we ship 4. The user CSS 1. With custom `@theme` values 2. With custom `@custom-variant` implementations 3. With custom `@utility` implementations 2. The upgrade tool now has a concept of `signatures` The signatures part is the most interesting one, and it allows us to be 100% sure that we can migrate your codebase without breaking anything. A signature is some unique identifier that represents a utility. But 2 utilities that do the exact same thing will have the same signature. To make this work, we have to make sure that we normalize values. One such value is the selector. I think a little visualization will help here: | UTILITY | GENERATED SIGNATURE | | ---------------- | ----------------------- | | `[display:flex]` | `.x { display: flex; }` | | `flex` | `.x { display: flex; }` | They have the exact same signature and therefore the upgrade tool can safely migrate them to the same utility. For this we will prefer the following order: 1. Static utilities — essentially no brackets. E.g.: `flex`, `grid-cols-2` 2. Arbitrary values — e.g.: `max-h-[1lh]`, `border-[2px]` 3. Arbitrary properties — e.g.: `[color-scheme:dark]`, `[display:flex]` We also have to canonicalize utilities to there minimal form. Essentially making sure we increase the chance of finding a match. ``` [display:_flex_] → [display:flex] → flex [display:_flex] → [display:flex] → flex [display:flex_] → [display:flex] → flex [display:flex] → [display:flex] → flex ``` If we don't do this, then the signatures will be slightly different, due to the whitespace: | UTILITY | GENERATED SIGNATURE | | ------------------ | ------------------------- | | `[display:_flex_]` | `.x { display: flex ; }` | | `[display:_flex]` | `.x { display: flex; }` | | `[display:flex_]` | `.x { display: flex ; }` | | `[display:flex]` | `.x { display: flex; }` | ### Other small improvements A few other improvements are for optimizing existing utilities: 1. Remove unnecessary data types. E.g.: - `bg-[color:red]` -> `bg-[red]` - `shadow-[shadow:inset_0_1px_--theme(--color-white/15%)]` -> `shadow-[inset_0_1px_--theme(--color-white/15%)]` This also makes use of these signatures and if dropping the data type results in the same signature then we can safely drop it. Additionally, if a more specific utility exists, we will prefer that one. This reduced ambiguity and the need for data types. - `bg-[position:123px]` → `bg-position-[123px]` - `bg-[123px]` → `bg-position-[123px]` - `bg-[size:123px]` → `bg-size-[123px]` 2. Optimizing modifiers. E.g.: - `bg-red-500/[25%]` → `bg-red-500/25` - `bg-red-500/[100%]` → `bg-red-500` - `bg-red-500/100` → `bg-red-500` 3. Hoist `not` in arbitrary variants - `[@media_not_(prefers-color-scheme:dark)]:flex` → `not-[@media_(prefers-color-scheme:dark)]:flex` → `not-dark:flex` (in case you are using the default `dark` mode implementation 4. Optimize raw values that could be converted to bare values. This uses the `--spacing` variable to ensure it is safe. - `w-[64rem]` → `w-256` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-05-02 23:18:06 +02:00
### Fixed
- Ensure negative arbitrary `scale` values generate negative values ([#17831](https://github.com/tailwindlabs/tailwindcss/pull/17831))
Fix HAML extraction with embedded Ruby (#17846) This PR fixes and improves the HAML extractor by ensuring that whenever we detect lines or blocks of Ruby code (`-`, `=` and `~`) characters at the beginning of the line, we treat them as Ruby code. Fixes: #17813 ## Test Plan 1. Existing tests pass 2. Changed 1 existing test which embedded Ruby syntax 3. Added a dedicated test to ensure the HAML file in the linked issue is parsed correctly Running this in the internal extractor tool you can see that the `w-[12px]`, `w-[16px]`, `h-[12px]`, and `h-[16px]` are properly extracted. Note: the `mr-12px` is also extracted, but not highlighted because this is not a valid Tailwind CSS class. <img width="1816" alt="image" src="https://github.com/user-attachments/assets/fc5929ca-bc71-47d2-b21b-7abeec86f54d" />
2025-05-05 16:26:17 +02:00
- Fix HAML extraction with embedded Ruby ([#17846](https://github.com/tailwindlabs/tailwindcss/pull/17846))
Ignore `@tailwind utilities` inside `@reference` (#17836) You can use `@reference "tailwindcss"` or `@reference "../path/to/your/css/file.css"` to reference your theme for use in `@apply`, `theme(…)`, etc… Unfortunatley, because the imported file still contains `@tailwind utilities` it would trigger a re-scan of the filesystem — even though the use of `@reference` ensures that no CSS can actually be output by the import itself. This PR does two things: - Adds some explicit feature detection tests for what features we pick up in a stylesheet based on the CSS written and how things are imported - Explicitly ignores `@tailwind utilities` inside of `@reference` so it isn't a trigger for file scanning Because of how Vite itself handles dependencies editing files on disk will still trigger a rebuild of any file using `@reference`. This is because Vite rebuilds files when _any_ of its transitive dependencies change. For example, given this Vue file: ```vue <style> @reference "./styles.css"; </style> <template> <!-- ... --> </template> ``` And this stylesheet: ```css @import "tailwindcss"; ``` The dependency chain looks like this: `file.vue -> styles.css -> {all the sources in your project}` Vite sees that a file (e.g. `index.html`) has changed, thus `styles.css` needs change, which means `file.vue` needs to be compiled again as well. Now in reality we depend on the _on disk_ version of styles.css not the compiled version but Vite itself doesn't know that (or have a way to indicate this afaik). Coming up with a solution to that problem will have to be a separate PR — but there is a workaround: ### 1. Inline the imports from `@import "tailwindcss";` Replace this in your main stylesheet: ```css @import "tailwindcss"; ``` with this (this is basically what `node_modules/tailwindcss/index.css` is): ```css @layer theme, base, components, utilities; @import 'tailwindcss/theme' layer(theme); @import 'tailwindcss/preflight' layer(base); @import 'tailwindcss/utilities' layer(utilities); /* the rest of your styles imports, styles, etc… */ ``` ### 2. Split your stylesheet into "main" and "theme" parts Your "theme" is comprised of the `@import 'tailwindcss/theme' layer(theme);` import, any custom `@theme` blocks, any `@config` directives, and any `@plugin` directives. Move all of these into their own file. For example, replace this with two files: ```css @layer theme, base, components, utilities; @import 'tailwindcss/theme' layer(theme); @import 'tailwindcss/preflight' layer(base); @import 'tailwindcss/utilities' layer(utilities); @theme { --color-primary: #c0ffee; } @plugin "./my-plugin.js"; /* the rest of your styles imports, styles, etc… */ ``` with a theme file: ```css @import 'tailwindcss/theme' layer(theme); /* all your `@theme` stuff goes in this file */ @theme { --color-primary: #c0ffee; } /* additionally any @config or @plugin does too */ @plugin "./my-plugin.js"; ``` and your main CSS file: ```css @layer theme, base, components, utilities; @import './my-theme.css'; /* I replaced this import */ @import 'tailwindcss/preflight' layer(base); @import 'tailwindcss/utilities' layer(utilities); /* the rest of your styles imports, styles, etc… */ ``` ### 3. Import only your "theme" file in your Vue components / CSS modules / etc… ```vue <style> @reference "./my-theme.css"; </style> <template> <!-- ... --> </template> ``` Fixes #17693
2025-05-05 11:21:55 -04:00
- Don't scan files for utilities when using `@reference` ([#17836](https://github.com/tailwindlabs/tailwindcss/pull/17836))
Fix bug replacing modifier variable shorthand syntax underscores (#17889) Resolves #17888 **Reproduction URL:** https://play.tailwindcss.com/YvIekuzVRd Changes: * Don't use `decodeArbitraryValue` when parsing variable shorthand syntax in modifiers * replace `decodeArbitraryValue(modifier.slice(1, -1))` with `modifier.slice(1, -1)` * added test case, passing ✅ --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-05-06 09:32:47 -04:00
- Fix incorrectly replacing `_` with ` ` in arbitrary modifier shorthand `bg-red-500/(--my_opacity)` ([#17889](https://github.com/tailwindlabs/tailwindcss/pull/17889))
Write to log file when using `DEBUG=*` (#17906) This PR improves the debugability of the scanner when using `DEBUG=*` by writing to a `tailwindcss-{pid}.log` file in the current working directory. It will include all the tracing information from the scanner. This PR also introduces `Discovering {path}` and `Reading {path}` logs. - `Discovering {path}` — this is logged when we are traversing the file system looking for files. We use the `ignore` crate, and log this information in the `filter_entry` callback. If a file was already ignored by `.gitignore` files, this won't show up, but it also means that we will not read it. - `Reading {path}` — this is when we are actually reading the file so we can start extracting potential Tailwind CSS classes. These will give you some insights in what paths are being scanned, and if we get stuck, where we get stuck. Also, we are appending to the file. In the log below, you can already see that a `tailwindcss-<number>.log` file exists already even though it didn't exist before running the command. This should make it easier to debug if we get stuck on a specific file/folder because the file will be populated with information. There are a few reasons for appending to a file: 1. There is a lot of output, so spamming the stdout/stderr is not ideal 2. If you run the same command again, after changing your `@source` directives, you could diff the outputs. (although, the timestamps will be different) 3. When using `DEBUG=*`, a lot of other tools also output debug information, so writing to a file should make this better. <details> <summary>Example log</summary> ```log 2025-05-06T23:13:45.912292Z INFO scan_sources: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.912697Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/out.css" 2025-05-06T23:13:45.912716Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/tailwindcss-61347.log" 2025-05-06T23:13:45.912748Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app" 2025-05-06T23:13:45.912786Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/test" 2025-05-06T23:13:45.912814Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/test/utils.ts" 2025-05-06T23:13:45.912851Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils" 2025-05-06T23:13:45.912873Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils/flatten.ts" 2025-05-06T23:13:45.912884Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils/matrix.ts" 2025-05-06T23:13:45.912893Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils/default-map.ts" 2025-05-06T23:13:45.912904Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/tailwind.css" 2025-05-06T23:13:45.912914Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/root.tsx" 2025-05-06T23:13:45.912936Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain" 2025-05-06T23:13:45.912962Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/expression.ts" 2025-05-06T23:13:45.912972Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/walk-ast.ts" 2025-05-06T23:13:45.912995Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature" 2025-05-06T23:13:45.913019Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/parser.test.ts" 2025-05-06T23:13:45.913029Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/validate.test.ts" 2025-05-06T23:13:45.913039Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/tokenizer.ts" 2025-05-06T23:13:45.913048Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/validate.ts" 2025-05-06T23:13:45.913058Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/parser.ts" 2025-05-06T23:13:45.913067Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/tokenizer.test.ts" 2025-05-06T23:13:45.913077Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/ast.ts" 2025-05-06T23:13:45.913086Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/version-control.ts" 2025-05-06T23:13:45.913095Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/tokenizer.ts" 2025-05-06T23:13:45.913105Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/type-checker.test.ts" 2025-05-06T23:13:45.913121Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/evaluation-result.ts" 2025-05-06T23:13:45.913505Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/tmp.test.ts" 2025-05-06T23:13:45.913514Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/version-control.test.ts" 2025-05-06T23:13:45.913523Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/tokenizer.test.ts" 2025-05-06T23:13:45.913531Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/evaluation.ts" 2025-05-06T23:13:45.913554Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions" 2025-05-06T23:13:45.913583Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/sequence.test.ts" 2025-05-06T23:13:45.913592Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/date.ts" 2025-05-06T23:13:45.913601Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/lookup.test.ts" 2025-05-06T23:13:45.913613Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/statistics.ts" 2025-05-06T23:13:45.913622Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/intrinsics.test.ts" 2025-05-06T23:13:45.913631Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/math.ts" 2025-05-06T23:13:45.913640Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/engineering.ts" 2025-05-06T23:13:45.913648Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/types.test.ts" 2025-05-06T23:13:45.913656Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/text.ts" 2025-05-06T23:13:45.913665Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/text.test.ts" 2025-05-06T23:13:45.913673Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/intrinsics.ts" 2025-05-06T23:13:45.913681Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/logic.ts" 2025-05-06T23:13:45.913689Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/date.test.ts" 2025-05-06T23:13:45.913697Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/types.ts" 2025-05-06T23:13:45.913705Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/logic.test.ts" 2025-05-06T23:13:45.913713Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/lookup.ts" 2025-05-06T23:13:45.913720Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/sequence.ts" 2025-05-06T23:13:45.913728Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/engineering.test.ts" 2025-05-06T23:13:45.913741Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/index.ts" 2025-05-06T23:13:45.913749Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/math.test.ts" 2025-05-06T23:13:45.913757Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/statistics.test.ts" 2025-05-06T23:13:45.913783Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/__snapshots__" 2025-05-06T23:13:45.913817Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/spreadsheet.test.ts" 2025-05-06T23:13:45.913826Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/type-checker.ts" 2025-05-06T23:13:45.913833Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/function-utils.ts" 2025-05-06T23:13:45.913841Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/spreadsheet.ts" 2025-05-06T23:13:45.913849Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/expression.test.ts" 2025-05-06T23:13:45.913857Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/evaluation.test.ts" 2025-05-06T23:13:45.913879Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/routes" 2025-05-06T23:13:45.913896Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/app/routes/_index.tsx" 2025-05-06T23:13:45.914172Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/README.md" 2025-05-06T23:13:45.914197Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/public" 2025-05-06T23:13:45.914228Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/public/fonts" 2025-05-06T23:13:45.914268Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/package.json" 2025-05-06T23:13:45.914289Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/scripts" 2025-05-06T23:13:45.914310Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/scripts/generate-documentation.ts" 2025-05-06T23:13:45.914332Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/.github" 2025-05-06T23:13:45.914383Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/.github/workflows" 2025-05-06T23:13:45.914410Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/.github/workflows/ci.yml" 2025-05-06T23:13:45.914420Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/tsconfig.json" 2025-05-06T23:13:45.914455Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/vite.config.ts" 2025-05-06T23:13:45.914486Z INFO scan_sources: tailwindcss_oxide::scanner: Discovering "/Users/robin/github.com/RobinMalfait/spreadsheet/biome.json" 2025-05-06T23:13:45.914512Z INFO scan_sources: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.914515Z INFO extract_candidates: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.914518Z INFO extract_candidates:read_all_files: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.914524Z INFO extract_candidates:read_all_files: tailwindcss_oxide::scanner: Reading 58 file(s) 2025-05-06T23:13:45.914808Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/tailwindcss-61347.log" 2025-05-06T23:13:45.914990Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/routes/_index.tsx" 2025-05-06T23:13:45.915138Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/.github/workflows/ci.yml" 2025-05-06T23:13:45.915140Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/statistics.test.ts" 2025-05-06T23:13:45.915145Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/tokenizer.ts" 2025-05-06T23:13:45.915163Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/tsconfig.json" 2025-05-06T23:13:45.915153Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/engineering.ts" 2025-05-06T23:13:45.915226Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils/matrix.ts" 2025-05-06T23:13:45.915229Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/walk-ast.ts" 2025-05-06T23:13:45.915372Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/test/utils.ts" 2025-05-06T23:13:45.915578Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/ast.ts" 2025-05-06T23:13:45.915599Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/validate.ts" 2025-05-06T23:13:45.915637Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/version-control.ts" 2025-05-06T23:13:45.915647Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/parser.ts" 2025-05-06T23:13:45.915657Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/vite.config.ts" 2025-05-06T23:13:45.915680Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/types.test.ts" 2025-05-06T23:13:45.915681Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils/flatten.ts" 2025-05-06T23:13:45.915701Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/parser.test.ts" 2025-05-06T23:13:45.915706Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/README.md" 2025-05-06T23:13:45.915691Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/utils/default-map.ts" 2025-05-06T23:13:45.915701Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/spreadsheet.test.ts" 2025-05-06T23:13:45.915730Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/package.json" 2025-05-06T23:13:45.915753Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/tokenizer.ts" 2025-05-06T23:13:45.915731Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/biome.json" 2025-05-06T23:13:45.915787Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/validate.test.ts" 2025-05-06T23:13:45.915822Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/signature/tokenizer.test.ts" 2025-05-06T23:13:45.915826Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/text.ts" 2025-05-06T23:13:45.915885Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/root.tsx" 2025-05-06T23:13:45.915885Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/types.ts" 2025-05-06T23:13:45.915886Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/type-checker.ts" 2025-05-06T23:13:45.915990Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/type-checker.test.ts" 2025-05-06T23:13:45.915995Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/text.test.ts" 2025-05-06T23:13:45.915998Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/logic.ts" 2025-05-06T23:13:45.916000Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/intrinsics.ts" 2025-05-06T23:13:45.916024Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/sequence.ts" 2025-05-06T23:13:45.916056Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/function-utils.ts" 2025-05-06T23:13:45.916058Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/scripts/generate-documentation.ts" 2025-05-06T23:13:45.916070Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/expression.ts" 2025-05-06T23:13:45.916075Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/logic.test.ts" 2025-05-06T23:13:45.916063Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/date.test.ts" 2025-05-06T23:13:45.916119Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/evaluation-result.ts" 2025-05-06T23:13:45.916120Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/index.ts" 2025-05-06T23:13:45.916148Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/expression.test.ts" 2025-05-06T23:13:45.916152Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/engineering.test.ts" 2025-05-06T23:13:45.916193Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/lookup.ts" 2025-05-06T23:13:45.916219Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/tmp.test.ts" 2025-05-06T23:13:45.916228Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/tokenizer.test.ts" 2025-05-06T23:13:45.916245Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/evaluation.test.ts" 2025-05-06T23:13:45.916256Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/spreadsheet.ts" 2025-05-06T23:13:45.916253Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/lookup.test.ts" 2025-05-06T23:13:45.916267Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/sequence.test.ts" 2025-05-06T23:13:45.916287Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/math.test.ts" 2025-05-06T23:13:45.916286Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/version-control.test.ts" 2025-05-06T23:13:45.916317Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/intrinsics.test.ts" 2025-05-06T23:13:45.916323Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/evaluation.ts" 2025-05-06T23:13:45.916354Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/statistics.ts" 2025-05-06T23:13:45.916562Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/date.ts" 2025-05-06T23:13:45.916609Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/domain/functions/math.ts" 2025-05-06T23:13:45.916676Z INFO extract_candidates:read_all_files: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.916682Z INFO extract_candidates:parse_all_blobs: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.916688Z INFO extract_candidates:parse_all_blobs:extract: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.918271Z INFO extract_candidates:parse_all_blobs:extract: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.918282Z INFO extract_candidates:parse_all_blobs: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.918286Z INFO extract_candidates:read_all_files: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.918288Z INFO extract_candidates:read_all_files: tailwindcss_oxide::scanner: Reading 2 file(s) 2025-05-06T23:13:45.918315Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/app/tailwind.css" 2025-05-06T23:13:45.918504Z INFO tailwindcss_oxide::scanner: Reading "/Users/robin/github.com/RobinMalfait/spreadsheet/out.css" 2025-05-06T23:13:45.918512Z INFO extract_candidates:read_all_files: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.918519Z INFO extract_candidates:extract_css_variables: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.918522Z INFO extract_candidates:extract_css_variables:extract: tailwindcss_oxide::scanner: enter 2025-05-06T23:13:45.918635Z INFO extract_candidates:extract_css_variables:extract: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.918640Z INFO extract_candidates:extract_css_variables: tailwindcss_oxide::scanner: exit 2025-05-06T23:13:45.919059Z INFO extract_candidates: tailwindcss_oxide::scanner: exit ``` </details> We also output where we are writing the file to. This looks like this when using the CLI: <img width="1462" alt="image" src="https://github.com/user-attachments/assets/79c2cc95-adea-4bbd-a4f1-101de45726f5" /> Last but not least, this also ignores `.log` files by default ## Test plan Ran the CLI (but you can use any tool real, since this is implemented in Oxide) with the `DEBUG=*` flag. The file generated, looks like the example I shared above.
2025-05-07 16:19:54 +02:00
- Don't scan `.log` files for classes by default ([#17906](https://github.com/tailwindlabs/tailwindcss/pull/17906))
Fix bug with nested @apply rules in utility classes (#17924) (#17925) Fixes #17924 When an `@apply` pointed to utility that nested usages of `@apply`, these nested usages were not properly carried through the dependency chain. This was because we were only tracking dependencies on the immediate parent rather than all parents. To fix this, this PR: - Modifies the dependency resolution to track dependencies through the entire parent path - Uses a `walk(…)` for the node replacement logic so that all nested `@apply` usages are also resolved (as these are now tracked in the dependency list anyways ## Test Plan - Added a regression test for #17924 to the unit tests and ensure existing tests don't break
2025-05-08 18:26:07 +02:00
- Ensure that custom utilities applying other custom utilities don't swallow nested `@apply` rules ([#17925](https://github.com/tailwindlabs/tailwindcss/pull/17925))
Prepare v4.1.6 release (#17951) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-09 15:39:18 +02:00
- Download platform specific package if `optionalDependencies` are skipped ([#17929](https://github.com/tailwindlabs/tailwindcss/pull/17929))
Prepare v4.1.5 release (#17830) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-30 16:57:44 +02:00
## [4.1.5] - 2025-04-30
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717) This PR ensures that the `@tailwindcss/upgrade` tool works on existing Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is idempotent, meaning that it can be run multiple times and it should result in the same output. One awesome feature this unlocks is that you can run the upgrade tool on your codebase at any time and upgrade classes if you still have some legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory. One small note: If something changed in the first run, re-running will not work immediately because your git repository will not be clean and the upgrade tool requires your git repo to be clean. But once you verified and committed your changes, the upgrade tool will be idempotent. Idempotency is guaranteed by ensuring that some migrations are skipped by checking what version of Tailwind CSS you are on _before_ the version is upgraded. For the Tailwind CSS version: We will resolve `tailwindcss` itself to know the _actual_ version that is installed (the one resolved from `node_modules`). Not the one available in your package.json. Your `package.json` could be out of sync if you reverted changes but didn't run `npm install` yet. Back to Idempotency: For example, we have migrations where we change the variant order of stacked variants. If we would run these migrations every time you run the upgrade tool then we would be flip-flopping the order every run. See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order Another example is where we rename some utilities. For example, we rename: | Before | After | | ----------- | ----------- | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | Notice how we have `shadow-sm` in both the `before` and `after` column. If we would run the upgrade tool again, then we would eventually migrate your original `shadow` to `shadow-sm` (first run) and then to `shadow-xs` (second run). Which would result in the wrong shadow. See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities --- The order of upgrade steps changed a bit as well to make the internals are easier to work with and reason about. 1. Find CSS files 2. Link JS config files (if you are in a Tailwind CSS v3 project) 3. Migrate the JS config files (if you are in a Tailwind CSS v3 project) 4. Upgrade Tailwind CSS to v4 (or the latest version at that point) 5. Migrate the stylesheets (we used to migrate the source files first) 6. Migrate the source files This is done so that step 5 and 6 will always operate on a Tailwind CSS v4 project and we don't need to check the version number again. This is also necessary because your CSS file will now very likely contain `@import "tailwindcss";` which doesn't exist in Tailwind CSS v3. This also means that we can rely on the same internals that Tailwind CSS actually uses for locating the source files. We will use `@tailwindcss/oxide`'s scanner to find the source files (and it also keeps your custom `@source` directives into account). This PR also introduces a few actual migrations related to recent features and changes we shipped. 1. We migrate deprecated classes to their new names: | Before | After | | --------------------- | --------------------- | | `bg-left-top` | `bg-top-left` | | `bg-left-bottom` | `bg-bottom-left` | | `bg-right-top` | `bg-top-right` | | `bg-right-bottom` | `bg-bottom-right` | | `object-left-top` | `object-top-left` | | `object-left-bottom` | `object-bottom-left` | | `object-right-top` | `object-top-right` | | `object-right-bottom` | `object-bottom-right` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/17378 - https://github.com/tailwindlabs/tailwindcss/pull/17437 2. We migrate simple arbitrary variants to their dedicated variant: | Before | After | | ----------------------- | ------------------- | | `[&:user-valid]:flex` | `user-valid:flex` | | `[&:user-invalid]:flex` | `user-invalid:flex` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/12370 3. We migrate `@media` variants to their dedicated variant: | Before | After | | ----------------------------------------------------- | ------------------------- | | `[@media_print]:flex` | `print:flex` | | `[@media(prefers-reduced-motion:no-preference)]:flex` | `motion-safe:flex` | | `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex` | | `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` | | `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` | | `[@media(orientation:portrait)]:flex` | `portrait:flex` | | `[@media(orientation:landscape)]:flex` | `landscape:flex` | | `[@media(forced-colors:active)]:flex` | `forced-colors:flex` | | `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` | | `[@media(pointer:none)]:flex` | `pointer-none:flex` | | `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` | | `[@media(pointer:fine)]:flex` | `pointer-fine:flex` | | `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` | | `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` | | `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` | | `[@media(scripting:none)]:flex` | `noscript:flex` | The new variants related to `inverted-colors`, `pointer`, `any-pointer` and `scripting` were introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/11693 - https://github.com/tailwindlabs/tailwindcss/pull/16946 - https://github.com/tailwindlabs/tailwindcss/pull/11929 - https://github.com/tailwindlabs/tailwindcss/pull/17431 This also applies to the `not` case, e.g.: | Before | After | | --------------------------------------------------------- | ----------------------------- | | `[@media_not_print]:flex` | `not-print:flex` | | `[@media_not(prefers-reduced-motion:no-preference)]:flex` | `not-motion-safe:flex` | | `[@media_not(prefers-reduced-motion:reduce)]:flex` | `not-motion-reduce:flex` | | `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex` | | `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex` | | `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` | | `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` | | `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` | | `[@media_not(inverted-colors:inverted)]:flex` | `not-inverted-colors:flex` | | `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` | | `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` | | `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` | | `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` | | `[@media_not(any-pointer:coarse)]:flex` | `not-any-pointer-coarse:flex` | | `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` | | `[@media_not(scripting:none)]:flex` | `not-noscript:flex` | For each candidate, we run a set of upgrade migrations. If at the end of the migrations the original candidate is still the same as the new candidate, then we will parse & print the candidate one more time to pretty print into consistent classes. Luckily parsing is cached so there is no real downside overhead. Consistency (especially with arbitrary variants and values) will reduce your CSS file because there will be fewer "versions" of your class. Concretely, the pretty printing will apply changes such as: | Before | After | | ---------------------- | ----------------- | | `bg-[var(--my-color)]` | `bg-(--my-color)` | | `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` | Another big important reason for this change is that these classes on their own would have been migrated _if_ another migration was relevant for this candidate. This means that there are were some inconsistencies. E.g.: | Before | After | Reason | | ----------------------- | ---------------------- | ------------------------------------ | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in the wrong spot | | `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no migrations rand | As you can see, the way the `--my-color` variable is used, is different. This changes will make sure it will now always be consistent: | Before | After | | ----------------------- | ---------------------- | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | | `bg-[var(--my-color)]` | `bg-(--my-color)` | Yay! Of course, if you don't want these more cosmetic changes, you can always ignore the upgrade and revert these changes and only commit the changes you want. # Test plan - All existing tests still pass. - But I had to delete 1 test (we tested that Tailwind CSS v3 was required). - And had to mock the `version.isMajor` call to ensure we run the individual migration tests correctly. - Added new tests to test: 1. Migrating Tailwind CSS v4 projects works 1. Idempotency of the upgrade tool [ci-all]
2025-04-22 17:10:46 +02:00
### Added
Design system driven upgrade migrations (#17831) This PR introduces a vastly improved upgrade migrations system, to migrate your codebase and modernize your utilities to make use of the latest variants and utilities. It all started when I saw this PR the other day: https://github.com/tailwindlabs/tailwindcss/pull/17790 I was about to comment "Don't forget to add a migration". But I've been thinking about a system where we can automate this process away. This PR introduces this system. This PR introduces upgrade migrations based on the internal Design System, and it mainly updates arbitrary variants, arbitrary properties and arbitrary values. ## The problem Whenever we ship new utilities, or you make changes to your CSS file by introducing new `@theme` values, or adding new `@utility` rules. It could be that the rest of your codebase isn't aware of that, but you could be using these values. For example, it could be that you have a lot of arbitrary properties in your codebase, they look something like this: ```html <div class="[color-scheme:dark] [text-wrap:balance]"></div> ``` Whenever we introduce new features in Tailwind CSS, you probably don't keep an eye on the release notes and update all of these arbitrary properties to the newly introduced utilities. But with this PR, we can run the upgrade tool: ```console npx -y @tailwindcss/upgrade@latest ``` ...and it will upgrade your project to use the new utilities: ```html <div class="scheme-dark text-balance"></div> ``` It also works for arbitrary values, for example imagine you have classes like this: ```html <!-- Arbitrary property --> <div class="[max-height:1lh]"></div> <!-- Arbitrary value --> <div class="max-h-[1lh]"></div> ``` Running the upgrade tool again: ```console npx -y @tailwindcss/upgrade@latest ``` ... gives you the following output: ```html <!-- Arbitrary property --> <div class="max-h-lh"></div> <!-- Arbitrary value --> <div class="max-h-lh"></div> ``` This is because of the original PR I mentioned, which introduced the `max-h-lh` utilities. A nice benefit is that this output only has 1 unique class instead of 2, which also potentially reduces the size of your CSS file. It could also be that you are using arbitrary values where you (or a team member) didn't even know an alternative solution existed. E.g.: ```html <div class="w-[48rem]"></div> ``` After running the upgrade tool you will get this: ```html <div class="w-3xl"></div> ``` We can go further though. Since the release of Tailwind CSS v4, we introduced the concept of "bare values". Essentially allowing you to type a number on utilities where it makes sense, and we produce a value based on that number. So an input like this: ```html <div class="border-[123px]"></div> ``` Will be optimized to just: ```html <div class="border-123"></div> ``` This can be very useful for complex utilities, for example, how many times have you written something like this: ```html <div class="grid-cols-[repeat(16,minmax(0,1fr))]"></div> ``` Because up until Tailwind CSS v4, we only generated 12 columns by default. But since v4, we can generate any number of columns automatically. Running the migration tool will give you this: ```html <div class="grid-cols-16"></div> ``` ### User CSS But, what if I told you that we can keep going... In [Catalyst](https://tailwindcss.com/plus/ui-kit) we often use classes that look like this for accessibility reasons: ```html <div class="text-[CanvasText] bg-[Highlight]"></div> ``` What if you want to move the `CanvasText` and `Highlight` colors to your CSS: ```css @import "tailwincdss"; @theme { --color-canvas: CanvasText; --color-highlight: Highlight; } ``` If you now run the upgrade tool again, this will be the result: ```html <div class="text-canvas bg-highlight"></div> ``` We never shipped a `text-canvas` or `bg-highlight` utility, but the upgrade tool uses your own CSS configuration to migrate your codebase. This will keep your codebase clean, consistent and modern and you are in control. Let's look at one more example, what if you have this in a lot of places: ```html <div class="[scrollbar-gutter:stable]"></div> ``` And you don't want to wait for the Tailwind CSS team to ship a `scrollbar-stable` (or similar) feature. You can add your own utility: ```css @import "tailwincdss"; @utility scrollbar-stable { scrollbar-gutter: stable; } ``` ```html <div class="scrollbar-stable"></div> ``` ## The solution — how it works There are 2 big things happening here: 1. Instead of us (the Tailwind CSS team) hardcoding certain migrations, we will make use of the internal `DesignSystem` which is the source of truth for all this information. This is also what Tailwind CSS itself uses to generate the CSS file. The internal `DesignSystem` is essentially a list of all: 1. The internal utilities 2. The internal variants 3. The default theme we ship 4. The user CSS 1. With custom `@theme` values 2. With custom `@custom-variant` implementations 3. With custom `@utility` implementations 2. The upgrade tool now has a concept of `signatures` The signatures part is the most interesting one, and it allows us to be 100% sure that we can migrate your codebase without breaking anything. A signature is some unique identifier that represents a utility. But 2 utilities that do the exact same thing will have the same signature. To make this work, we have to make sure that we normalize values. One such value is the selector. I think a little visualization will help here: | UTILITY | GENERATED SIGNATURE | | ---------------- | ----------------------- | | `[display:flex]` | `.x { display: flex; }` | | `flex` | `.x { display: flex; }` | They have the exact same signature and therefore the upgrade tool can safely migrate them to the same utility. For this we will prefer the following order: 1. Static utilities — essentially no brackets. E.g.: `flex`, `grid-cols-2` 2. Arbitrary values — e.g.: `max-h-[1lh]`, `border-[2px]` 3. Arbitrary properties — e.g.: `[color-scheme:dark]`, `[display:flex]` We also have to canonicalize utilities to there minimal form. Essentially making sure we increase the chance of finding a match. ``` [display:_flex_] → [display:flex] → flex [display:_flex] → [display:flex] → flex [display:flex_] → [display:flex] → flex [display:flex] → [display:flex] → flex ``` If we don't do this, then the signatures will be slightly different, due to the whitespace: | UTILITY | GENERATED SIGNATURE | | ------------------ | ------------------------- | | `[display:_flex_]` | `.x { display: flex ; }` | | `[display:_flex]` | `.x { display: flex; }` | | `[display:flex_]` | `.x { display: flex ; }` | | `[display:flex]` | `.x { display: flex; }` | ### Other small improvements A few other improvements are for optimizing existing utilities: 1. Remove unnecessary data types. E.g.: - `bg-[color:red]` -> `bg-[red]` - `shadow-[shadow:inset_0_1px_--theme(--color-white/15%)]` -> `shadow-[inset_0_1px_--theme(--color-white/15%)]` This also makes use of these signatures and if dropping the data type results in the same signature then we can safely drop it. Additionally, if a more specific utility exists, we will prefer that one. This reduced ambiguity and the need for data types. - `bg-[position:123px]` → `bg-position-[123px]` - `bg-[123px]` → `bg-position-[123px]` - `bg-[size:123px]` → `bg-size-[123px]` 2. Optimizing modifiers. E.g.: - `bg-red-500/[25%]` → `bg-red-500/25` - `bg-red-500/[100%]` → `bg-red-500` - `bg-red-500/100` → `bg-red-500` 3. Hoist `not` in arbitrary variants - `[@media_not_(prefers-color-scheme:dark)]:flex` → `not-[@media_(prefers-color-scheme:dark)]:flex` → `not-dark:flex` (in case you are using the default `dark` mode implementation 4. Optimize raw values that could be converted to bare values. This uses the `--spacing` variable to ensure it is safe. - `w-[64rem]` → `w-256` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-05-02 23:18:06 +02:00
- Support using `@tailwindcss/upgrade` to upgrade between versions of v4.\* ([#17717](https://github.com/tailwindlabs/tailwindcss/pull/17717))
Prepare v4.1.5 release (#17830) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-30 16:57:44 +02:00
- Add `h-lh` / `min-h-lh` / `max-h-lh` utilities ([#17790](https://github.com/tailwindlabs/tailwindcss/pull/17790))
- Transition `display`, `visibility`, `content-visibility`, `overlay`, and `pointer-events` when using `transition` to simplify `@starting-style` usage ([#17812](https://github.com/tailwindlabs/tailwindcss/pull/17812))
Ensure `@tailwindcss/upgrade` runs on Tailwind CSS v4 projects and is idempotent (#17717) This PR ensures that the `@tailwindcss/upgrade` tool works on existing Tailwind CSS v4 projects. This PR also ensures that the upgrade tool is idempotent, meaning that it can be run multiple times and it should result in the same output. One awesome feature this unlocks is that you can run the upgrade tool on your codebase at any time and upgrade classes if you still have some legacy syntaxes, such as `bg-[var(--my-color)]`, in your muscle memory. One small note: If something changed in the first run, re-running will not work immediately because your git repository will not be clean and the upgrade tool requires your git repo to be clean. But once you verified and committed your changes, the upgrade tool will be idempotent. Idempotency is guaranteed by ensuring that some migrations are skipped by checking what version of Tailwind CSS you are on _before_ the version is upgraded. For the Tailwind CSS version: We will resolve `tailwindcss` itself to know the _actual_ version that is installed (the one resolved from `node_modules`). Not the one available in your package.json. Your `package.json` could be out of sync if you reverted changes but didn't run `npm install` yet. Back to Idempotency: For example, we have migrations where we change the variant order of stacked variants. If we would run these migrations every time you run the upgrade tool then we would be flip-flopping the order every run. See: https://tailwindcss.com/docs/upgrade-guide#variant-stacking-order Another example is where we rename some utilities. For example, we rename: | Before | After | | ----------- | ----------- | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | Notice how we have `shadow-sm` in both the `before` and `after` column. If we would run the upgrade tool again, then we would eventually migrate your original `shadow` to `shadow-sm` (first run) and then to `shadow-xs` (second run). Which would result in the wrong shadow. See: https://tailwindcss.com/docs/upgrade-guide#renamed-utilities --- The order of upgrade steps changed a bit as well to make the internals are easier to work with and reason about. 1. Find CSS files 2. Link JS config files (if you are in a Tailwind CSS v3 project) 3. Migrate the JS config files (if you are in a Tailwind CSS v3 project) 4. Upgrade Tailwind CSS to v4 (or the latest version at that point) 5. Migrate the stylesheets (we used to migrate the source files first) 6. Migrate the source files This is done so that step 5 and 6 will always operate on a Tailwind CSS v4 project and we don't need to check the version number again. This is also necessary because your CSS file will now very likely contain `@import "tailwindcss";` which doesn't exist in Tailwind CSS v3. This also means that we can rely on the same internals that Tailwind CSS actually uses for locating the source files. We will use `@tailwindcss/oxide`'s scanner to find the source files (and it also keeps your custom `@source` directives into account). This PR also introduces a few actual migrations related to recent features and changes we shipped. 1. We migrate deprecated classes to their new names: | Before | After | | --------------------- | --------------------- | | `bg-left-top` | `bg-top-left` | | `bg-left-bottom` | `bg-bottom-left` | | `bg-right-top` | `bg-top-right` | | `bg-right-bottom` | `bg-bottom-right` | | `object-left-top` | `object-top-left` | | `object-left-bottom` | `object-bottom-left` | | `object-right-top` | `object-top-right` | | `object-right-bottom` | `object-bottom-right` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/17378 - https://github.com/tailwindlabs/tailwindcss/pull/17437 2. We migrate simple arbitrary variants to their dedicated variant: | Before | After | | ----------------------- | ------------------- | | `[&:user-valid]:flex` | `user-valid:flex` | | `[&:user-invalid]:flex` | `user-invalid:flex` | Introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/12370 3. We migrate `@media` variants to their dedicated variant: | Before | After | | ----------------------------------------------------- | ------------------------- | | `[@media_print]:flex` | `print:flex` | | `[@media(prefers-reduced-motion:no-preference)]:flex` | `motion-safe:flex` | | `[@media(prefers-reduced-motion:reduce)]:flex` | `motion-reduce:flex` | | `[@media(prefers-contrast:more)]:flex` | `contrast-more:flex` | | `[@media(prefers-contrast:less)]:flex` | `contrast-less:flex` | | `[@media(orientation:portrait)]:flex` | `portrait:flex` | | `[@media(orientation:landscape)]:flex` | `landscape:flex` | | `[@media(forced-colors:active)]:flex` | `forced-colors:flex` | | `[@media(inverted-colors:inverted)]:flex` | `inverted-colors:flex` | | `[@media(pointer:none)]:flex` | `pointer-none:flex` | | `[@media(pointer:coarse)]:flex` | `pointer-coarse:flex` | | `[@media(pointer:fine)]:flex` | `pointer-fine:flex` | | `[@media(any-pointer:none)]:flex` | `any-pointer-none:flex` | | `[@media(any-pointer:coarse)]:flex` | `any-pointer-coarse:flex` | | `[@media(any-pointer:fine)]:flex` | `any-pointer-fine:flex` | | `[@media(scripting:none)]:flex` | `noscript:flex` | The new variants related to `inverted-colors`, `pointer`, `any-pointer` and `scripting` were introduced in: - https://github.com/tailwindlabs/tailwindcss/pull/11693 - https://github.com/tailwindlabs/tailwindcss/pull/16946 - https://github.com/tailwindlabs/tailwindcss/pull/11929 - https://github.com/tailwindlabs/tailwindcss/pull/17431 This also applies to the `not` case, e.g.: | Before | After | | --------------------------------------------------------- | ----------------------------- | | `[@media_not_print]:flex` | `not-print:flex` | | `[@media_not(prefers-reduced-motion:no-preference)]:flex` | `not-motion-safe:flex` | | `[@media_not(prefers-reduced-motion:reduce)]:flex` | `not-motion-reduce:flex` | | `[@media_not(prefers-contrast:more)]:flex` | `not-contrast-more:flex` | | `[@media_not(prefers-contrast:less)]:flex` | `not-contrast-less:flex` | | `[@media_not(orientation:portrait)]:flex` | `not-portrait:flex` | | `[@media_not(orientation:landscape)]:flex` | `not-landscape:flex` | | `[@media_not(forced-colors:active)]:flex` | `not-forced-colors:flex` | | `[@media_not(inverted-colors:inverted)]:flex` | `not-inverted-colors:flex` | | `[@media_not(pointer:none)]:flex` | `not-pointer-none:flex` | | `[@media_not(pointer:coarse)]:flex` | `not-pointer-coarse:flex` | | `[@media_not(pointer:fine)]:flex` | `not-pointer-fine:flex` | | `[@media_not(any-pointer:none)]:flex` | `not-any-pointer-none:flex` | | `[@media_not(any-pointer:coarse)]:flex` | `not-any-pointer-coarse:flex` | | `[@media_not(any-pointer:fine)]:flex` | `not-any-pointer-fine:flex` | | `[@media_not(scripting:none)]:flex` | `not-noscript:flex` | For each candidate, we run a set of upgrade migrations. If at the end of the migrations the original candidate is still the same as the new candidate, then we will parse & print the candidate one more time to pretty print into consistent classes. Luckily parsing is cached so there is no real downside overhead. Consistency (especially with arbitrary variants and values) will reduce your CSS file because there will be fewer "versions" of your class. Concretely, the pretty printing will apply changes such as: | Before | After | | ---------------------- | ----------------- | | `bg-[var(--my-color)]` | `bg-(--my-color)` | | `bg-[rgb(0,_0,_0)]` | `bg-[rgb(0,0,0)]` | Another big important reason for this change is that these classes on their own would have been migrated _if_ another migration was relevant for this candidate. This means that there are were some inconsistencies. E.g.: | Before | After | Reason | | ----------------------- | ---------------------- | ------------------------------------ | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | Because the `!` is in the wrong spot | | `bg-[var(--my-color)]` | `bg-[var(--my-color)]` | Because no migrations rand | As you can see, the way the `--my-color` variable is used, is different. This changes will make sure it will now always be consistent: | Before | After | | ----------------------- | ---------------------- | | `!bg-[var(--my-color)]` | `bg-(--my-color)!` | | `bg-[var(--my-color)]` | `bg-(--my-color)` | Yay! Of course, if you don't want these more cosmetic changes, you can always ignore the upgrade and revert these changes and only commit the changes you want. # Test plan - All existing tests still pass. - But I had to delete 1 test (we tested that Tailwind CSS v3 was required). - And had to mock the `version.isMajor` call to ensure we run the individual migration tests correctly. - Added new tests to test: 1. Migrating Tailwind CSS v4 projects works 1. Idempotency of the upgrade tool [ci-all]
2025-04-22 17:10:46 +02:00
Ignore .geojson files by default (#17700) Resolves https://github.com/tailwindlabs/tailwindcss/issues/17699 GeoJSON files are giant JSON files for geographic data structures and will never contain Tailwind classes, but because they are often huge they will slow down the build a lot if scanned. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2025-04-18 04:46:33 -04:00
### Fixed
Prepare v4.1.5 release (#17830) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-30 16:57:44 +02:00
- Don't scan `.geojson` or `.db` files for classes by default ([#17700](https://github.com/tailwindlabs/tailwindcss/pull/17700), [#17711](https://github.com/tailwindlabs/tailwindcss/pull/17711))
- Hide default shadow suggestions when missing default shadow theme keys ([#17743](https://github.com/tailwindlabs/tailwindcss/pull/17743))
- Replace `_` with `.` in theme suggestions for `@utility` if surrounded by digits ([#17733](https://github.com/tailwindlabs/tailwindcss/pull/17733))
Skip `color-mix(…)` when opacity is `100%` (#17815) This PR improves colors with alpha values where the alpha value results in 100%. Before this change, a class like `bg-red-500/100` would be generated as: ```css .bg-red-500\/100 { background-color: #ef4444; } @supports (color: color-mix(in lab, red, red)) { .bg-red-500\/100 { background-color: color-mix(in oklab, var(--color-red-500) 100%, transparent); } } ``` But we don't need the `color-mix`, or the fallback styles at all in case the alpha value is 100%. After this change the `bg-red-500/100` class will generate as: ```css .bg-red-500\/100 { background-color: var(--color-red-500); } ``` Which is essentially the same as `bg-red-500`, but we can migrate that away in the future. At least the generated CSS is smaller. ## Test plan 1. Added a test to ensure the generated value doesn't include color-mix at all.
2025-04-28 19:30:01 +02:00
- Skip `color-mix(…)` when opacity is `100%` ([#17815](https://github.com/tailwindlabs/tailwindcss/pull/17815))
Prepare v4.1.5 release (#17830) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-30 16:57:44 +02:00
- PostCSS: Ensure that errors in imported stylesheets are recoverable ([#17754](https://github.com/tailwindlabs/tailwindcss/pull/17754))
- Upgrade: Bump all Tailwind CSS related dependencies during upgrade ([#17763](https://github.com/tailwindlabs/tailwindcss/pull/17763))
- Upgrade: Don't add `-` to variants starting with `@` ([#17814](https://github.com/tailwindlabs/tailwindcss/pull/17814))
- Upgrade: Don't format stylesheets that didn't change when upgrading ([#17824](https://github.com/tailwindlabs/tailwindcss/pull/17824))
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
Add more folders to the list of ignored content dirs (#17892) Closes #15452 This PR adds more directories to the list of ignored content dirs. These are now handled the same as `node_modules`: - Contents of this directory are ignored by default to avoid scanning dependency trees - Explicit `@import`s inside these folders are now treated as _external_, bypassing any `.gitignore` files. The new extensions are: - Version control systems: `.hg`, `.svn` - Bundler caches: `.venv`, `venv`, `.yarn` - Framework caches: `.next`, `.turbo`, `.parcel-cache`, `__pycache__`, `.svelte-kit` ## Test plan Verified with the repro of #15452 by renaming the ignored directory to `.venv` and installing a local tarball: <img width="1283" alt="Screenshot 2025-05-06 at 13 14 55" src="https://github.com/user-attachments/assets/3265acbb-e121-47b3-ac6c-e174770f8234" />
2025-05-08 11:27:11 +02:00
### Changed
- Ignore `.hg`, `.svn`, `.venv`, `venv`, `.yarn`, `.next`, `.turbo`, `.parcel-cache`, `__pycache__`, and `.svelte-kit` folders by default (can be overridden by `@source …` rules) ([#17892](https://github.com/tailwindlabs/tailwindcss/pull/17892))
- `@source` rules that point inside `.hg`, `.svn`, `.venv`, `venv`, `.yarn`, `.next`, `.turbo`, `.parcel-cache`, `__pycache__`, and `.svelte-kit` folders no longer consider your `.gitignore` rules ([#17892](https://github.com/tailwindlabs/tailwindcss/pull/17892))
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
## [4.1.4] - 2025-04-14
Add experimental `@tailwindcss/oxide-wasm32-wasi` (#17558) Closes #17448 Closes #13133 This PR adds an a new Oxide target for `wasm32-wasip1-threads`: `@tailwindcss/oxide-wasm32-wasi`. The goal of this is to enable more environments to run Oxide, including (but not limited to) StackBlitz. We're making use of `napi-rs`'s upcoming v3 features to simplify the setup here, meaning `napi-rs` will configure the WASM target and create an npm package that works across Node and browser environments. ## MacOS AArch64 issues While setting up an integration test for the new WASM target, I ran into an issue where FS reads where not terminating on macOS. After some research I found this to be a limitation of the Node.js container interface right now, see: https://github.com/nodejs/node/issues/47193 ### Windows issues We also found that the Node.js wasi container does not properly support Windows: https://github.com/nodejs/uvwasi/issues/11 For now we, it's probably best for MacOS AArch64 users and Windows users to use the native modules instead. ## Test plan The `@tailwindcss/oxide-wasm32-wasi` npm package can be built locally via `pnpm build` and then run with the Oxide API. A usage example can be taken from the newly added integration test. Furthermore this was tested to work as a polyfill on StackBlitz: https://stackblitz.com/edit/vitejs-vite-uks3gt5p [ci-all] --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-04-11 17:19:55 +02:00
### Added
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
- Add experimental `@tailwindcss/oxide-wasm32-wasi` target for running Tailwind in browser environments like StackBlitz ([#17558](https://github.com/tailwindlabs/tailwindcss/pull/17558))
Add experimental `@tailwindcss/oxide-wasm32-wasi` (#17558) Closes #17448 Closes #13133 This PR adds an a new Oxide target for `wasm32-wasip1-threads`: `@tailwindcss/oxide-wasm32-wasi`. The goal of this is to enable more environments to run Oxide, including (but not limited to) StackBlitz. We're making use of `napi-rs`'s upcoming v3 features to simplify the setup here, meaning `napi-rs` will configure the WASM target and create an npm package that works across Node and browser environments. ## MacOS AArch64 issues While setting up an integration test for the new WASM target, I ran into an issue where FS reads where not terminating on macOS. After some research I found this to be a limitation of the Node.js container interface right now, see: https://github.com/nodejs/node/issues/47193 ### Windows issues We also found that the Node.js wasi container does not properly support Windows: https://github.com/nodejs/uvwasi/issues/11 For now we, it's probably best for MacOS AArch64 users and Windows users to use the native modules instead. ## Test plan The `@tailwindcss/oxide-wasm32-wasi` npm package can be built locally via `pnpm build` and then run with the Oxide API. A usage example can be taken from the newly added integration test. Furthermore this was tested to work as a polyfill on StackBlitz: https://stackblitz.com/edit/vitejs-vite-uks3gt5p [ci-all] --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-04-11 17:19:55 +02:00
Fix polyfill in combination with unused CSS variable removal (#17555) This PR fixes an issue we noticed while investigating #17553, where the unused CSS variable removal didn't work properly when the theme variable it tried to remove was modified by a polyfill rule. The way the bookkeeping for the unused CSS variable worked was that it tired to find the declaration inside it's parent after the traversal. However, the `color-mix(…)` polyfill has since then made changes to the declaration so it can't find it's position correctly anymore and will thus instead delete the last declaration of the node (this caused unrelated CSS variables to be eliminated while the ones with `color-mix(…)` were unexpectedly kept). To fix this, we decided to apply the polyfills after any eventual deletions. This also ensures that no `@supports` query for the variables are created and simplifies the code a bit since all polyfills are now colocated. ## Test plan - Added a unit test for the example we discovered in #17553 - Luckily the conditions of this seemed rare enough so that it doesn't cause any other of our tests to update. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-04-07 11:18:47 +02:00
### Fixed
- Ensure `color-mix(…)` polyfills do not cause used CSS variables to be removed ([#17555](https://github.com/tailwindlabs/tailwindcss/pull/17555))
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
- Ensure `color-mix(…)` polyfills create fallbacks for theme variables that reference other theme variables ([#17562](https://github.com/tailwindlabs/tailwindcss/pull/17562))
- Fix brace expansion in declining ranges like `{10..0..5}` and `{0..10..-5}` ([#17591](https://github.com/tailwindlabs/tailwindcss/pull/17591))
Workaround Chrome rendering bug for `skew-*` utilities (#17627) Closes #17621 Chrome as a pretty ugly rendering glitch when using a `skew-*` utility in Tailwind 4: https://play.tailwindcss.com/HuiZtbrHOc The was not an issue in v3 since transforms were set up in a different way. Without the `var(…)` syntax, the difference boils down to this: ```css .skew-v3 { transform: rotate(0) skewX(-20deg); } .skew-v4 { transform: rotateX(0) rotateY(0) rotateZ(0) skewX(-20deg); } ``` It appears that using any of the single-dimension rotate functions will cause the Chrome rendering to glitch. After doing some digging, we found [that initially these `@property`s were defined as type `<transform-function>` and later changed to `*`](https://github.com/tailwindlabs/tailwindcss/issues/15144). With a type of `*`, it makes sense that the initial value of these variables can default to `initial` without any compromises, allowing us to default to something like this now: ```css .skew-new { transform: skewX(-20deg); } ``` Tested this change in the latest version of Chrome (135) and it does make the rendering glitch in the initial issue disappear. By using the `var(--tw-rotate-x,)` syntax we also ensure this works on older versions of Safari (tested on Safari 15.5 and 16.4). Note, however, that there are still glitches happening when you combine rotate and skew in the latest version of Chrome or when you transition the `skew(…)` variable. This also happens in plain CSS with no variables though, so there isn't something we can do about this: https://play.tailwindcss.com/g3FXPEJHpn ## Test plan - Tested on latest Chrome, Firefox, and Safari as well as Safari 15.5 and 16.4. <img width="564" alt="Screenshot 2025-04-09 at 18 01 51" src="https://github.com/user-attachments/assets/2e0b1c96-7c4d-41a8-b3d0-0f6134a3e635" />
2025-04-11 16:38:46 +02:00
- Work around a Chrome rendering bug when using the `skew-*` utilities ([#17627](https://github.com/tailwindlabs/tailwindcss/pull/17627))
Fix container names with hyphens (#17628) Fixes #17614. Candidate parsing for variants only account for the root `@` if there no hyphens. It seems like the current logic assumes if it *does* have a hyphen, then it would be one of `@min` or `@max`. However, with: ```css @theme { --container-foo-bar: 1440px; } ``` Then `@foo-bar` should be valid. However, we only check for `@foo-bar` and `@foo` as roots, but never `@`. This PR adds a check for `@` at the very end after iterating through root permutations. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-04-11 11:28:25 +01:00
- Ensure container query variant names can contain hyphens ([#17628](https://github.com/tailwindlabs/tailwindcss/pull/17628))
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
- Ensure `shadow-inherit`, `inset-shadow-inherit`, `drop-shadow-inherit`, and `text-shadow-inherit` inherit the shadow color ([#17647](https://github.com/tailwindlabs/tailwindcss/pull/17647))
Fix `fontSize` array upgrade (#17630) Fixes #17622. Adds a specific handling case in `themeableValues()` in `packages/tailwindcss/src/compat/apply-config-to-theme.ts`. It seems like this has unique handling in v3 for an array value, whereby the second value is treated as a `line-height`. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-04-11 12:23:54 +01:00
- Ensure compatibility with array tuples used in `fontSize` JS theme keys ([#17630](https://github.com/tailwindlabs/tailwindcss/pull/17630))
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
- Ensure folders with binary file extensions in their names are scanned for utilities ([#17595](https://github.com/tailwindlabs/tailwindcss/pull/17595))
Fix `fontSize` array upgrade (#17630) Fixes #17622. Adds a specific handling case in `themeableValues()` in `packages/tailwindcss/src/compat/apply-config-to-theme.ts`. It seems like this has unique handling in v3 for an array value, whereby the second value is treated as a `line-height`. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-04-11 12:23:54 +01:00
- Upgrade: Convert `fontSize` array tuple syntax to CSS theme variables ([#17630](https://github.com/tailwindlabs/tailwindcss/pull/17630))
Prepare v4.1.3 release (#17563) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-04 19:54:23 +02:00
## [4.1.3] - 2025-04-04
Show warning when using unsupported bare value data type (#17464) This PR will show a warning if you are using a bare value data type that is not supported. Let's say you want to create a new utility that allows `color` to be a bare value data type like this: ```css @utility paint-* { paint: --value([color], color); } ``` This means that this would enable new syntax that we don't support yet. E.g.: `paint-#0088cc`. The only supported data types for bare values are: - `number` — `2.5` - `integer` — `2` - `ratio` — `1/2` - `percentage` — `50%` All other data types are not supported in this position. This PR will now show a warning: ~~~ Unsupported bare value data type: "color". Only valid data types are: "number", "integer", "ratio", "percentage". ```css --value([color],color) ^^^^^ ``` ~~~ Once we have better sourcemap / location tracking support, this warning will point to the exact spot, but for now, only a re-print of the AST can be used. If you _do_ want to use other data types, then you will have to use arbitrary value syntax with `[…]` instead. ```css @utility paint-* { paint: --value([color]); } ``` This will allow for `paint-[#0088cc]` for example. Note: this is not a behavioral change, we already didn't support other data types, but we silently ignored them. This means that we have to do more parsing at runtime when evaluating the utility. With this change, a warning is shown when registering the `@utility`, not when using it.
2025-04-04 14:20:46 +02:00
### Fixed
- Show warning when using unsupported bare value data type in `--value(…)` ([#17464](https://github.com/tailwindlabs/tailwindcss/pull/17464))
Prepare v4.1.3 release (#17563) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-04 19:54:23 +02:00
- PostCSS: Ensure changes to the input CSS file don't generate stale output when using Turbopack ([#17554](https://github.com/tailwindlabs/tailwindcss/pull/17554))
- Ensure classes are detected in Ruby's `%w` syntax in Slim templates ([#17557](https://github.com/tailwindlabs/tailwindcss/pull/17557))
Prepare release v4.1.2 (#17530) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-03 17:36:42 +02:00
## [4.1.2] - 2025-04-03
Use `@layer properties` for `@property` polyfills (#17506) This PR changes how polyfills for `@property` are inserted. The main motivation is to remove the need to rely on the correct placement of `@layer base;`—Something that's not really required right not in Tailwind CSS v4 and we'd like to keep it this way. The idea is that the polyfills are inserted for you automatically. To ensure they always take precedence, we insert an empty `@layer properties;` at the top of the CSS file so that later, when we emit all `@property` rules and their fallback, we can use this new named layer to ensure the rules have a higher order. Unfortunately, just putting `@layer properties;` at the beginning of a file would not work as `lightningcss` incorrectly hoists all content into the first occurrence of a layer name meaning these rules might be inserted _before_ eventual external imports: ![image](https://github.com/user-attachments/assets/c5a1694d-1549-47ed-ad0f-266807be4730) To work around this, we have to insert that layer name after any eventual remaining external `@imports` for now. ## Test plan - Updated snapshot tests - Deployed a new version of the website with the patch applied to ensure it works across browsers: https://tailwindcss-com-git-legacy-browsers-tailwindlabs.vercel.app/. Tested on: Safari on iOS 15.5, Safari on iOS 16.0, Firefox 127, Firefox 128, Chrome 110, Chrome latest, Safari latest, Firefox latest
2025-04-02 18:16:28 +02:00
### Fixed
Prepare release v4.1.2 (#17530) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-03 17:36:42 +02:00
- Don't rely on the presence of `@layer base` to polyfill `@property` ([#17506](https://github.com/tailwindlabs/tailwindcss/pull/17506))
- Support setting multiple inset shadows as arbitrary values ([#17523](https://github.com/tailwindlabs/tailwindcss/pull/17523))
- Fix `drop-shadow-*` utilities that are defined with multiple shadows ([#17515](https://github.com/tailwindlabs/tailwindcss/pull/17515))
Fix race condition in Next.js with `--turbopack` (#17514) This PR fixes an issue where if you use Next.js with `--turbopack` a race condition happens because the `@tailwindcss/postcss` plugin is called twice in rapid succession. The first call sees an update and does a partial update with the new classes. Next some internal `mtimes` are updated. The second call therefore doesn't see any changes anymore because the `mtimes` are the same, therefore it's serving its stale data. Fixes: #17508 ## Test plan - Tested with the repro provided in #17508 - Added a new unit test that calls into the PostCSS plugin directly for the same change from the same JavaScript run-loop. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-04-03 17:07:38 +02:00
- PostCSS: Fix race condition when two changes are queued concurrently ([#17514](https://github.com/tailwindlabs/tailwindcss/pull/17514))
Prepare release v4.1.2 (#17530) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-03 17:36:42 +02:00
- PostCSS: Ensure files containing `@tailwind utilities` are processed ([#17514](https://github.com/tailwindlabs/tailwindcss/pull/17514))
- Ensure the `color-mix(…)` polyfill creates fallbacks even when using colors that cannot be statically analyzed ([#17513](https://github.com/tailwindlabs/tailwindcss/pull/17513))
Fix slow incremental builds (especially on Windows) (#17511) This PR fixes slow rebuilds on Windows where rebuilds go from ~2s to ~20ms. Fixes: #16911 Fixes: #17522 ## Test plan 1. Tested it on a reproduction with the following results: Before: https://github.com/user-attachments/assets/10c5e9e0-3c41-4e1d-95f6-ee8d856577ef After: https://github.com/user-attachments/assets/2c7597e9-3fff-4922-a2da-a8d06eab9047 Zooming in on the times, it looks like this: <img width="674" alt="image" src="https://github.com/user-attachments/assets/85eee69c-bbf6-4c28-8ce3-6dcdad74be9c" /> But with these changes: <img width="719" alt="image" src="https://github.com/user-attachments/assets/d89cefda-0711-4f84-bfaf-2bea11977bf7" /> We also tested this on Windows with the following results: Before: <img width="961" alt="image" src="https://github.com/user-attachments/assets/3a42f822-f103-4598-9a91-e659ae09800c" /> After: <img width="956" alt="image" src="https://github.com/user-attachments/assets/05b6b6bc-d107-40d1-a207-3638aba3fc3a" /> [ci-all] --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-04-03 17:13:15 +02:00
- Fix slow incremental builds with `@tailwindcss/vite` and `@tailwindcss/postscss` (especially on Windows) ([#17511](https://github.com/tailwindlabs/tailwindcss/pull/17511))
update changelog
2025-04-03 19:14:18 +02:00
- Vite: Fix missing CSS file in Qwik setups ([#17533](https://github.com/tailwindlabs/tailwindcss/pull/17533))
Prepare release v4.1.1 (#17503)
2025-04-02 11:27:58 +02:00
## [4.1.1] - 2025-04-02
Disable padding in `@source inline(…)` brace expansion (#17491) The padding code we had was incorrect as it would always pad on the largest string representation. So for an input like this: ``` @source inline("z-{10..100..10}"); ``` It would create the following candidates: - `z-010` - `z-020` - `z-030` - `z-040` - `z-050` - `z-060` - `z-070` - `z-060` - `z-070` - `z-100` Instead of fixing the padding logic we realized that Tailwind utilities don't need padding at all so this PR removes this feature ## Test plan - Added the following to the Vite playground: `@source inline("z-{10..100..10}");` - Ensure it works: ![image](https://github.com/user-attachments/assets/f4714729-4ef7-4678-a531-70b471e75e6e)
2025-04-01 22:55:03 +02:00
### Fixed
- Disable padding in `@source inline(…)` brace expansion ([#17491](https://github.com/tailwindlabs/tailwindcss/pull/17491))
Inject polyfills after `@import` and body-less `@layer` (#17493) This PR fixes an issue where polyfills were injected at the top, but they should be after `@import` and body-less `@layer` rules. This is necessary in case you are using Google fonts like this for example: ```css @import url('https://fonts.google.com'); @import "tailwindcss"; ``` While the `@import url(…);` sits above `@import "tailwindcss";` in the final generated CSS we injected the polyfills at the very beginning. This PR will inject the polyfills after the first AST Node that is not: 1. A comment 2. An external import — `@import url(…)` 3. A body-less layer — `@layer foo, bar, baz;` The snapshots look a little confusing, but that's because Lightning CSS is optimizing the output and moving things around a bit: <img width="1482" alt="image" src="https://github.com/user-attachments/assets/a0552c8b-93df-4e1d-ad90-8b8abf9492b1" /> [Lightning CSS Playground](https://lightningcss.dev/playground/index.html#%7B%22minify%22%3Afalse%2C%22customMedia%22%3Atrue%2C%22cssModules%22%3Afalse%2C%22analyzeDependencies%22%3Afalse%2C%22targets%22%3A%7B%22chrome%22%3A6225920%7D%2C%22include%22%3A0%2C%22exclude%22%3A0%2C%22source%22%3A%22%40layer%20theme%2C%20base%2C%20components%2C%20utilities%3B%5Cn%5Cn%40supports%20(((-webkit-hyphens%3A%20none))%20and%20(not%20(margin-trim%3A%20inline)))%20or%20((-moz-orient%3A%20inline)%20and%20(not%20(color%3A%20rgb(from%20red%20r%20g%20b))))%20%7B%5Cn%20%20%40layer%20base%20%7B%5Cn%20%20%20%20*%2C%20%3Abefore%2C%20%3Aafter%2C%20%3A%3Abackdrop%20%7B%5Cn%20%20%20%20%20%20--tw-font-weight%3A%20initial%3B%5Cn%20%20%20%20%7D%5Cn%20%20%7D%5Cn%7D%5Cn%5Cn%40layer%20theme%20%7B%5Cn%20%20%3Aroot%2C%20%3Ahost%20%7B%5Cn%20%20%20%20--font-sans%3A%20ui-sans-serif%2C%20system-ui%2C%20sans-serif%2C%20%5C%22Apple%20Color%20Emoji%5C%22%2C%20%5C%22Segoe%20UI%20Emoji%5C%22%2C%20%5C%22Segoe%20UI%20Symbol%5C%22%2C%20%5C%22Noto%20Color%20Emoji%5C%22%3B%5Cn%20%20%20%20--font-mono%3A%20ui-monospace%2C%20SFMono-Regular%2C%20Menlo%2C%20Monaco%2C%20Consolas%2C%20%5C%22Liberation%20Mono%5C%22%2C%20%5C%22Courier%20New%5C%22%2C%20monospace%3B%5Cn%20%20%20%5Cn%20%20%7D%5Cn%7D%5Cn%5Cn%40layer%20base%20%7B%5Cn%20%20*%2C%20%3Aafter%2C%20%3Abefore%2C%20%3A%3Abackdrop%20%7B%5Cn%20%20%20%20box-sizing%3A%20border-box%3B%5Cn%20%20%20%20border%3A%200%20solid%3B%5Cn%20%20%20%20margin%3A%200%3B%5Cn%20%20%20%20padding%3A%200%3B%5Cn%20%20%7D%5Cn%7D%5Cn%5Cn%40layer%20utilities%20%7B%5Cn%20%20.text-2xl%20%7B%5Cn%20%20%20%20font-size%3A%20var(--text-2xl)%3B%5Cn%20%20%20%20line-height%3A%20var(--tw-leading%2C%20var(--text-2xl--line-height))%3B%5Cn%20%20%7D%5Cn%7D%5Cn%5Cn%40property%20--tw-font-weight%20%7B%5Cn%20%20syntax%3A%20%5C%22*%5C%22%3B%5Cn%20%20inherits%3A%20false%5Cn%7D%22%2C%22visitorEnabled%22%3Afalse%2C%22visitor%22%3A%22%7B%5Cn%20%20Color(color)%20%7B%5Cn%20%20%20%20if%20(color.type%20%3D%3D%3D%20'rgb')%20%7B%5Cn%20%20%20%20%20%20color.g%20%3D%200%3B%5Cn%20%20%20%20%20%20return%20color%3B%5Cn%20%20%20%20%7D%5Cn%20%20%7D%5Cn%7D%22%2C%22unusedSymbols%22%3A%5B%5D%2C%22version%22%3A%22local%22%7D) Fixes: #17494
2025-04-02 11:05:35 +02:00
- Inject polyfills after `@import` and body-less `@layer` ([#17493](https://github.com/tailwindlabs/tailwindcss/pull/17493))
Use `@tailwindcss/node` for import in CLI (#17502) Closes #17501 Seems like an oversight. The CLI does have a dependency on `@tailwindcss/node` so it should use it from the public import like the other stuff.
2025-04-02 11:16:58 +02:00
- Ensure `@tailwindcss/cli` does not contain an import for `jiti` ([#17502](https://github.com/tailwindlabs/tailwindcss/pull/17502))
Prepare 4.1.0 release (#17483) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-01 18:05:18 +02:00
## [4.1.0] - 2025-04-01
Introduce `:user-valid` & `:user-invalid` variants (#12370) See - https://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid - https://developer.mozilla.org/en-US/docs/Web/CSS/:user-invalid Just landed in Chrome, Firefox & Safari: - https://caniuse.com/mdn-css_selectors_user-valid - https://caniuse.com/mdn-css_selectors_user-invalid --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-02-12 17:17:54 +01:00
### Added
Prepare 4.1.0 release (#17483) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-01 18:05:18 +02:00
- Add `details-content` variant ([#15319](https://github.com/tailwindlabs/tailwindcss/pull/15319))
- Add `inverted-colors` variant ([#11693](https://github.com/tailwindlabs/tailwindcss/pull/11693))
- Add `noscript` variant ([#11929](https://github.com/tailwindlabs/tailwindcss/pull/11929), [#17431](https://github.com/tailwindlabs/tailwindcss/pull/17431))
- Add `items-baseline-last` and `self-baseline-last` utilities ([#13888](https://github.com/tailwindlabs/tailwindcss/pull/13888), [#17476](https://github.com/tailwindlabs/tailwindcss/pull/17476))
- Add `pointer-none`, `pointer-coarse`, and `pointer-fine` variants ([#16946](https://github.com/tailwindlabs/tailwindcss/pull/16946))
- Add `any-pointer-none`, `any-pointer-coarse`, and `any-pointer-fine` variants ([#16941](https://github.com/tailwindlabs/tailwindcss/pull/16941))
- Add safe alignment utilities ([#14607](https://github.com/tailwindlabs/tailwindcss/pull/14607))
- Add `user-valid` and `user-invalid` variants ([#12370](https://github.com/tailwindlabs/tailwindcss/pull/12370))
- Add `wrap-anywhere`, `wrap-break-word`, and `wrap-normal` utilities ([#12128](https://github.com/tailwindlabs/tailwindcss/pull/12128))
- Add `@source inline(…)` and `@source not inline(…)` ([#17147](https://github.com/tailwindlabs/tailwindcss/pull/17147))
- Add `@source not "…"` ([#17255](https://github.com/tailwindlabs/tailwindcss/pull/17255))
- Add `text-shadow-*` utilities ([#17389](https://github.com/tailwindlabs/tailwindcss/pull/17389))
- Add `mask-*` utilities ([#17134](https://github.com/tailwindlabs/tailwindcss/pull/17134))
- Add `bg-{position,size}-*` utilities for arbitrary values ([#17432](https://github.com/tailwindlabs/tailwindcss/pull/17432))
- Add `shadow-*/<alpha>`, `inset-shadow-*/<alpha>`, `drop-shadow-*/<alpha>`, and `text-shadow-*/<alpha>` utilities to control shadow opacity ([#17398](https://github.com/tailwindlabs/tailwindcss/pull/17398), [#17434](https://github.com/tailwindlabs/tailwindcss/pull/17434))
- Add `drop-shadow-<color>` utilities ([#17434](https://github.com/tailwindlabs/tailwindcss/pull/17434))
- Improve compatibility with older versions of Safari and Firefox ([#17435](https://github.com/tailwindlabs/tailwindcss/pull/17435))
Prepare v4.0.16 release (#17372) Prepare the 4.0.16 release. ~~Also added a commit to mark the `--value('…')` and `--modifier('…')` with literals strings as an experimental feature (aka not shipped in this PR). But we can revert that commit if we still want to ship it in 4.0.16 instead of 4.1.~~ --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-25 15:30:32 +01:00
Fix Ruby files causing the CLI to hang (#17383) Fixes #17379 The preprocessor we added to detect embedded languages uses a back reference and given a long enough file with certain byte / character patterns it'll cause what appears to be an indefinite hang (might just be catastrophically exponential backtracking but not sure) This replaces the one regex w/ back references with two, anchored, multi-line regexes Now we search for all the starting & ending delimiters in the file. We then loop over all the starting delimiters, find the paired ending one, and preprocess the content inside --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-26 06:00:10 -04:00
### Fixed
Prepare 4.1.0 release (#17483) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-01 18:05:18 +02:00
- Follow symlinks when resolving `@source` directives ([#17391](https://github.com/tailwindlabs/tailwindcss/pull/17391))
- Don't scan ignored files for classes when changing an ignored file triggers a rebuild using `@tailwindcss/cli` ([#17255](https://github.com/tailwindlabs/tailwindcss/pull/17255))
- Support negated `content` rules in legacy JavaScript configuration ([#17255](https://github.com/tailwindlabs/tailwindcss/pull/17255))
- Interpret syntax like `@("@")md:…` as `@md:…` in Razor files ([#17427](https://github.com/tailwindlabs/tailwindcss/pull/17427))
- Disallow top-level braces, top-level semicolons, and unbalanced parentheses and brackets in arbitrary values ([#17361](https://github.com/tailwindlabs/tailwindcss/pull/17361))
- Ensure the `--theme(…)` function still resolves to the CSS variables when using legacy JS plugins ([#17458](https://github.com/tailwindlabs/tailwindcss/pull/17458))
- Detect used theme variables in CSS module files ([#17433](https://github.com/tailwindlabs/tailwindcss/pull/17433), [#17467](https://github.com/tailwindlabs/tailwindcss/pull/17467))
Fix symlink issues when resolving `@source` directives (#17391) This PR fixes some issues related to symlinks when using them in the `@source` directive. Fixes: #16765 Fixes: #16038 ## Test plan 1. Added tests to prove this works - Added a recursive symlink test as well to make sure we don't hang 2. Existing tests still pass [ci-all]
2025-03-26 13:11:55 +01:00
Add `bg-{top,bottom}-{left,right}` utilities (#17378) We’re using this naming for `mask-*` and `mask-radial-at-*` position utilities and we want to be consistent. The old ones for `background-position` will stay but are deprecated --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-03-27 07:43:02 -04:00
### Changed
Prepare 4.1.0 release (#17483) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-01 18:05:18 +02:00
- Ignore `node_modules` by default (can be overridden by `@source …` rules) ([#17255](https://github.com/tailwindlabs/tailwindcss/pull/17255))
- `@source` rules that include file extensions or point inside `node_modules/` folders no longer consider your `.gitignore` rules ([#17255](https://github.com/tailwindlabs/tailwindcss/pull/17255))
- Deprecate `bg-{left,right}-{top,bottom}` in favor of `bg-{top,bottom}-{left,right}` utilities ([#17378](https://github.com/tailwindlabs/tailwindcss/pull/17378))
- Deprecate `object-{left,right}-{top,bottom}` in favor of `object-{top,bottom}-{left,right}` utilities ([#17437](https://github.com/tailwindlabs/tailwindcss/pull/17437))
Add `bg-{top,bottom}-{left,right}` utilities (#17378) We’re using this naming for `mask-*` and `mask-radial-at-*` position utilities and we want to be consistent. The old ones for `background-position` will stay but are deprecated --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-03-27 07:43:02 -04:00
Fix symlink issues when resolving `@source` directives (#17391) This PR fixes some issues related to symlinks when using them in the `@source` directive. Fixes: #16765 Fixes: #16038 ## Test plan 1. Added tests to prove this works - Added a recursive symlink test as well to make sure we don't hang 2. Existing tests still pass [ci-all]
2025-03-26 13:11:55 +01:00
## [4.0.17] - 2025-03-26
### Fixed
Fix Ruby files causing the CLI to hang (#17383) Fixes #17379 The preprocessor we added to detect embedded languages uses a back reference and given a long enough file with certain byte / character patterns it'll cause what appears to be an indefinite hang (might just be catastrophically exponential backtracking but not sure) This replaces the one regex w/ back references with two, anchored, multi-line regexes Now we search for all the starting & ending delimiters in the file. We then loop over all the starting delimiters, find the paired ending one, and preprocess the content inside --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-26 06:00:10 -04:00
- Fix an issue causing the CLI to hang when processing Ruby files ([#17383](https://github.com/tailwindlabs/tailwindcss/pull/17383))
Prepare v4.0.16 release (#17372) Prepare the 4.0.16 release. ~~Also added a commit to mark the `--value('…')` and `--modifier('…')` with literals strings as an experimental feature (aka not shipped in this PR). But we can revert that commit if we still want to ship it in 4.0.16 instead of 4.1.~~ --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-25 15:30:32 +01:00
## [4.0.16] - 2025-03-25
### Added
Revert "Temporarily revert changes to `@utility" This reverts commit 1aab04cebff39a5a1b89ff22c6655cf1f549b7a1.
2025-03-20 17:00:23 -04:00
- Add support for literal values in `--value('…')` and `--modifier('…')` ([#17304](https://github.com/tailwindlabs/tailwindcss/pull/17304))
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
Fix changelog (#17348) This change was added in #17320 which was not released yet, see commit order on `main`: https://github.com/tailwindlabs/tailwindcss/commits/main/
2025-03-24 11:39:22 +01:00
### Fixed
- Fix class extraction followed by `(` in Pug ([#17320](https://github.com/tailwindlabs/tailwindcss/pull/17320))
Prepare v4.0.16 release (#17372) Prepare the 4.0.16 release. ~~Also added a commit to mark the `--value('…')` and `--modifier('…')` with literals strings as an experimental feature (aka not shipped in this PR). But we can revert that commit if we still want to ship it in 4.0.16 instead of 4.1.~~ --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-25 15:30:32 +01:00
- Ensure `@keyframes` for theme animations are emitted if they are referenced following a comma ([#17352](https://github.com/tailwindlabs/tailwindcss/pull/17352))
- Vite: Ensure that updates to an imported CSS file are properly propagated after updating source files ([#17347](https://github.com/tailwindlabs/tailwindcss/pull/17347))
Pre process `Slim` templates embedded in Ruby files (#17336) This PR fixes an issue where embedded Slim templates inside of Ruby files are not pre processed because we pre process based on a file extension. This PR also handles embedded SLIM templates using the following syntax: ```rb slim_template <<~SLIM .flex .flex-1 h1 Hello World .flex-1 p This is a test SLIM ``` ~~As far as I can tell, this is only a Slim template thing and not a Haml template thing but I could be wrong here. See: https://viewcomponent.org/guide/templates.html#interpolations~~ The ViewComponent package handles anything that looks like `{lang}_template`, so the lang here will be used as the pre processing language for now. Fixes: #17334 # Test plan 1. Added test for this 2. Existing tests pass 3. Made sure that the snippet from the issue works as expected: Added an example where we have a `slim_template` and a `svelte_template` to prove that it embeds based on the language. I also added a `html_template` with Svelte syntax to really make sure that that _doesn't_ work. <img width="1816" alt="image" src="https://github.com/user-attachments/assets/35564a32-9c46-4b51-bb1f-e02f4ffe8b01" />
2025-03-24 11:58:37 +01:00
- Pre process `Slim` templates embedded in Ruby files ([#17336](https://github.com/tailwindlabs/tailwindcss/pull/17336))
Add Input & Output check to CLI (#17311) Throw an error if the input and output file for the CLI are identical. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-03-24 13:00:36 +02:00
- Error when input and output files resolve to the same file when using the CLI ([#17311](https://github.com/tailwindlabs/tailwindcss/pull/17311))
Prepare v4.0.16 release (#17372) Prepare the 4.0.16 release. ~~Also added a commit to mark the `--value('…')` and `--modifier('…')` with literals strings as an experimental feature (aka not shipped in this PR). But we can revert that commit if we still want to ship it in 4.0.16 instead of 4.1.~~ --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-25 15:30:32 +01:00
- Add missing suggestions when `--spacing(--value(integer, number))` is used ([#17308](https://github.com/tailwindlabs/tailwindcss/pull/17308))
- Add `::-webkit-details-marker` pseudo to `marker` variant ([#17362](https://github.com/tailwindlabs/tailwindcss/pull/17362))
Fix changelog (#17348) This change was added in #17320 which was not released yet, see commit order on `main`: https://github.com/tailwindlabs/tailwindcss/commits/main/
2025-03-24 11:39:22 +01:00
use correct heading level for v4.0.15
2025-03-25 15:52:51 +01:00
## [4.0.15] - 2025-03-20
Prepare v4.0.15 release (#17302) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2025-03-20 17:51:30 +01:00
Fix `-bg-conic-*` utilities (#17174) The negative versions were missing the `deg` in `<number>deg` so they didn’t work whoops
2025-03-13 10:13:56 -04:00
### Fixed
- Fix incorrect angle in `-bg-conic-*` utilities ([#17174](https://github.com/tailwindlabs/tailwindcss/pull/17174))
Fix inferring data type of `border-[…]` with multiple values (#17248) This PR fixes an issue where arbitrary values such as `border-[12px_4px]` were incorrectly producing `border-color` instead of `border-width` values. To solve it, I extended the `<line-width>` check to make sure that every part of the value is a valid `<line-width>`. In order for a `line-width` to be valid, every part should be one of: 1. A keyword: `thin`, `medium`, `thick` 2. A length: `12px` 3. A number: `0` Fixes: #17221 # Test plan 1. Added test to verify this works 2. All existing tests pass
2025-03-17 12:35:55 +01:00
- Fix `border-[12px_4px]` being interpreted as a `border-color` instead of a `border-width` ([#17248](https://github.com/tailwindlabs/tailwindcss/pull/17248))
Revert "Don't use `color-mix(…)` on `currentColor` (#17247)" and work around Preflight crash (#17306) Closes #17194. This reverts commit d6d913ec39e2a4cc0a70e9d21c484c6ed95d40ae. The initial fix does breaks older versions of Chrome (where text won't render with a color for the placeholder at all anymore) and the usage of the _relative colors_ features also means it'll require a much newer version of Safari/Firefox/Chrome to work correctly. The implementation was also wrong as it always set alpha to the specific percent instead of applying it additively (note that this can be fixed with `calc(alpha * opacity)` though). Instead we decided to fix this by adding a `@supports` query to Preflight that only targets browsers that aren't affected by the crash. We currently use the following workaround: ```css /* Set the default placeholder color to a semi-transparent version of the current text color in browsers that do not crash when using `color-mix(…)` with `currentColor`. (https://github.com/tailwindlabs/tailwindcss/issues/17194) */ @supports (not (-webkit-appearance: -apple-pay-button)) /* Not Safari */ or (contain-intrinsic-size: 1px) /* Safari 17+ */ { ::placeholder { color: color-mix(in oklab, currentColor 50%, transparent); } } ``` ## Test plan When testing the `color-mix(currentColor)` vs `oklab(from currentColor …)` we created the following support matrix. I'm extending it with _our fix_ which is the fix ended up using: | Browser | Version | `color-mix(… currentColor …)` | `oklab(from currentColor …)` | `@supports { color-mix(…) }` | | ------- | ------- | ----------------------------- | ---------------------------- | ------- | | Chrome | 111 | ❌ | ❌ | ❌ | | Chrome | 116 | ✅ | ❌ | ✅ | | Chrome | 131+ | ✅ | ✅ | ✅ | | Safari | 16.4 | 💥 | ❌ | ❌ | | Safari | 16.6+ | ✅ | ❌ | ❌ | | Safari | 18+ | ✅ | ✅ | ✅ | | Firefox | 128 | ✅ | ❌ | ✅ | | Firefox | 133 | ✅ | ✅ | ✅ | Note that on Safari 16, this change makes it so that the browser does not crash yet it still won't work either. That's because now the browser will fall back to the default placeholder color instead. We used the following play to test the fix: https://play.tailwindcss.com/RF1RYbZLKY
2025-03-20 17:43:32 +01:00
- Work around a crash in Safari 16.4 and 16.5 when using the default Preflight styles ([#17306](https://github.com/tailwindlabs/tailwindcss/pull/17306))
Pre process `<template lang="…">` in Vue files (#17252) This PR fixes an issue where `<template lang="…">…</template>` in Vue files should be handled as-if it's the language specified in the `lang` attribute. To do this, we added a new Vue pre processor and run the content through the same pre processor logic as we do for other languages. Fixes: #17211 # Test plan 1. Added a test to verify this works 2. Existing tests still work Visually verified against the reproduction in the issue: | Before | After | | --- | --- | | <img width="1273" alt="image" src="https://github.com/user-attachments/assets/d1accdeb-97cf-48ef-83fb-978832b3e599" /> | <img width="1273" alt="image" src="https://github.com/user-attachments/assets/ab7ec19c-b6c4-43be-8845-096ff4e58808" /> | --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-17 14:54:37 +01:00
- Pre-process `<template lang="…">` in Vue files ([#17252](https://github.com/tailwindlabs/tailwindcss/pull/17252))
Revert "Don't use `color-mix(…)` on `currentColor` (#17247)" and work around Preflight crash (#17306) Closes #17194. This reverts commit d6d913ec39e2a4cc0a70e9d21c484c6ed95d40ae. The initial fix does breaks older versions of Chrome (where text won't render with a color for the placeholder at all anymore) and the usage of the _relative colors_ features also means it'll require a much newer version of Safari/Firefox/Chrome to work correctly. The implementation was also wrong as it always set alpha to the specific percent instead of applying it additively (note that this can be fixed with `calc(alpha * opacity)` though). Instead we decided to fix this by adding a `@supports` query to Preflight that only targets browsers that aren't affected by the crash. We currently use the following workaround: ```css /* Set the default placeholder color to a semi-transparent version of the current text color in browsers that do not crash when using `color-mix(…)` with `currentColor`. (https://github.com/tailwindlabs/tailwindcss/issues/17194) */ @supports (not (-webkit-appearance: -apple-pay-button)) /* Not Safari */ or (contain-intrinsic-size: 1px) /* Safari 17+ */ { ::placeholder { color: color-mix(in oklab, currentColor 50%, transparent); } } ``` ## Test plan When testing the `color-mix(currentColor)` vs `oklab(from currentColor …)` we created the following support matrix. I'm extending it with _our fix_ which is the fix ended up using: | Browser | Version | `color-mix(… currentColor …)` | `oklab(from currentColor …)` | `@supports { color-mix(…) }` | | ------- | ------- | ----------------------------- | ---------------------------- | ------- | | Chrome | 111 | ❌ | ❌ | ❌ | | Chrome | 116 | ✅ | ❌ | ✅ | | Chrome | 131+ | ✅ | ✅ | ✅ | | Safari | 16.4 | 💥 | ❌ | ❌ | | Safari | 16.6+ | ✅ | ❌ | ❌ | | Safari | 18+ | ✅ | ✅ | ✅ | | Firefox | 128 | ✅ | ❌ | ✅ | | Firefox | 133 | ✅ | ✅ | ✅ | Note that on Safari 16, this change makes it so that the browser does not crash yet it still won't work either. That's because now the browser will fall back to the default placeholder color instead. We used the following play to test the fix: https://play.tailwindcss.com/RF1RYbZLKY
2025-03-20 17:43:32 +01:00
- Ensure that all CSS variables used by Preflight are prefixed ([#17036](https://github.com/tailwindlabs/tailwindcss/pull/17036))
Fix segmentation fault when loading @tailwindcss/oxide in a Worker thread (#17276) When Tailwind is loaded in a Node Worker thread, it currently causes a segmentation fault on Linux when the thread exits. This is due to a longstanding issue in Rust that affects all native modules: https://github.com/rust-lang/rust/issues/91979. I reported this years ago but unfortunately it is still not fixed, and seems to have gotten worse in Rust 1.83.0 and later. Looks like Tailwind recently updated Rust versions and this issue started appearing when run in tools like Parcel that use worker threads. The workaround is to prevent the native module from ever being unloaded. One way to do that is to always load the native module in the main thread in addition to workers, but this is hard to enforce. @Brooooooklyn found another method, which is to use a linker option for this. I tested this on an Ubuntu system and verified it fixed the issue. You can test with the following script. ```js // test.js const {Worker} = require('worker_threads'); new Worker('./worker.js'); // worker.js require('@tailwindcss/oxide'); ``` Without this change, a segmentation fault will occur. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-03-18 13:28:20 -07:00
- Prevent segfault when loaded in a worker thread on Linux ([#17276](https://github.com/tailwindlabs/tailwindcss/pull/17276))
Ensure multiple `--value(…)` or `--modifier(…)` calls don't delete subsequent declarations (#17273) This PR fixes a bug in the handling of `@utility`. Essentially if you had a declaration where you used a `--modifier(…)` _and_ a `--value(…)` and both caused the declaration to be removed, the declaration after the current one would be removed as well. This happened because 2 reasons: 1. Once we removed the declaration when we handled `--modifier(…)`, we didn't stop the walk and kept going. 2. The `replaceWith(…)` code allows you to call the function multiple times but immediately mutates the AST. This means that if you call it multiple times that you are potentially removing / updating nodes followed by the current one. E.g.: ```css @utility mask-r-* { --mask-right: linear-gradient(to left, transparent, black --value(percentage)); --mask-right: linear-gradient( to left, transparent calc(var(--spacing) * --modifier(integer)), black calc(var(--spacing) * --value(integer)) ); mask-image: var(--mask-linear), var(--mask-radial), var(--mask-conic); } ``` If this is used as `mask-r-10%`, then the first definition of `--mask-right` is kept, but the second definition of `--mask-right` is deleted because both `--modifier(integer)` and `--value(integer)` do not result in a valid value. However, the `mask-image` declaration was also removed because the `replaceWith(…)` function was called twice. Once for `--modifier(integer)` and once for `--value(integer)`. # Test plan 1. Added a test to cover this case. 2. Existing tests pass. 3. Added a hard error if we call `replaceWith(…)` multiple times.
2025-03-19 14:25:53 +01:00
- Ensure multiple `--value(…)` or `--modifier(…)` calls don't delete subsequent declarations ([#17273](https://github.com/tailwindlabs/tailwindcss/pull/17273))
Fix class extraction followed by `(` in Slim (#17278) This PR fixes an issue where using the class shorthand in Slim templates, followed by an `(` results in the last class being ignored. E.g.: ```slim body.border-t-4.p-8(class="#{body_classes}" data-hotwire-native="#{hotwire_native_app?}" data-controller="update-time-zone") ``` This is because we will eventually extract `p-8` but it's followed by an invalid boundary character `(`. To solve this, we make sure to replace the `(` with a space. We already do a similar thing when the classes are followed by an `[`. One caveat, we _can_ have `(` in our classes, like `bg-(--my-color)`. But in my testing this is not something that can be used in the shorthand version. E.g.: ```slim div.bg-(--my-color) ``` Compiles to: ```html <div --my-color="" class="bg-"></div> ``` So I didn't add any special handling for this. Even when trying to escape the `(`, `-` and `)` characters, it still doesn't work. E.g.: ```slim div.bg-\(--my-color\) ``` Compiles to: ```html <div class="bg-">\(--my-color\)</div> ``` # Test plan 1. Added test for the issue 2. Existing tests pass 3. Verified via the extractor tool: | Before | After | | --- | --- | | <img width="958" alt="image" src="https://github.com/user-attachments/assets/f72c420e-5429-424f-a01d-12f724062bf2" /> | <img width="958" alt="image" src="https://github.com/user-attachments/assets/b0cc8f2f-97a8-4fca-8813-3bb1da8d99a8" /> | --- Fixes: #17277
2025-03-19 14:50:30 +01:00
- Fix class extraction followed by `(` in Slim ([#17278](https://github.com/tailwindlabs/tailwindcss/pull/17278))
Export `PluginUtils` from `tailwindcss/plugin` (#17299) Closes #17293 We used to export this in v3 so might as well bring it back for the `tailwindcss/plugin` export list.
2025-03-20 12:19:45 +01:00
- Export `PluginUtils` from `tailwindcss/plugin` for compatibility with v3 ([#17299](https://github.com/tailwindlabs/tailwindcss/pull/17299))
Prepare v4.0.15 release (#17302) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2025-03-20 17:51:30 +01:00
- Remove redundant `line-height: initial` from Preflight ([#15212](https://github.com/tailwindlabs/tailwindcss/pull/15212))
Use bun-baseline for all x64 builds (#17267) Closes #17259 This PR now also updates the MacOS x64 build to use `bun-baseline`, meaning all x64 builds now use baseline for the improved hardware compatibility. Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-03-20 12:16:04 +01:00
- Increase Standalone hardware compatibility on macOS x64 builds ([#17267](https://github.com/tailwindlabs/tailwindcss/pull/17267))
Ensure that the CSS file rebuilds if a new CSS variable is used from templates (#17301) Fixes #17288 This PR fixes an issue where changes in template files that _only mark a new CSS variable as used_ was not causing the CSS file to rebuilds. This also fixes a flaky integration test that was caused by a missing `await` line on the final assertion (causing it to sometimes run the assertion in time while the test runner was still running). ## Test plan Turns out we already had an integration test for this but it wasn't correctly running due to the missing await.
2025-03-20 12:52:02 +01:00
- Ensure that the CSS file rebuilds if a new CSS variable is used from templates ([#17301](https://github.com/tailwindlabs/tailwindcss/pull/17301))
Fix `-bg-conic-*` utilities (#17174) The negative versions were missing the `deg` in `<number>deg` so they didn’t work whoops
2025-03-13 10:13:56 -04:00
Prepare v4.0.15 release (#17302) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2025-03-20 17:51:30 +01:00
### Changed
- The `--theme(…)` function now returns CSS variables from your theme variables unless used inside positions where CSS variables are invalid (e.g. inside `@media` queries) ([#17036](https://github.com/tailwindlabs/tailwindcss/pull/17036))
Prepare v4.0.14 release (#17173)
2025-03-13 12:36:34 +01:00
## [4.0.14] - 2025-03-13
Do not extract candidates containing JS string interpolation pattern `${` (#17142) This PR fixes an issue where often people run into issues where they try to use string interpolation and it doesn't work. Even worse, it could result in crashes because we will actually generate CSS. This fix only filters out candidates with a pattern like `${`. If this occurs in a string position it is fine. Another solution would be to add a pre processor for JS/TS (and all thousand file extension combinations) but the problem is that you can also write JS in HTML files so we would have to pre process HTML as well which would not be ideal. # Test plan 1. Added tests to prove this works in arbitrary values, arbitrary variables in both utilities and variants. 2. Existing tests pass. 3. Some screenshots with before / after situations: Given this input: ```ts let color = '#0088cc'; let opacity = 0.8; let name = 'variable-name'; let classes = [ // Arbitrary Properties `[color:${color}]` `[${property}:value]`, `[--img:url('https://example.com?q=${name}')]`, // WONT WORK BUT VALID CSS // Arbitrary Values `bg-[${color}]`, // Arbitrary Variables `bg-(--my-${color})`, `bg-(--my-color,${color})`, // Arbitrary Modifier `bg-red-500/[${opacity}]`, `bg-red-500/(--my-${name})`, `bg-red-500/(--my-opacity,${opacity})`, // Arbitrary Variant `data-[state=${name}]:flex`, `supports-(--my-${name}):flex`, `[@media(width>=${value})]:flex`, ]; ``` This is the result: | Before | After | | --- | --- | | <img width="908" alt="image" src="https://github.com/user-attachments/assets/c64d1b16-d39d-48a6-a098-bc4477cb4b0a" /> | <img width="908" alt="image" src="https://github.com/user-attachments/assets/d71aaf62-5e13-4174-82bb-690eb81aaeaf" /> | Fixes: #17054 Fixes: #15853
2025-03-12 12:09:13 +01:00
### Fixed
- Do not extract candidates with JS string interpolation `${` ([#17142](https://github.com/tailwindlabs/tailwindcss/pull/17142))
Fix variants with `<digit>.</digit>` are extracted correctly (#17153) This PR fixes an issue where if you use a number with a decimal in a variant then it wasn't picked up correctly. E.g.: ``` <div class="2xl:flex 1.5xl:flex"></div> ^^^^^^^^ Picked up ^^^^^^^^^^ Not picket up ``` This PR fixes that behavior by applying the same rules for utilities where a `.` is valid if it is surrounded by numbers. # Test plan 1. Added test to ensure this is picked up 2. Existing tests pass 3. Ran the extractor on a real example with the following results: | Before | After | | --- | --- | | <img width="821" alt="image" src="https://github.com/user-attachments/assets/a77ed5e4-6848-4fe3-8cbf-cf61ff8db41d" /> | <img width="821" alt="image" src="https://github.com/user-attachments/assets/61aca66a-e38d-4b61-bf86-e6286a89a3d9" /> | They are crossed out just because it's not a default value we know in the system, but you can see that the `1.` part is also extracted now. Fixes: #17148
2025-03-12 22:04:11 +01:00
- Fix extraction of variants containing `.` character ([#17153](https://github.com/tailwindlabs/tailwindcss/pull/17153))
Ensure candidate extraction works as expected in Clojure/ClojureScript (#17087) This PR adds a Clojure/ClojureScript pre processor to make sure that candidate extraction works as expected. | Before | After | | --- | --- | | <img width="908" alt="image" src="https://github.com/user-attachments/assets/98aba8b6-0c44-47c6-b87c-ecf955e5e007" /> | <img width="908" alt="image" src="https://github.com/user-attachments/assets/7a5ec3eb-1630-4b60-80bd-c07bc2381d3b" /> | You can see that the classes preceded by `:` are not properly extracted in the before case, but they are in the after case. We do extract a few more cases now like `:class` and `:className` itself, but at least we also retrieve all the `flex-*` classes. We could also always ignore `:class` and `:className` literals: <img width="908" alt="image" src="https://github.com/user-attachments/assets/f5a67cae-25d6-4811-b777-f72fdb5ef450" />
2025-03-13 11:31:27 +01:00
- Fix extracting candidates in Clojure/ClojureScript ([#17087](https://github.com/tailwindlabs/tailwindcss/pull/17087))
Do not extract candidates containing JS string interpolation pattern `${` (#17142) This PR fixes an issue where often people run into issues where they try to use string interpolation and it doesn't work. Even worse, it could result in crashes because we will actually generate CSS. This fix only filters out candidates with a pattern like `${`. If this occurs in a string position it is fine. Another solution would be to add a pre processor for JS/TS (and all thousand file extension combinations) but the problem is that you can also write JS in HTML files so we would have to pre process HTML as well which would not be ideal. # Test plan 1. Added tests to prove this works in arbitrary values, arbitrary variables in both utilities and variants. 2. Existing tests pass. 3. Some screenshots with before / after situations: Given this input: ```ts let color = '#0088cc'; let opacity = 0.8; let name = 'variable-name'; let classes = [ // Arbitrary Properties `[color:${color}]` `[${property}:value]`, `[--img:url('https://example.com?q=${name}')]`, // WONT WORK BUT VALID CSS // Arbitrary Values `bg-[${color}]`, // Arbitrary Variables `bg-(--my-${color})`, `bg-(--my-color,${color})`, // Arbitrary Modifier `bg-red-500/[${opacity}]`, `bg-red-500/(--my-${name})`, `bg-red-500/(--my-opacity,${opacity})`, // Arbitrary Variant `data-[state=${name}]:flex`, `supports-(--my-${name}):flex`, `[@media(width>=${value})]:flex`, ]; ``` This is the result: | Before | After | | --- | --- | | <img width="908" alt="image" src="https://github.com/user-attachments/assets/c64d1b16-d39d-48a6-a098-bc4477cb4b0a" /> | <img width="908" alt="image" src="https://github.com/user-attachments/assets/d71aaf62-5e13-4174-82bb-690eb81aaeaf" /> | Fixes: #17054 Fixes: #15853
2025-03-12 12:09:13 +01:00
Prepare release 4.0.13 (#17132)
2025-03-11 17:58:53 +01:00
## [4.0.13] - 2025-03-11
Add Haml pre processor (#17051) This PR ensures we extract candidates from Haml files. Fixes: #17050
2025-03-07 22:32:15 +01:00
### Fixed
Prepare release 4.0.13 (#17132)
2025-03-11 17:58:53 +01:00
- Fix Haml pre-processing ([#17051](https://github.com/tailwindlabs/tailwindcss/pull/17051))
Add `.node` and `.wasm` to known binary file list (#17123) Closes #17092 After a lot of spelunking we found one specific reason for the very slow builds in the repro from #17092: Turns our we are needlessly scanning the binary `.node` extension for class names 😬. This PR adds `.wasm` and `.node` to the list of known binary extensions. ## Test plan - Check out the repro from `#17092` - Delete the `.gitignore` file - Observe that builds are very slow (`527.79s`) - Add a _pnpm override_ to load local versions of Oxide - `pnpm build` now completes in ~50s
2025-03-11 13:05:51 +01:00
- Ensure `.node` and `.wasm` files are not scanned for utilities ([#17123](https://github.com/tailwindlabs/tailwindcss/pull/17123))
Improve candidate extraction when candidates contain `.` characters (#17113) This PR fixes an issue where some classes weren't properly extracted due to some incorrect assumptions in the pre processors. Templating languages such as Haml, Slim and Pug allow you to write classes in a shorter way that are not properly contained inside of strings. E.g.: ```slim p.flex.px-2 ``` These candidates are not properly extracted because there are no bounding characters like quotes. To solve this, we pre-process it and replace `.` with ` ` characters. This results in something like: ``` p flex px-2 ``` However, this has some challenges on its own. Candidates like `px-2.5` cannot be written in this shorthand form, instead they need to be in strings. Now we _cannot_ replace the `.` because otherwise we would change `px-2.5` to `px-2 5` which is wrong. The next problem is that we need to know when they are in a "string". This has another set of problems because these templating languages allow you to write normal text that will eventually be the contents of the HTML tags. ```haml .text-red-500.text-3xl | This text can't should be red ^ Wait, is this the start of a string now??? ``` In this example, if we consider the `'` the start of a string, when it's clearly not, how would we know it's for _sure_ not a string? This ended up as a bit of a rabbit hole, but we came up with another approach entirely if we think about the original problem we want to solve which is when do we change `.` to ` ` characters. One of the rules in our current extractor is that a `.` has to be between 2 numbers. Which works great in a scenario like: `px-2.5`. However, if you look at Haml or Slim syntax, this is also allowed: ```slim p.bg-red-500.2xl:flex ^^^ Uh oh... ``` In this scenario, a `.` is surrounded by numbers so we shouldn't replace it with a space. But as you can see, we clearly do... so we need another heuristic in this case. Luckily, one of the rules in Tailwind CSS is that a utility cannot start with a number, but a variant _can_. This means that if we see a scenario like `<digit>.<digit>` then we can just check if the value after the `.` is a valid variant or not. In this case it is a valid variant so we _do_ want to replace the `.` with a ` ` even though we do have the `<digit>.<digit>` format. 🥴 # Test plan 1. Added additional tests. 2. Existing tests still pass --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-11 17:53:16 +01:00
- Improve performance when scanning JSON files ([#17125](https://github.com/tailwindlabs/tailwindcss/pull/17125))
Prepare release 4.0.13 (#17132)
2025-03-11 17:58:53 +01:00
- Fix extracting candidates containing dots in Haml, Pug, and Slim pre processors ([#17094](https://github.com/tailwindlabs/tailwindcss/pull/17094), [#17085](https://github.com/tailwindlabs/tailwindcss/pull/17085), [#17113](https://github.com/tailwindlabs/tailwindcss/pull/17113))
Don't extract links as arbitrary properties (#17129) Closes #17128 This PR prevents extraction of links inside square brackets as valid candidate: ``` [https://example/] ``` We do this by throwing out arbitrary properties when the value starts with a slash (`/`). ## Test plan - Added unit test --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-03-11 17:40:24 +01:00
- Don't create invalid CSS when encountering a link wrapped in square brackets ([#17129](https://github.com/tailwindlabs/tailwindcss/pull/17129))
Add Haml pre processor (#17051) This PR ensures we extract candidates from Haml files. Fixes: #17050
2025-03-07 22:32:15 +01:00
Prepare v4.0.12 release (#17033) Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-07 12:38:53 +01:00
## [4.0.12] - 2025-03-07
Fix sorting of classes that have undefined declarations (#16995) Closes #16973 Declaration values of `undefined` are an implementation detail and skipped when printing the CSS. Thus, these should not count towards the sort order at a.. ## Test plan - See added regression test
2025-03-06 15:20:12 +01:00
### Fixed
Enable URL rewriting for PostCSS (#16965) Fixes #16636 This PR enables URL rebasing for PostCSS. Furthermore it fixes an issue where transitive imports rebased against the importer CSS file instead of the input CSS file. While fixing this we noticed that this is also broken in Vite right now and that our integration test swallowed that when testing because it did not import any Tailwind CSS code and thus was not considered a Tailwind file. ## Test plan - Added regression integration tests - Also validated it against the repro of https://github.com/tailwindlabs/tailwindcss/issues/16962: <img width="1149" alt="Screenshot 2025-03-05 at 16 41 01" src="https://github.com/user-attachments/assets/85396659-d3d0-48c0-b1c7-6125ff8e73ac" /> --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-03-07 12:18:10 +01:00
- Vite: Fix `url(…)` rebasing in transitively imported CSS files ([#16965](https://github.com/tailwindlabs/tailwindcss/pull/16965))
- PostCSS: Rebase `url(…)`s in imported CSS files ([#16965](https://github.com/tailwindlabs/tailwindcss/pull/16965))
Fix sorting of classes that have undefined declarations (#16995) Closes #16973 Declaration values of `undefined` are an implementation detail and skipped when printing the CSS. Thus, these should not count towards the sort order at a.. ## Test plan - See added regression test
2025-03-06 15:20:12 +01:00
- Ensure utilities are sorted based on their actual property order ([#16995](https://github.com/tailwindlabs/tailwindcss/pull/16995))
Ensure strings in Pug and Slim templates are handled correctly (#17000) This PR fixes an issue where strings in the Pug and Slim pre-processor were handled using the `string_machine`. However, the `string_machine` is not for strings inside of Tailwind CSS classes which means that whitespace is invalid. This means that parts of the code that _are_ inside strings will not be inside strings and parts of the code that are not inside strings will be part of a potential string. This is a bit confusing to wrap your head around, but here is a visual representation of the problem: ``` .join(' ') ^ 3. start of new string, which means that the `)` _could_ be part of a string if a new `'` occurs later. ^ 2. whitespace is not allowed, stop string ^ 1. start of string ``` Fixes: #16998 # Test plan 1. Added new test 2. Existing tests still pass 3. Added a simple test helper to make sure that we can extract the correct candidates _after_ pre-processing
2025-03-06 17:24:00 +01:00
- Ensure strings in Pug and Slim templates are handled correctly ([#17000](https://github.com/tailwindlabs/tailwindcss/pull/17000))
Prepare v4.0.12 release (#17033) Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-07 12:38:53 +01:00
- Ensure classes between `}` and `{` are properly extracted ([#17001](https://github.com/tailwindlabs/tailwindcss/pull/17001))
Add Haml pre processor (#17051) This PR ensures we extract candidates from Haml files. Fixes: #17050
2025-03-07 22:32:15 +01:00
- Fix `razor`/`cshtml` pre-processing ([#17027](https://github.com/tailwindlabs/tailwindcss/pull/17027))
Ensure extracting candidates from JS embedded in a PHP string works as expected (#17031) This PR fixes an issue where candidates are not properly extractor when they end in `\`. This can happen if you embed a programming language like JS inside another language like PHP where you need to escape some strings. Here is an example of Livewire flux: ```blade @php if ($sidebarIsStashable) { $attributes = $attributes->merge([ 'x-init' => '$el.classList.add(\'-translate-x-full\'); $el.classList.add(\'transition-transform\')', // ^ ^ ]); } @endphp <div x-data {{ $attributes->class('border-r w-64 p-4 min-h-dvh max-h-dvh top-0 fixed left-0') }}> {{ $slot }} </div> ``` Where the `\'` is causing some issues. Another solution might be to add a custom pre processor for blade files where we drop the escaped characters, but that felt overkill for now because some escapes are still valid. Fixes: #17023 # Test plan 1. Added a test to cover this case. 2. Existing tests still pass
2025-03-07 12:19:01 +01:00
- Ensure extracting candidates from JS embedded in a PHP string works as expected ([#17031](https://github.com/tailwindlabs/tailwindcss/pull/17031))
Fix sorting of classes that have undefined declarations (#16995) Closes #16973 Declaration values of `undefined` are an implementation detail and skipped when printing the CSS. Thus, these should not count towards the sort order at a.. ## Test plan - See added regression test
2025-03-06 15:20:12 +01:00
Prepare v4.0.11 release (#16987)
2025-03-06 12:09:39 +01:00
## [4.0.11] - 2025-03-06
Ensure `--` is allowed inside candidates (#16972) This PR fixes an issue where named utilities that contain double dashes `--` are not extracted correctly. Some people use `--` in the middle of the utility to create some form of namespaced utility. Given this input: ```js let x = 'foo--bar' ``` The extracted candidates before this change: ```js [ "let", "x", "--bar" ] ``` The extracted candidates after this change: ```js [ "let", "x", "foo--bar", "--bar" ] ``` The reason `--bar` is still extracted in both cases is because of the CSS variable machine. We could improve its extraction by checking its boundary characters but that's a different issue. For now, the important thing is that `foo--bar` was extracted. # Test plan 1. Added new test 2. Existing tests pass
2025-03-05 22:46:43 +01:00
### Fixed
- Ensure classes containing `--` are extracted correctly ([#16972](https://github.com/tailwindlabs/tailwindcss/pull/16972))
Ensure classes containing number followed by dash or underscore are extracted correctly (#16980) Fixes #16978, and also added support for dash. Classes like `text-theme1-primary` or `text-theme1_primary` should be treated as valid. If this approach is not aligned with the project’s direction or there are any concerns, please feel free to close or edit this PR 😃 <br/> ### As is Classes conatining number followed by dash or underscore (e.g. `bg-theme1-primary`, `text-title1_strong`) are ignored, and utility classes are not generated. ### To be Classes conatining number followed by dash or underscore (e.g. `bg-theme1-primary`, `text-title1_strong`) are treated as valid tailwindcss classes --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-06 19:44:43 +09:00
- Ensure classes containing numbers followed by dash or underscore are extracted correctly ([#16980](https://github.com/tailwindlabs/tailwindcss/pull/16980))
Oxide: Extract arbitrary container queries (#16984) Closes #16982 Handle the case of variants looking like this: `@[32rem]:flex`. ## Test plan Added regression tests Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-03-06 11:55:42 +01:00
- Ensure arbitrary container queries are extracted correctly ([#16984](https://github.com/tailwindlabs/tailwindcss/pull/16984))
Fix Slim attributes (#16985) This PR fixes an issue in Slim templates where the start of attributes causes some candidates to be missing. ```slim .text-xl.text-red-600[ data-foo="bar" ] | This line should be red ``` Because of the `[` attached to the `text-red-600`, the `text-red-600` was not extracted because `[` is not a valid boundary character. To solve this, we copied the Pug pre processor and created a dedicated Slim pre processor. Next, we ensure that we replace `[` with ` ` in this scenario (by also making sure that we don't replace `[` where it's important). Additionally, we noticed that `.` was also replaced inside of arbitrary values such as URLs. This has been fixed for both Pug and Slim. Fixes: #16975 # Test plan 1. Added failing tests 2. Existing tests still pass
2025-03-06 11:59:14 +01:00
- Ensure classes ending in `[` are extracted in Slim templating language ([#16985](https://github.com/tailwindlabs/tailwindcss/pull/16985))
Ensure arbitrary variables with data types are extracted correctly (#16986) Closes #16983 This PR fixes an issue where the arbitrary variable machine did not extract data type correctly. ## Test plan - Added regression test
2025-03-06 12:05:33 +01:00
- Ensure arbitrary variables with data types are extracted correctly ([#16986](https://github.com/tailwindlabs/tailwindcss/pull/16986))
Ensure `--` is allowed inside candidates (#16972) This PR fixes an issue where named utilities that contain double dashes `--` are not extracted correctly. Some people use `--` in the middle of the utility to create some form of namespaced utility. Given this input: ```js let x = 'foo--bar' ``` The extracted candidates before this change: ```js [ "let", "x", "--bar" ] ``` The extracted candidates after this change: ```js [ "let", "x", "foo--bar", "--bar" ] ``` The reason `--bar` is still extracted in both cases is because of the CSS variable machine. We could improve its extraction by checking its boundary characters but that's a different issue. For now, the important thing is that `foo--bar` was extracted. # Test plan 1. Added new test 2. Existing tests pass
2025-03-05 22:46:43 +01:00
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
## [4.0.10] - 2025-03-05
### Added
Support bare `col-*` and `row-*` utilities (#15183) Resolves #15170. This PR adds support for bare integer values to the `col-*` and `row-*` utilities: ```css .col-5 { grid-column: 5; } .row-6 { grid-row: 6; } ``` These properties are shorthands for `grid-column-start`/`grid-column-end` and `grid-row-start`/`grid-row-end`, so using a bare integer value ends up being a shortcut for: ```css .col-5 { grid-column-start: 5; grid-column-end: auto; } ``` …which makes these basically work like an alternative to `col-start-*` and `row-start-*`. These support negative values like `-col-6` as well, which also technically extends to arbitrary values like `-col-[6/span_2]` now even though that is a junk value. I've decided not to guard against that though and just consider it user error to keep the implementation simple. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-02-27 17:58:24 -05:00
- Add `col-<number>` and `row-<number>` utilities for `grid-column` and `grid-row` ([#15183](https://github.com/tailwindlabs/tailwindcss/pull/15183))
Introduce `:user-valid` & `:user-invalid` variants (#12370) See - https://developer.mozilla.org/en-US/docs/Web/CSS/:user-valid - https://developer.mozilla.org/en-US/docs/Web/CSS/:user-invalid Just landed in Chrome, Firefox & Safari: - https://caniuse.com/mdn-css_selectors_user-valid - https://caniuse.com/mdn-css_selectors_user-invalid --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-02-12 17:17:54 +01:00
Ensure `not-*` does not remove `:is(…)` (#16825) Resolves #16821 This PR removes a special case in the `not-*` variant compound that removed `:is(…)` if it was the only part of the inversed selector list. While in-theory this makes sense, `:is(…)` accepts a _forgiving_ selector list where as `:not(…)` does not. See the [last point here](https://developer.mozilla.org/en-US/docs/Web/CSS/:not#description). This is an issue specifically in combinations with variants that have selectors that are not supported by all browsers yet, for example `:open`. It seems to be the most expected to simply keep the `:is(…)` here in any case. ## Test plan - Ensured the repro form #16821 now also works in browsers that do not support `:open` (Safari and Firefox at the time of writing this): <img width="484" alt="Screenshot 2025-02-26 at 15 36 22" src="https://github.com/user-attachments/assets/f3391693-895b-4e44-8566-95e2960ec4e3" />
2025-02-26 18:03:11 +01:00
### Fixed
- Ensure `not-*` does not remove `:is(…)` from variants ([#16825](https://github.com/tailwindlabs/tailwindcss/pull/16825))
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
- Ensure `@keyframes` are correctly emitted when using a prefix ([#16850](https://github.com/tailwindlabs/tailwindcss/pull/16850))
Don't swallow `@utility` declarations when `@apply` is used in nested rules (#16940) Fixes #16935 This PR fixes an issue where the order of how `@apply` was resolved was incorrect for nested rules. Consider this example: ```css .rule { @apply underline; .nested-rule { @apply custom-utility; } } @utility custom-utility { @apply flex; } ``` The way we topologically sort these, we end up with a list that looks roughly like this: ```css .rule { @apply underline; .nested-rule { @apply custom-utility; } } @utility custom-utility { @apply flex; } .nested-rule { @apply custom-utility; } ``` As you can see here the nested rule is now part of the top-level list. This is correct because we first have to substitute the `@apply` inside the `@utility custom-utility` before we can apply the `custom-utility` inside `.nested-rule`. However, because we were using a regular AST walk and because the initial `.rule` also contains the `.nested-rule` as child, we would first substitute the `@apply` inside the `.nested-rule`, causing the design-system to force resolve (and cache) the wrong value for `custom-utility`. Because the list is already flattened, we do not need to recursively look into child declarations when we traverse the sorted list. This PR changes it to use a regular `for` loop instead of the `walk`. ## Test plan - Added a regression test - Rest of tests still green
2025-03-04 16:54:05 +01:00
- Don't swallow `@utility` declarations when `@apply` is used in nested rules ([#16940](https://github.com/tailwindlabs/tailwindcss/pull/16940))
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
- Ensure `outline-hidden` behaves like `outline-none` outside of forced colors mode ([#16943](https://github.com/tailwindlabs/tailwindcss/pull/16943))
Allow `!important` on CSS variables (#16873) We recently fixed an issue (https://github.com/tailwindlabs/tailwindcss/issues/16664) so that we could remove the `!important` on CSS variables. The reason we did that is because Google Chrome is showing a warning in the devtools styles panel that this is invalid. However, this _is_ valid and the code actually works as expected. If we look at the CSS spec for this: > Note: Custom properties can contain a trailing `!important`, but this is automatically removed from the property’s value by the CSS parser, and makes the custom property "important" in the CSS cascade. In other words, the prohibition on top-level "!" characters does not prevent `!important` from being used, as the `!important` is removed before syntax checking happens. > > — https://www.w3.org/TR/css-variables-1/#syntax So given this input: ```css @import "tailwindcss"; body { --text-color: var(--color-white) !important; --bg-color: var(--color-blue-950) !important; /* Direct usage */ background-color: var(--bg-color); /* Usage inside other functions as-if the `!important` is in the middle instead of the end */ color: color-mix(in oklab, var(--text-color) 75%, transparent); } ``` You will notice that everything works as expected, but if you look at the Styles panel in Chrome for the `<body>` element, you will see an incorrect warning. (At least that's what you used to see, I updated Chrome and everything renders fine in devtools). Play: https://play.tailwindcss.com/BpjAJ6Uxg3?file=css This change reverts the "fix" for: https://github.com/tailwindlabs/tailwindcss/issues/16664. @winchesHe you were the original person that opened the issue so this info might be useful to you as well. Can you verify that the Play link above does work as expected for you? Fixes: #16810
2025-03-04 17:21:56 +01:00
- Allow `!important` on CSS variables again ([#16873](https://github.com/tailwindlabs/tailwindcss/pull/16873))
Vite: Work around crash when `.svg` file contains `#` or `?` (#16957) Closes #16877 This PR works around #16877 by not registering `.svg` files containing a `#` or `?` as a watch dependency for now. ## Test plan - Add a file to the Vite playground called `src/c#.svg` - Observe Vite no longer prints errors
2025-03-05 14:55:07 +01:00
- Vite: Do not crash when encountering an `.svg` file with `#` or `?` in the filename ([#16957](https://github.com/tailwindlabs/tailwindcss/pull/16957))
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
- Ensure utilities are properly detected within square brackets ([#16306](https://github.com/tailwindlabs/tailwindcss/pull/16306))
- Ensure utilities are properly detected using Angular's conditional class binding syntax ([#16306](https://github.com/tailwindlabs/tailwindcss/pull/16306))
- Ensure utilities starting with numbers are properly extracted from Slim templates ([#16306](https://github.com/tailwindlabs/tailwindcss/pull/16306))
- Discard arbitrary property candidates that have guaranteed-invalid property names ([#16306](https://github.com/tailwindlabs/tailwindcss/pull/16306))
Ensure `not-*` does not remove `:is(…)` (#16825) Resolves #16821 This PR removes a special case in the `not-*` variant compound that removed `:is(…)` if it was the only part of the inversed selector list. While in-theory this makes sense, `:is(…)` accepts a _forgiving_ selector list where as `:not(…)` does not. See the [last point here](https://developer.mozilla.org/en-US/docs/Web/CSS/:not#description). This is an issue specifically in combinations with variants that have selectors that are not supported by all browsers yet, for example `:open`. It seems to be the most expected to simply keep the `:is(…)` here in any case. ## Test plan - Ensured the repro form #16821 now also works in browsers that do not support `:open` (Safari and Firefox at the time of writing this): <img width="484" alt="Screenshot 2025-02-26 at 15 36 22" src="https://github.com/user-attachments/assets/f3391693-895b-4e44-8566-95e2960ec4e3" />
2025-02-26 18:03:11 +01:00
Remove `max-w-auto` and `max-h-auto` (#16917) Closes #16916 This PR removes `max-w-auto` and `max-h-auto` due to them not being part of v3 and not being valid CSS: - https://developer.mozilla.org/en-US/docs/Web/CSS/max-width#syntax - https://developer.mozilla.org/en-US/docs/Web/CSS/max-height#syntax <img width="886" alt="Screenshot 2025-03-03 at 14 00 39" src="https://github.com/user-attachments/assets/2c7fa17c-975b-4e1f-ae56-99b703d6ca70" /> <img width="163" alt="Screenshot 2025-03-03 at 13 54 26" src="https://github.com/user-attachments/assets/12902a14-5a1e-4d7f-8127-fc2a3833221d" /> I decided to keep `max-w-auto` and `max-h-auto` since these values are valid even though these were not in v3 either: <img width="886" alt="Screenshot 2025-03-03 at 13 55 11" src="https://github.com/user-attachments/assets/83bf6543-06a3-429e-b39e-ef3ac3290f0b" />
2025-03-05 11:59:33 +01:00
### Changed
- Removed `max-w-auto` and `max-h-auto` utilities as they generate invalid CSS ([#16917](https://github.com/tailwindlabs/tailwindcss/pull/16917))
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
- Replaced the existing candidate extractor with a brand new extractor to improve maintainability, correctness, and performance ([#16306](https://github.com/tailwindlabs/tailwindcss/pull/16306))
Prepare v4.0.9 release (#16804) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-25 17:33:28 +01:00
## [4.0.9] - 2025-02-25
Vite: Don't crash with virtual module dependencies (#16780) Fixes #16732 If we can not get the mtime from a file, chances are that the resource is a virtual module. This is perfectly legit and we can fall back to what we did before the changes in `4.0.8` (which is to rebuild the root every time a change contains a dependency like that). ## Test plan Added a test to mimic the setup from the repor in #16732. Also ensured the repro now passes: <img width="1278" alt="Screenshot 2025-02-24 at 17 29 38" src="https://github.com/user-attachments/assets/d111273d-579f-44c2-82f5-aa32d6a1879a" /> Note that importing virtual modules directly in CSS does not work as the resolver we use does not resolve against the Vite runtime it seems. This is unrelated to the regression added in `4.0.8` though and something to look into in the future.
2025-02-25 11:29:58 +01:00
### Fixed
Make JS APIs available to plugins and configs in the Standalone CLI (#15934) This PR ensures we bundle the relevant JS APIs in the Standalone CLI like `tailwindcss`, `tailwindcss/plugin`, `tailwindcss/colors`, etc… Before, when loading plugins or configs, imports for those resources would fail. Fixes #15235 --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-02-25 07:21:46 -05:00
- Make JS APIs available to plugins and configs in the Standalone CLI ([#15934](https://github.com/tailwindlabs/tailwindcss/pull/15934))
Prepare v4.0.9 release (#16804) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-25 17:33:28 +01:00
- Vite: Don't crash when importing a virtual module from JavaScript that ends in `.css` ([#16780](https://github.com/tailwindlabs/tailwindcss/pull/16780))
Make `@reference` emit variable fallbacks instead of CSS variable declarations (#16774) Fixes #16725 When using `@reference "tailwindcss";` inside a separate CSS root (e.g. Svelte `<style>` components, CSS modules, etc.), we have no guarantee that the CSS variables will be defined in the main stylesheet (or if there even is one). To work around potential issues with this we decided in #16676 that we would emit all used CSS variables from the `@theme` inside the `@reference` block. However, this is not only a bit surprising but also unexpected in CSS modules and Next.js that **requires CSS module files to only create scope-able declarations**. To fix this issue, we decided to not emit CSS variables but instead ensure all `var(…)` calls we create for theme values in reference mode will simply have their fallback value added. This ensures styles work as-expected even if the root Tailwind file does not pick up the variable as being used or _if you don't add a root at all_. Furthermore we do not duplicate any variable declarations across your stylesheets and you still have the ability to change variables at runtime. ## Test plan - Updated snapshots everywhere (see diff) - New Next.js CSS modules integration test
2025-02-25 11:36:43 +01:00
- Fix an issue where `@reference "…"` would sometimes omit keyframe animations ([#16774](https://github.com/tailwindlabs/tailwindcss/pull/16774))
Prepare v4.0.9 release (#16804) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-25 17:33:28 +01:00
- Ensure `z-*!` utilities are properly marked as `!important` ([#16795](https://github.com/tailwindlabs/tailwindcss/pull/16795))
Fix link in CHANGELOG.md (#16806) The proper PR for this changelog entry is #16800.
2025-02-25 16:12:14 -05:00
- Read UTF-8 CSS files that start with a byte-order mark (BOM) ([#16800](https://github.com/tailwindlabs/tailwindcss/pull/16800))
Ensure nested functions in selectors used with JavaScript plugins are not truncated (#16802) Fixes #16799 This was caused by a wrong condition in the CSS value parser that put child function arguments into the parent function by accident. ## Test plan - Added a unit test to guard against regressions - Validated against the repro: <img width="914" alt="Screenshot 2025-02-25 at 16 31 14" src="https://github.com/user-attachments/assets/f5fdf2e7-9c1b-4b04-89a8-1fa78a27f0f5" />
2025-02-25 17:00:55 +01:00
- Ensure nested functions in selectors used with JavaScript plugins are not truncated ([#16802](https://github.com/tailwindlabs/tailwindcss/pull/16802))
Vite: Don't crash with virtual module dependencies (#16780) Fixes #16732 If we can not get the mtime from a file, chances are that the resource is a virtual module. This is perfectly legit and we can fall back to what we did before the changes in `4.0.8` (which is to rebuild the root every time a change contains a dependency like that). ## Test plan Added a test to mimic the setup from the repor in #16732. Also ensured the repro now passes: <img width="1278" alt="Screenshot 2025-02-24 at 17 29 38" src="https://github.com/user-attachments/assets/d111273d-579f-44c2-82f5-aa32d6a1879a" /> Note that importing virtual modules directly in CSS does not work as the resolver we use does not resolve against the Vite runtime it seems. This is unrelated to the regression added in `4.0.8` though and something to look into in the future.
2025-02-25 11:29:58 +01:00
Prepare v4.0.9 release (#16804) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-25 17:33:28 +01:00
### Changed
- Emit variable fallbacks when using `@reference "…"` instead of duplicate CSS variable declarations ([#16774](https://github.com/tailwindlabs/tailwindcss/pull/16774))
Prepare v4.0.8 release (#16713) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-21 16:06:37 +01:00
## [4.0.8] - 2025-02-21
Re-enable: Only expose used CSS variables (#16676) This PR re-enables the changes necessary to remove unused theme variables and keyframes form your CSS. This change was initially landed as #16211 and then later reverted in #16403 because we found some unexpected interactions with using `@apply` and CSS variables in multi-root setups like CSS modules or Vue inline `<style>` blocks that were no longer seeing their required variables defined. This issue is fixed by now ensuring that theme variables that are defined within an `@reference "…"` boundary will still be emitted in the generated CSS when used (as this would otherwise not generate a valid stylesheet). So given the following input CSS: ```css @reference "tailwindcss"; .text-red { @apply text-red-500; } ``` We will now compile this to: ```css @layer theme { :root, :host { --text-red-500: oklch(0.637 0.237 25.331); } } .text-red { color: var(--text-red-500); } ``` This PR also improves the initial implementation to not mark theme variables as used if they are only used to define other theme variables. For example: ```css @theme { --font-sans: ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; --font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, 'Liberation Mono', 'Courier New', monospace; --default-font-family: var(--font-sans); --default-mono-font-family: var(--font-mono); } .default-font-family { font-family: var(--default-font-family); } ``` This would be reduced to the following now as `--font-mono` is only used to define another variable and never used outside the theme block: ```css :root, :host { --font-sans: ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; --default-font-family: var(--font-sans); } .default-font-family { font-family: var(--default-font-family); } ``` ## Test plan - See updated unit and integration tests - Validated it works end-to-end by using a SvelteKit example
2025-02-21 10:45:22 +01:00
Prepare v4.0.8 release (#16713) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-21 16:06:37 +01:00
### Added
- Allow `@import` with `theme(…)` options for stylesheets that contain more than just `@theme` rules ([#16514](https://github.com/tailwindlabs/tailwindcss/pull/16514))
Re-enable: Only expose used CSS variables (#16676) This PR re-enables the changes necessary to remove unused theme variables and keyframes form your CSS. This change was initially landed as #16211 and then later reverted in #16403 because we found some unexpected interactions with using `@apply` and CSS variables in multi-root setups like CSS modules or Vue inline `<style>` blocks that were no longer seeing their required variables defined. This issue is fixed by now ensuring that theme variables that are defined within an `@reference "…"` boundary will still be emitted in the generated CSS when used (as this would otherwise not generate a valid stylesheet). So given the following input CSS: ```css @reference "tailwindcss"; .text-red { @apply text-red-500; } ``` We will now compile this to: ```css @layer theme { :root, :host { --text-red-500: oklch(0.637 0.237 25.331); } } .text-red { color: var(--text-red-500); } ``` This PR also improves the initial implementation to not mark theme variables as used if they are only used to define other theme variables. For example: ```css @theme { --font-sans: ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; --font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, 'Liberation Mono', 'Courier New', monospace; --default-font-family: var(--font-sans); --default-mono-font-family: var(--font-mono); } .default-font-family { font-family: var(--default-font-family); } ``` This would be reduced to the following now as `--font-mono` is only used to define another variable and never used outside the theme block: ```css :root, :host { --font-sans: ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol', 'Noto Color Emoji'; --default-font-family: var(--font-sans); } .default-font-family { font-family: var(--default-font-family); } ``` ## Test plan - See updated unit and integration tests - Validated it works end-to-end by using a SvelteKit example
2025-02-21 10:45:22 +01:00
Fix remove `!important` on CSS variable declarations (#16668) This PR fixes an issue where `!important` is added to declarations that define CSS variables. The `!important` should only be added to the other declarations. Before: ```css .ease-out\! { --tw-ease: var(--ease-out) !important; transition-timing-function: var(--ease-out) !important; } ``` After: ```css .ease-out\! { --tw-ease: var(--ease-out); transition-timing-function: var(--ease-out) !important; } ``` Fixes: https://github.com/tailwindlabs/tailwindcss/issues/16664
2025-02-19 18:20:09 +01:00
### Fixed
Prepare v4.0.8 release (#16713) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-21 16:06:37 +01:00
- Don't add `!important` to CSS variable declarations when using the important modifier ([#16668](https://github.com/tailwindlabs/tailwindcss/pull/16668))
- Vite: Ignore files and directories specified in your `.gitignore` file when using automatic source detection([#16631](https://github.com/tailwindlabs/tailwindcss/pull/16631))
- Vite: Don't rely on the module graph for detecting candidates to ensure setups with multiple Vite builds work as expected ([#16631](https://github.com/tailwindlabs/tailwindcss/pull/16631))
- Vite: Ensure Astro production builds always contain classes used in client-only components ([#16631](https://github.com/tailwindlabs/tailwindcss/pull/16631))
- Vite: Always scan raw file contents for utility classes before any other transforms have been applied to ensure utility classes are scanned without any additional escaping ([#16631](https://github.com/tailwindlabs/tailwindcss/pull/16631))
- Ensure utilities with more declarations are always sorted before utilities with fewer declarations when utilities only define CSS variables ([#16715](https://github.com/tailwindlabs/tailwindcss/pull/16715))
- Only include `translate-z-px` utilities once in compiled CSS ([#16718](https://github.com/tailwindlabs/tailwindcss/pull/16718))
### Changed
- Don't include theme variables that aren't used in compiled CSS ([#16211](https://github.com/tailwindlabs/tailwindcss/pull/16211), [#16676](https://github.com/tailwindlabs/tailwindcss/pull/16676))
Fix remove `!important` on CSS variable declarations (#16668) This PR fixes an issue where `!important` is added to declarations that define CSS variables. The `!important` should only be added to the other declarations. Before: ```css .ease-out\! { --tw-ease: var(--ease-out) !important; transition-timing-function: var(--ease-out) !important; } ``` After: ```css .ease-out\! { --tw-ease: var(--ease-out); transition-timing-function: var(--ease-out) !important; } ``` Fixes: https://github.com/tailwindlabs/tailwindcss/issues/16664
2025-02-19 18:20:09 +01:00
Prepare v4.0.7 release (#16629) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-18 16:51:20 +01:00
## [4.0.7] - 2025-02-18
Add `tailwindcss/lib/util/flattenColorPalette.js` export (#16411) Closes #16401 This adds a `tailwindcss/lib/util/flattenColorPalette.js` (notice the `.js` suffix) inline with our other exports.
2025-02-10 23:01:26 +01:00
### Fixed
- Export `tailwindcss/lib/util/flattenColorPalette.js` for backward compatibility ([#16411](https://github.com/tailwindlabs/tailwindcss/pull/16411))
Prepare v4.0.7 release (#16629) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-18 16:51:20 +01:00
- Fix sorting of numeric utility suggestions when they have different magnitudes ([#16414](https://github.com/tailwindlabs/tailwindcss/pull/16414))
Show suggestions for fractions in IntelliSense (#16353) Fixes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1178 (partially) An IntelliSense PR (+ Play update) is required to make this work better with v4: https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1182 <img width="671" alt="Screenshot 2025-02-07 at 15 19 59" src="https://github.com/user-attachments/assets/7642b80c-f431-4a1e-964d-2a98ffe7a67a" />
2025-02-11 12:03:37 -05:00
- Show suggestions for fractions in IntelliSense ([#16353](https://github.com/tailwindlabs/tailwindcss/pull/16353))
Don’t replace `_` in suggested theme keys (#16433) Fixes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1184 The alpha and beta releases used `_` in theme keys to represent a `.`. This meant we used `--leading-1_5` instead of `--leading-1\.5` to add utilities like `leading-1.5`. We prefer the use of the escaped dot now but still want to make sure suggestions for the legacy key format still works as expected when surrounded by numbers.
2025-02-11 13:14:43 -05:00
- Don’t replace `_` in suggested theme keys ([#16433](https://github.com/tailwindlabs/tailwindcss/pull/16433))
Prepare v4.0.7 release (#16629) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-18 16:51:20 +01:00
- Ensure `--default-outline-width` can be used to change the `outline-width` value of the `outline` utility ([#16469](https://github.com/tailwindlabs/tailwindcss/pull/16469))
Emit `--tw-drop-shadow` property (#16471) Fixes #16461 Ensure we also emit `@property --tw-drop-shadow`. ## Test plan ``` <div class="drop-shadow-2xl size-72 bg-white"> <div class="size-48 saturate-100 bg-white"></div> </div> ``` now only drops one shadow (screenshot from Vite playground): <img width="562" alt="Screenshot 2025-02-12 at 16 37 25" src="https://github.com/user-attachments/assets/94eaaf54-6fd5-4d10-9297-9e7523a02602" />
2025-02-12 18:36:03 +01:00
- Ensure drop shadow utilities don't inherit unexpectedly ([#16471](https://github.com/tailwindlabs/tailwindcss/pull/16471))
Prepare v4.0.7 release (#16629) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-18 16:51:20 +01:00
- Export config and plugin types from `tailwindcss/plugin` for backward compatibility ([#16505](https://github.com/tailwindlabs/tailwindcss/pull/16505))
- Ensure JavaScript plugins that emit nested rules referencing the utility name work as expected ([#16539](https://github.com/tailwindlabs/tailwindcss/pull/16539))
- Statically link Visual Studio redistributables in `@tailwindcss/oxide` Windows builds ([#16602](https://github.com/tailwindlabs/tailwindcss/pull/16602))
- Ensure that Next.js splat routes are scanned for classes ([#16457](https://github.com/tailwindlabs/tailwindcss/pull/16457))
- Pin exact version of `tailwindcss` in `@tailwindcss/*` packages ([#16623](https://github.com/tailwindlabs/tailwindcss/pull/16623))
Upgrade: Report errors when updating dependencies (#16504) Closes #16391 Like the title suggest this PR adds error reporting when the `npm install` or `npm remove` commands fail. ## Test plan Tested by swapping out the command for `echo "bla"; exit 1` and capturing the output from the integration tests: <img width="792" alt="Screenshot 2025-02-13 at 14 33 02" src="https://github.com/user-attachments/assets/d1288114-106a-4ac6-a54b-d02b74c98f35" /> <img width="761" alt="Screenshot 2025-02-13 at 14 31 05" src="https://github.com/user-attachments/assets/6d5b9427-457f-4e67-9723-4e340da61749" /> Decided not to add a new test for this since it's unlikely we'll do big changes here and the upgrade integration tests are already quite slow.
2025-02-13 16:02:59 +01:00
- Upgrade: Report errors when updating dependencies ([#16504](https://github.com/tailwindlabs/tailwindcss/pull/16504))
Upgrade: Handle `darkMode` value with block syntax (#16507) Closes #16171 This PR handles `darkMode` variant configs containing braces (so creating sub-rules) the same way we handle it in the interop layer. Since the interop layer runs inside the `addVariant` API that we do not run here, I instead oped to copy the one liner. ## Test plan Updated one of the migration tests to include a rule that wasn't working before. Ensured the new output works via https://play.tailwindcss.com/nR99uhKtv3
2025-02-14 16:48:52 +01:00
- Upgrade: Ensure a `darkMode` JS config setting with block syntax converts to use `@slot` ([#16507](https://github.com/tailwindlabs/tailwindcss/pull/16507))
Prepare v4.0.7 release (#16629) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-18 16:51:20 +01:00
- Upgrade: Ensure the latest version of `tailwindcss` and `@tailwindcss/postcss` are installed when upgrading ([#16620](https://github.com/tailwindlabs/tailwindcss/pull/16620))
Prepare v4.0.6 (#16407)
2025-02-10 14:09:00 +01:00
## [4.0.6] - 2025-02-10
Revert: Only expose used CSS variables (#16403) This reverts #16211 We found some unexpected interactions with using `@apply` and CSS variables in multi-root setups like CSS modules or Vue inline `<style>` blocks that were broken due to that change. We plan to re-enable this soon and include a proper fix for those scenarios. ## Test plan - Updated snapshots - Tested using the CLI in a new project: <img width="1523" alt="Screenshot 2025-02-10 at 13 08 42" src="https://github.com/user-attachments/assets/defe0858-adb3-4d61-9d2c-87166558fd68" /> --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-02-10 13:26:13 +01:00
### Fixed
Prepare v4.0.6 (#16407)
2025-02-10 14:09:00 +01:00
- Revert change to no longer include theme variables that aren't used in compiled CSS ([#16403](https://github.com/tailwindlabs/tailwindcss/pull/16403))
fix(upgrade): prevent nextjs image blur property from modified (#16405) Fix #16404 --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-02-11 17:37:59 +01:00
- Upgrade: Don't migrate `blur` to `blur-sm` when used with Next.js `<Image placeholder="blur" />` ([#16405](https://github.com/tailwindlabs/tailwindcss/pull/16405))
Prepare v4.0.5 (#16373) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2025-02-08 13:48:34 -05:00
## [4.0.5] - 2025-02-08
### Added
- Add `@theme static` option for always including theme variables in compiled CSS ([#16211](https://github.com/tailwindlabs/tailwindcss/pull/16211))
Only expose used CSS variables (#16211) This PR only exposes used CSS variables. My initial approach was to track the used variables, this was a bit messy because it meant that we had to walk part of the AST(s) in multiple places. We also had to be careful because sometimes if a variable exists in an AST, that doesn't mean that it's actually used. E.g.: ```css h1 { color: var(--color-red-500); /* Definitely used, so let's keep it */ } @utility foo { color: var(--color-blue-500); /* Hmm, used? */ } ``` In this last case, the `--color-blue-500` is part of the CSS AST, but as long as `foo` the utility is not used, it won't end up in your actual CSS file, therefore the variable is **not** used. Alternatively, if the `foo` utility is used with an invalid variant (e.g.: `group-[>.foo]:foo`, then the `@utility foo` code will still run internally because variants are applied on top of the utility. This means that it looks like `var(--color-blue-500)` is being used. Another annoying side effect was that because variables are conditionally generated, that the `@theme` -> `:root, :host` conversion had to happen for every build, instead of once in the `compile(…)` step. --- To prevent all the messy rules and additional booking while walking of ASTs I thought about a different approach. We are only interested in variables that are actually used. The only way we know for sure, is right before the `toCss(…)` step. Any step before that could still throw away AST nodes. However, we do have an `optimizeAst` step right before printing to simplify and optimize the AST. So the idea was to keep all the CSS variables in the AST, and only in the `optimizeAst` step we perform a kind of mark-and-sweep algorithm where we can first check which variables are _actually_ used (these are the ones that are left in the AST), and later we removed the ones that weren't part of known used list. Moving the logic to this step feels a natural spot for this to happen, because we are in fact optimizing the AST. We were already walking the AST, so we can just handle these cases while we are walking without additional walks. Last but not least, this also means that there is only a single spot where need to track and remove variables. Now, there is a different part to this story. If you use a variable in JS land for example, we also want to make sure that we keep the CSS variable in the CSS. To do this, we can mark variables as being used in the internal `Theme`. The Oxide scanner will also emit used variables that it can find such as `var(--color-red-500)` and will emit `--color-red-500` as a "candidate". We can then proactively mark this one as used even though it may not be used anyway in the actual AST. --- ### Always including all variables Some users might make heavy use of JavaScript and string interpolation where they _need_ all the variables to be present. Similar to the `inline` and `reference` theme options, this also exposes a new `static` option. This ensures that all the CSS variables will always be generated regardless of whether it's used or not. One handy feature is that you have granular control over this: ```css /* These will always be generated */ @theme static { --color-primary: red; --color-secondary: blue; } /* Only generated when used */ @theme { --color-maybe: pink; } ``` ### Performance considerations: Now that we are tracking which variables are being used, it means that we will produce a smaller CSS file, but we are also doing more work (the mark-and-sweep part). That said, ran some benchmarks and the changes look like this: Running it on Catalyst: <img width="1086" alt="image" src="https://github.com/user-attachments/assets/ec2124f0-2e64-4a11-aa5e-5f7ae6605962" /> _(probably within margin of error)_ Running it on Tailwind UI: <img width="1113" alt="image" src="https://github.com/user-attachments/assets/6bea2328-d790-4f33-a0ae-72654c688edb" /> ### Test plan - Tests have been updated with the removed CSS variables - Added a dedicated integration test to show that Oxide can find variables and mark them as used (so they are included) - Ran the code on Catalyst, and verified that all the removed variables are in fact not used anywhere in the codebase. The diff on Catalyst looks like this: <details> ```diff diff --git a/templates/catalyst/out.css b/templates/catalyst/out.css index f2b364ea..240d1d90 100644 --- a/templates/catalyst/out.css +++ b/templates/catalyst/out.css @@ -29,218 +29,111 @@ @layer theme { :root, :host { --font-sans: Inter, sans-serif; - --font-serif: ui-serif, Georgia, Cambria, "Times New Roman", Times, serif; --font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace; - --color-red-50: oklch(0.971 0.013 17.38); - --color-red-100: oklch(0.936 0.032 17.717); --color-red-200: oklch(0.885 0.062 18.334); --color-red-300: oklch(0.808 0.114 19.571); --color-red-400: oklch(0.704 0.191 22.216); --color-red-500: oklch(0.637 0.237 25.331); --color-red-600: oklch(0.577 0.245 27.325); --color-red-700: oklch(0.505 0.213 27.518); - --color-red-800: oklch(0.444 0.177 26.899); --color-red-900: oklch(0.396 0.141 25.723); - --color-red-950: oklch(0.258 0.092 26.042); - --color-orange-50: oklch(0.98 0.016 73.684); - --color-orange-100: oklch(0.954 0.038 75.164); --color-orange-200: oklch(0.901 0.076 70.697); --color-orange-300: oklch(0.837 0.128 66.29); --color-orange-400: oklch(0.75 0.183 55.934); --color-orange-500: oklch(0.705 0.213 47.604); --color-orange-600: oklch(0.646 0.222 41.116); --color-orange-700: oklch(0.553 0.195 38.402); - --color-orange-800: oklch(0.47 0.157 37.304); --color-orange-900: oklch(0.408 0.123 38.172); - --color-orange-950: oklch(0.266 0.079 36.259); - --color-amber-50: oklch(0.987 0.022 95.277); - --color-amber-100: oklch(0.962 0.059 95.617); - --color-amber-200: oklch(0.924 0.12 95.746); - --color-amber-300: oklch(0.879 0.169 91.605); --color-amber-400: oklch(0.828 0.189 84.429); --color-amber-500: oklch(0.769 0.188 70.08); --color-amber-600: oklch(0.666 0.179 58.318); --color-amber-700: oklch(0.555 0.163 48.998); - --color-amber-800: oklch(0.473 0.137 46.201); - --color-amber-900: oklch(0.414 0.112 45.904); --color-amber-950: oklch(0.279 0.077 45.635); - --color-yellow-50: oklch(0.987 0.026 102.212); - --color-yellow-100: oklch(0.973 0.071 103.193); - --color-yellow-200: oklch(0.945 0.129 101.54); --color-yellow-300: oklch(0.905 0.182 98.111); --color-yellow-400: oklch(0.852 0.199 91.936); - --color-yellow-500: oklch(0.795 0.184 86.047); --color-yellow-600: oklch(0.681 0.162 75.834); --color-yellow-700: oklch(0.554 0.135 66.442); - --color-yellow-800: oklch(0.476 0.114 61.907); - --color-yellow-900: oklch(0.421 0.095 57.708); --color-yellow-950: oklch(0.286 0.066 53.813); - --color-lime-50: oklch(0.986 0.031 120.757); - --color-lime-100: oklch(0.967 0.067 122.328); - --color-lime-200: oklch(0.938 0.127 124.321); --color-lime-300: oklch(0.897 0.196 126.665); --color-lime-400: oklch(0.841 0.238 128.85); - --color-lime-500: oklch(0.768 0.233 130.85); --color-lime-600: oklch(0.648 0.2 131.684); --color-lime-700: oklch(0.532 0.157 131.589); - --color-lime-800: oklch(0.453 0.124 130.933); - --color-lime-900: oklch(0.405 0.101 131.063); --color-lime-950: oklch(0.274 0.072 132.109); - --color-green-50: oklch(0.982 0.018 155.826); - --color-green-100: oklch(0.962 0.044 156.743); - --color-green-200: oklch(0.925 0.084 155.995); - --color-green-300: oklch(0.871 0.15 154.449); --color-green-400: oklch(0.792 0.209 151.711); --color-green-500: oklch(0.723 0.219 149.579); --color-green-600: oklch(0.627 0.194 149.214); --color-green-700: oklch(0.527 0.154 150.069); - --color-green-800: oklch(0.448 0.119 151.328); --color-green-900: oklch(0.393 0.095 152.535); - --color-green-950: oklch(0.266 0.065 152.934); - --color-emerald-50: oklch(0.979 0.021 166.113); - --color-emerald-100: oklch(0.95 0.052 163.051); - --color-emerald-200: oklch(0.905 0.093 164.15); - --color-emerald-300: oklch(0.845 0.143 164.978); --color-emerald-400: oklch(0.765 0.177 163.223); --color-emerald-500: oklch(0.696 0.17 162.48); --color-emerald-600: oklch(0.596 0.145 163.225); --color-emerald-700: oklch(0.508 0.118 165.612); - --color-emerald-800: oklch(0.432 0.095 166.913); --color-emerald-900: oklch(0.378 0.077 168.94); - --color-emerald-950: oklch(0.262 0.051 172.552); - --color-teal-50: oklch(0.984 0.014 180.72); - --color-teal-100: oklch(0.953 0.051 180.801); - --color-teal-200: oklch(0.91 0.096 180.426); --color-teal-300: oklch(0.855 0.138 181.071); --color-teal-400: oklch(0.777 0.152 181.912); --color-teal-500: oklch(0.704 0.14 182.503); --color-teal-600: oklch(0.6 0.118 184.704); --color-teal-700: oklch(0.511 0.096 186.391); - --color-teal-800: oklch(0.437 0.078 188.216); --color-teal-900: oklch(0.386 0.063 188.416); - --color-teal-950: oklch(0.277 0.046 192.524); - --color-cyan-50: oklch(0.984 0.019 200.873); - --color-cyan-100: oklch(0.956 0.045 203.388); - --color-cyan-200: oklch(0.917 0.08 205.041); --color-cyan-300: oklch(0.865 0.127 207.078); --color-cyan-400: oklch(0.789 0.154 211.53); --color-cyan-500: oklch(0.715 0.143 215.221); - --color-cyan-600: oklch(0.609 0.126 221.723); --color-cyan-700: oklch(0.52 0.105 223.128); - --color-cyan-800: oklch(0.45 0.085 224.283); - --color-cyan-900: oklch(0.398 0.07 227.392); --color-cyan-950: oklch(0.302 0.056 229.695); - --color-sky-50: oklch(0.977 0.013 236.62); - --color-sky-100: oklch(0.951 0.026 236.824); - --color-sky-200: oklch(0.901 0.058 230.902); --color-sky-300: oklch(0.828 0.111 230.318); - --color-sky-400: oklch(0.746 0.16 232.661); --color-sky-500: oklch(0.685 0.169 237.323); --color-sky-600: oklch(0.588 0.158 241.966); --color-sky-700: oklch(0.5 0.134 242.749); - --color-sky-800: oklch(0.443 0.11 240.79); --color-sky-900: oklch(0.391 0.09 240.876); - --color-sky-950: oklch(0.293 0.066 243.157); - --color-blue-50: oklch(0.97 0.014 254.604); - --color-blue-100: oklch(0.932 0.032 255.585); - --color-blue-200: oklch(0.882 0.059 254.128); --color-blue-300: oklch(0.809 0.105 251.813); --color-blue-400: oklch(0.707 0.165 254.624); --color-blue-500: oklch(0.623 0.214 259.815); --color-blue-600: oklch(0.546 0.245 262.881); --color-blue-700: oklch(0.488 0.243 264.376); - --color-blue-800: oklch(0.424 0.199 265.638); --color-blue-900: oklch(0.379 0.146 265.522); - --color-blue-950: oklch(0.282 0.091 267.935); - --color-indigo-50: oklch(0.962 0.018 272.314); - --color-indigo-100: oklch(0.93 0.034 272.788); --color-indigo-200: oklch(0.87 0.065 274.039); --color-indigo-300: oklch(0.785 0.115 274.713); --color-indigo-400: oklch(0.673 0.182 276.935); --color-indigo-500: oklch(0.585 0.233 277.117); --color-indigo-600: oklch(0.511 0.262 276.966); --color-indigo-700: oklch(0.457 0.24 277.023); - --color-indigo-800: oklch(0.398 0.195 277.366); --color-indigo-900: oklch(0.359 0.144 278.697); - --color-indigo-950: oklch(0.257 0.09 281.288); - --color-violet-50: oklch(0.969 0.016 293.756); - --color-violet-100: oklch(0.943 0.029 294.588); --color-violet-200: oklch(0.894 0.057 293.283); --color-violet-300: oklch(0.811 0.111 293.571); --color-violet-400: oklch(0.702 0.183 293.541); --color-violet-500: oklch(0.606 0.25 292.717); --color-violet-600: oklch(0.541 0.281 293.009); --color-violet-700: oklch(0.491 0.27 292.581); - --color-violet-800: oklch(0.432 0.232 292.759); --color-violet-900: oklch(0.38 0.189 293.745); - --color-violet-950: oklch(0.283 0.141 291.089); - --color-purple-50: oklch(0.977 0.014 308.299); - --color-purple-100: oklch(0.946 0.033 307.174); --color-purple-200: oklch(0.902 0.063 306.703); --color-purple-300: oklch(0.827 0.119 306.383); --color-purple-400: oklch(0.714 0.203 305.504); --color-purple-500: oklch(0.627 0.265 303.9); --color-purple-600: oklch(0.558 0.288 302.321); --color-purple-700: oklch(0.496 0.265 301.924); - --color-purple-800: oklch(0.438 0.218 303.724); --color-purple-900: oklch(0.381 0.176 304.987); - --color-purple-950: oklch(0.291 0.149 302.717); - --color-fuchsia-50: oklch(0.977 0.017 320.058); - --color-fuchsia-100: oklch(0.952 0.037 318.852); --color-fuchsia-200: oklch(0.903 0.076 319.62); --color-fuchsia-300: oklch(0.833 0.145 321.434); --color-fuchsia-400: oklch(0.74 0.238 322.16); --color-fuchsia-500: oklch(0.667 0.295 322.15); --color-fuchsia-600: oklch(0.591 0.293 322.896); --color-fuchsia-700: oklch(0.518 0.253 323.949); - --color-fuchsia-800: oklch(0.452 0.211 324.591); --color-fuchsia-900: oklch(0.401 0.17 325.612); - --color-fuchsia-950: oklch(0.293 0.136 325.661); - --color-pink-50: oklch(0.971 0.014 343.198); - --color-pink-100: oklch(0.948 0.028 342.258); --color-pink-200: oklch(0.899 0.061 343.231); --color-pink-300: oklch(0.823 0.12 346.018); --color-pink-400: oklch(0.718 0.202 349.761); --color-pink-500: oklch(0.656 0.241 354.308); --color-pink-600: oklch(0.592 0.249 0.584); --color-pink-700: oklch(0.525 0.223 3.958); - --color-pink-800: oklch(0.459 0.187 3.815); --color-pink-900: oklch(0.408 0.153 2.432); - --color-pink-950: oklch(0.284 0.109 3.907); - --color-rose-50: oklch(0.969 0.015 12.422); - --color-rose-100: oklch(0.941 0.03 12.58); --color-rose-200: oklch(0.892 0.058 10.001); --color-rose-300: oklch(0.81 0.117 11.638); --color-rose-400: oklch(0.712 0.194 13.428); --color-rose-500: oklch(0.645 0.246 16.439); --color-rose-600: oklch(0.586 0.253 17.585); --color-rose-700: oklch(0.514 0.222 16.935); - --color-rose-800: oklch(0.455 0.188 13.697); --color-rose-900: oklch(0.41 0.159 10.272); - --color-rose-950: oklch(0.271 0.105 12.094); - --color-slate-50: oklch(0.984 0.003 247.858); - --color-slate-100: oklch(0.968 0.007 247.896); - --color-slate-200: oklch(0.929 0.013 255.508); - --color-slate-300: oklch(0.869 0.022 252.894); - --color-slate-400: oklch(0.704 0.04 256.788); - --color-slate-500: oklch(0.554 0.046 257.417); - --color-slate-600: oklch(0.446 0.043 257.281); - --color-slate-700: oklch(0.372 0.044 257.287); - --color-slate-800: oklch(0.279 0.041 260.031); - --color-slate-900: oklch(0.208 0.042 265.755); - --color-slate-950: oklch(0.129 0.042 264.695); - --color-gray-50: oklch(0.985 0.002 247.839); - --color-gray-100: oklch(0.967 0.003 264.542); - --color-gray-200: oklch(0.928 0.006 264.531); - --color-gray-300: oklch(0.872 0.01 258.338); - --color-gray-400: oklch(0.707 0.022 261.325); - --color-gray-500: oklch(0.551 0.027 264.364); - --color-gray-600: oklch(0.446 0.03 256.802); - --color-gray-700: oklch(0.373 0.034 259.733); - --color-gray-800: oklch(0.278 0.033 256.848); - --color-gray-900: oklch(0.21 0.034 264.665); - --color-gray-950: oklch(0.13 0.028 261.692); --color-zinc-50: oklch(0.985 0 0); --color-zinc-100: oklch(0.967 0.001 286.375); --color-zinc-200: oklch(0.92 0.004 286.32); @@ -252,38 +145,9 @@ --color-zinc-800: oklch(0.274 0.006 286.033); --color-zinc-900: oklch(0.21 0.006 285.885); --color-zinc-950: oklch(0.141 0.005 285.823); - --color-neutral-50: oklch(0.985 0 0); - --color-neutral-100: oklch(0.97 0 0); - --color-neutral-200: oklch(0.922 0 0); - --color-neutral-300: oklch(0.87 0 0); - --color-neutral-400: oklch(0.708 0 0); - --color-neutral-500: oklch(0.556 0 0); - --color-neutral-600: oklch(0.439 0 0); - --color-neutral-700: oklch(0.371 0 0); - --color-neutral-800: oklch(0.269 0 0); - --color-neutral-900: oklch(0.205 0 0); - --color-neutral-950: oklch(0.145 0 0); - --color-stone-50: oklch(0.985 0.001 106.423); - --color-stone-100: oklch(0.97 0.001 106.424); - --color-stone-200: oklch(0.923 0.003 48.717); - --color-stone-300: oklch(0.869 0.005 56.366); - --color-stone-400: oklch(0.709 0.01 56.259); - --color-stone-500: oklch(0.553 0.013 58.071); - --color-stone-600: oklch(0.444 0.011 73.639); - --color-stone-700: oklch(0.374 0.01 67.558); - --color-stone-800: oklch(0.268 0.007 34.298); - --color-stone-900: oklch(0.216 0.006 56.043); - --color-stone-950: oklch(0.147 0.004 49.25); --color-black: #000; --color-white: #fff; --spacing: 0.25rem; - --breakpoint-sm: 40rem; - --breakpoint-md: 48rem; - --breakpoint-lg: 64rem; - --breakpoint-xl: 80rem; - --breakpoint-2xl: 96rem; - --container-3xs: 16rem; - --container-2xs: 18rem; --container-xs: 20rem; --container-sm: 24rem; --container-md: 28rem; @@ -302,92 +166,23 @@ --text-base: 1rem; --text-base--line-height: calc(1.5 / 1); --text-lg: 1.125rem; - --text-lg--line-height: calc(1.75 / 1.125); --text-xl: 1.25rem; - --text-xl--line-height: calc(1.75 / 1.25); --text-2xl: 1.5rem; - --text-2xl--line-height: calc(2 / 1.5); - --text-3xl: 1.875rem; - --text-3xl--line-height: calc(2.25 / 1.875); - --text-4xl: 2.25rem; - --text-4xl--line-height: calc(2.5 / 2.25); - --text-5xl: 3rem; - --text-5xl--line-height: 1; - --text-6xl: 3.75rem; - --text-6xl--line-height: 1; - --text-7xl: 4.5rem; - --text-7xl--line-height: 1; - --text-8xl: 6rem; - --text-8xl--line-height: 1; - --text-9xl: 8rem; - --text-9xl--line-height: 1; - --font-weight-thin: 100; - --font-weight-extralight: 200; - --font-weight-light: 300; --font-weight-normal: 400; --font-weight-medium: 500; --font-weight-semibold: 600; --font-weight-bold: 700; - --font-weight-extrabold: 800; - --font-weight-black: 900; - --tracking-tighter: -0.05em; - --tracking-tight: -0.025em; - --tracking-normal: 0em; - --tracking-wide: 0.025em; - --tracking-wider: 0.05em; - --tracking-widest: 0.1em; - --leading-tight: 1.25; - --leading-snug: 1.375; - --leading-normal: 1.5; - --leading-relaxed: 1.625; - --leading-loose: 2; - --radius-xs: 0.125rem; --radius-sm: 0.25rem; --radius-md: 0.375rem; --radius-lg: 0.5rem; --radius-xl: 0.75rem; --radius-2xl: 1rem; --radius-3xl: 1.5rem; - --radius-4xl: 2rem; - --shadow-2xs: 0 1px rgb(0 0 0 / 0.05); - --shadow-xs: 0 1px 2px 0 rgb(0 0 0 / 0.05); - --shadow-sm: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1); - --shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1), - 0 2px 4px -2px rgb(0 0 0 / 0.1); - --shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 0.1), - 0 4px 6px -4px rgb(0 0 0 / 0.1); - --shadow-xl: 0 20px 25px -5px rgb(0 0 0 / 0.1), - 0 8px 10px -6px rgb(0 0 0 / 0.1); - --shadow-2xl: 0 25px 50px -12px rgb(0 0 0 / 0.25); - --inset-shadow-2xs: inset 0 1px rgb(0 0 0 / 0.05); - --inset-shadow-xs: inset 0 1px 1px rgb(0 0 0 / 0.05); - --inset-shadow-sm: inset 0 2px 4px rgb(0 0 0 / 0.05); - --drop-shadow-xs: 0 1px 1px rgb(0 0 0 / 0.05); - --drop-shadow-sm: 0 1px 2px rgb(0 0 0 / 0.15); - --drop-shadow-md: 0 3px 3px rgb(0 0 0 / 0.12); - --drop-shadow-lg: 0 4px 4px rgb(0 0 0 / 0.15); - --drop-shadow-xl: 0 9px 7px rgb(0 0 0 / 0.1); - --drop-shadow-2xl: 0 25px 25px rgb(0 0 0 / 0.15); --ease-in: cubic-bezier(0.4, 0, 1, 1); --ease-out: cubic-bezier(0, 0, 0.2, 1); --ease-in-out: cubic-bezier(0.4, 0, 0.2, 1); - --animate-spin: spin 1s linear infinite; - --animate-ping: ping 1s cubic-bezier(0, 0, 0.2, 1) infinite; - --animate-pulse: pulse 2s cubic-bezier(0.4, 0, 0.6, 1) infinite; - --animate-bounce: bounce 1s infinite; - --blur-xs: 4px; - --blur-sm: 8px; --blur-md: 12px; - --blur-lg: 16px; --blur-xl: 24px; - --blur-2xl: 40px; - --blur-3xl: 64px; - --perspective-dramatic: 100px; - --perspective-near: 300px; - --perspective-normal: 500px; - --perspective-midrange: 800px; - --perspective-distant: 1200px; - --aspect-video: 16 / 9; --default-transition-duration: 150ms; --default-transition-timing-function: cubic-bezier(0.4, 0, 0.2, 1); --default-font-family: var(--font-sans); ``` </details> If you have `ripgrep` installed, you can use this command to verify that these variables are indeed not used anywhere: <details> ```shell rg "\-\-font-serif\b" rg "\-\-color-red-50\b" rg "\-\-color-red-100\b" rg "\-\-color-red-800\b" rg "\-\-color-red-950\b" rg "\-\-color-orange-50\b" rg "\-\-color-orange-100\b" rg "\-\-color-orange-800\b" rg "\-\-color-orange-950\b" rg "\-\-color-amber-50\b" rg "\-\-color-amber-100\b" rg "\-\-color-amber-200\b" rg "\-\-color-amber-300\b" rg "\-\-color-amber-800\b" rg "\-\-color-amber-900\b" rg "\-\-color-yellow-50\b" rg "\-\-color-yellow-100\b" rg "\-\-color-yellow-200\b" rg "\-\-color-yellow-500\b" rg "\-\-color-yellow-800\b" rg "\-\-color-yellow-900\b" rg "\-\-color-lime-50\b" rg "\-\-color-lime-100\b" rg "\-\-color-lime-200\b" rg "\-\-color-lime-500\b" rg "\-\-color-lime-800\b" rg "\-\-color-lime-900\b" rg "\-\-color-green-50\b" rg "\-\-color-green-100\b" rg "\-\-color-green-200\b" rg "\-\-color-green-300\b" rg "\-\-color-green-800\b" rg "\-\-color-green-950\b" rg "\-\-color-emerald-50\b" rg "\-\-color-emerald-100\b" rg "\-\-color-emerald-200\b" rg "\-\-color-emerald-300\b" rg "\-\-color-emerald-800\b" rg "\-\-color-emerald-950\b" rg "\-\-color-teal-50\b" rg "\-\-color-teal-100\b" rg "\-\-color-teal-200\b" rg "\-\-color-teal-800\b" rg "\-\-color-teal-950\b" rg "\-\-color-cyan-50\b" rg "\-\-color-cyan-100\b" rg "\-\-color-cyan-200\b" rg "\-\-color-cyan-600\b" rg "\-\-color-cyan-800\b" rg "\-\-color-cyan-900\b" rg "\-\-color-sky-50\b" rg "\-\-color-sky-100\b" rg "\-\-color-sky-200\b" rg "\-\-color-sky-400\b" rg "\-\-color-sky-800\b" rg "\-\-color-sky-950\b" rg "\-\-color-blue-50\b" rg "\-\-color-blue-100\b" rg "\-\-color-blue-200\b" rg "\-\-color-blue-800\b" rg "\-\-color-blue-950\b" rg "\-\-color-indigo-50\b" rg "\-\-color-indigo-100\b" rg "\-\-color-indigo-800\b" rg "\-\-color-indigo-950\b" rg "\-\-color-violet-50\b" rg "\-\-color-violet-100\b" rg "\-\-color-violet-800\b" rg "\-\-color-violet-950\b" rg "\-\-color-purple-50\b" rg "\-\-color-purple-100\b" rg "\-\-color-purple-800\b" rg "\-\-color-purple-950\b" rg "\-\-color-fuchsia-50\b" rg "\-\-color-fuchsia-100\b" rg "\-\-color-fuchsia-800\b" rg "\-\-color-fuchsia-950\b" rg "\-\-color-pink-50\b" rg "\-\-color-pink-100\b" rg "\-\-color-pink-800\b" rg "\-\-color-pink-950\b" rg "\-\-color-rose-50\b" rg "\-\-color-rose-100\b" rg "\-\-color-rose-800\b" rg "\-\-color-rose-950\b" rg "\-\-color-slate-50\b" rg "\-\-color-slate-100\b" rg "\-\-color-slate-200\b" rg "\-\-color-slate-300\b" rg "\-\-color-slate-400\b" rg "\-\-color-slate-500\b" rg "\-\-color-slate-600\b" rg "\-\-color-slate-700\b" rg "\-\-color-slate-800\b" rg "\-\-color-slate-900\b" rg "\-\-color-slate-950\b" rg "\-\-color-gray-50\b" rg "\-\-color-gray-100\b" rg "\-\-color-gray-200\b" rg "\-\-color-gray-300\b" rg "\-\-color-gray-400\b" rg "\-\-color-gray-500\b" rg "\-\-color-gray-600\b" rg "\-\-color-gray-700\b" rg "\-\-color-gray-800\b" rg "\-\-color-gray-900\b" rg "\-\-color-gray-950\b" rg "\-\-color-neutral-50\b" rg "\-\-color-neutral-100\b" rg "\-\-color-neutral-200\b" rg "\-\-color-neutral-300\b" rg "\-\-color-neutral-400\b" rg "\-\-color-neutral-500\b" rg "\-\-color-neutral-600\b" rg "\-\-color-neutral-700\b" rg "\-\-color-neutral-800\b" rg "\-\-color-neutral-900\b" rg "\-\-color-neutral-950\b" rg "\-\-color-stone-50\b" rg "\-\-color-stone-100\b" rg "\-\-color-stone-200\b" rg "\-\-color-stone-300\b" rg "\-\-color-stone-400\b" rg "\-\-color-stone-500\b" rg "\-\-color-stone-600\b" rg "\-\-color-stone-700\b" rg "\-\-color-stone-800\b" rg "\-\-color-stone-900\b" rg "\-\-color-stone-950\b" rg "\-\-breakpoint-sm\b" rg "\-\-breakpoint-md\b" rg "\-\-breakpoint-lg\b" rg "\-\-breakpoint-xl\b" rg "\-\-breakpoint-2xl\b" rg "\-\-container-3xs\b" rg "\-\-container-2xs\b" rg "\-\-text-lg--line-height\b" rg "\-\-text-xl--line-height\b" rg "\-\-text-2xl--line-height\b" rg "\-\-text-3xl\b" rg "\-\-text-3xl--line-height\b" rg "\-\-text-4xl\b" rg "\-\-text-4xl--line-height\b" rg "\-\-text-5xl\b" rg "\-\-text-5xl--line-height\b" rg "\-\-text-6xl\b" rg "\-\-text-6xl--line-height\b" rg "\-\-text-7xl\b" rg "\-\-text-7xl--line-height\b" rg "\-\-text-8xl\b" rg "\-\-text-8xl--line-height\b" rg "\-\-text-9xl\b" rg "\-\-text-9xl--line-height\b" rg "\-\-font-weight-thin\b" rg "\-\-font-weight-extralight\b" rg "\-\-font-weight-light\b" rg "\-\-font-weight-extrabold\b" rg "\-\-font-weight-black\b" rg "\-\-tracking-tighter\b" rg "\-\-tracking-tight\b" rg "\-\-tracking-normal\b" rg "\-\-tracking-wide\b" rg "\-\-tracking-wider\b" rg "\-\-tracking-widest\b" rg "\-\-leading-tight\b" rg "\-\-leading-snug\b" rg "\-\-leading-normal\b" rg "\-\-leading-relaxed\b" rg "\-\-leading-loose\b" rg "\-\-radius-xs\b" rg "\-\-radius-4xl\b" rg "\-\-shadow-2xs\b" rg "\-\-shadow-xs\b" rg "\-\-shadow-sm\b" rg "\-\-shadow-md\b" rg "\-\-shadow-lg\b" rg "\-\-shadow-xl\b" rg "\-\-shadow-2xl\b" rg "\-\-inset-shadow-2xs\b" rg "\-\-inset-shadow-xs\b" rg "\-\-inset-shadow-sm\b" rg "\-\-drop-shadow-xs\b" rg "\-\-drop-shadow-sm\b" rg "\-\-drop-shadow-md\b" rg "\-\-drop-shadow-lg\b" rg "\-\-drop-shadow-xl\b" rg "\-\-drop-shadow-2xl\b" rg "\-\-animate-spin\b" rg "\-\-animate-ping\b" rg "\-\-animate-pulse\b" rg "\-\-animate-bounce\b" rg "\-\-blur-xs\b" rg "\-\-blur-sm\b" rg "\-\-blur-lg\b" rg "\-\-blur-2xl\b" rg "\-\-blur-3xl\b" rg "\-\-perspective-dramatic\b" rg "\-\-perspective-near\b" rg "\-\-perspective-normal\b" rg "\-\-perspective-midrange\b" rg "\-\-perspective-distant\b" rg "\-\-aspect-video\b" ``` </details> The only exception I noticed is that we have this: ```css src/typography.utilities.css 10: @media (width >= theme(--breakpoint-sm)) { ``` But this is not a variable, but it's replaced at build time with the actual value, so this is not a real issue. Testing on other templates: <img width="2968" alt="image" src="https://github.com/user-attachments/assets/cabf121d-4cb9-468f-9cf5-ceb02609dc7d" /> Fixes: https://github.com/tailwindlabs/tailwindcss/issues/16145 --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2025-02-07 18:12:47 +01:00
### Fixed
Prepare v4.0.5 (#16373) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2025-02-08 13:48:34 -05:00
- Remove rogue `console.log` from `@tailwindcss/vite` ([#16307](https://github.com/tailwindlabs/tailwindcss/pull/16307))
### Changed
- Don't include theme variables that aren't used in compiled CSS ([#16211](https://github.com/tailwindlabs/tailwindcss/pull/16211))
Prepare v4.0.4 (#16302) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-06 15:18:11 +01:00
## [4.0.4] - 2025-02-06
Update upgrade CLI to handle `containers` config correctly (#16169)
2025-02-03 22:16:14 +08:00
### Fixed
Don't crash when setting JS theme value to `null` (#16210) Closes #16035 In v3 it was possible to unset a specific color namespace by setting doing something like this: ```js export default { theme: { extend: { colors: { red: null, }, }, }, } ``` This pattern would crash in v4 right now due to the theme access function not being able to work on the red property being a `null`. This PR fixes this crash. However it leaves the behavior as-is for now so that the red namespace _defined via CSS will still be accessible_. This is technically different from v3 but fixing this would be more work as we only allow unsetting top-level namespaces in the interop layer (via the non-`extend`-theme-object). I would recommend migrating to the v4 API for doing these partial namespace resets if you want to get rid of the defaults in v4: ```css @theme { --color-red-*: initial; } ``` ## Test plan The crash was mainly captured via the test in `compat/config.test.ts` but I've added two more tests across the different levels of abstractions so that it's clear what `null` should be doing. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-02-04 15:43:48 +01:00
- Fix a crash when setting JS theme values to `null` ([#16210](https://github.com/tailwindlabs/tailwindcss/pull/16210))
Prepare v4.0.4 (#16302) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-06 15:18:11 +01:00
- Ensure escaped underscores in CSS variables in arbitrary values are properly unescaped ([#16206](https://github.com/tailwindlabs/tailwindcss/pull/16206))
Vite: Skip parsing stylesheets with the `?commonjs-proxy` flag (#16238) Fixes #16233 Vite has a number of special parameters that can be appended to `.css` files that make it actually load as a JavaScript module. One such parameter that we haven't handled before is the `?commonjs-proxy` flag. When importing e.g. `plotly.js/lib/core`, the dependency tree would eventually load a file called `*.css?commonjs-proxy`. We previously scanned this for candidates even though it was not, in-fact, a stylesheet. This PR fixes this by adding the `?commonjs-proxy` to the ignore list. I have also updated `SPECIAL_QUERY_RE` to more closely match the Vite implementation. It does seem like this was the only condition we were missing, though: https://github.com/vitejs/vite/blob/2b2299cbac37548a163f0523c0cb92eb70a9aacf/packages/vite/src/node/plugins/css.ts#L511-L517 ## Test plan Add and import `plotly.js/lib/core` into a Vite app. I also added an integration test to do that. Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-02-04 12:45:23 +01:00
- Ensure that the `containers` JS theme key is added to the `--container-*` namespace ([#16169](https://github.com/tailwindlabs/tailwindcss/pull/16169))
Prepare v4.0.4 (#16302) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-06 15:18:11 +01:00
- Ensure theme `@keyframes` are generated even if an `--animation-*` variable spans multiple lines ([#16237](https://github.com/tailwindlabs/tailwindcss/pull/16237))
Vite: Skip parsing stylesheets with the `?commonjs-proxy` flag (#16238) Fixes #16233 Vite has a number of special parameters that can be appended to `.css` files that make it actually load as a JavaScript module. One such parameter that we haven't handled before is the `?commonjs-proxy` flag. When importing e.g. `plotly.js/lib/core`, the dependency tree would eventually load a file called `*.css?commonjs-proxy`. We previously scanned this for candidates even though it was not, in-fact, a stylesheet. This PR fixes this by adding the `?commonjs-proxy` to the ignore list. I have also updated `SPECIAL_QUERY_RE` to more closely match the Vite implementation. It does seem like this was the only condition we were missing, though: https://github.com/vitejs/vite/blob/2b2299cbac37548a163f0523c0cb92eb70a9aacf/packages/vite/src/node/plugins/css.ts#L511-L517 ## Test plan Add and import `plotly.js/lib/core` into a Vite app. I also added an integration test to do that. Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-02-04 12:45:23 +01:00
- Vite: Skip parsing stylesheets with the `?commonjs-proxy` flag ([#16238](https://github.com/tailwindlabs/tailwindcss/pull/16238))
Fix `order-first` and `order-last` for Firefox (#16266) This PR fixes an issue where `order-last` doesn't work as expected in Firefox. The implementation of `order-last`, looks like this: ```css .order-last { order: calc(infinity); } ``` Which is valid CSS, and `calc(infinity)` is even valid in Firefox. You can use this in other properties such as `border-radius`: ```css .rounded-full { border-radius: calc(infinity * 1px); } ``` While this works, in properties like `order` it just doesn't work. Fixes: #16165
2025-02-05 12:04:43 +01:00
- Fix `order-first` and `order-last` for Firefox ([#16266](https://github.com/tailwindlabs/tailwindcss/pull/16266))
Standalone: Use bun baseline builds for Linux (#16244) Closes #15181 This PR changes the Standalone builds to use bun baseline instead. This compiles to a reduced instruction set and should work around the compatibility issues experienced across older server hardware. ## Test plan See https://github.com/tailwindlabs/tailwindcss/issues/15181#issuecomment-2634621266 Also tested it with the repor from @npezza93 and it now works locally as well with a Docker build.
2025-02-06 14:29:54 +01:00
- Fix support for older instruction sets on Linux x64 builds of the standalone CLI ([#16244](https://github.com/tailwindlabs/tailwindcss/pull/16244))
Take `NODE_PATH` into account when resolving modules (#16274) Fixes #15847 This PR changes the node specific resolver config to takes the eventual `NODE_PATH` env into account. ## Test plan See #15847 <img width="1273" alt="Screenshot 2025-02-05 at 12 58 20" src="https://github.com/user-attachments/assets/8e1b99d1-608d-437a-a7b2-212feb153da5" />
2025-02-05 16:21:31 +01:00
- Ensure `NODE_PATH` is respected when resolving JavaScript and CSS files ([#16274](https://github.com/tailwindlabs/tailwindcss/pull/16274))
Add Freebsd build target (#16277) Closes #15731 This PR adds a FreeBSD build target to our CI workflows. It was tested on CI: https://github.com/tailwindlabs/tailwindcss/actions/runs/13159185517/job/36723613079 However, due to the build not emitting final npm packages, we don't have a way to actually test the final package before we ship it to an insiders release. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-02-05 16:48:05 +01:00
- Ensure Node addons are packaged correctly with FreeBSD builds ([#16277](https://github.com/tailwindlabs/tailwindcss/pull/16277))
Properly skip over nodes when using `replaceNode` (#16300) Fixes #16298 This PR fixes an issue where using an AST walk in combination with `replaceNode` and various `SkipAction` would either cause children to be visited multiple times or not visited at all even though it should. This PR fixes the issue which also means we can get rid of a custom walk for `@variant` inside the `@media` that was used to apply `@variant` because we never recursively visited children inside the `@media` rule. Because we now can use the regular walk for `@variant`, we now properly convert `@variant` to `@custom-variant` inside `@reference`-ed stylesheet which also fixes #16298 ## Test plan Lots of tests added to ensure the combinations of `WalkAction` and `replaceWith()` works as expected.
2025-02-06 14:30:04 +01:00
- Fix an issue where `@variant` inside a referenced stylesheet could cause a stack overflow ([#16300](https://github.com/tailwindlabs/tailwindcss/pull/16300))
Update upgrade CLI to handle `containers` config correctly (#16169)
2025-02-03 22:16:14 +08:00
Prepare v4.0.3 (#16146)
2025-02-01 12:38:55 +01:00
## [4.0.3] - 2025-02-01
Fix `@import url()` being stripped (#16144)
2025-02-01 11:16:16 +00:00
### Fixed
Prepare v4.0.3 (#16146)
2025-02-01 12:38:55 +01:00
- Fix incorrect removal of `@import url();` ([#16144](https://github.com/tailwindlabs/tailwindcss/pull/16144))
Prepare for v4.0.2 release (#16131) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-31 19:30:36 +01:00
## [4.0.2] - 2025-01-31
Only generate positive `grid-cols-*` and `grid-rows-*` utilities (#16020) This PR fixes an issue where `grid-cols-0` and `grid-rows-0` generated invalid CSS. We now ensure that the value is any positive integer (except 0). Fixes: #16012
2025-01-29 20:56:23 +01:00
### Fixed
- Only generate positive `grid-cols-*` and `grid-rows-*` utilities ([#16020](https://github.com/tailwindlabs/tailwindcss/pull/16020))
Ensure escaped theme variables are handled correctly (#16064) This PR ensures that escaped theme variables are properly handled. We do this by moving the `escape`/`unescape` responsibility back into the main tailwindcss entrypoint that reads and writes from the CSS and making sure that _all internal state of the `Theme` class are unescaped classes. However, due to us accidentally shipping the part where a dot in the theme variable would translate to an underscore in CSS already, this logic is going to stay as-is for now. Here's an example test that visualizes the new changes: ```ts expect( await compileCss( css` @theme { --spacing-*: initial; --spacing-1\.5: 2.5rem; --spacing-foo\/bar: 3rem; } @tailwind utilities; `, ['m-1.5', 'm-foo/bar'], ), ).toMatchInlineSnapshot(` ":root, :host { --spacing-1\.5: 2.5rem; --spacing-foo\\/bar: 3rem; } .m-1\\.5 { margin: var(--spacing-1\.5); } .m-foo\\/bar { margin: var(--spacing-foo\\/bar); }" `) ``` ## Test plan - Added a unit test - Ensure this works end-to-end using the Vite playground: <img width="1016" alt="Screenshot 2025-01-30 at 14 51 05" src="https://github.com/user-attachments/assets/463c6fd5-793f-4ecc-86d2-5ad40bbb3e74" />
2025-01-31 15:20:18 +01:00
- Ensure escaped theme variables are handled correctly ([#16064](https://github.com/tailwindlabs/tailwindcss/pull/16064))
Ensure we process Tailwind CSS features when using `@reference` (#16057) This PR fixes an issue where if you only used `@reference` that we didn't process Tailwind CSS features. We have a 'quick bail check', in the PostCSS plugin to quickly bail if we _konw_ that we don't need to handle any Tailwind CSS features. This is useful in Next.js applications where every single CSS file will be passed to the PostCSS plugin. If you use custom font ins Next.js, each of those fonts will have a CSS file as well. Before we introduced `@reference`, we used `@import "tailwindcss" reference`, which passed the bail check because `@import` was being used. Now we have `@reference` which wasn't included in the list. This is now solved. Fixes: #16056 ### Test plan Added a failing test that is now failing after the fix.
2025-01-30 16:29:08 +01:00
- Ensure we process Tailwind CSS features when only using `@reference` or `@variant` ([#16057](https://github.com/tailwindlabs/tailwindcss/pull/16057))
Refactor gradient implementation to work around prettier/prettier#17058 (#16072) This PR fixes an issue where tools like Prettier remove important trailing commas in CSS variables, making gradients invalid. We encoded the `,` in the `--tw-gradient-position` to ensure that _if_ the `var(--tw-gradient-position)` is used, that the `,` was there. And if the variable was _not_ used that we didn't end up with a double `,,` rendering the gradient invalid. However, when running Prettier (there might be other tools that do this as well), the trailing comma in the `--tw-gradient-position` was removed which made the entire gradient invalid. E.g.: ```diff .bg-gradient-to-r { - --tw-gradient-position: to right in oklab,; + --tw-gradient-position: to right in oklab; background-image: linear-gradient(var(--tw-gradient-stops)); } ``` Notice how the `,` is removed. This PR fixes that, by moving the `,` to where the variable is being used. The only side effect is that we have to guarantee that the `--tw-gradient-position` is always present. In our testing (and using UI tests) this should be the case. Related Prettier issue: https://github.com/prettier/prettier/issues/17058 Fixes: #16037
2025-01-30 16:46:29 +01:00
- Refactor gradient implementation to work around [prettier/prettier#17058](https://github.com/prettier/prettier/issues/17058) ([#16072](https://github.com/tailwindlabs/tailwindcss/pull/16072))
Fix Vite issues with SolidStart (#16052) Fixes #16045 This PR fixes two Vite issues found with SolidStart: - SolidStart seems to emit an empty HTML chunk (where the content is literally just `/`) with _no pathname_. Since we use the path to generate an `id` for HTML chunks, this would currently cause a crash. This was reported in #16045 - While testing the fix for the above, we also found that hot reloading was not working in SolidStart since `4.0.0-alpha.22`. After doing some bisecting we found that this is happening as SolidStart has the same module ID in different servers and we were invalidating the root when we shouldn't. After trying to restructure this code so that it only cleans up the root when it is _no longer part of any server_, we noticed some other compatibility issues with Nuxt and SvelteKit. It seems that the safest bet is to no longer update a root at all during rebuilds in the SSR step. This makes `invalidateAllRoots` a function that only notifiers the servers about a change which is conceptually also less confusing. ## Test plan - Added an integration test for SolidStart dev mode - Manually tested the dev mode across all Vite based templates in https://github.com/philipp-spiess/tailwindcss-playgrounds: Astro, Nuxt, Remix, Solid, SvelteKit, and Vue. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-30 16:58:20 +01:00
- Vite: Ensure hot-reloading works with SolidStart setups ([#16052](https://github.com/tailwindlabs/tailwindcss/pull/16052))
- Vite: Fix a crash when starting the development server in SolidStart setups ([#16052](https://github.com/tailwindlabs/tailwindcss/pull/16052))
Prepare for v4.0.2 release (#16131) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-31 19:30:36 +01:00
- Vite: Don't rebase URLs that appear to be aliases ([#16078](https://github.com/tailwindlabs/tailwindcss/pull/16078))
Vite: Transform `<style>` blocks in html files (#16069) Fixes #16036 This adds a new rule to treat `<style>` blocks found within `.html` file as Tailwind CSS targets. ## Test plan - Tested using the Vite extension (dev) and a new integration test (prod) Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-31 15:26:45 +01:00
- Vite: Transform `<style>` blocks in HTML files ([#16069](https://github.com/tailwindlabs/tailwindcss/pull/16069))
Prepare for v4.0.2 release (#16131) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-31 19:30:36 +01:00
- Prevent camel-casing CSS custom properties added by JavaScript plugins ([#16103](https://github.com/tailwindlabs/tailwindcss/pull/16103))
Do not emit `@keyframes` in `@theme reference` (#16120) This PR fixes na issue where `@keyframes` were emitted if they wre in a `@theme reference` and anothe `@theme {}` (that is not a reference) was present. E.g.: ```css @reference "tailwindcss"; @theme { /* ... */ } ``` Produces: ```css :root, :host { } @keyframes spin { to { transform: rotate(360deg); } } @keyframes ping { 75%, 100% { transform: scale(2); opacity: 0; } } @keyframes pulse { 50% { opacity: 0.5; } } @keyframes bounce { 0%, 100% { transform: translateY(-25%); animation-timing-function: cubic-bezier(0.8, 0, 1, 1); } 50% { transform: none; animation-timing-function: cubic-bezier(0, 0, 0.2, 1); } } ``` With this PR, the produced CSS looks like this instead: ```css :root, :host { } ``` Note: the empty `:root, :host` will be solved in a subsequent PR. ### Test plan Added some unit tests, and a dedicated integration test.
2025-01-31 15:13:17 +01:00
- Do not emit `@keyframes` in `@theme reference` ([#16120](https://github.com/tailwindlabs/tailwindcss/pull/16120))
Discard invalid declarations when parsing CSS (#16093) I discovered this when triaging an error someone had on Tailwind Play. 1. When we see a `;` we often assume a valid declaration precedes it but that may not be the case 2. When we see the name of a custom property we assume everything that follows will be a valid declaration but that is not necessarily the case 3. A bare identifier inside of a rule is treated as a declaration which is not the case This PR fixes all three of these by ignoring these invalid cases. Though some should probably be turned into errors. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-31 09:53:02 -05:00
- Discard invalid declarations when parsing CSS ([#16093](https://github.com/tailwindlabs/tailwindcss/pull/16093))
Do not emit empty rules/at-rules (#16121) This PR is an optimization where it will not emit empty rules and at-rules. I noticed this while working on https://github.com/tailwindlabs/tailwindcss/pull/16120 where we emitted: ```css :root, :host { } ``` There are some exceptions for "empty" at-rules, such as: ```css @charset "UTF-8"; @layer foo, bar, baz; @custom-media --modern (color), (hover); @namespace "http://www.w3.org/1999/xhtml"; ``` These don't have a body, but they still have a purpose and therefore they will be emitted. However, if you look at this: ```css /* Empty rule */ .foo { } /* Empty rule, with nesting */ .foo { .bar { } .baz { } } /* Empty rule, with special case '&' rules */ .foo { & { &:hover { } &:focus { } } } /* Empty at-rule */ @media (min-width: 768px) { } /* Empty at-rule with nesting*/ @media (min-width: 768px) { .foo { } @media (min-width: 1024px) { .bar { } } } ``` None of these will be emitted. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-01-31 17:56:52 +01:00
- Do not emit empty CSS rules and at-rules ([#16121](https://github.com/tailwindlabs/tailwindcss/pull/16121))
Allow `@variant` to be used at the top-level (#16129) This makes it so `@variant` is replaced at the top level and not just within rules. This also fixes a bug where `@variant` wasn't handled when inside an `@media` at-rule.
2025-01-31 13:18:11 -05:00
- Handle `@variant` when at the top-level of a stylesheet ([#16129](https://github.com/tailwindlabs/tailwindcss/pull/16129))
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
## [4.0.1] - 2025-01-29
Include `:open` in the open variant (#15349) Update the `open` variant to addtionally match the new `:open` pseudo class. See spec at https://drafts.csswg.org/selectors-4/#open-state See Chromium intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/Pdo4oOXYKcA `:open` matches open `<details>` and `<dialog>` elements (already covered by [open]), but also matches select elements with their picker open and inputs with their picker open. Thanks to `:is()` taking a forgiving selector list, this is safe to add even with limited browser support. Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-27 12:43:12 +00:00
### Added
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
- Include `:open` pseudo-class in existing `open` variant ([#15349](https://github.com/tailwindlabs/tailwindcss/pull/15349))
Include `:open` in the open variant (#15349) Update the `open` variant to addtionally match the new `:open` pseudo class. See spec at https://drafts.csswg.org/selectors-4/#open-state See Chromium intent to ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/Pdo4oOXYKcA `:open` matches open `<details>` and `<dialog>` elements (already covered by [open]), but also matches select elements with their picker open and inputs with their picker open. Thanks to `:is()` taking a forgiving selector list, this is safe to add even with limited browser support. Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-27 12:43:12 +00:00
Remove `min-w/h-none` (#15845) `none` is not a valid value for `min-width` or `min-height` according to [the CSS spec](https://www.w3.org/TR/css-sizing-3/#min-size-properties): > | | | > | --- | --- | > | [Value](https://www.w3.org/TR/css-values/#value-defs): | auto \| [&lt;length-percentage>](https://www.w3.org/TR/css-values-4/#typedef-length-percentage) \| min-content \| max-content \| fit-content([&lt;length-percentage>](https://www.w3.org/TR/css-values-4/#typedef-length-percentage)) | I believe we should be able to remove the `min-w-none` and `min-h-none` class candidates since they wouldn't have done anything anyway and thus should not affect backwards compatibility. Indeed, these did not exist in v3 either: https://github.com/tailwindlabs/tailwindcss/blob/4f9f603e12b51cc53b8a09c7739b8f88c8eb87eb/stubs/config.full.js#L674-L684 https://github.com/tailwindlabs/tailwindcss/blob/4f9f603e12b51cc53b8a09c7739b8f88c8eb87eb/stubs/config.full.js#L685-L691 --- Credit to `@i` on Discord for spotting this[^1], fixes #15846 [^1]: https://discord.com/channels/486935104384532500/486935104384532502/1332680061144403968 --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-25 17:04:55 +00:00
### Fixed
- Remove invalid `min-w/h-none` utilities ([#15845](https://github.com/tailwindlabs/tailwindcss/pull/15845))
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
- Discard CSS variable shorthand utilities that don't use valid CSS variables ([#15738](https://github.com/tailwindlabs/tailwindcss/pull/15738))
- Ensure font-size utilities with `none` modifier have a line-height set e.g. `text-sm/none` ([#15921](https://github.com/tailwindlabs/tailwindcss/pull/15921))
Ensure font-size utilities with `none` modifier works e.g.: `text-sm/none` (#15921) This PR fixes an issue where classes such as `text-sm/none` don't work as expected. The reason for this is that `leading-none` is the only hardcoded leading utility and is not coming from the `@theme`. This means that `text-sm/none` tries to do a lookup for `none` but it won't resolve. This PR fixes that by allowing `none` as a modifier. While working on this, I noticed that `text-sm/none` _did_ generate CSS: ```css .text-sm\/none { font-size: var(--text-sm); } ``` Notice that the `line-height` is missing. This means that any modifier that can't be resolved doesn't get the `line-height` set, but it _will_ generate CSS. In this case, no CSS should have been generated. Otherwise, all of these generate CSS which will only bloat your CSS and won't work as expected. E.g.: `text-sm/foo`, `text-sm/bar`, and `text-sm/baz`: ```css .text-sm\/bar { font-size: var(--text-sm); } .text-sm\/baz { font-size: var(--text-sm); } .text-sm\/foo { font-size: var(--text-sm); } ``` Fixes: #15911
2025-01-27 14:10:09 +01:00
- Ensure font-size utilities with unknown modifier don't generate CSS ([#15921](https://github.com/tailwindlabs/tailwindcss/pull/15921))
Fix IntelliSense class suggestions (#15857) This PR fixes a few problems with IntelliSense: - Default installs suggest font weight utilities twice - When setting `--font-weight-*: initial;` the default weights are still suggested - Setting `--spacing-*: initial;` still shows suggestions for utilities using the spacing scale assuming it's multiplier-based. Removing the `--spacing: …` key should make them entirely theme driven instead. - The default container query variants like `@sm`, `@md`, etc… aren't suggested. Only the `@min-sm` and `@max-sm` style ones are. Fixes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1133 Fixes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1136 Fixes #15811 --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-28 10:35:11 -05:00
- Don’t suggest font weight utilities more than once ([#15857](https://github.com/tailwindlabs/tailwindcss/pull/15857))
- Suggest container query variants ([#15857](https://github.com/tailwindlabs/tailwindcss/pull/15857))
- Disable bare value suggestions when not using the `--spacing` variable ([#15857](https://github.com/tailwindlabs/tailwindcss/pull/15857))
- Ensure suggested classes are properly sorted ([#15857](https://github.com/tailwindlabs/tailwindcss/pull/15857))
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
- Don’t look at .gitignore files outside initialized repos ([#15941](https://github.com/tailwindlabs/tailwindcss/pull/15941))
Fix Oxide scanner bugs (#15974) Fixes #15632 Fixes #15740 This PR fixes a number of Oxide scanner bugs reported over various channels, specifically: - When using the Svelte class shorthand split over various lines, we weren't extracting class names properly: ```svelte <div class:underline={isUnderline}> </div> ``` - We now extract classes when using the class shortcut in Angular: ```html <div [class.underline]=\"bool\"></div> ``` - We now validate parentheses within arbitrary candidates so that we don't consume invalid arbitrary candidates anymore which allows us to parse the following case properly: ```js const classes = [wrapper("bg-red-500")] ``` ## Test plan Added unit tests --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-01-28 17:19:31 +01:00
- Find utilities when using the Svelte class shorthand syntax across multiple lines ([#15974](https://github.com/tailwindlabs/tailwindcss/pull/15974))
- Find utilities when using the Angular class shorthand syntax ([#15974](https://github.com/tailwindlabs/tailwindcss/pull/15974))
- Find utilities when using functions inside arrays ([#15974](https://github.com/tailwindlabs/tailwindcss/pull/15974))
Add missing changelog entry for #15978
2025-01-28 17:37:53 +01:00
- Ensure that `@tailwindcss/browser` does not pollute the global namespace ([#15978](https://github.com/tailwindlabs/tailwindcss/pull/15978))
Do not scan `tailwind-merge` sources for candidates (#16005) Resolves #15722 This PR adds a list of ignored dependencies (in the current form only `tailwind-merge`) to the Vite extension which, when included in the dependency tree, are no longer scanned by the Tailwind CSS compiler for candidates. This is to work around an issue where some dependencies contain vast lists of valid Tailwind CSS class names which would otherwise always be inlined in the build. ## Test plan This was tested in our Vite playground on both dev and prod builds across macOS and Windows: ### Windows prod build before ![telegram-cloud-photo-size-4-5823632138052944949-y](https://github.com/user-attachments/assets/a2bca1c7-cef3-4f04-a588-cbf1afdbdd37) ### Windows prod build after This includes a debug `console.log(…)` to make sure it matches the right module. ![telegram-cloud-photo-size-4-5823632138052944951-y](https://github.com/user-attachments/assets/109b82c5-1946-4d44-b812-d68474686eb7) ### Windows dev build after This includes a debug `console.log(…)` to make sure it matches the right module. ![telegram-cloud-photo-size-4-5823632138052944948-y](https://github.com/user-attachments/assets/41cbe7f1-f997-4c6c-b5fe-01d574f7a999)
2025-01-29 17:32:06 +01:00
- Ensure that `tailwind-merge` is not scanned when using the Vite plugin ([#16005](https://github.com/tailwindlabs/tailwindcss/pull/16005))
Add `:host` rule to `@theme` layer (#15975) Resolves #15799 Resolves #14478 Part-of #15005 Adds a `:host` selector for the `@theme` layer. This is necessary for the `@theme` layer to work correctly in shadow DOM. Also updates the snapshots for the tests that were affected by this change (in a separate commit). ## Test plan Tested via the Vite playground: <img width="1121" alt="Screenshot 2025-01-29 at 15 06 49" src="https://github.com/user-attachments/assets/a7908135-5ff8-472f-a053-d2c6d5c81e1b" /> Additionally made sure that `@property` defaults also work across Firefox, Chrome, and Safari (the `@property` definition from the root is pulled in) and added a UI spec. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-01-29 17:20:29 +01:00
- Ensure CSS theme variables are available within shadow roots ([#15975](https://github.com/tailwindlabs/tailwindcss/pull/15975))
update changelog
2025-01-29 11:47:47 +01:00
- Fix crash when project lives in the `/` directory ([#15988](https://github.com/tailwindlabs/tailwindcss/pull/15988))
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
- Ensure custom variants have a non-empty selector list ([#16009](https://github.com/tailwindlabs/tailwindcss/pull/16009))
Fix handling of absolute config files in upgrade tool (#15927) Closes #15220 This PR fixes an issue where the upgrade tool would not be able to load some JavaScript config files across different drive letters on Windows. The issue in detail is that `path.relative(…)` tries to build a relative path but if the file is inside the same folder, it won't start the relative path with a `./` so we manually appended it in case that it isn't there. The issue on Windows specifically is that `file.relative(…)` can also return a legit absolute path, e.g. when the file is on a different drive. In this case we obviously don't want to prefix a path with `./`. ## Test plan To reproduce this issue, I checked out a Tailwind v3 project _on a different drive letter than my Windows installation_. In that case, I was adding a repo inside `D:` while `npm` was installed in `C:`. I then run `npx @tailwindcss/upgrade` to reproduce the issue. The fix was validated with a local `bun` run of the upgrade tool: ![telegram-cloud-photo-size-4-5818901845756725194-y](https://github.com/user-attachments/assets/d32b21e3-a08d-4608-b65a-93dddc04f890)
2025-01-28 12:42:30 +01:00
- _Upgrade_: Ensure JavaScript config files on different drives are correctly migrated ([#15927](https://github.com/tailwindlabs/tailwindcss/pull/15927))
Correctly migrate `leading-*` classes (#16004) This PR fixes the upgrade tool by properly migrating the `leading-[<number>]` classes. The issue is that `leading-[<number>]` maps to the number directly, but if you use a bare value, then it's a multiplier for based on the `--spacing` value. E.g.: *leading-[2]*: ```css .leading-\[2\] { --tw-leading: 2; line-height: 2; } @property --tw-leading { syntax: "*"; inherits: false; } ``` *leading-2*: ```css .leading-2 { --tw-leading: calc(var(--spacing) * 2); line-height: calc(var(--spacing) * 2); } @property --tw-leading { syntax: "*"; inherits: false; } ``` This PR will now prevent migrating arbitrary values to bare values for `leading-*` utilities. That said, this does introduce a small improvement where `leading-[1]` is migrated to `leading-none`. Fixes: https://github.com/tailwindlabs/tailwindcss/issues/15924
2025-01-29 15:22:13 +01:00
- _Upgrade_: Migrate `leading-[1]` to `leading-none` ([#16004](https://github.com/tailwindlabs/tailwindcss/pull/16004))
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
- _Upgrade_: Do not migrate arbitrary leading utilities to bare values ([#16004](https://github.com/tailwindlabs/tailwindcss/pull/16004))
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
Prepare v4.0.0 release (#15693)
2025-01-21 15:58:59 -05:00
## [4.0.0] - 2025-01-21
Remove `min-w/h-none` (#15845) `none` is not a valid value for `min-width` or `min-height` according to [the CSS spec](https://www.w3.org/TR/css-sizing-3/#min-size-properties): > | | | > | --- | --- | > | [Value](https://www.w3.org/TR/css-values/#value-defs): | auto \| [&lt;length-percentage>](https://www.w3.org/TR/css-values-4/#typedef-length-percentage) \| min-content \| max-content \| fit-content([&lt;length-percentage>](https://www.w3.org/TR/css-values-4/#typedef-length-percentage)) | I believe we should be able to remove the `min-w-none` and `min-h-none` class candidates since they wouldn't have done anything anyway and thus should not affect backwards compatibility. Indeed, these did not exist in v3 either: https://github.com/tailwindlabs/tailwindcss/blob/4f9f603e12b51cc53b8a09c7739b8f88c8eb87eb/stubs/config.full.js#L674-L684 https://github.com/tailwindlabs/tailwindcss/blob/4f9f603e12b51cc53b8a09c7739b8f88c8eb87eb/stubs/config.full.js#L685-L691 --- Credit to `@i` on Discord for spotting this[^1], fixes #15846 [^1]: https://discord.com/channels/486935104384532500/486935104384532502/1332680061144403968 --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-25 17:04:55 +00:00
Merge changelogs (#15698) This PR makes sure all v3 and earlier versions are visible in the changelog as well as the v4 changelog entries.
2025-01-27 12:54:26 +01:00
### Added
- [New high-performance engine](https://tailwindcss.com/blog/tailwindcss-v4#new-high-performance-engine) — where full builds are up to 5x faster, and incremental builds are over 100x faster — and measured in microseconds.
- [Designed for the modern web](https://tailwindcss.com/blog/tailwindcss-v4#designed-for-the-modern-web) — built on cutting-edge CSS features like cascade layers, registered custom properties with `@property`, and `color-mix()`.
- [Simplified installation](https://tailwindcss.com/blog/tailwindcss-v4#simplified-installation) — fewer dependencies, zero configuration, and just a single line of code in your CSS file.
- [First-party Vite plugin](https://tailwindcss.com/blog/tailwindcss-v4#first-party-vite-plugin) — tight integration for maximum performance and minimum configuration.
- [Automatic content detection](https://tailwindcss.com/blog/tailwindcss-v4#automatic-content-detection) — all of your template files are discovered automatically, with no configuration required.
- [Built-in import support](https://tailwindcss.com/blog/tailwindcss-v4#built-in-import-support) — no additional tooling necessary to bundle multiple CSS files.
- [CSS-first configuration](https://tailwindcss.com/blog/tailwindcss-v4#css-first-configuration) — a reimagined developer experience where you customize and extend the framework directly in CSS instead of a JavaScript configuration file.
- [CSS theme variables](https://tailwindcss.com/blog/tailwindcss-v4#css-theme-variables) — all of your design tokens exposed as native CSS variables so you can access them anywhere.
- [Dynamic utility values and variants](https://tailwindcss.com/blog/tailwindcss-v4#dynamic-utility-values-and-variants) — stop guessing what values exist in your spacing scale, or extending your configuration for things like basic data attributes.
- [Modernized P3 color palette](https://tailwindcss.com/blog/tailwindcss-v4#modernized-p3-color-palette) — a redesigned, more vivid color palette that takes full advantage of modern display technology.
- [Container queries](https://tailwindcss.com/blog/tailwindcss-v4#container-queries) — first-class APIs for styling elements based on their container size, no plugins required.
- [New 3D transform utilities](https://tailwindcss.com/blog/tailwindcss-v4#new-3d-transform-utilities) — transform elements in 3D space directly in your HTML.
- [Expanded gradient APIs](https://tailwindcss.com/blog/tailwindcss-v4#expanded-gradient-apis) — radial and conic gradients, interpolation modes, and more.
- [@starting-style support](https://tailwindcss.com/blog/tailwindcss-v4#starting-style-support) — a new variant you can use to create enter and exit transitions, without the need for JavaScript.
- [not-\* variant](https://tailwindcss.com/blog/tailwindcss-v4#not-variant) — style an element only when it doesn't match another variant, custom selector, or media or feature query.
- [Even more new utilities and variants](https://tailwindcss.com/blog/tailwindcss-v4#even-more-new-utilities-and-variants) — including support for `color-scheme`, `field-sizing`, complex shadows, `inert`, and more.
Start using Tailwind CSS v4.0 today by [installing it in a new project](https://tailwindcss.com/docs/installation/), or playing with it directly in the browser on [Tailwind Play](https://play.tailwindcss.com/).
For existing projects, we've published a comprehensive [upgrade guide](https://tailwindcss.com/docs/upgrade-guide) and built an [automated upgrade tool](https://tailwindcss.com/docs/upgrade-guide#using-the-upgrade-tool) to get you on the latest version as quickly and painlessly as possible.
For a deep-dive into everything that's new, [check out the announcement post](https://tailwindcss.com/blog/tailwindcss-v4).
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
## [4.0.0-beta.10] - 2025-01-21
update changelog
2025-01-21 10:40:22 -05:00
### Added
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
- Add support for using `@variant` to use variants in your CSS ([#15663](https://github.com/tailwindlabs/tailwindcss/pull/15663))
Transition `outline-color` (#15690) This PR adds `outline-color` to the transition-property again, and updates the implementation for `outline-hidden`. The `outline-hidden` will behave exactly the same as `outline-none` _except_ in forced colors mode. In forced colors mode, `outline-hidden` will force a 2px solid border. Closes: #15591
2025-01-21 11:02:57 -05:00
- Include `outline-color` when transitioning colors ([#15690](https://github.com/tailwindlabs/tailwindcss/pull/15690))
update changelog
2025-01-21 10:40:22 -05:00
Add missing `main` field for `@tailwindcss/browser` (#15594) This PR adds a `main` and `browser` field for the `@tailwindcss/browser` package. In the package, we do have the `exports` field setup, which is an alternative to the `main` field according to the docs: > The "exports" provides a modern alternative to "main" … > > — https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#exports However, if you look at the unpkg link: https://unpkg.com/@tailwindcss/browser, it tries to load the `index.js` file. This is probably a bug in the unpkg resolver. That said, if you look at other CDNs such as esm.sh, it does resolve correctly: https://esm.sh/@tailwindcss/browser According to the npm docs: > If `main` is not set, it defaults to `index.js` in the package's root folder. > > — https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#main This explains why unpkg is trying to load the `index.js` file. Additionally, the npm docs also mention the `browser` field: > If your module is meant to be used client-side the browser field should be used instead of the main field. This is helpful to hint users that it might rely on primitives that aren't available in Node.js modules. (e.g. window) > > — https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#browser So this PR also adds that field just to be sure.
2025-01-10 13:39:00 +01:00
### Fixed
- Add missing `main` and `browser` fields for `@tailwindcss/browser` ([#15594](https://github.com/tailwindlabs/tailwindcss/pull/15594))
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
- Support escaping `*` in theme namespace syntax (e.g.: `--color-\*: initial;`) ([#15603](https://github.com/tailwindlabs/tailwindcss/pull/15603))
- Respect `@theme` options when resolving values in custom functional utilities ([#15623](https://github.com/tailwindlabs/tailwindcss/pull/15623))
- Discard invalid variants (e.g. `data-checked-[selected=1]:*`) ([#15629](https://github.com/tailwindlabs/tailwindcss/pull/15629))
Ensure `-outline-offset-*` utilities are suggested in IntelliSense (#15646) Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-16 12:09:56 -05:00
- Ensure `-outline-offset-*` utilities are suggested in IntelliSense ([#15646](https://github.com/tailwindlabs/tailwindcss/pull/15646))
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
- Write to `stdout` when `--output` is set to `-` or omitted with `@tailwindcss/cli` ([#15656](https://github.com/tailwindlabs/tailwindcss/pull/15656))
Prevent `not-*` from being used with variants with multiple sibling rules (#15689) Variants like this can't be easily negated by our current system: ```css @custom-variant dark { &.is-dark { @slot; } @media (prefers-color-scheme: dark) { @slot; } } ``` Right now it produces the following CSS which is logically incorrect: ```css .utility-name { &:not(.is-dark) { /* ... */ } @media not (prefers-color-scheme: dark) { /* ... */ } } ``` The correct CSS is this which requires moving things around: ```css .utility-name { @media not (prefers-color-scheme: dark) { &:not(.is-dark) { /* ... */ } } } ``` We're opting to disable this instead of generating incorrect CSS for now. I'd like to bring this back in the future for simpler cases in the future.
2025-01-21 10:38:32 -05:00
- Prevent `not-*` from being used with variants that have multiple sibling rules ([#15689](https://github.com/tailwindlabs/tailwindcss/pull/15689))
Ensure `-outline-offset-*` utilities are suggested in IntelliSense (#15646) Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-16 12:09:56 -05:00
- _Upgrade (experimental)_: Pretty print `--spacing(…)` to prevent ambiguity ([#15596](https://github.com/tailwindlabs/tailwindcss/pull/15596))
Prepare v4.0.0-beta.9 release (#15583) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-09 18:04:34 +01:00
Use more modern `--alpha(color / 50%)` syntax (#15665) This PR changes the syntax for the `--alpha(…)` function to look like more modern CSS. The arguments to apply an alpha to a color is using the `/` syntax instead of the comma syntax. ```diff - --alpha(color, 50%) + --alpha(color / 50%) ``` This syntax is now similar to modern `rgb(0 0 0 / 50%)` syntax in CSS.
2025-01-18 00:48:18 +01:00
### Changed
- Use more modern `--alpha(color / 50%)` syntax instead of `--alpha(color, 50%)` ([#15665](https://github.com/tailwindlabs/tailwindcss/pull/15665))
update changelog
2025-01-21 10:40:22 -05:00
- Rename `@variant` to `@custom-variant` ([#15663](https://github.com/tailwindlabs/tailwindcss/pull/15663))
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
- Change `outline-hidden` to set `outline-style: none` except in forced colors mode ([#15690](https://github.com/tailwindlabs/tailwindcss/pull/15690))
Use more modern `--alpha(color / 50%)` syntax (#15665) This PR changes the syntax for the `--alpha(…)` function to look like more modern CSS. The arguments to apply an alpha to a color is using the `/` syntax instead of the comma syntax. ```diff - --alpha(color, 50%) + --alpha(color / 50%) ``` This syntax is now similar to modern `rgb(0 0 0 / 50%)` syntax in CSS.
2025-01-18 00:48:18 +01:00
Prepare v4.0.0-beta.9 release (#15583) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-09 18:04:34 +01:00
## [4.0.0-beta.9] - 2025-01-09
Add `@tailwindcss/browser` package (#15558) Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-07 09:57:34 -05:00
### Added
- Add `@tailwindcss/browser` package to run Tailwind CSS in the browser ([#15558](https://github.com/tailwindlabs/tailwindcss/pull/15558))
Add `@reference "…"` (#15565) This PR adds a new `@reference "…"` API as an replacement for the previously added [`@import "…" reference`](https://github.com/tailwindlabs/tailwindcss/pull/15228). The motivation for a distinct at rule is that `@import` is already handled outside of Tailwind in some scenarios (e.g. when using in combination with postcss-import, other pre-processors, or frameworks like Svelte). While our implementation of hijacking the `media` attribute _works in this cases_, it can cause annoying linter issues because tooling build around `@import` does not know about our behavior. To fix this, we've decided to move this mode into a separate at rule that is passed-through in the other tooling. Here's an example of how this would look like in Svelte: ```svelte <h1>Hello world!</h1> <style> @reference './theme.css'; h1 { color: var(--theme-color); } </style> ``` With this change, the Svelte linter would not be detecting unused CSS from the `theme.css` file as it would if we'd rely on `@import`.
2025-01-07 16:41:43 +01:00
- Add `@reference "…"` API as a replacement for the previous `@import "…" reference` option ([#15565](https://github.com/tailwindlabs/tailwindcss/pull/15565))
Prepare v4.0.0-beta.9 release (#15583) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-09 18:04:34 +01:00
- Add support for defining functional utilities in CSS ([#15455](https://github.com/tailwindlabs/tailwindcss/pull/15455))
Implement `--spacing(…)`, `--alpha(…)` and `--theme(…)` CSS functions (#15572) This PR implements new CSS functions that you can use in your CSS (or even in arbitrary value position). For starters, we renamed the `theme(…)` function to `--theme(…)`. The legacy `theme(…)` function is still available for backwards compatibility reasons, but this allows us to be future proof since `--foo(…)` is the syntax the CSS spec recommends. See: https://drafts.csswg.org/css-mixins/ In addition, this PR implements a new `--spacing(…)` function, this allows you to write: ```css @import "tailwindcss"; @theme { --spacing: 0.25rem; } .foo { margin: --spacing(4): } ``` This is syntax sugar over: ```css @import "tailwindcss"; @theme { --spacing: 0.25rem; } .foo { margin: calc(var(--spacing) * 4); } ``` If your `@theme` uses the `inline` keyword, we will also make sure to inline the value: ```css @import "tailwindcss"; @theme inline { --spacing: 0.25rem; } .foo { margin: --spacing(4): } ``` Boils down to: ```css @import "tailwindcss"; @theme { --spacing: 0.25rem; } .foo { margin: calc(0.25rem * 4); /* And will be optimised to just 1rem */ } ``` --- Another new function function we added is the `--alpha(…)` function that requires a value, and a number / percentage value. This allows you to apply an alpha value to any color, but with a much shorter syntax: ```css @import "tailwindcss"; .foo { color: --alpha(var(--color-red-500), 0.5); } ``` This is syntax sugar over: ```css @import "tailwindcss"; .foo { color: color-mix(in oklab, var(--color-red-500) 50%, transparent); } ``` --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
2025-01-08 21:16:08 +01:00
- Add new `--spacing(…)`, `--alpha(…)`, and `--theme(…)` CSS functions ([#15572](https://github.com/tailwindlabs/tailwindcss/pull/15572))
Prepare v4.0.0-beta.9 release (#15583) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-09 18:04:34 +01:00
- Add musl-based Linux builds of the standalone CLI ([#15567](https://github.com/tailwindlabs/tailwindcss/pull/15567))
- Improve performance of internal AST manipulations ([#15529](https://github.com/tailwindlabs/tailwindcss/pull/15529))
Add `@tailwindcss/browser` package (#15558) Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2025-01-07 09:57:34 -05:00
Fixed definition of `place-content-*` (#15440) The utilities `place-content-between`, `place-content-around`, and `place-content-evenly` are defined incorrectly. This PR fixes them. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-18 20:17:29 -05:00
### Fixed
- Use the correct property value for `place-content-between`, `place-content-around`, and `place-content-evenly` utilities ([#15440](https://github.com/tailwindlabs/tailwindcss/pull/15440))
Don’t detect arbitrary properties when preceded by an escape (#15456) This is a targeted bug fix uncovered by the v4 docs. Given this code: ```html <!-- [!code word:group-has-\\[a\\]\\:block] --> ``` We'd pick up `[a\\]\\:block]` as a candidate which would then make it far enough to get output to CSS and throw an error. This makes sure we don't try to start an arbitrary property if the preceding character is a `\` cc @RobinMalfait this look okay? --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-12-20 09:22:49 -05:00
- Don’t detect arbitrary properties when preceded by an escape ([#15456](https://github.com/tailwindlabs/tailwindcss/pull/15456))
Rename `bg-round` -> `bg-repeat-round`, `bg-space` -> `bg-repeat-space` (#15462) When we were porting all of the utilities from v3 to v4 we accidentally used the wrong names for these two classes, so this PR fixes that and corrects them back to the names used in v3. | Before | After | | --- | --- | | `bg-round` | `bg-repeat-round` | | `bg-space` | `bg-repeat-space` | --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-20 15:54:40 +01:00
- Fix incorrectly named `bg-round` and `bg-space` utilities to `bg-repeat-round` to `bg-repeat-space` ([#15462](https://github.com/tailwindlabs/tailwindcss/pull/15462))
Fix `inset-shadow-*` suggestions in IntelliSense (#15471)
2024-12-22 22:13:48 +08:00
- Fix `inset-shadow-*` suggestions in IntelliSense ([#15471](https://github.com/tailwindlabs/tailwindcss/pull/15471))
Only compile arbitrary values ending in `]` (#15503) This PR ensures that if you are using an arbitrary value such as `bg-[red` that it only compiles if it's a properly closed arbitrary value. Currently what happens is that it assumes the `]` is there, and cuts it off. This then results in the `bg-[red` to be compiled as: ```css .bg-\[red { background-color: re; } ``` Note how the `d` in `red` is cut off. That's the assumption that the `]` is there. This PR fixes that by ensuring that the arbitrary value is properly closed. Fixes: #15484
2025-01-06 12:00:36 +01:00
- Only compile arbitrary values ending in `]` ([#15503](https://github.com/tailwindlabs/tailwindcss/pull/15503))
Ensure `@utility` is processed before using them (#15542) This PR fixes an issue where using an `@utility` before it is defined, and _if_ that `@utility` contains `@apply`, that it won't result in the expected output. But results in an `@apply` rule that is not substituted. Additionally, if you have multiple levels of `@apply`, we have to make sure that everything is applied (no pun intended) in the right order. Right now, the following steps are taken: 1. Collect all the `@utility` at-rules (and register them in the system as utilities). 2. Substitute `@apply` on the AST (including `@utility`'s ASTs) with the content of the utility. 3. Delete the `@utility` at-rules such that they are removed from the CSS output itself. The reason we do it in this order is because handling `@apply` during `@utility` handling means that we could rely on another `@utility` that is defined later and therefore the order of the utilities starts to matter. This is not a bad thing, but the moment you import multiple CSS files or plugins, this could become hard to manage. Another important step is that when using `@utility foo`, the implementation creates a `structuredClone` from its AST when first using the utility. The reason we do that is because `foo` and `foo!` generate different output and we don't want to accidentally mutate the same AST. This structured clone is the start of the problem in the linked issue (#15501). If we don't do the structured clone, then substituting the `@apply` rules would work, but then `foo` and `foo!` will generate the same output, which is bad. The linked issue has this structure: ```css .foo { @apply bar; } @utility bar { @apply flex; } ``` If we follow the steps above, this would substitute `@apply bar` first, which results in: ```css .foo { @apply flex; } ``` But the `bar` utility, was already cloned (and cached) so now we end up with an `@apply` rule that is not substituted. To properly solve this problem, we have to make sure that we collect all the `@apply` at-rules, and apply them in the correct order. To do this, we run a topological sort on them which ensures that all the dependencies are applied before substituting the current `@apply`. This means that in the above example, in order to process `@apply bar`, we have to process the `bar` utility first. If we run into a circular dependency, then we will throw an error like before. You'll notice that the error message in this PR is updated to a different spot. This one is a bit easier to grasp because it shows the error where the circular dependency _starts_ not where it _ends_ (and completes the circle). The previous message was not wrong (since it's a circle), but now it's a bit easier to reason about. Fixes: #15501
2025-01-07 16:19:37 +01:00
- Ensure `@apply` rules are processed in the correct order ([#15542](https://github.com/tailwindlabs/tailwindcss/pull/15542))
Prepare v4.0.0-beta.9 release (#15583) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-09 18:04:34 +01:00
- Allow negative utility names in `@utility` ([#15573](https://github.com/tailwindlabs/tailwindcss/pull/15573))
Remove all `@keyframes` in reference import mode (#15581) This PR fixes an issue where JavaScript plugins were still able to contribute `@keyframes` when loaded inside an `@reference` import. This was possible because we only gated the `addBase` API and not the `addUtilities` one which also has a special branch to handle `@keyframe` rules. To make this work, we have to create a new instance of the plugin API that has awareness of wether the plugin accessing it is inside reference import mode. ## Test plan Added a unit test that reproduces the issue observed via #15544
2025-01-09 17:14:07 +01:00
- Remove all `@keyframes` contributed by JavaScript plugins when using `@reference` imports ([#15581](https://github.com/tailwindlabs/tailwindcss/pull/15581))
Upgrade: Do not extract class names from functions (#15566) This PR prevents the migration of utilities detected in function names, e.g.: the use of `shadow` inside `filter: 'drop-shadow(…)'`. ## Test plan Have content like this in a project you're migrating using the upgrade tool: ```js { filter: 'drop-shadow(0 0 0.5rem #000)' } ``` This was verified by adding unit tests to the specific codemods and adding an integration test.
2025-01-07 15:31:48 +01:00
- _Upgrade (experimental)_: Do not extract class names from functions (e.g. `shadow` in `filter: 'drop-shadow(…)'`) ([#15566](https://github.com/tailwindlabs/tailwindcss/pull/15566))
Migrate `theme(…)` to `--theme(…)`, migrate `calc(var(--spacing)*x)` to `--spacing(x)` (#15579) This PR improves the codemod tool to simplify 2 things: 1. Whenever you have a `theme(…)` call, we try to change it to a `var(…)`, but if that doesn't work for some reason, we will make sure to at least convert it to the more modern `--theme(…)`. 2. When converting `theme(spacing.2)`, we used to convert it to `calc(var(--spacing)*2)`, but now we will convert it to `--spacing(2)` instead.
2025-01-09 17:17:07 +01:00
- _Upgrade (experimental)_: Migrate `theme(spacing.2)` to `--spacing(2)` ([#15579](https://github.com/tailwindlabs/tailwindcss/pull/15579))
- _Upgrade (experimental)_: Migrate `theme(…)` to `--theme(…)` ([#15579](https://github.com/tailwindlabs/tailwindcss/pull/15579))
Fixed definition of `place-content-*` (#15440) The utilities `place-content-between`, `place-content-around`, and `place-content-evenly` are defined incorrectly. This PR fixes them. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-18 20:17:29 -05:00
Move `--container-prose` to `--max-width-prose` (#15439) We don’t want utilities like `basis-prose`, `w-prose`, etc existing nor a `@prose:*` variant. So we’re moving the theme key to `--max-width-*` to align with the definition as it was in v3. cc @adamwathan --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-12-18 20:15:37 -05:00
### Changed
Prepare v4.0.0-beta.9 release (#15583) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-09 18:04:34 +01:00
- Remove `--container-prose` in favor of a deprecated `--max-width-prose` theme variable so that `*-prose` is only available for max-width utilities and only for backward compatibility ([#15439](https://github.com/tailwindlabs/tailwindcss/pull/15439))
Vite: Process `<style>` blocks inside Svelte files as a post-processor (#15436) This PR changes the Svelte integration to be a post-processor similar to what we're doing for `<style>` blocks in Astro and Vue files. More details can be found in the GitHub discussion: https://github.com/sveltejs/svelte/discussions/14668#discussioncomment-11620743
2025-01-09 17:16:33 +01:00
- Use Vite post-processor APIs for processing Svelte `<style>` blocks ([#15436](https://github.com/tailwindlabs/tailwindcss/pull/15436))
Remove `@property` fallbacks for Firefox (#15622) This PR removes the `@property` fallbacks added in #13655. This is possible because we're targeting a minimum Firefox version of 128 which [includes support for \`@property\` rules](https://developer.mozilla.org/de/docs/Web/CSS/@property). <img width="1284" alt="Screenshot 2025-01-14 at 11 36 44" src="https://github.com/user-attachments/assets/ae070781-35c1-4165-be51-baa63f28db5b" />
2025-01-14 15:51:44 +01:00
- Remove `@property` fallback rules for Firefox ([#15622](https://github.com/tailwindlabs/tailwindcss/pull/15622))
Prepare v4.0.0-beta.8 release (#15418)
2024-12-17 13:31:28 +01:00
## [4.0.0-beta.8] - 2024-12-17
Ensure `Symbol.dispose` and `Symbol.asyncDispose` are available (#15404) We recently introduced some better instrumentation (https://github.com/tailwindlabs/tailwindcss/pull/15303) which uses the new `using` keyword. I made sure that this was compiled correctly for environments where `using` is not available yet. The issue is that this also relies on `Symbol.dispose` being available. In my testing on our minimal required Node.js version (18) it did work fine. However, turns out that I was using `18.20.x` locally where `Symbol.dispose` **_is_** available, but on older version of Node.js 18 (e.g.: `18.17.x`) it is **_not_** available. This now results in some completely broken builds, e.g.: when running on Cloudflare Pages. See: #15399 I could reproduce this error in CI, by temporarily downgrading the used Node.js version to `18.17.0`. See: <img width="1142" alt="image" src="https://github.com/user-attachments/assets/5bf30f80-9ca0-40d9-ad02-d1ffb4e0e5dd" /> Implementing the proper polyfill, as recommended by the TypeScript docs ( see: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-2.html#:~:text=Symbol.dispose,-??=%20Symbol(%22Symbol.dispose ), the error goes away. (If you look at CI after the polyfill, it still fails but for different reasons unrelated to this change) Fixes: #15399 --- ## Test plan 1. I reproduced it in CI, and I kept the commits so that you can take a look where it fails with the `Object not disposable`. 2. Using the provided reproduction from #15399: ### Before It works on Node.js v18.20.x, but switching to Node.js v18.17.x you can see it fail: <img width="1607" alt="image" src="https://github.com/user-attachments/assets/cb6ab73a-8eb2-4003-bab7-b2390f1c879d" /> ### After Using pnpm's overrides, we can apply the fix from this PR and test it in the reproduction. You'll notice that it now works in both Node.js v18.20.x and v18.17.x <img width="1604" alt="image" src="https://github.com/user-attachments/assets/b3a65557-0658-4cb0-a2f9-e3079c7936d5" />
2024-12-16 14:17:44 +01:00
### Fixed
- Ensure `Symbol.dispose` and `Symbol.asyncDispose` are polyfilled ([#15404](https://github.com/tailwindlabs/tailwindcss/pull/15404))
Prepare v4.0.0-beta.7 release (#15392) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-13 15:18:21 +01:00
## [4.0.0-beta.7] - 2024-12-13
Expose `flattenColorPalette` (#15318) Resolves #15315 It looks like we implemented this in Core but forgot to expose it from the distributed package (the references are only used for testing plugins internally right now). This exposes `flattenColorPalette` under the old import path of `tailwindcss/lib/util/flattenColorPalette`. ## Test Plan Added the following plugin to the Vite example and ensured it works as expected: ```ts import flattenColorPalette from 'tailwindcss/lib/util/flattenColorPalette' import plugin from 'tailwindcss/plugin' export default plugin(({ matchUtilities, theme }) => { matchUtilities( { 'hover-bg': (value) => { return { '&:hover': { backgroundColor: value, }, } }, }, { values: flattenColorPalette(theme('colors')) }, ) }) ``` <img width="462" alt="Screenshot 2024-12-06 at 11 47 44" src="https://github.com/user-attachments/assets/11163390-053e-4c6e-8cb9-ae67184ad594">
2024-12-09 11:33:19 +01:00
### Added
Prepare v4.0.0-beta.7 release (#15392) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-13 15:18:21 +01:00
- Export `tailwindcss/lib/util/flattenColorPalette` for backward compatibility ([#15318](https://github.com/tailwindlabs/tailwindcss/pull/15318))
- Improve debug logs to get better insights ([#15303](https://github.com/tailwindlabs/tailwindcss/pull/15303))
Expose `flattenColorPalette` (#15318) Resolves #15315 It looks like we implemented this in Core but forgot to expose it from the distributed package (the references are only used for testing plugins internally right now). This exposes `flattenColorPalette` under the old import path of `tailwindcss/lib/util/flattenColorPalette`. ## Test Plan Added the following plugin to the Vite example and ensured it works as expected: ```ts import flattenColorPalette from 'tailwindcss/lib/util/flattenColorPalette' import plugin from 'tailwindcss/plugin' export default plugin(({ matchUtilities, theme }) => { matchUtilities( { 'hover-bg': (value) => { return { '&:hover': { backgroundColor: value, }, } }, }, { values: flattenColorPalette(theme('colors')) }, ) }) ``` <img width="462" alt="Screenshot 2024-12-06 at 11 47 44" src="https://github.com/user-attachments/assets/11163390-053e-4c6e-8cb9-ae67184ad594">
2024-12-09 11:33:19 +01:00
### Fixed
- Fix dependency related warnings when using `@tailwindcss/postcss` on Windows ([#15321](https://github.com/tailwindlabs/tailwindcss/pull/15321))
Skip creating a compiler for CSS files that should not be processed (#15340) This PR skips creating a compiler in the `@tailwindcss/postcss` implementation if we know that the CSS file we are handling is definitely not a Tailwind CSS file. This is a performance improvement for initial builds where some CSS files would've been handling by Tailwind CSS but shouldn't. E.g.: When setting up custom fonts in Next.js applications, each font will have it's own CSS file that is passed to `@tailwindcss/postcss`. Since they don't contain `@import` or any other Tailwind CSS directives, we can just skip them.
2024-12-09 11:55:33 +01:00
- Skip creating a compiler for CSS files that should not be processed ([#15340](https://github.com/tailwindlabs/tailwindcss/pull/15340))
Suggest `shadow-none` (#15342) Noticed a missing `shadow-none` completion while finally starting the work to migrate my personal blog to Tailwind, lol.
2024-12-09 12:32:50 +01:00
- Fix missing `shadow-none` suggestion in IntelliSense ([#15342](https://github.com/tailwindlabs/tailwindcss/pull/15342))
Optimize AST before printing for IntelliSense (#15347) We changed how AST printing worked recently but forgot to update this. Which causes us to print properties with a value of `undefined` in Tailwind Play, Tailwind CSS IntelliSense, and our Language Server (oops). This PR fixes this by optimizing the AST before printing (which is what toCss did previously)
2024-12-09 12:44:42 -05:00
- Optimize AST before printing for IntelliSense ([#15347](https://github.com/tailwindlabs/tailwindcss/pull/15347))
Prepare v4.0.0-beta.7 release (#15392) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-13 15:18:21 +01:00
- Generate vendor prefixes for Chrome 111+ (e.g. `-webkit-background-clip: text`) ([#15389](https://github.com/tailwindlabs/tailwindcss/pull/15389))
Prepare v4.0.0-beta.6 release (#15325)
2024-12-06 14:32:21 -05:00
Rename `--aspect-ratio-*` theme key to `--aspect-*` (#15365) This PR renames the `--aspect-ratio` theme key to `--aspect`. This is to match what we've done with other theme keys where they match the utility names, like `--ease` and `--leading`. ```diff @theme { - --aspect-ratio-retro: 4 / 3; + --aspect-retro: 4 / 3; } ``` Additionally, I've also converted the existing `aspect-video` static utility to a theme value. This will allow people to override this utility in their own projects—something that's not possible with static utilities. This change feels appropriate since the video aspect ratio is subjective, unlike other static utilities like `aspect-square`. ```css @theme { --aspect-video: 4 / 3; /* N64 baby! */ } ```
2024-12-10 14:33:20 -05:00
### Changed
- Rename `--aspect-ratio-*` theme key to `--aspect-*` ([#15365](https://github.com/tailwindlabs/tailwindcss/pull/15365))
- Derive `aspect-video` utility from theme ([#15365](https://github.com/tailwindlabs/tailwindcss/pull/15365))
Prepare v4.0.0-beta.6 release (#15325)
2024-12-06 14:32:21 -05:00
## [4.0.0-beta.6] - 2024-12-06
Reference imports should not generate utilities (#15307) We noticed an issue where the new `@import "…" reference` syntax was not throwing away `@tailwind` declarations, effectively causing you to create utility classes whenever you used this feature. This is especially noticed in setups with very strict compilers like Svelte. ## Test Plan ### Before <img width="1142" alt="Screenshot 2024-12-05 at 11 56 00" src="https://github.com/user-attachments/assets/546f0eb3-4401-48c9-9268-76992e899226"> ### After <img width="2560" alt="Screenshot 2024-12-05 at 12 27 30" src="https://github.com/user-attachments/assets/16732000-e02c-49bc-ac6f-91da0cfcc7e8">
2024-12-05 16:18:06 +01:00
### Fixed
- Ensure `@import "…" reference` never generates utilities ([#15307](https://github.com/tailwindlabs/tailwindcss/pull/15307))
Prepare v4.0.0-beta.5 (#15285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-04 16:28:16 +01:00
## [4.0.0-beta.5] - 2024-12-04
Add `@import "…" reference` (#15228) Closes #15219 This PR adds a new feature, `@import "…" reference` that can be used to load Tailwind CSS configuration files without adding any style rules to the CSS. The idea is that you can use this in combination with your Tailwind CSS root file when you need to have access to your full CSS config outside of the main stylesheet. A common example is for Vue, Svelte, or CSS modules: ```css @import "./tailwind.css" reference; .link { @apply underline; } ``` Importing a file as a reference will convert all `@theme` block to be `reference`, so no CSS variables will be emitted. Furthermore it will strip out all custom styles from the stylesheet. Furthermore plugins registered via `@plugin` or `@config` inside reference-mode files will not add any content to the CSS file via `addBase()`. ## Test Plan Added unit test for when we handle the import resolution and when `postcss-import` does it outside of Tailwind CSS. I also changed the Svelte and Vue integration tests to use this new syntax to ensure it works end to end. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-12-03 14:15:24 +01:00
### Added
- Parallelize parsing of individual source files ([#15270](https://github.com/tailwindlabs/tailwindcss/pull/15270))
Prepare v4.0.0-beta.5 (#15285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-04 16:28:16 +01:00
- Add new `@import "…" reference` option for importing Tailwind CSS configuration details into another CSS entry point without duplicating CSS ([#15228](https://github.com/tailwindlabs/tailwindcss/pull/15228))
- Improve performance of `@tailwindcss/postcss` by translating between internal data structures and PostCSS nodes directly without additional parsing or stringification ([#15297](https://github.com/tailwindlabs/tailwindcss/pull/15297))
Add `@import "…" reference` (#15228) Closes #15219 This PR adds a new feature, `@import "…" reference` that can be used to load Tailwind CSS configuration files without adding any style rules to the CSS. The idea is that you can use this in combination with your Tailwind CSS root file when you need to have access to your full CSS config outside of the main stylesheet. A common example is for Vue, Svelte, or CSS modules: ```css @import "./tailwind.css" reference; .link { @apply underline; } ``` Importing a file as a reference will convert all `@theme` block to be `reference`, so no CSS variables will be emitted. Furthermore it will strip out all custom styles from the stylesheet. Furthermore plugins registered via `@plugin` or `@config` inside reference-mode files will not add any content to the CSS file via `addBase()`. ## Test Plan Added unit test for when we handle the import resolution and when `postcss-import` does it outside of Tailwind CSS. I also changed the Svelte and Vue integration tests to use this new syntax to ensure it works end to end. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-12-03 14:15:24 +01:00
Vite: Don't rebase absolute `url()`s (#15275) Closes #15269 This PR fixes an issue where our Vite extension was rebasing absolute urls inside `@import`-ed files. We forgot to cover this when we implemented the URL rebasing. ## Test Plan We validated that this fixes the repro in #15269: <img width="851" alt="Screenshot 2024-12-02 at 18 07 35" src="https://github.com/user-attachments/assets/3b2c2be3-1f73-469e-9f64-301c6b948b02"> Also added a unit test for this. Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-12-02 20:23:38 +01:00
### Fixed
Prepare v4.0.0-beta.5 (#15285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-04 16:28:16 +01:00
- Ensure absolute URLs inside imported CSS files are not rebased when using `@tailwindcss/vite` ([#15275](https://github.com/tailwindlabs/tailwindcss/pull/15275))
- Fix issues with dev servers using Svelte 5 with `@tailwindcss/vite` ([#15274](https://github.com/tailwindlabs/tailwindcss/issues/15274))
- Support installing `@tailwindcss/vite` in Vite 6 projects ([#15274](https://github.com/tailwindlabs/tailwindcss/issues/15274))
- Fix resolution of imported CSS files in SSR builds with `@tailwindcss/vite` ([#15279](https://github.com/tailwindlabs/tailwindcss/issues/15279))
Postcss: Run plugin in `Once` hook (#15273) Closes #15138 This PR changes the postcss client to run in the `Once` hook instead of `OnceExit`. This makes sure the postcss order in v4 matches that of v3. Conceptually this also makes more sense, since we expect tailwindcss to be run as one of the first plugins in the pipeline (where `OnceExit` would run it almost at the end). To make sure it's still possible to use `postcss-import` before and have it resolve to the right paths, we also needed to change the `postcss-fix-relative-paths` plugin to run in the `Once` order (`postcss-import` also uses `Once` order so the order). ## Test Plan This issue had many ways in which it can manifest. I added a unit test to ensure the plugin order works but here's a concrete example when using the postcss plugin in Vite. ### Before Image `url()`s were not properly handled since the postcss plugin to transform these was run before Tailwind CSS could generate the class for it: <img width="2532" alt="Screenshot 2024-12-02 at 14 55 42" src="https://github.com/user-attachments/assets/2f23b409-1576-441d-9ffe-6f24ad6e7436"> ### After <img width="2529" alt="Screenshot 2024-12-02 at 14 53 52" src="https://github.com/user-attachments/assets/b754c3d8-1af1-4aeb-87da-0bfc3ffecdb7"> --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-12-03 10:28:51 +01:00
- Ensure other plugins can run after `@tailwindcss/postcss` ([#15273](https://github.com/tailwindlabs/tailwindcss/pull/15273))
Prepare v4.0.0-beta.5 (#15285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-12-04 16:28:16 +01:00
- Rebase URLs inside imported CSS files when using Vite with the `@tailwindcss/postcss` extension ([#15273](https://github.com/tailwindlabs/tailwindcss/pull/15273))
Add some missing suggestions in IntelliSense (#15288) When we renamed the theme keys this got missed Theme keys like `--font-sans` will result in suggestions for `font-sans` again
2024-12-03 19:11:30 -05:00
- Fix missing font family suggestions in IntelliSense ([#15288](https://github.com/tailwindlabs/tailwindcss/pull/15288))
- Fix missing `@container` suggestion in IntelliSense ([#15288](https://github.com/tailwindlabs/tailwindcss/pull/15288))
Vite: Don't rebase absolute `url()`s (#15275) Closes #15269 This PR fixes an issue where our Vite extension was rebasing absolute urls inside `@import`-ed files. We forgot to cover this when we implemented the URL rebasing. ## Test Plan We validated that this fixes the repro in #15269: <img width="851" alt="Screenshot 2024-12-02 at 18 07 35" src="https://github.com/user-attachments/assets/3b2c2be3-1f73-469e-9f64-301c6b948b02"> Also added a unit test for this. Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-12-02 20:23:38 +01:00
Prepare v4.0.0-beta.4 (#15245)
2024-11-29 17:18:42 +01:00
## [4.0.0-beta.4] - 2024-11-29
Improve performance of `@tailwindcss/postcss` and `@tailwindcss/vite` (#15226) This PR improves the performance of the `@tailwindcss/postcss` and `@tailwindcss/vite` implementations. The issue is that in some scenarios, if you have multiple `.css` files, then all of the CSS files are ran through the Tailwind CSS compiler. The issue with this is that in a lot of cases, the CSS files aren't even related to Tailwind CSS at all. E.g.: in a Next.js project, if you use the `next/font/local` tool, then every font you used will be in a separate CSS file. This means that we run Tailwind CSS in all these files as well. That said, running Tailwind CSS on these files isn't the end of the world because we still need to handle `@import` in case `@tailwind utilities` is being used. However, we also run the auto source detection logic for every CSS file in the system. This part is bad. To solve this, this PR introduces an internal `features` to collect what CSS features are used throughout the system (`@import`, `@plugin`, `@apply`, `@tailwind utilities`, etc…) The `@tailwindcss/postcss` and `@tailwindcss/vite` plugin can use that information to decide if they can take some shortcuts or not. --- Overall, this means that we don't run the slow parts of Tailwind CSS if we don't need to. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-29 16:59:29 +01:00
### Fixed
- Don't scan source files for utilities unless `@tailwind utilities` is present in the CSS in `@tailwindcss/postcss` and `@tailwindcss/vite` ([#15226](https://github.com/tailwindlabs/tailwindcss/pull/15226))
- Skip reserializing CSS files that don't use Tailwind features in `@tailwindcss/postcss` and `@tailwindcss/vite` ([#15226](https://github.com/tailwindlabs/tailwindcss/pull/15226))
Upgrade: Do not migrate `overflow-clip` utility (#15244) `overflow-clip` was the name for `text-clip` in v4. However, that was changed in v3 already so in v3 `overflow-clip` is already doing the same as in v4. Hence a codemod is not necessary. Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-29 17:00:15 +01:00
- _Upgrade (experimental)_: Do not migrate the `overflow-clip` utility ([#15244](https://github.com/tailwindlabs/tailwindcss/pull/15244))
Migrate `backdrop-blur-*` utilities (#15242) This PR adds missing migrations for the `backdrop-blur-*` utilities. It uses the same values from your theme as `blur` does.
2024-11-29 17:11:47 +01:00
- _Upgrade (experimental)_: Rename `backdrop-blur` to `backdrop-blur-sm` and `backdrop-blur-sm` to `backdrop-blur-xs` ([#15242](https://github.com/tailwindlabs/tailwindcss/pull/15242))
Upgrade: Migrate prefixed `group` and `peer` classes (#15208) Resolves #15193 This PR fixes an issue where `group` and `peer` would not have their prefixes migrated as part of the upgrade script. We do this by registering `group` and `peer` as utilities during the codemods. This way, `parseCandidate` will find these classes to be valid Tailwind candidates and the prefix can be migrated just like any other utility. ## Test Plan Tried it with the v3 upgrade playground in the repo and it worked fine: <img width="1257" alt="Screenshot 2024-11-27 at 12 17 25" src="https://github.com/user-attachments/assets/1ee101e1-1d6a-4ce0-b0d4-8d51e5f6b0d2"> I've also added tests to our prefix upgrade integration test and the prefix migration unit tests.
2024-11-27 17:34:27 +01:00
Prepare v4.0.0-beta.3 (#15217) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-27 18:15:21 +01:00
## [4.0.0-beta.3] - 2024-11-27
Upgrade: Migrate prefixed `group` and `peer` classes (#15208) Resolves #15193 This PR fixes an issue where `group` and `peer` would not have their prefixes migrated as part of the upgrade script. We do this by registering `group` and `peer` as utilities during the codemods. This way, `parseCandidate` will find these classes to be valid Tailwind candidates and the prefix can be migrated just like any other utility. ## Test Plan Tried it with the v3 upgrade playground in the repo and it worked fine: <img width="1257" alt="Screenshot 2024-11-27 at 12 17 25" src="https://github.com/user-attachments/assets/1ee101e1-1d6a-4ce0-b0d4-8d51e5f6b0d2"> I've also added tests to our prefix upgrade integration test and the prefix migration unit tests.
2024-11-27 17:34:27 +01:00
Ensure `.group` and `.peer` are prefixed when using the `prefix(…)` option (#15174) This PR fixes an issue where the `.group` and `.peer` classes didn't get prefixed if you are using the `prefix(…)` option. Before this change, `tw:group-hover:flex`, generated: ```css .tw\\:group-hover\\:flex { &:is(:where(.group):hover *) { @media (hover: hover) { display: flex; } } } ``` But now it generates: ```css .tw\\:group-hover\\:flex { &:is(:where(.tw\\:group):hover *) { @media (hover: hover) { display: flex; } } } ``` Or as a diff, it might be more clear: ```diff .tw\\:group-hover\\:flex { - &:is(:where(.group):hover *) { + &:is(:where(.tw\\:group):hover *) { @media (hover: hover) { display: flex; } } } ``` Fixes: #15172
2024-11-25 22:00:21 +01:00
### Fixed
Set browser targets for iOS Safari, Firefox, and Chrome (#15166) Closes #15160 We need to set browser targets for each browser individually to see vendor prefixes created for each browser. Exact values are up for discussion, this first pass is taken from @adamwathan's comments in https://github.com/tailwindlabs/tailwindcss/issues/15160 --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-26 12:22:12 +01:00
- Ensure any necessary vendor prefixes are generated for iOS Safari, Firefox, and Chrome ([#15166](https://github.com/tailwindlabs/tailwindcss/pull/15166))
Ensure `.group` and `.peer` are prefixed when using the `prefix(…)` option (#15174) This PR fixes an issue where the `.group` and `.peer` classes didn't get prefixed if you are using the `prefix(…)` option. Before this change, `tw:group-hover:flex`, generated: ```css .tw\\:group-hover\\:flex { &:is(:where(.group):hover *) { @media (hover: hover) { display: flex; } } } ``` But now it generates: ```css .tw\\:group-hover\\:flex { &:is(:where(.tw\\:group):hover *) { @media (hover: hover) { display: flex; } } } ``` Or as a diff, it might be more clear: ```diff .tw\\:group-hover\\:flex { - &:is(:where(.group):hover *) { + &:is(:where(.tw\\:group):hover *) { @media (hover: hover) { display: flex; } } } ``` Fixes: #15172
2024-11-25 22:00:21 +01:00
- Ensure `.group` and `.peer` are prefixed when using the `prefix(…)` option ([#15174](https://github.com/tailwindlabs/tailwindcss/pull/15174))
Declare transform properties with "*" syntax instead of "<transform-function>" (#15179) Fixes #15144. Weird bug in Safari that breaks 3D transforms when using registered custom properties registered with the "<transform-function>" type: https://bugs.webkit.org/show_bug.cgi?id=283487 Declaring them as just "*" fixes it with no apparent downside since transitioning these 3D transforms still works, and usually transitions/animations are the reason you'd type these properties. Evidence of rotations looking the same in all browsers here: ![image](https://github.com/user-attachments/assets/bcaa6145-e047-4e26-8384-c5599b647cf9) --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-25 21:20:54 -05:00
- Ensure 3D transforms render correctly in Safari ([#15179](https://github.com/tailwindlabs/tailwindcss/pull/15179))
Ensure `--spacing-*` variables take precedence over `--container-*` variables (#15180) Fixes #15146. This PR updates the `w-*`, `max-w-*`, `min-w-*`, and `basis-*` utilities to make sure that `--spacing-*` values are preferred over `--container-*` values when there is a conflict. Given this theme configuration: ```css @theme { --spacing-sm: 8px; --container-sm: 256px; } ``` …utilities like `max-w-sm` will use `8px` instead of `256px` after this change. Users can still be explicit about the value they want to use if they've introduced a naming collision like this by using our variable shorthand like `max-w-(--container-sm)`. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-26 09:45:16 -05:00
- Ensure `--spacing-*` variables take precedence over `--container-*` variables ([#15180](https://github.com/tailwindlabs/tailwindcss/pull/15180))
Fix scanning classes delimited by tab characters (#15169) This PR fixes an issue where multi-line candidates in Svelte files couldn't be found as reported in #15148 After digging in, the real culprit seems to be that the reproduction used tab `\t` characters instead of spaces and we only delimited explicitly on spaces. Initially I couldn't reproduce this in an integration test until we (@thecrypticace and I) realised that `\t` was being used. ## Test plan: This PR adds an integration test that fails before the fix happens. The fix itself is easy in the sense that we just use all ascii whitespace characters instead of just spaces. Fixes: #15148
2024-11-26 19:22:18 +01:00
- Fix scanning classes delimited by tab characters ([#15169](https://github.com/tailwindlabs/tailwindcss/pull/15169))
Use `oklab` instead of `oklch` for `color-mix(…)` and gradients (#15201) Fixes https://github.com/tailwindlabs/tailwindcss/discussions/15184, https://github.com/tailwindlabs/tailwindcss/issues/14955 There's a strange bug in Safari < 18 where mixing a color with `transparent` or with a gray tone, the resulting color looks as if it's been interpolated through a red-ish color. Here's the same blue to transparent gradient in Safari 17 using OKLAB and OKLCH for comparison: <img width="747" alt="image" src="https://github.com/user-attachments/assets/1cb09b00-0d84-4284-be34-103726d8af03"> In other browsers, both of these examples look identical. This bug also shows up when using an opacity modifier right now because we use `in oklch` in our `color-mix(…)` calls: <img width="744" alt="image" src="https://github.com/user-attachments/assets/b029c5f1-0c5c-4119-80ba-dfeabe25927e"> This PR updates all of the affected places in Tailwind to use `in oklab` instead of `in oklch` which then renders everything as expected in all browsers. The big unfortunate change here is changing the default behavior of gradient utilities like `bg-linear-to-r` to use `in oklab` instead of `in oklch`. This means you get muddier gradients by default when creating a gradient between two regular colors (no transparent or gray), like how they looked in v3: <img width="740" alt="image" src="https://github.com/user-attachments/assets/d02e7596-4c99-4ba3-b929-d2db4911c8e9"> This feels worth it though to avoid people getting bitten by this Safari bug without realizing it, and people can always opt in to using OKLCH with classes like `bg-linear-to-r/oklch`. The nice thing about making this opt-in is that no one will opt-in to this when using transparent or gray because it won't make things look any different/better, and the only places where it does make things look better _do_ work as expected in Safari anyways. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-27 06:18:31 -05:00
- Ensure opacity modifiers and semi-transparent gradients render correctly by default in Safari ([#15201](https://github.com/tailwindlabs/tailwindcss/pull/15201))
Use unitless line-heights for font-size variables (#15216) Safari has an [insane bug](https://github.com/tailwindlabs/tailwindcss/issues/15196) where if you register custom properties for gradient colors using the `"<color>"` type, you attempt to transition a gradient on an element, _and_ you set a font-size and line-height on that element that point to CSS variables defined using `rem` units, the element size changes and shifts the layout while the transition is happening: https://github.com/user-attachments/assets/46eefccf-8a12-4751-8a44-54e48c54cd06 This bug goes away if you use anything other than `rem` units for the line-height. So this PR changes all of our variables like `--text-3xl--line-height` to use unitless relative line-height values instead of fixed line-height values to workaround this bug. Not my favorite change but pretty low impact because you likely aren't going to reference those variables for much anyways. If Safari ever fixes this bug (which is still present as of Safari 18), it would be nice to swap these back to what they were. Fixes #15196. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-27 11:39:04 -05:00
- Fix element size thrashing when transitioning gradients on elements with a defined font-size in Safari ([#15216](https://github.com/tailwindlabs/tailwindcss/pull/15216))
Don't register properties with types unless necessary (#15215) This PR updates many of our `@property` rules to use `syntax: "*"` instead of a specific type. Registering custom properties with types triggers all sorts of obscure edge-case bugs in different browsers (mostly Safari, sometimes Firefox), but using `"*"` always seems to work. So unless we know we actually need to animate a custom property, it's safer to register is as `"*"`. Many of the places our custom properties are used are already inherently animatable (like the `translate`, `scale`, and `transform`) even when the underlying properties are not typed, so removing types for things like `--tw-scale-x` doesn't actually stop the `scale-*` utilities from being animateable. I've also updated the `--tw-gradient-from/via/to-position` properties to use `<length-percentage>` instead of `<length> | <percentage>` because for some reason I don't understand, only `<length-percentage>` works correctly when using `calc(…)` in arbitrary values. Fixes https://github.com/tailwindlabs/tailwindcss/issues/15188, https://github.com/tailwindlabs/tailwindcss/issues/14277. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-27 11:47:27 -05:00
- Ensure `translate-*` utilities work with arbitrary values that use `calc(…)` ([#15215](https://github.com/tailwindlabs/tailwindcss/pull/15215))
- Ensure gradient stop position utilities work with arbitrary values that use `calc(…)` ([#15215](https://github.com/tailwindlabs/tailwindcss/pull/15215))
Prepare v4.0.0-beta.3 (#15217) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-27 18:15:21 +01:00
- Ensure Node addons are packaged correctly with Windows ARM builds ([#15171](https://github.com/tailwindlabs/tailwindcss/pull/15171))
- Ensure the Vite plugin resolves CSS and JS files according to the configured resolver conditions ([#15173])(https://github.com/tailwindlabs/tailwindcss/pull/15173)
- _Upgrade (experimental)_: Migrate prefixes for `.group` and `.peer` classes ([#15208](https://github.com/tailwindlabs/tailwindcss/pull/15208))
Use `oklab` instead of `oklch` for `color-mix(…)` and gradients (#15201) Fixes https://github.com/tailwindlabs/tailwindcss/discussions/15184, https://github.com/tailwindlabs/tailwindcss/issues/14955 There's a strange bug in Safari < 18 where mixing a color with `transparent` or with a gray tone, the resulting color looks as if it's been interpolated through a red-ish color. Here's the same blue to transparent gradient in Safari 17 using OKLAB and OKLCH for comparison: <img width="747" alt="image" src="https://github.com/user-attachments/assets/1cb09b00-0d84-4284-be34-103726d8af03"> In other browsers, both of these examples look identical. This bug also shows up when using an opacity modifier right now because we use `in oklch` in our `color-mix(…)` calls: <img width="744" alt="image" src="https://github.com/user-attachments/assets/b029c5f1-0c5c-4119-80ba-dfeabe25927e"> This PR updates all of the affected places in Tailwind to use `in oklab` instead of `in oklch` which then renders everything as expected in all browsers. The big unfortunate change here is changing the default behavior of gradient utilities like `bg-linear-to-r` to use `in oklab` instead of `in oklch`. This means you get muddier gradients by default when creating a gradient between two regular colors (no transparent or gray), like how they looked in v3: <img width="740" alt="image" src="https://github.com/user-attachments/assets/d02e7596-4c99-4ba3-b929-d2db4911c8e9"> This feels worth it though to avoid people getting bitten by this Safari bug without realizing it, and people can always opt in to using OKLCH with classes like `bg-linear-to-r/oklch`. The nice thing about making this opt-in is that no one will opt-in to this when using transparent or gray because it won't make things look any different/better, and the only places where it does make things look better _do_ work as expected in Safari anyways. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-27 06:18:31 -05:00
### Changed
- Interpolate gradients using OKLAB instead of OKLCH by default ([#15201](https://github.com/tailwindlabs/tailwindcss/pull/15201))
Throw when `layer(…)` in `@import` is in the incorrect spot (#15109) This PR throws an error when we notice that an `layer(…)` in an `@import` or `@media` is incorrect. This hints the user to ensure that `layer(…)` in an `@import` should be the first condition. In case of an `@media`, it should be an `@layer …` instead. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-27 12:33:25 +01:00
- Error when `layer(…)` in `@import` is not first in the list of functions/conditions ([#15109](https://github.com/tailwindlabs/tailwindcss/pull/15109))
Use unitless line-heights for font-size variables (#15216) Safari has an [insane bug](https://github.com/tailwindlabs/tailwindcss/issues/15196) where if you register custom properties for gradient colors using the `"<color>"` type, you attempt to transition a gradient on an element, _and_ you set a font-size and line-height on that element that point to CSS variables defined using `rem` units, the element size changes and shifts the layout while the transition is happening: https://github.com/user-attachments/assets/46eefccf-8a12-4751-8a44-54e48c54cd06 This bug goes away if you use anything other than `rem` units for the line-height. So this PR changes all of our variables like `--text-3xl--line-height` to use unitless relative line-height values instead of fixed line-height values to workaround this bug. Not my favorite change but pretty low impact because you likely aren't going to reference those variables for much anyways. If Safari ever fixes this bug (which is still present as of Safari 18), it would be nice to swap these back to what they were. Fixes #15196. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-27 11:39:04 -05:00
- Use unitless line-height values for font-size variables in default theme ([#15216](https://github.com/tailwindlabs/tailwindcss/pull/15216))
Don't register properties with types unless necessary (#15215) This PR updates many of our `@property` rules to use `syntax: "*"` instead of a specific type. Registering custom properties with types triggers all sorts of obscure edge-case bugs in different browsers (mostly Safari, sometimes Firefox), but using `"*"` always seems to work. So unless we know we actually need to animate a custom property, it's safer to register is as `"*"`. Many of the places our custom properties are used are already inherently animatable (like the `translate`, `scale`, and `transform`) even when the underlying properties are not typed, so removing types for things like `--tw-scale-x` doesn't actually stop the `scale-*` utilities from being animateable. I've also updated the `--tw-gradient-from/via/to-position` properties to use `<length-percentage>` instead of `<length> | <percentage>` because for some reason I don't understand, only `<length-percentage>` works correctly when using `calc(…)` in arbitrary values. Fixes https://github.com/tailwindlabs/tailwindcss/issues/15188, https://github.com/tailwindlabs/tailwindcss/issues/14277. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-27 11:47:27 -05:00
- Don't register custom properties with explicit types unless those custom properties need to be animateable ([#15215](https://github.com/tailwindlabs/tailwindcss/pull/15215))
Prepare `v4.0.0-beta.2` release (#15104) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-22 11:17:21 -05:00
## [4.0.0-beta.2] - 2024-11-22
Use configured letter-spacing values for custom font-size utilities (#15099) Fixes https://github.com/tailwindlabs/tailwindcss/issues/15096. We were mistakenly reading from the `--tracking` sub-property but should be reading from `--letter-spacing`. To test this I copied the reproduction from the issue into our Vite playground and made sure the custom letter-spacing was being applied as expected: <img width="1443" alt="image" src="https://github.com/user-attachments/assets/bfc9ca23-bfc7-40d4-aec0-d3e715312eac"> --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-22 08:49:22 -05:00
### Fixed
- Use configured `--letter-spacing` values for custom font size utilities ([#15099](https://github.com/tailwindlabs/tailwindcss/pull/15099))
Reset reverse state in `space-x/y-*` and `divide-x/y-*` (#15094) We weren't resetting the `--tw-space-x-reverse` and `--tw-space-y-reverse` state in the `space-x/y-{number}` utilities which broke code assuming that `md:space-x-3` would no longer be reversed. This PR fixes that. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-22 08:52:11 -05:00
- Ensure `space-x/y-*` and `divide-x/y-*` with variants can undo `space-x/y-reverse` and `divide-x/y-reverse` ([#15094](https://github.com/tailwindlabs/tailwindcss/pull/15094))
Don't print minified code when the build fails (#15106) Fix #15085 We were relying on Node's printing of errors during build but this prints the line of code the error occurs on. Since the code is minified you'd get a really long string of code that wrapped a ton in the console before the actual error. Now we print errors during build like we do in watch mode.
2024-11-22 10:39:51 -05:00
- Don't print minified code when the build fails in the CLI ([#15106](https://github.com/tailwindlabs/tailwindcss/pull/15106))
Generate the correct CSS for the `break-keep` utility (#15108) Fixes https://github.com/tailwindlabs/tailwindcss/issues/15107. Previously we were generating `word-break: break-keep` when it should be `word-break: keep-all`. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-22 10:40:23 -05:00
- Generate the correct CSS for the `break-keep` utility ([#15108](https://github.com/tailwindlabs/tailwindcss/pull/15108))
Prepare `v4.0.0-beta.2` release (#15104) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-22 11:17:21 -05:00
- Detect single word utilities that include numbers (e.g. `h1`) when scanning files ([#15110](https://github.com/tailwindlabs/tailwindcss/pull/15110))
Always add `layer(…)` as the first param to `@import` (#15102) This PR ensures that when we inject `layer(…)` into an `@import` that it always gets inserted as the first param. The `layer(…)` has to come first by spec. Input: ```css @import "./foo" supports(--foo); ``` Before: ```css @import "./foo" supports(--foo) layer(utilities); ``` After: ```css @import "./foo" layer(utilities) supports(--foo); ```
2024-11-22 15:09:26 +01:00
- _Upgrade (experimental)_: Always add `layer(…)` as the first param to `@import` ([#15102](https://github.com/tailwindlabs/tailwindcss/pull/15102))
Prepare v4.0.0-beta.1 release (#15070)
2024-11-21 13:20:30 -05:00
Revert new default form styles (#15100) Closes #15071 This PR reverts the changes in #15036 which add consistent base styles for buttons and form controls to Preflight. While this felt like a good idea (for the reasons explained in that PR), practically this is just too disruptive of a change for people upgrading from v3 to v4. While updating some of our projects to v4 we found ourselves adding classes to undo styles more often than we expected, and it also felt inconsistent to have to use a different set of classes to style a link or a button when we wanted them to look the same. We also decided it feels a little strange that you could change the border color of an element without ever specifying that it should have a border, for example this just feels a little wrong: ```html <button class="border-blue-500"> ``` We also needed to set a default `color-scheme` value for any of this stuff to work which breaks the ability to use the `color-scheme` meta tag. Since this change was a fairly major breaking change and we aren't feeling much benefit from it, it doesn't feel worth making this change for v4. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-22 08:55:05 -05:00
### Changed
- Revert the new base styles for buttons and form controls ([#15100](https://github.com/tailwindlabs/tailwindcss/pull/15100))
Prepare v4.0.0-beta.1 release (#15070)
2024-11-21 13:20:30 -05:00
## [4.0.0-beta.1] - 2024-11-21
Convert opacity keys to percentage values (#15067) This PR improves compatibility for named `opacity` theme values. One of the changes in v4 is that we use the CSS `color-mix()` function to apply opacity to colors. This, however, is limited to percentage values only: ```css color: color-mix(in oklch, var(--color-red-500) 50%, transparent); /* ^^^ */ /* This needs to be a percentage value */ ``` In v3, however, it was common to specify custom opacity values as decimal numbers. That's also what we did in our default config: https://github.com/tailwindlabs/tailwindcss/blob/6069a811871c58a9b202fbb3a6f13774c57278c0/stubs/config.full.js#L703-L725 This PR improves interop with these values by: 1. Converting decimal numbers in the range of `[0, 1]` to their percentage value equivalent when using the interop layer. 2. Adjusts the codemod that migrates `opacity` theme keys to Tailwind v4 theme variables to include the same conversion. 3. Furthermore, due to the added support of named opacity modifers, we can also drop theme keys that would now be the default. For example the following config would not be necessary in v4 as the opacity modifier would accept the value `50` by default: ```js module.exports = { theme: { opacity: { 50: 0.5 } } } ``` ## Test Plan Added a new integration test for the codemod and a unit test for the interop layer. I also re-ran the codemod on the Commit template and it's now working as expected (left is v3, right is v4): <img width="2560" alt="Screenshot 2024-11-21 at 17 25 32" src="https://github.com/user-attachments/assets/f0c87243-ca80-4c39-ae5e-c1ab48fbe614">
2024-11-21 19:06:58 +01:00
### Added
- _Upgrade (experimental)_: Drop unnecessary `opacity` theme values when migrating to CSS ([#15067](https://github.com/tailwindlabs/tailwindcss/pull/15067))
Add `color` to form reset snippet (#15064) While testing the latest alpha release across Tailwind v3 projects, we noticed one regression in relation to the default color of `<button>` elements. In v3, the reset would change the default to `inherit` but in v4 we would _not include it in the reset snippet inserted by the upgrade too_. This PR changes the upgrade snippet to include it: ```diff /* In Tailwind CSS v4, basic styles are applied to form elements by default. To maintain compatibility with v3, the following resets have been added: */ @layer base { input, textarea, select, button { border: 0px solid; border-radius: 0; padding: 0; + color: inherit; background-color: transparent; } } ``` This PR also ensures that there's a newline between the two code snippets. ## Test Plan ### Before ![image](https://github.com/user-attachments/assets/00b5ea23-a6f2-4f7c-93c9-62aac841ce97) ### After <img width="1354" alt="Screenshot 2024-11-21 at 15 42 58" src="https://github.com/user-attachments/assets/9a4503fe-683f-4d08-abf2-7dd111ed5428">
2024-11-21 16:14:52 +01:00
### Fixed
Convert opacity keys to percentage values (#15067) This PR improves compatibility for named `opacity` theme values. One of the changes in v4 is that we use the CSS `color-mix()` function to apply opacity to colors. This, however, is limited to percentage values only: ```css color: color-mix(in oklch, var(--color-red-500) 50%, transparent); /* ^^^ */ /* This needs to be a percentage value */ ``` In v3, however, it was common to specify custom opacity values as decimal numbers. That's also what we did in our default config: https://github.com/tailwindlabs/tailwindcss/blob/6069a811871c58a9b202fbb3a6f13774c57278c0/stubs/config.full.js#L703-L725 This PR improves interop with these values by: 1. Converting decimal numbers in the range of `[0, 1]` to their percentage value equivalent when using the interop layer. 2. Adjusts the codemod that migrates `opacity` theme keys to Tailwind v4 theme variables to include the same conversion. 3. Furthermore, due to the added support of named opacity modifers, we can also drop theme keys that would now be the default. For example the following config would not be necessary in v4 as the opacity modifier would accept the value `50` by default: ```js module.exports = { theme: { opacity: { 50: 0.5 } } } ``` ## Test Plan Added a new integration test for the codemod and a unit test for the interop layer. I also re-ran the codemod on the Commit template and it's now working as expected (left is v3, right is v4): <img width="2560" alt="Screenshot 2024-11-21 at 17 25 32" src="https://github.com/user-attachments/assets/f0c87243-ca80-4c39-ae5e-c1ab48fbe614">
2024-11-21 19:06:58 +01:00
- Ensure `opacity` theme values configured as decimal numbers via JS config files work with color utilities ([#15067](https://github.com/tailwindlabs/tailwindcss/pull/15067))
Bring back some deprecated utilities (#15069) These utilities are deprecated (and were removed) but we're brining them back so they keep working: - `flex-grow-*` - `flex-shrink-*` - `decoration-slice` - `decoration-clone` - `overflow-ellipsis`
2024-11-21 13:09:41 -05:00
- Bring back support for `decoration-clone`, `decoration-slice`, `overflow-ellipsis`, `flex-grow-*`, and `flex-shrink-*` ([#15069](https://github.com/tailwindlabs/tailwindcss/pull/15069))
Fix changelog
2024-11-21 17:52:44 +01:00
- _Upgrade (experimental)_: Include `color` in the form reset snippet ([#15064](https://github.com/tailwindlabs/tailwindcss/pull/15064))
v4.0.0-alpha.36 (#15062) Prepare v4.0.0-alpha.36
2024-11-21 13:57:25 +01:00
## [4.0.0-alpha.36] - 2024-11-21
Improve `in-*` variant migrations (#15054) While testing the codemods on some projects, I noticed some issues with the migration to the new `in-*` variant. One such example is that we checked for `&` at the end, instead of ` &` (the whitespace is significant). This meant that `[figure>&]:my-0` was converted to `in-[figure>]:my-0` which is wrong. In this case, we want to keep it as `[figure>&]:my-0`. Additionally this PR brings back the migration from `group-[]:flex` to `in-[.group]:flex`. If you are using a prefix, then `group-[]:tw-flex` is migrated to `tw:in-[.tw\:group]:flex`. Last but not least, this does some internal refactors to group migrations logically together.
2024-11-20 15:47:26 +01:00
### Added
Add consistent base styles for buttons and form controls (#15036) This PR introduces consistent base styles for buttons and form controls in Tailwind CSS v4. ## Motivation In v3, form elements lack default styles, which can be confusing—especially when certain elements, like a text input without a placeholder or value, are rendered completely invisible on the page. The goal of this change is to provide reasonable default styles for buttons, inputs, selects, and textareas that are (mostly) consistent across all browsers while remaining easy to customize with your own styles. This improvement should make Tailwind more accessible for developers new to the framework and more convenient in scenarios where you need to quickly create demos (e.g., using Tailwind Play). ## Light and dark mode support These styles support both light and dark mode, achieved using the `light-dark()` CSS function. While browser support for this function is still somewhat limited, Lightning CSS transpiles it to a CSS variable-based approach that works in older browsers. For this approach to function correctly, a default `color-scheme` must be set in your CSS (as explained in [the Lightning CSS documentation](https://lightningcss.dev/transpilation.html#light-dark()-color-function)). This PR addresses this requirement by setting the `color-scheme` to `light` on the `html` element in Preflight. <img width="1712" alt="image" src="https://github.com/user-attachments/assets/dba56368-1427-47b3-9419-7c2f6313a944"> <img width="1709" alt="image" src="https://github.com/user-attachments/assets/3d84fcd2-9606-4626-8e03-164a1dce9018"> ## Breaking changes While we don’t expect these changes to significantly impact v3 users upgrading to v4, there may be minor differences for those relying on the simpler v3 styles. For example, Preflight now applies a `border-radius` to buttons and form controls. If you weren’t explicitly setting the border radius to `0` in your project, you’ll need to do so to restore the previous look. Thankfully, reverting to the v3 styles is straightforward—just add the following reset to your CSS: ```css @layer base { input, textarea, select, button { border: 0px solid; border-radius: 0; padding: 0; background-color: transparent; } } ``` It’s worth noting that this reset doesn't touch the `::file-selector-button` styles that were added in this PR. This is because it's not possible to reliably "undo" these styles and restore the original user-agent styles (which is what was used in v3), as these are different in each browser. However, these new styles actually match the defaults in most browsers pretty closely, so hopefully this just won't be an issue. ## Codemod This PR includes a codemod that automatically inserts the above mentioned v3 reset to help avoid breaking changes during the upgrade. The codemod will insert the following CSS: ```css /* In Tailwind CSS v4, basic styles are applied to form elements by default. To maintain compatibility with v3, the following resets have been added: */ @layer base { input, textarea, select, button { border: 0px solid; border-radius: 0; padding: 0; background-color: transparent; } } ``` ## Testing These changes have been tested across a wide range of browsers, including Chrome, Safari, Firefox, Edge, and Opera on macOS and Windows, as well as Safari, Chrome, Firefox, and several lesser-known browsers on iOS and Android. However, some quirks still exist in certain mobile browsers, such as iOS Safari, which adds too much bottom padding below date and time inputs: <img width="1548" alt="Screenshot 2024-11-20 at 3 57 20 PM" src="https://github.com/user-attachments/assets/507c7724-ac41-4634-a2b3-61ac4917ebce"> The only reliable way to address these issues is by applying `appearance: none` to these form controls. However, this felt too opinionated for Preflight, so we’ve opted to leave such adjustments to user-land implementations. --------- Co-authored-by: Jonathan Reinink <jonathan@reinink.ca> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-11-21 11:21:31 +01:00
- Add consistent base styles for buttons and form controls ([#15036](https://github.com/tailwindlabs/tailwindcss/pull/15036))
Improve `in-*` variant migrations (#15054) While testing the codemods on some projects, I noticed some issues with the migration to the new `in-*` variant. One such example is that we checked for `&` at the end, instead of ` &` (the whitespace is significant). This meant that `[figure>&]:my-0` was converted to `in-[figure>]:my-0` which is wrong. In this case, we want to keep it as `[figure>&]:my-0`. Additionally this PR brings back the migration from `group-[]:flex` to `in-[.group]:flex`. If you are using a prefix, then `group-[]:tw-flex` is migrated to `tw:in-[.tw\:group]:flex`. Last but not least, this does some internal refactors to group migrations logically together.
2024-11-20 15:47:26 +01:00
- _Upgrade (experimental)_: Convert `group-[]:flex` to `in-[.group]:flex` ([#15054](https://github.com/tailwindlabs/tailwindcss/pull/15054))
Add consistent base styles for buttons and form controls (#15036) This PR introduces consistent base styles for buttons and form controls in Tailwind CSS v4. ## Motivation In v3, form elements lack default styles, which can be confusing—especially when certain elements, like a text input without a placeholder or value, are rendered completely invisible on the page. The goal of this change is to provide reasonable default styles for buttons, inputs, selects, and textareas that are (mostly) consistent across all browsers while remaining easy to customize with your own styles. This improvement should make Tailwind more accessible for developers new to the framework and more convenient in scenarios where you need to quickly create demos (e.g., using Tailwind Play). ## Light and dark mode support These styles support both light and dark mode, achieved using the `light-dark()` CSS function. While browser support for this function is still somewhat limited, Lightning CSS transpiles it to a CSS variable-based approach that works in older browsers. For this approach to function correctly, a default `color-scheme` must be set in your CSS (as explained in [the Lightning CSS documentation](https://lightningcss.dev/transpilation.html#light-dark()-color-function)). This PR addresses this requirement by setting the `color-scheme` to `light` on the `html` element in Preflight. <img width="1712" alt="image" src="https://github.com/user-attachments/assets/dba56368-1427-47b3-9419-7c2f6313a944"> <img width="1709" alt="image" src="https://github.com/user-attachments/assets/3d84fcd2-9606-4626-8e03-164a1dce9018"> ## Breaking changes While we don’t expect these changes to significantly impact v3 users upgrading to v4, there may be minor differences for those relying on the simpler v3 styles. For example, Preflight now applies a `border-radius` to buttons and form controls. If you weren’t explicitly setting the border radius to `0` in your project, you’ll need to do so to restore the previous look. Thankfully, reverting to the v3 styles is straightforward—just add the following reset to your CSS: ```css @layer base { input, textarea, select, button { border: 0px solid; border-radius: 0; padding: 0; background-color: transparent; } } ``` It’s worth noting that this reset doesn't touch the `::file-selector-button` styles that were added in this PR. This is because it's not possible to reliably "undo" these styles and restore the original user-agent styles (which is what was used in v3), as these are different in each browser. However, these new styles actually match the defaults in most browsers pretty closely, so hopefully this just won't be an issue. ## Codemod This PR includes a codemod that automatically inserts the above mentioned v3 reset to help avoid breaking changes during the upgrade. The codemod will insert the following CSS: ```css /* In Tailwind CSS v4, basic styles are applied to form elements by default. To maintain compatibility with v3, the following resets have been added: */ @layer base { input, textarea, select, button { border: 0px solid; border-radius: 0; padding: 0; background-color: transparent; } } ``` ## Testing These changes have been tested across a wide range of browsers, including Chrome, Safari, Firefox, Edge, and Opera on macOS and Windows, as well as Safari, Chrome, Firefox, and several lesser-known browsers on iOS and Android. However, some quirks still exist in certain mobile browsers, such as iOS Safari, which adds too much bottom padding below date and time inputs: <img width="1548" alt="Screenshot 2024-11-20 at 3 57 20 PM" src="https://github.com/user-attachments/assets/507c7724-ac41-4634-a2b3-61ac4917ebce"> The only reliable way to address these issues is by applying `appearance: none` to these form controls. However, this felt too opinionated for Preflight, so we’ve opted to leave such adjustments to user-land implementations. --------- Co-authored-by: Jonathan Reinink <jonathan@reinink.ca> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-11-21 11:21:31 +01:00
- _Upgrade (experimental)_: Add form reset styles to CSS files for compatibility with v3 ([#15036](https://github.com/tailwindlabs/tailwindcss/pull/15036))
Upgrade: Migrate `ring` to `ring-3` (#15063) This PR adds a codemod for migrating `ring` to `ring-3` if it is safe to do so. # Test plan Added a `ring` to the Catalyst project and then migrated it: <img width="864" alt="image" src="https://github.com/user-attachments/assets/163d9faa-c712-494e-b9d7-106508157915">
2024-11-21 14:20:26 +01:00
- _Upgrade (experimental)_: Migrate `ring` to `ring-3` ([#15063](https://github.com/tailwindlabs/tailwindcss/pull/15063))
Improve `in-*` variant migrations (#15054) While testing the codemods on some projects, I noticed some issues with the migration to the new `in-*` variant. One such example is that we checked for `&` at the end, instead of ` &` (the whitespace is significant). This meant that `[figure>&]:my-0` was converted to `in-[figure>]:my-0` which is wrong. In this case, we want to keep it as `[figure>&]:my-0`. Additionally this PR brings back the migration from `group-[]:flex` to `in-[.group]:flex`. If you are using a prefix, then `group-[]:tw-flex` is migrated to `tw:in-[.tw\:group]:flex`. Last but not least, this does some internal refactors to group migrations logically together.
2024-11-20 15:47:26 +01:00
### Fixed
Update CHANGELOG.md
2024-11-21 09:06:36 -05:00
- _Upgrade (experimental)_: Don't migrate arbitrary variants to `in-*` that use the child combinator instead of the descendant combinator ([#15054](https://github.com/tailwindlabs/tailwindcss/pull/15054))
Prepare v4.0.0-alpha.35 release (#15052)
2024-11-20 12:12:32 +01:00
Inline theme values in `drop-shadow` (#15056) This PR updates the default `drop-shadow-*` values to use a single shadow instead of multiple shadows. This ensures that the usage with `drop-shadow(var(--drop-shadow-xl))` is correct because the `drop-shadow(…)` needs to encode a single drop shadow. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-11-21 07:13:38 -05:00
### Changed
- Use single drop shadow values instead of multiple ([#15056](https://github.com/tailwindlabs/tailwindcss/pull/15056))
Disallow empty arbitrary values (#15055) This PR makes the candidate parser more strict by not allowing empty arbitrary values. Examples that are not allowed anymore: - `bg-[]` — arbitrary value - `bg-()` — arbitrary value, var shorthand - `bg-[length:]` — arbitrary value, with typehint - `bg-(length:)` — arbitrary value, with typehint, var shorthand - `bg-red-500/[]` — arbitrary modifier - `bg-red-500/()` — arbitrary modifier, var shorthand - `data-[]:flex` — arbitrary value for variant - `data-():flex` — arbitrary value for variant, var shorthand - `group-visible/[]:flex` — arbitrary modifier for variant - `group-visible/():flex` — arbitrary modifier for variant, var shorthand If you are trying to trick the parser by injecting some spaces like this: - `bg-[_]` Then that is also not allowed.
2024-11-21 13:47:13 +01:00
- Do not parse invalid candidates with empty arbitrary values ([#15055](https://github.com/tailwindlabs/tailwindcss/pull/15055))
Inline theme values in `drop-shadow` (#15056) This PR updates the default `drop-shadow-*` values to use a single shadow instead of multiple shadows. This ensures that the usage with `drop-shadow(var(--drop-shadow-xl))` is correct because the `drop-shadow(…)` needs to encode a single drop shadow. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-11-21 07:13:38 -05:00
Prepare v4.0.0-alpha.35 release (#15052)
2024-11-20 12:12:32 +01:00
## [4.0.0-alpha.35] - 2024-11-20
restructure changelog Re-ordered it to be: - Added - Fixed - Changed
2024-11-18 13:54:43 +01:00
### Added
- Reintroduce `max-w-screen-*` utilities that read from the `--breakpoint` namespace as deprecated utilities ([#15013](https://github.com/tailwindlabs/tailwindcss/pull/15013))
Re-introduce automatic var injection shorthand (#15020) This PR re-introduces the automatic var injection feature. For some backstory, we used to support classes such as `bg-[--my-color]` that resolved as-if you wrote `bg-[var(--my-color)]`. The is issue is that some newer CSS properties accepts dashed-idents (without the `var(…)`). This means that some properties accept `view-timeline-name: --my-name;` (see: https://developer.mozilla.org/en-US/docs/Web/CSS/view-timeline-name). To make this a tiny bit worse, these properties _also_ accept `var(--my-name-reference)` where the variable `--my-name-reference` could reference a dashed-ident such as `--my-name`. This makes the `bg-[--my-color]` ambiguous because we don't know if you want `var(--my-color)` or `--my-color`. With this PR, we bring back the automatic var injection feature as syntactic sugar, but we use a different syntax to avoid the ambiguity. Instead of `bg-[--my-color]`, you can now write `bg-(--my-color)` to get the same effect as `bg-[var(--my-color)]`. This also applies to modifiers, so `bg-red-500/[var(--my-opacity)]` can be written as `bg-red-500/(--my-opacity)`. To go full circle, you can rewrite `bg-[var(--my-color)]/[var(--my-opacity)]` as `bg-(--my-color)/(--my-opacity)`. --- This is implemented as syntactical sugar at the parsing stage and handled when re-printing. Internally the system (and every plugin) still see the proper `var(--my-color)` value. Since this is also handled during printing of the candidate, codemods don't need to be changed but they will provide the newly updated syntax. E.g.: running this on the Catalyst codebase, you'll now see changes like this: <img width="542" alt="image" src="https://github.com/user-attachments/assets/8f0e26f8-f4c9-4cdc-9f28-52307c38610e"> Whereas before we converted this to the much longer `min-w-[var(--button-width)]`. --- Additionally, this required some changes to the Oxide scanner to make sure that `(` and `)` are valid characters for arbitrary-like values. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-18 15:47:48 +01:00
- Support using CSS variables as arbitrary values without `var(…)` by using parentheses instead of square brackets (e.g. `bg-(--my-color)`) ([#15020](https://github.com/tailwindlabs/tailwindcss/pull/15020))
Add new `in-*` variant (#15025) This PR adds a new `in-*` variant that allows you to apply utilities when you are in a certain selector. While doing research for codemods, we notice that some people use `group-[]:flex` (yep, the arbitrary value is empty…). The idea behind is that people want to know if you are in a `.group` or not. Similarly, some people use `group-[]/name:flex` to know when you are in a `.group/name` class or not. This new `in-*` variant allows you to do that without any hacks. If you want to check whether you are inside of a `p` tag, then you can write `in-[p]:flex`. If you want to check that you are inside of a `.group`, you can write `in-[.group]`. This variant is also a compound variant, which means that you can write `in-data-visible:flex` which generates the following CSS: ```css :where([data-visible]) .in-data-visible\:flex { display: flex; } ``` This variant also compounds with `not-*`, for example: `not-in-[.group]:flex`. Additionally, this PR also includes a codemod to convert `group-[]:flex` to `in-[.group]:flex`. --- This was proposed before for v3 in #13912 --------- Co-authored-by: Eloy Espinaco <eloyesp@gmail.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-11-18 16:28:16 +01:00
- Add new `in-*` variant ([#15025](https://github.com/tailwindlabs/tailwindcss/pull/15025))
Bundle core plugins with the standalone build (#15028) Closes #15012 We do not have replacements for these plugins _just yet_. In order to increase compatibility with setups that rely on some of these legacy plugins, this PR bundles `@tailwindcss/forms`, `@tailwindcss/typography`, and `@tailwindcss/aspect-ratio` (after https://github.com/tailwindlabs/tailwindcss/pull/15029) with the standalone build now. In comparison to v3, this omits the `@tailwindcss/container-queries` plugin since is not a first-party feature of Tailwind CSS v4. ## Test Plan Added an integration test. I also tested this by running the standalone binary in a temporary folder with as simple input css: ```css @import "tailwindcss"; @plugin "@tailwindcss/typography"; ```
2024-11-19 16:19:08 +01:00
- Bundle `@tailwindcss/forms`, `@tailwindcss/typography`, and `@tailwindcss/aspect-ratio` with the standalone CLI ([#15028](https://github.com/tailwindlabs/tailwindcss/pull/15028))
Support complex `addUtilities()` configs (#15029) This PR adds support for complex `addUtilities()` configuration objects that use child combinators and other features. For example, in v3 it was possible to add a utility that changes the behavior of all children of the utility class node by doing something like this: ```ts addUtilities({ '.red-children > *': { color: 'red', }, }); ``` This is a pattern that was used by first-party plugins like `@tailwindcss/aspect-ratio` but that we never made working in v4, since it requires parsing the selector and properly extracting all utility candidates. While working on the codemod that can transform `@layer utilities` scoped declarations like the above, we found out a pretty neat heuristics on how to migrate these cases. We're basically finding all class selectors and replace them with `&`. Then we create a nested CSS structure like this: ```css .red-children { & > * { color: red; } } ``` Due to first party support for nesting, this works as expected in v4. ## Test Plan We added unit tests to ensure the rewriting works in some edge cases. Furthermore we added an integration test running the `@tailwindcss/aspect-ratio` plugin. We've also installed the tarballs in the Remix example from the [playgrounds](https://github.com/philipp-spiess/tailwindcss-playgrounds) and ensure we can use the `@tailwindcss/aspect-ratio` plugin just like we could in v3: <img width="2560" alt="Screenshot 2024-11-18 at 13 44 52" src="https://github.com/user-attachments/assets/31889131-fad0-4c37-b574-cfac2b99f786"> --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-11-19 15:52:06 +01:00
- Allow `addUtilities()` and `addComponents()` to work with child combinators and other complex selectors ([#15029](https://github.com/tailwindlabs/tailwindcss/pull/15029))
Implement compat for `<alpha-value>` from v3 (#15033) This implements backwards compatibility for colors that use the old `<alpha-value>` feature from v3. We can do this by replacing `<alpha-value>` with `1` because we use `color-mix` to actually apply opacity modifiers in v4.
2024-11-19 10:01:45 -05:00
- Support colors that use `<alpha-value>` in JS configs and plugins ([#15033](https://github.com/tailwindlabs/tailwindcss/pull/15033))
Add new `transition-discrete` and `transition-normal` utilities (#15051) This PR adds two new utilities for the `transition-behavior` property: | Name | Definition | | --- | --- | | `transition-discrete` | `transition-behavior: allow-discrete` | | `transition-normal` | `transition-behavior: normal` | # Test plan Not a lot too test here, but verified in the browser that these properties generate correct CSS: <img width="301" alt="image" src="https://github.com/user-attachments/assets/db314750-e129-47d6-b605-d3b367ae81a4"> <img width="253" alt="image" src="https://github.com/user-attachments/assets/24da5a6e-0b6a-48aa-a042-5ec19773bc6b"> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-20 11:39:16 +01:00
- Add new `transition-discrete` and `transition-normal` utilities for `transition-behavior` ([#15051](https://github.com/tailwindlabs/tailwindcss/pull/15051))
Migrate `[&>*]` to `*` variant, and `[&_*]` to `**` variant (#15022) This PR adds a migration to convert the `[&>*]` variant to the `*` variant. Additionally this PR also converts the `[&_*]` variant to the `**` variant. We use this variant in Catalyst for example, and now that the specificity is the same as `*`, we can use the more modern syntax instead. # Test plan: Running this on Catalyst results in a diff like: <img width="615" alt="image" src="https://github.com/user-attachments/assets/f384885e-cae1-4b6b-80ab-85f76fa89a33"> <img width="833" alt="image" src="https://github.com/user-attachments/assets/8a185e1d-0f1b-4fe6-9e06-ca7597534398"> Note: the swapped order of variants is another codemod at work --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-18 16:19:15 +01:00
- _Upgrade (experimental)_: Migrate `[&>*]` to the `*` variant ([#15022](https://github.com/tailwindlabs/tailwindcss/pull/15022))
- _Upgrade (experimental)_: Migrate `[&_*]` to the `**` variant ([#15022](https://github.com/tailwindlabs/tailwindcss/pull/15022))
Upgrade: Error when project is already using Tailwind CSS v4 (#15015) In some local testing we ran the `@tailwindcss/upgrade` command twice in a row. It would be great to get some feedback that this is not working, so this PR now checks if it can resolve the installed version of `tailwindcss` and if it can, it requires it to be < 4 (you can bypass this check with `--force`). --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-11-19 15:53:02 +01:00
- _Upgrade (experimental)_: Warn when trying to migrating a project that is not on Tailwind CSS v3 ([#15015](https://github.com/tailwindlabs/tailwindcss/pull/15015))
Implement compat for `<alpha-value>` from v3 (#15033) This implements backwards compatibility for colors that use the old `<alpha-value>` feature from v3. We can do this by replacing `<alpha-value>` with `1` because we use `color-mix` to actually apply opacity modifiers in v4.
2024-11-19 10:01:45 -05:00
- _Upgrade (experimental)_: Migrate colors that use `<alpha-value>` in JS configs ([#15033](https://github.com/tailwindlabs/tailwindcss/pull/15033))
restructure changelog Re-ordered it to be: - Added - Fixed - Changed
2024-11-18 13:54:43 +01:00
Make `flex` a static utility (#15014) This PR makes `flex` a static utility, which also means that it is located near the other static `display` utilities. This is possible because we changed how `parseCandidate` returns an array of utilities instead of a single utility. This makes the code more consistent and a bit easier to understand. Bonus: turns out that `flex` was never suggested to intellisense, but now it is!
2024-11-15 18:02:57 +01:00
### Fixed
- Ensure `flex` is suggested ([#15014](https://github.com/tailwindlabs/tailwindcss/pull/15014))
Use `resolveJsId` when resolving `tailwindcss/package.json` (#15041) This PR uses the `enhanced-resolve` instead of `createRequire(…).resolve` which improves the usability when running the upgrade tool locally using Bun. While testing, we also noticed that it is not possible to use a `cjs`-only plugin inside of an `esm` project. It was also not possible to use an `esm`-only plugin inside of a `cjs` project. # Test plan We added integration tests in both the CLI (the CLI is an mjs project) and in the PostCSS (where we can configure a `cjs` and `esm` PostCSS config) integration tests where we created an `esm` and `cjs` based project with 4 plugins (`cjs`-only, `esm`-only, and TypeScript based plugins: `cts`-only and `mts`-only).
2024-11-19 18:39:49 +01:00
- Improve module resolution for `cjs`-only and `esm`-only plugins ([#15041](https://github.com/tailwindlabs/tailwindcss/pull/15041))
Update CHANGELOG.md
2024-11-19 20:37:17 -05:00
- Perform `calc(…)` on just values for negative `-rotate-*` utilities, not on the `rotateX/Y/Z(…)` functions themselves ([#15044](https://github.com/tailwindlabs/tailwindcss/pull/15044))
Tweak changelog
2024-11-16 11:46:03 -05:00
- _Upgrade (experimental)_: Resolve imports when specifying a CSS entry point on the command-line ([#15010](https://github.com/tailwindlabs/tailwindcss/pull/15010))
Improve multi-root `@config` linking (#15001) This PR improves the discoverability of Tailwind config files when we are trying to link them to your CSS files. When you have multiple "root" CSS files in your project, and if they don't include an `@config` directive, then we tried to find the Tailwind config file in your current working directory. This means that if you run the upgrade command from the root of your project, and you have a nested folder with a separate Tailwind setup, then the nested CSS file would link to the root Tailwind config file. Visually, you can think of it like this: ``` . ├── admin │   ├── src │   │   └── styles │   │   └── index.css <-- This will be linked to (1) │   └── tailwind.config.js (2) ├── src │   └── styles │   └── index.css <-- This will be linked to (1) └── tailwind.config.js (1) ``` If you run the upgrade command from the root of your project, then the `/src/styles/index.css` will be linked to `/tailwind.config.js` which is what we expect. But `/admin/src/styles/index.css` will _also_ be linked to `/tailwind.config.js` With this PR we improve this behavior by looking at the CSS file, and crawling up the parent tree. This mens that the new behavior looks like this: ``` . ├── admin │   ├── src │   │   └── styles │   │   └── index.css <-- This will be linked to (2) │   └── tailwind.config.js (2) ├── src │   └── styles │   └── index.css <-- This will be linked to (1) └── tailwind.config.js (1) ``` Now `/src/styles/index.css` will be linked to `/tailwind.config.js`, and `/admin/src/styles/index.css` will be linked to `/admin/tailwind.config.js`. When we discover the Tailwind config file, we will also print a message to the user to let them know which CSS file is linked to which Tailwind config file. This should be a safe improvement because if your Tailwind config file had a different name, or if it lived in a sibling folder then Tailwind wouldn't find it either and you already required a `@config "…";` directive in your CSS file to point to the correct file. In the unlikely event that it turns out that 2 (or more) CSS files resolve to the same to the same Tailwind config file, then an upgrade might not be safe and some manual intervention might be needed. In this case, we will show a warning about this. <img width="1552" alt="image" src="https://github.com/user-attachments/assets/7a1ad11d-18c5-4b7d-9a02-14f0116ae955"> Test plan: --- - Added an integration test that properly links the nearest Tailwind config file by looking up the tree - Added an integration test that resolves 2 or more CSS files to the same config file, resulting in an error where manual intervention is needed - Ran it on the Tailwind UI codebase Running this on Tailwind UI's codebase it looks like this: <img width="1552" alt="image" src="https://github.com/user-attachments/assets/21785428-5e0d-47f7-80ec-dab497f58784"> --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-11-18 17:43:44 +01:00
- _Upgrade (experimental)_: Resolve nearest Tailwind config file when CSS file does not contain `@config` ([#15001](https://github.com/tailwindlabs/tailwindcss/pull/15001))
Upgrade: don't show error during upgrade when analyzing external URL import (#15040) This PR improves the output of the upgrade tool when we are handling imports and the import happens to be an external URL. External URLs shouldn't and can't be upgraded, so printing an error message doesn't help the user. Additionally, if an `@import` is using the `url(…)` function, then we skip over it and continue with the rest of the imports. | Before | After | | --- | --- | | <img width="1455" alt="image" src="https://github.com/user-attachments/assets/1ee00ea4-68e1-4252-b1cf-30a04f608b75"> | <img width="1455" alt="image" src="https://github.com/user-attachments/assets/da1f3eaf-dedb-4b1b-bf73-93bdfee65759"> | Running this on github.com/parcel-bundler/parcel | Before | After | | -- | -- | | <img width="1552" alt="image" src="https://github.com/user-attachments/assets/89987444-8008-4edd-a907-6ad9276a86a0"> | <img width="1552" alt="image" src="https://github.com/user-attachments/assets/cc2a34ae-ef17-4ad1-b06d-097874400b4d"> |
2024-11-19 15:52:30 +01:00
- _Upgrade (experimental)_: Improve output when CSS imports can not be found ([#15038](https://github.com/tailwindlabs/tailwindcss/pull/15038))
- _Upgrade (experimental)_: Ignore analyzing imports with external URLs (e.g.: `@import "https://fonts.google.com"`) ([#15040](https://github.com/tailwindlabs/tailwindcss/pull/15040))
- _Upgrade (experimental)_: Ignore analyzing imports with `url(…)` (e.g.: `@import url("https://fonts.google.com")`) ([#15040](https://github.com/tailwindlabs/tailwindcss/pull/15040))
Use `resolveJsId` when resolving `tailwindcss/package.json` (#15041) This PR uses the `enhanced-resolve` instead of `createRequire(…).resolve` which improves the usability when running the upgrade tool locally using Bun. While testing, we also noticed that it is not possible to use a `cjs`-only plugin inside of an `esm` project. It was also not possible to use an `esm`-only plugin inside of a `cjs` project. # Test plan We added integration tests in both the CLI (the CLI is an mjs project) and in the PostCSS (where we can configure a `cjs` and `esm` PostCSS config) integration tests where we created an `esm` and `cjs` based project with 4 plugins (`cjs`-only, `esm`-only, and TypeScript based plugins: `cts`-only and `mts`-only).
2024-11-19 18:39:49 +01:00
- _Upgrade (experimental)_: Use `resolveJsId` when resolving `tailwindcss/package.json` ([#15041](https://github.com/tailwindlabs/tailwindcss/pull/15041))
Improve root file detection (#15048) This PR fixes an issue where the Tailwind root file detection was wrong. Whenever a CSS file contains any of the `@tailwind` directives or an `@import` to any of the Tailwind files, the file is considered a Tailwind root file. If multiple CSS files are part of the same tree, then we make the nearest common parent the root file. This root file will be the file where we add `@config` and/or inject other changes during the migration process. However, if your folder structure looked like this: ```css /* index.css */ @import "./base.css"; @import "./typography.css"; @import "tailwindcss/components"; /* This makes index.css a root file */ @import "./utilities.css"; /* base.css */ @tailwind base; /* This makes base.css a root file */ /* utilities.css */ @tailwind utilities; /* This makes utilities.css a root file */ ``` Then we computed that `index.css` nad `base.css` were considered root files even though they belong to the same tree (because `base.css` is imported by `index.css`). This PR fixes that behaviour by essentially being less smart, and just checking again if any sheets are part of the same tree. # Test plan: Added an integration test that covers this scenario and fails before the fix. Also ran it on our tailwindcss.com codebase. | Before | After | | --- | --- | | <img width="1072" alt="image" src="https://github.com/user-attachments/assets/8ee99a59-335e-4221-b368-a8cd81e85191"> | <img width="1072" alt="image" src="https://github.com/user-attachments/assets/fe5acae4-d3fc-43a4-bd31-eee768a3a6a5"> | (Yes, I know the migration still fails, but that's a different issue.)
2024-11-20 00:20:40 +01:00
- _Upgrade (experimental)_: Ensure children of Tailwind root file are not considered Tailwind root files ([#15048](https://github.com/tailwindlabs/tailwindcss/pull/15048))
Make `flex` a static utility (#15014) This PR makes `flex` a static utility, which also means that it is located near the other static `display` utilities. This is possible because we changed how `parseCandidate` returns an array of utilities instead of a single utility. This makes the code more consistent and a bit easier to understand. Bonus: turns out that `flex` was never suggested to intellisense, but now it is!
2024-11-15 18:02:57 +01:00
Bring back named opacity support for color opacity modifiers (#15009) This PR reverts https://github.com/tailwindlabs/tailwindcss/pull/14278 to bring back support for using named opacity values in color opacity modifiers: ```css @theme { --opacity-myOpacity: 50%; } ``` ```html <div class="bg-red-500/myOpacity"></div> ``` We briefly discuss to restructure the code so that we avoid adding a `theme` argument to the call sites but I do still prefer the current approach for the following reasons: The way to avoid this is to a) put something in either the `Theme` class scope, where it feels grossly out of place, or b) put it into the shared closure in the utilities file which is already very large and hard to reason. Furthermore, there's a second call site in the compile function where we would need to duplicate the namespace lookup. Every caller of the current `asColor` value already has access to the `Theme` so passing that as an argument seems like the least intrusive way. ## Test Plan Brought back the unit tests but I also tested it with the Vite extension: <img width="744" alt="Screenshot 2024-11-15 at 11 15 05" src="https://github.com/user-attachments/assets/63923b80-767e-4104-b7eb-f71fc815b51e"> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-15 15:43:12 +01:00
### Changed
- Bring back support for color opacity modifiers to read from `--opacity-*` theme values ([#14278](https://github.com/tailwindlabs/tailwindcss/pull/14278))
Prepare v4.0.0-alpha.34 (#15002)
2024-11-14 18:23:40 +01:00
## [4.0.0-alpha.34] - 2024-11-14
Support opacity values in increments of 0.25 by default (#14980) This PR updates all areas in the framework that accept opacity values (`opacity-*`, `backdrop-opacity-*`, `bg-red-500/*`, etc.) to accept fractional values in increments of 0.25 instead of just whole numbers. We noticed we use values like `2.5` and `7.5` pretty regularly in our templates and don't see why those should be treated as any more "weird" than something like `opacity-63` which we already support, so baking this in to core. IntelliSense will still only suggest values in increments of `5` like it did before. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-12 14:04:13 -05:00
### Added
- Support opacity values in increments of `0.25` by default ([#14980](https://github.com/tailwindlabs/tailwindcss/pull/14980))
Support specifying gradient interpolation method via modifier (#14984) This PR adds support for specifying a color interpolation method for all gradient utilities using a modifier: ```html <div class="bg-linear-to-r/oklab"> ``` Supported bare values are any valid color space keyword, as well as the special keywords `shorter`, `longer`, `increasing`, and `decreasing`, which are shortcuts for `in oklch {keyword} hue`. Arbitrary values are also supported and are used as-is, so the `in` keyword is not automatically included for you: ```html <div class="bg-linear-to-r/[in_oklab]"> ``` Modifiers are not supported when using arbitrary values for the actual gradient, as it's expected that your arbitrary gradient value contain all of the details you want in your gradient: ```html <!-- Won't work --> <div class="bg-linear-[to_right]/oklab"> <!-- Do this --> <div class="bg-linear-[to_right_in_oklab]"> ``` Resolves https://github.com/tailwindlabs/tailwindcss/issues/14955, but it may still be wise to make `oklab` the default since I do sort of agree with the poster there that most people probably expect a gradient between two colors to sort of just "fade" between them rather than interpolate between them around the color wheel. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-13 10:18:59 -05:00
- Support specifying the color interpolation method for gradients via modifier ([#14984](https://github.com/tailwindlabs/tailwindcss/pull/14984))
Add codemod and interop for legacy `container` component configu (#14999) This PR adds support for handling v3 [`container` customizations ](https://tailwindcss.com/docs/container#customizing). This is done by adding a custom utility to extend the core `container` utility. A concrete example can be taken from the added integration test. ### Input ```ts /** @type {import('tailwindcss').Config} */ export default { content: ['./src/**/*.html'], theme: { container: { center: true, padding: { DEFAULT: '2rem', '2xl': '4rem', }, screens: { md: '48rem', // Matches a default --breakpoint xl: '1280px', '2xl': '1536px', }, }, }, } ``` ### Output ```css @import "tailwindcss"; @utility container { margin-inline: auto; padding-inline: 2rem; @media (width >= theme(--breakpoint-sm)) { max-width: none; } @media (width >= 48rem) { max-width: 48rem; } @media (width >= 1280px) { max-width: 1280px; } @media (width >= 1536px) { max-width: 1536px; padding-inline: 4rem; } } ```` ## Test Plan This PR adds extensive tests to the compat layer as part of unit tests. Additionally it does at a test to the codemod setup that shows that the right `@utility` code is generated. Furthermore I compared the implementation against v3 on both the compat layer and the custom `@utility`: https://github.com/user-attachments/assets/44d6cbfb-4861-4225-9593-602b719f628f
2024-11-14 18:19:21 +01:00
- Reintroduce `container` component as a utility ([#14993](https://github.com/tailwindlabs/tailwindcss/pull/14993), [#14999](https://github.com/tailwindlabs/tailwindcss/pull/14999))
- _Upgrade (experimental)_: Migrate `container` component configuration to CSS ([#14999](https://github.com/tailwindlabs/tailwindcss/pull/14999))
Prepare v4.0.0-alpha.33 release (#14967) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-11 20:28:41 -05:00
Vite: Don't track candidate changes for Svelte `<style>` tags (#14981) Closes #14965 This PR changes the way we register Tailwind CSS as a Svelte preprocessor when using the Vite plugin. The idea is to reduce the bookkeeping for interacting with CSS inside `<style>` tags so that we have a more consistent behavior and make sure the Svelte-specific post-processing (e.g. local class mangling) works as expected. Prior to this change, we were running Tailwind CSS as a Svelte preprocessor and then we would transform the file again when necessary inside the Vite `transform` hook. This is necessary to have the right list of candidates when we build the final CSS, but it did cause some situation to not apply the Svelte post-processors anymore. The repro for this seemed to indicate a timing specific issue and I did notice that specifically the code where we invalidate modules in Vite would cause unexpected processing orders. We do, however, not officially support rendering utilities (`@tailwind utilities;`) inside `<style>` tag. This is because the `<style>` block is scoped by default and emitting utilities will always include utilities for all classes in your whole project. For this case, we highly recommend creating as separate `.css` file and importing it explicitly. With this limitation in place, the additional bookkeeping where we need to invalidate modules because the candidate list has changed is no longer necessary and removing it allows us to reduce the complexity of the Svelte integration. ## Test Plan https://github.com/user-attachments/assets/32c8e91f-ab21-48c6-aeaf-2582273b9bac Not seen in the test plan above I also tested the `pnpm build --watch` step of the Vite project. This does require the `pnpm preview` server to restart but the build artifact are updated as expected.
2024-11-13 16:42:49 +01:00
### Fixed
- Ensure that CSS inside Svelte `<style>` blocks always run the expected Svelte processors when using the Vite extension ([#14981](https://github.com/tailwindlabs/tailwindcss/pull/14981))
Do not migrate legacy classes with custom values (#14976) This PR fixes an issue where we migrated classes such as `rounded` to `rounded-sm` (see: https://github.com/tailwindlabs/tailwindcss/pull/14875) However, if you override the values in your `tailwind.config.js` file, then the migration might not be correct. This PR makes sure to only migrate the classes if you haven't overridden the values in your `tailwind.config.js` file. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-14 11:31:05 +01:00
- _Upgrade (experimental)_: Ensure it's safe to migrate `blur`, `rounded`, or `shadow` ([#14979](https://github.com/tailwindlabs/tailwindcss/pull/14979))
- _Upgrade (experimental)_: Do not rename classes using custom defined theme values ([#14976](https://github.com/tailwindlabs/tailwindcss/pull/14976))
Ensure `@config` is injected in common ancestor sheet (#14989) This PR fixes an issue where an `@config` was injected in a strange location if you have multiple CSS files with Tailwind directives. Let's say you have this setup: ```css /* ./src/index.css */ @import "./tailwind-setup.css"; /* ./src/tailwind-setup.css */ @import "./base.css"; @import "./components.css"; @import "./utilities.css"; /* ./src/base.css */ @tailwind base; /* ./src/components.css */ @tailwind components; /* ./src/utilities.css */ @tailwind utilities; ``` In this case, `base.css`, `components.css`, and `utilities.css` are all considered Tailwind roots because they contain Tailwind directives or imports. Since there are multiple roots, the nearest common ancestor should become the tailwind root (where `@config` is injected). In this case, the nearest common ancestor is `tailwind-setup.css` (not `index.css` because that's further away). Before this change, we find the common ancestor between `base.css` and `components.css` which would be `index.css` instead of `tailwind-setup.css`. In a next iteration, we compare `index.css` with `utilities.css` and find that there is no common ancestor (because the `index.css` file has no parents). This resulted in the `@config` being injected in `index.css` and in `utilities.css`. Continuing with the rest of the migrations, we migrate the `index.css`'s `@config` away, but we didn't migrate the `@config` from `utilities.css`. With this PR, we don't even have the `@config` in the `utilities.css` file anymore. Test plan --- 1. Added an integration test with a non-migrateable config file to ensure that the `@config` is injected in the correct file. 2. Added an integration test with a migrateable config file to ensure that the CSS config is injected in the correct file. h/t @philipp-spiess 3. Ran the upgrade on the https://commit.tailwindui.com project and ensured that 1. The `@config` does not exist in the `utilities.css` file (this was the first bug we solved) 2. The `@config` is replaced in the `tailwind.css` file correctly. <img width="592" alt="image" src="https://github.com/user-attachments/assets/02e3f6ea-a85d-46c2-ac93-09f34ac4a4b8"> <img width="573" alt="image" src="https://github.com/user-attachments/assets/e372eb5f-5732-4052-ab39-096ba7970ff6">
2024-11-14 11:48:31 +01:00
- _Upgrade (experimental)_: Ensure `@config` is injected in nearest common ancestor stylesheet ([#14989](https://github.com/tailwindlabs/tailwindcss/pull/14989))
Add missing `layer(…)` to imports above Tailwind directives (#14982) This PR fixes an issue where imports above Tailwind directives didn't get a `layer(…)` argument. Given this CSS: ```css @import "./typography.css"; @tailwind base; @tailwind components; @tailwind utilities; ``` It was migrated to: ```css @import "./typography.css"; @import "tailwindcss"; ``` But to ensure that the typography styles end up in the correct location, it requires the `layer(…)` argument. This PR now migrates the input to: ```css @import "./typography.css" layer(base); @import "tailwindcss"; ``` Test plan: --- Added an integration test where an import receives the `layer(…)`, but an import that eventually contains `@utility` does not receive the `layer(…)` argument. This is necessary otherwise the `@utility` will be nested when we are processing the inlined CSS. Running this on the Commit template, we do have a proper `layer(…)` <img width="585" alt="image" src="https://github.com/user-attachments/assets/538055e6-a9ac-490d-981f-41065a6b59f9">
2024-11-14 18:05:14 +01:00
- _Upgrade (experimental)_: Add missing `layer(…)` to imports above Tailwind directives ([#14982](https://github.com/tailwindlabs/tailwindcss/pull/14982))
Vite: Don't track candidate changes for Svelte `<style>` tags (#14981) Closes #14965 This PR changes the way we register Tailwind CSS as a Svelte preprocessor when using the Vite plugin. The idea is to reduce the bookkeeping for interacting with CSS inside `<style>` tags so that we have a more consistent behavior and make sure the Svelte-specific post-processing (e.g. local class mangling) works as expected. Prior to this change, we were running Tailwind CSS as a Svelte preprocessor and then we would transform the file again when necessary inside the Vite `transform` hook. This is necessary to have the right list of candidates when we build the final CSS, but it did cause some situation to not apply the Svelte post-processors anymore. The repro for this seemed to indicate a timing specific issue and I did notice that specifically the code where we invalidate modules in Vite would cause unexpected processing orders. We do, however, not officially support rendering utilities (`@tailwind utilities;`) inside `<style>` tag. This is because the `<style>` block is scoped by default and emitting utilities will always include utilities for all classes in your whole project. For this case, we highly recommend creating as separate `.css` file and importing it explicitly. With this limitation in place, the additional bookkeeping where we need to invalidate modules because the candidate list has changed is no longer necessary and removing it allows us to reduce the complexity of the Svelte integration. ## Test Plan https://github.com/user-attachments/assets/32c8e91f-ab21-48c6-aeaf-2582273b9bac Not seen in the test plan above I also tested the `pnpm build --watch` step of the Vite project. This does require the `pnpm preview` server to restart but the build artifact are updated as expected.
2024-11-13 16:42:49 +01:00
Prepare v4.0.0-alpha.33 release (#14967) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-11 20:28:41 -05:00
## [4.0.0-alpha.33] - 2024-11-11
Don't reset horizontal padding on date/time pseudo-elements (#14959) Turns out all of these date/time pseudo elements have a bit of horizontal padding on them that we don't want to throw away when fixing the height issue, so this PR updates our reset to only remove vertical padding. Here's a demo showing the difference, test in Safari or Chrome to see the difference in horizontal spacing: https://play.tailwindcss.com/Opwa7pkDFP?file=css --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-11 13:11:28 -05:00
### Fixed
- Don't reset horizontal padding on date/time pseudo-elements ([#14959](https://github.com/tailwindlabs/tailwindcss/pull/14959))
Don't create bare spacing utilities with invalid multiples (#14962) Closes #14960 When we moved to the `--spacing` multiples scale, we seemingly overlooked a bail that caused us to use non-numerical values as a spacing multiple. This caused the `-translate-x-full` and `-translate-y-full` utilities to treat `full` as a valid multiple in our spacing scale and created invalid CSS: ```css .-translate-x-full { --tw-translate-x: calc(var(--spacing) * -x-full); --tw-translate-y: calc(var(--spacing) * -x-full); translate: var(--tw-translate-x) var(--tw-translate-y); } ``` ## Test plan I reproduced the issue in our Vite playground and then created a failing test case. It requires a `--spacing` `@theme` variable to be defined so I've added this as a test case now in the unit tests. I also audited all places that are using `calc()` and wrapping some numbers. In doing so I found a few other broken cases: - `-translate-x-full` - `-translate-y-full` - `-space-x-full` - `-space-y-full` - `-inset-full` I validated that the fix indeed works and no longer creates broken CSS definitions for these cases: <kbd><img width="1405" alt="Screenshot 2024-11-11 at 19 33 51" src="https://github.com/user-attachments/assets/99072112-9ed4-4456-bad8-5679679e7198"></kbd> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-11 19:45:37 +01:00
- Don't emit `calc()` with invalid values for bare values that aren't integers in spacing utilities ([#14962](https://github.com/tailwindlabs/tailwindcss/pull/14962))
Support spacing scale as line-height modifiers (#14966) This PR fixes an issue where utilities like `text-sm/6` failed to include a line-height because `--leading-6` is no longer an explicitly defined theme value by default. I don't really love seeing `calc(var(--spacing) * 9)` in the output here admittedly and it's making me consider again if we should register this variable as `inline` so we see the final computed value in the CSS, but if we do that it's something we should change in a separate PR. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-11 16:49:34 -05:00
- Ensure spacing scale values work as line-height modifiers ([#14966](https://github.com/tailwindlabs/tailwindcss/pull/14966))
Prepare v4.0.0-alpha.32 (#14954) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-11 11:05:22 -05:00
## [4.0.0-alpha.32] - 2024-11-11
Migrate `grid-cols-[subgrid]` and `grid-rows-[subgrid]` to `grid-cols-subgrid` and `grid-rows-subgrid` (#14840) This PR adds a migration to convert `grid-cols-[subgrid]` to `grid-cols-subgrid` and `grid-rows-[subgrid]` to `grid-rows-subgrid`.
2024-11-01 21:25:53 +01:00
### Added
Replace default explicit spacing scale with multiplier system (#14857) This PR replaces the default spacing scale (`--spacing-*`) with a generative system based on a default spacing _unit_. Instead of the default theme containing values like `--spacing-4`, `--spacing-6`, `--spacing-8`, etc., instead we just define a single `--spacing` value: ```css @theme { --spacing: 0.25rem; } ``` Utilities like `px-4` are derived from this unit by multiplying it by the value in the utility (4 in this case): ```css .px-4 { padding-inline: calc(var(--spacing) * 4); } ``` The biggest consequence of this change is that every value is available now, rather than just the explicitly configured values. This means utilities like `px-42` will work now, whereas prior to this PR only `px-40` and `px-44` were valid utilities. I personally found it very difficult to know which values actually existed at the higher end of the scale without IntelliSense, and in practice even when working with a skilled designer like [Steve](https://x.com/steveschoger) 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. This PR allows you to use any whole number, as well as decimal numbers that are multiples of `0.25` to ensure classes like `px-1.5` continue to work. While this means you can now technically do things like `pt-97.25`, I think the presence of the fractional value will be enough of a signal to developers that they are doing something a little unusual, and they can use their judgment as to whether they are making the right decision or not. I'll update this PR with a lot more detail when I have a chance, as there are a few other things to explain like: - Unifying all of the values for width/min-width/max-width/height/min-height/max-height utilities - Deriving numeric line-height values from the spacing multiplier instead of a separate line-height scale - Using `--spacing: initial` to disable the multiplier - How you can still use an explicit spacing scale and ignore this change - How we plan to use IntelliSense to surface a more curated set of spacing values even if smaller increments work when you type them explicitly --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-05 15:22:50 -05:00
- Support derived spacing scales based on a single `--spacing` theme value ([#14857](https://github.com/tailwindlabs/tailwindcss/pull/14857))
- Add `svh`, `dvh`, `svw`, `dvw`, and `auto` values to all width/height/size utilities ([#14857](https://github.com/tailwindlabs/tailwindcss/pull/14857))
Add new `**` variant (#14903) This PR adds a new `**` variant to target any level of children. This is very similar to the `*` variant, the big difference is that: - `*` applies to direct children only - `**` applies to any level of children Thought of this because of all the recent work we did around globs. So a good analogy for this is glob syntax where you have the exact same difference. `*.html` vs `**/*.html`.
2024-11-07 16:48:49 +01:00
- Add new `**` variant ([#14903](https://github.com/tailwindlabs/tailwindcss/pull/14903))
Vite: Support Tailwind in Svelte <style> blocks (#14151) Closes #13305 This PR adds registers a Svelte preprocessor, used by the Svelte Vite plugin, to run Tailwind CSS for styles inside the `<style>` block, this enables users to use Tailwind CSS features like `@apply` from inside Svelte components: ```svelte <script> let name = 'world' </script> <h1 class="foo underline">Hello {name}!</h1> <style global> @import 'tailwindcss/utilities'; @import 'tailwindcss/theme' theme(reference); @import './components.css'; </style> ``` ## Test Plan I've added integration tests to validate this works as expected. Furthermore I've used the [tailwindcss-playgrounds](https://github.com/philipp-spiess/tailwind-playgrounds) SvelteKit project to ensure this works in an end-to-end setup: <img width="2250" alt="Screenshot 2024-11-08 at 14 45 31" src="https://github.com/user-attachments/assets/64e9e0f3-53fb-4039-b0a7-3ce945a29179">
2024-11-08 20:01:16 +01:00
- Process `<style>` blocks inside Svelte files when using the Vite extension ([#14151](https://github.com/tailwindlabs/tailwindcss/pull/14151))
Normalize date/time input styles (#14931) This PR adds some additional styles to Preflight to normalize a bunch of inconsistencies in date/time inputs across browsers. The main motivation for this is to remove these insane classes we have to add in Catalyst: ```html <input type="date" class="[&::-webkit-datetime-edit-fields-wrapper]:p-0 [&::-webkit-date-and-time-value]:min-h-[1.5em] [&::-webkit-datetime-edit]:inline-flex [&::-webkit-datetime-edit]:p-0 [&::-webkit-datetime-edit-year-field]:p-0 [&::-webkit-datetime-edit-month-field]:p-0 [&::-webkit-datetime-edit-day-field]:p-0 [&::-webkit-datetime-edit-hour-field]:p-0 [&::-webkit-datetime-edit-minute-field]:p-0 [&::-webkit-datetime-edit-second-field]:p-0 [&::-webkit-datetime-edit-millisecond-field]:p-0 [&::-webkit-datetime-edit-meridiem-field]:p-0"/> ``` With these normalizations, changing things like padding, display type, etc. gives consistent results (at least as consistent as is actually possible) across all browsers. --- **Make text alignment work on iOS Safari** <kbd><img width="418" alt="iOS Safari text alignment" src="https://github.com/user-attachments/assets/0ff792b2-1f3a-40c6-9185-6bd076c8715d"></kbd> --- **Don't shrink date inputs on iOS Safari when there is no selected value** <kbd><img width="409" alt="ioS Safari no input" src="https://github.com/user-attachments/assets/a8e69af7-3f0c-4d1d-b7a0-10355a5d3907"></kbd> --- **Fix padding in macOS Safari** <kbd><img width="717" alt="MacOS Safari" src="https://github.com/user-attachments/assets/5ea19b66-2dec-46e2-a386-d61bd5b8517a"></kbd> --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-08 16:43:56 -05:00
- Normalize date/time input styles in Preflight ([#14931](https://github.com/tailwindlabs/tailwindcss/pull/14931))
Migrate `grid-cols-[subgrid]` and `grid-rows-[subgrid]` to `grid-cols-subgrid` and `grid-rows-subgrid` (#14840) This PR adds a migration to convert `grid-cols-[subgrid]` to `grid-cols-subgrid` and `grid-rows-[subgrid]` to `grid-rows-subgrid`.
2024-11-01 21:25:53 +01:00
- _Upgrade (experimental)_: Migrate `grid-cols-[subgrid]` and `grid-rows-[subgrid]` to `grid-cols-subgrid` and `grid-rows-subgrid` ([#14840](https://github.com/tailwindlabs/tailwindcss/pull/14840))
Support migrating projects with multiple config files (#14863) When migrating a project from Tailwind CSS v3 to Tailwind CSS v4, then we started the migration process in the following order: 1. Migrate the JS/TS config file 2. Migrate the source files (found via the `content` option) 3. Migrate the CSS files However, if you have a setup where you have multiple CSS root files (e.g.: `frontend` and `admin` are separated), then that typically means that you have an `@config` directive in your CSS files. These point to the Tailwind CSS config file. This PR changes the migration order to do the following: 1. Build a tree of all the CSS files 2. For each `@config` directive, migrate the JS/TS config file 3. For each JS/TS config file, migrate the source files If a CSS file does not contain any `@config` directives, then we start by filling in the `@config` directive with the default Tailwind CSS config file (if found, or the one passed in). If no default config file or passed in config file can be found, then we will error out (just like we do now) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-04 17:52:11 +01:00
- _Upgrade (experimental)_: Support migrating projects with multiple config files ([#14863](https://github.com/tailwindlabs/tailwindcss/pull/14863))
Migrate default utilities to have a value suffix (#14875) This PR adds a migration for migrating the changes we implemented in https://github.com/tailwindlabs/tailwindcss/pull/14849 This is the migration we perform: | Old | New | | ----------------- | ------------------ | | `shadow` | `shadow-sm` | | `shadow-sm` | `shadow-xs` | | `shadow-xs` | `shadow-2xs` | | `inset-shadow` | `inset-shadow-sm` | | `inset-shadow-sm` | `inset-shadow-xs` | | `inset-shadow-xs` | `inset-shadow-2xs` | | `drop-shadow` | `drop-shadow-sm` | | `drop-shadow-sm` | `drop-shadow-xs` | | `rounded` | `rounded-sm` | | `rounded-sm` | `rounded-xs` | | `blur` | `blur-sm` | | `blur-sm` | `blur-xs` | Also added an integration test to ensure that `shadow` is properly migrated to `shadow-sm`, and doesn't get migrated to `shadow-xs` (because `shadow-sm` is migrated to `shadow-xs`).
2024-11-06 12:28:38 +01:00
- _Upgrade (experimental)_: Rename `shadow` to `shadow-sm`, `shadow-sm` to `shadow-xs`, and `shadow-xs` to `shadow-2xs` ([#14875](https://github.com/tailwindlabs/tailwindcss/pull/14875))
- _Upgrade (experimental)_: Rename `inset-shadow` to `inset-shadow-sm`, `inset-shadow-sm` to `inset-shadow-xs`, and `inset-shadow-xs` to `inset-shadow-2xs` ([#14875](https://github.com/tailwindlabs/tailwindcss/pull/14875))
- _Upgrade (experimental)_: Rename `drop-shadow` to `drop-shadow-sm` and `drop-shadow-sm` to `drop-shadow-xs` ([#14875](https://github.com/tailwindlabs/tailwindcss/pull/14875))
- _Upgrade (experimental)_: Rename `rounded` to `rounded-sm` and `rounded-sm` to `rounded-xs` ([#14875](https://github.com/tailwindlabs/tailwindcss/pull/14875))
- _Upgrade (experimental)_: Rename `blur` to `blur-sm` and `blur-sm` to `blur-xs` ([#14875](https://github.com/tailwindlabs/tailwindcss/pull/14875))
Upgrade: Migrate spacing scale (#14905) This PR adds migrations for the recent changes to the `--spacing` scale done in #12263. There are a few steps that we do to ensure we have the best upgrade experience: - If you are overwriting the `spacing` theme with custom values, we now check if the new values are multiplies of the default spacing scale. When they are, we can safely remove the overwrite. - If you are extending the `spacing` theme, we will unset the default `--spacing` scale and only use the values you provided. - Any `theme()` function calls are replaced with `calc(var(--spacing) * multiplier)` unless the values are extending the default scale. One caveat here is for `theme()` key which can not be replaced with `var()` (e.g. in `@media` attribute positions). These will not be able to be replaced with `calc()` either so the following needs to stay unmigrated: ```css @media (max-width: theme(spacing.96)) { .foo { color: red; } } ``` ## Test plan We are mainly testing two scenarios: The JS config _extends_ the `spacing` namespace and the JS config _overwrites_ the `spacing` namespace. For both cases we have added an integration test each to ensure this works as expected. The test contains a mixture of keys (some of it matching the default multiples, some don't, some have different scales, and some use non-numeric identifiers). In addition to asserting on the created CSS `@theme`, we also ensure that `theme()` calls are properly replaced. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-07 20:25:21 +01:00
- _Upgrade (experimental)_: Migrate `theme()` usage and JS config files to use the new `--spacing` multiplier where possible ([#14905](https://github.com/tailwindlabs/tailwindcss/pull/14905))
Migrate arbitrary values to built-in values (#14841) This PR adds a migration where we detect arbitrary variants and try to upgrade them to built-in variants. For example, if you are using `[[data-visible]]:flex`, we can convert it to `data-visible:flex`. We can also upgrade more advanced examples such as `has-[[data-visible]]:flex` to a compound variant which becomes `has-data-visible:flex`. A table of example migrations: | Before | After | | ------------------------------------------ | ---------------------------------- | | `[[data-visible]]:flex` | `data-visible:flex` | | `[&[data-visible]]:flex` | `data-visible:flex` | | `[[data-visible]&]:flex` | `data-visible:flex` | | `[[data-url*="example"]]:flex` | `data-[url*="example"]:flex` | | `[[data-url$=".com"_i]]:flex` | `data-[url$=".com"_i]:flex` | | `[[data-url$=.com_i]]:flex` | `data-[url$=.com_i]:flex` | | `[&:is([data-visible])]:flex` | `data-visible:flex` | | `has-[[data-visible]]:flex` | `has-data-visible:flex` | | `has-[&:is([data-visible])]:flex` | `has-data-visible:flex` | | `has-[[data-slot=description]]:flex` | `has-data-[slot=description]:flex` | | `has-[&:is([data-slot=description])]:flex` | `has-data-[slot=description]:flex` | | `has-[[aria-visible="true"]]:flex` | `has-aria-visible:flex` | | `has-[[aria-visible]]:flex` | `has-aria-[visible]:flex` | We can also convert combinators from `[&>[data-visible]]:flex` to just `*:data-visible:flex` and `[&_[data-visible]]:flex` to `**:data-visible:flex`. | Before | After | | --- | --- | | `[&>[data-visible]]:flex` | `*:data-visible:flex` | | `[&_>_[data-visible]]:flex` | `*:data-visible:flex` | | `[&_[data-visible]]:flex` | `**:data-visible:flex` | Additionally, if you have complex selectors with `:not()`, we can convert this to a compound `not-*` variant in some cases as well: | Before | After | | --- | --- | | `[&:nth-child(2)]:flex` | `nth-2:flex` | | `[&:not(:nth-child(2))]:flex` | `not-nth-2:flex` | If some of the values in `nth-child(…)` are a bit too complex, then we still try to convert them but to arbitrary values instead. | Before | After | | --- | --- | | `[&:nth-child(-n+3)]:flex` | `nth-[-n+3]:flex` | | `[&:not(:nth-child(-n+3))]:flex` | `not-nth-[-n+3]:flex` | This also implements some optimizations around `even` and `odd`: | Before | After | | --- | --- | | `[&:nth-child(odd)]:flex` | `odd:flex` | | `[&:not(:nth-child(odd))]:flex` | `even:flex` | | `[&:nth-child(even)]:flex` | `even:flex` | | `[&:not(:nth-child(even))]:flex` | `odd:flex` | Some examples that stay as-is: - `has-[&>[data-visible]]:flex` we can't upgrade this one because `has-*` is not a valid variant. - `has-[[data-visible][data-dark]]:flex` we can't upgrade this one because `[data-visible][data-dark]` has to be on the same element. If we convert this to `has-data-visible:has-data-dark:flex` then this condition will be true if an element exists with `data-visible` and another element exists with `data-dark` but we don't guarantee that they are the same element. --- Running this on the Catalyst codebase results in some updates that look like this: <img width="676" alt="image" src="https://github.com/user-attachments/assets/6f0ff21d-5037-440b-9b80-0997ab0c11dd"> <img width="397" alt="image" src="https://github.com/user-attachments/assets/8f0856fa-1709-404a-ac34-7d8c661fa799"> --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-11 12:44:13 +01:00
- _Upgrade (experimental)_: Migrate arbitrary values in variants to built-in values where possible ([#14841](https://github.com/tailwindlabs/tailwindcss/pull/14841))
Migrate `grid-cols-[subgrid]` and `grid-rows-[subgrid]` to `grid-cols-subgrid` and `grid-rows-subgrid` (#14840) This PR adds a migration to convert `grid-cols-[subgrid]` to `grid-cols-subgrid` and `grid-rows-[subgrid]` to `grid-rows-subgrid`.
2024-11-01 21:25:53 +01:00
Fix new file detection in PostCSS plugin (#14829) We broke this at some point — probably when we tried to optimize rebuilds in PostCSS by not performing a full auto-source detection scan. This PR addresses this problem by: 1. Storing a list of found directories 2. Comparing their mod times on every scan 3. If the mod time has changed we scan the directory for new files which we then store and scan
2024-10-30 10:56:55 -04:00
### Fixed
- Detect classes in new files when using `@tailwindcss/postcss` ([#14829](https://github.com/tailwindlabs/tailwindcss/pull/14829))
Fix crash when using `@source` containing `..` (#14831) This PR fixes an issue where a `@source` crashes when the path eventually resolves to a path ending in `..`. We have to make sure that we canonicalize the path to make sure that we are working with the real directory. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-10-30 21:24:48 +01:00
- Fix crash when using `@source` containing `..` ([#14831](https://github.com/tailwindlabs/tailwindcss/pull/14831))
Fix non-deterministic variant sorting (#14835) Right now our variant sorting is sensitive to the authoring order of classes or the order in which we scan files because we weren't comparing variant values when sorting. This PR addresses this by: - "default" values in variants appear first - Then any named values - Then any arbitrary values - Finally, compare the values themselves when all else is equal --------- 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>
2024-10-31 10:39:56 -04:00
- Ensure instances of the same variant with different values are always sorted deterministically (e.g. `data-focus:flex` and `data-active:flex`) ([#14835](https://github.com/tailwindlabs/tailwindcss/pull/14835))
Ensure `--inset-ring=*` and `--inset-shadow-*` variables are ignored by `inset-*` utilities (#14855) This PR fixes a issue where utilities like `inset-x-*`, `left-*`, `top-*`, etc. mistakenly pull values from the `--inset-ring-*` and `--inset-shadow-*` theme namespaces. For example, the class `left-shadow-sm` currently generates this CSS: ```css .left-shadow-sm { left: var( --inset-shadow-sm, inset 0 1px 1px rgb(0 0 0 / 0.05) ); } ``` This happens because the `--inset-ring-*` and `--inset-shadow-*` namespaces collide with the `--inset-*` namespace. We were already handling this manually for just the `inset-*` utilities but didn't realize we needed to handle it for every related utility, so this PR fixes that. This also fixes an issue where IntelliSense would suggest classes like `inset-x-shadow-sm` when they shouldn't actually exist. To do this we've created this new concept of `ignoredThemeKeys` in the relevant APIs to make sure these are filtered out at the source. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-01 13:48:42 -04:00
- Ensure `--inset-ring=*` and `--inset-shadow-*` variables are ignored by `inset-*` utilities ([#14855](https://github.com/tailwindlabs/tailwindcss/pull/14855))
Fix parsing `url(…)` with special characters such as `;` or `{}` (#14879) This PR fixes an issue where some special characters (with an actual meaning CSS) were used inside of the `url(…)` function, would result in incorrectly parsed CSS. For example, when we encounter a `{`, then we would start a new "block" for nesting purposes. If we encounter an `}`, then the block would end. If we encounter a `;`, then that would be the end of a declaration. All of that is true, unless we are in a `url(…)` function. In that case, we should ignore all of those characters and treat them as part of the URL. This is only an issue because: 1. We are allowed to use these characters in URLs. 2. We can write an url inside `url(…)` without quotes. With quotes, this would not be an issue. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-06 12:06:49 +01:00
- Ensure `url(…)` containing special characters such as `;` or `{}` end up in one declaration ([#14879](https://github.com/tailwindlabs/tailwindcss/pull/14879))
Optimize generated CSS output (#14873) This PR improves the generated CSS by running it through Lightning CSS twice.Right now Lightning CSS merges adjacent at-rules and at the end flattens the nesting. This means that after the nesting is flattened, the at-rules that are adjacent and could be merged together will not be merged. This PR improves our output by running Lightning CSS twice on the generated CSS which will make sure to merge adjacent at-rules after the nesting is flattened. Note: in the diff output you'll notice that some properties are duplicated. These need some fixes in Lightning CSS itself but they don't break anything for us right now. Related PR in Lightning CSS for the double `-webkit-backdrop-filter` can be found here: https://github.com/parcel-bundler/lightningcss/pull/850 --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-06 12:39:09 +01:00
- Ensure adjacent rules are merged together after handling nesting when generating optimized CSS ([#14873](https://github.com/tailwindlabs/tailwindcss/pull/14873))
Rewrite urls in CSS files when using Vite (#14877) Fixes #14784 This is an alternative to #14850 in which we actually perform url rewriting / rebasing ourselves. We ported a large portion of the URL-rewriting code from Vite (with attribution) to use here with some minor modifications. We've added test cases for the url rewriting so verifying individual cases is easy. We also wrote integration tests for Vite that use PostCSS and Lightning CSS that verify that files are found and inlined or relocated/renamed as necessary. We also did some manual testing in the Playground to verify that this works as expected across several CSS files and directories which you can see a screenshot from here: <img width="1344" alt="Screenshot 2024-11-05 at 10 25 16" src="https://github.com/user-attachments/assets/ff0b3ac8-cdc9-4e26-af79-36396a5b77b9"> --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-07 09:51:58 -05:00
- Rebase `url()` inside imported CSS files when using Vite ([#14877](https://github.com/tailwindlabs/tailwindcss/pull/14877))
Apply non-Tailwind CSS transforms in Vite plugin (#14871) Fixes: #14839 Fixes: #14796 This PR fixes an issue in the Vite extension where we previously only ran a small list of allow-listed plugins for the second stage transform in the build step. This caused some CSS features to unexpectedly not work in production builds (one such example is Vue's `:deep(...)` selector). To fix this, I changed the allow listed plugins that we do want to run to a block list to filter out some plugins we know we don't want to run (e.g. the Tailwind Vite plugin for example or some built-in Vite plugins that are not necessary). ## Test plan This PR adds a new integration test suite to test interop with a custom Vite transformer that looks like this: ```js { name: 'recolor', transform(code, id) { if (id.includes('.css')) { return code.replace(/red/g, 'blue') } }, } ``` I also validated that this does indeed fix the Vue `:deep(...)` selector related issue that we were seeing by copying the repro of #14839 into our playground: ![Screenshot 2024-11-05 at 13.35.26.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/0Y77ilPI2WoJfMLFiAEw/4e46ab61-4acf-461a-9e40-f7c9ec3c69b2.png) You can see in the screenshot above that the `:deep()` selector overwrites the scoped styles as expected in both the dev mode and the prod build (screenshotted). Furthermore I reproduced the issue reported in https://github.com/tailwindlabs/tailwindcss/issues/14796 and was able to confirm that in a production build, the styling works as expected: <img width="517" alt="Screenshot 2024-11-06 at 14 26 50" src="https://github.com/user-attachments/assets/ade6fe38-be0d-4bd0-9a9a-67b6fec05ae0"> Lastly, I created a repository out of the biggest known-to-me Vite projects: [Astro, Nuxt, Remix, SolidStart, and SvelteKit](https://github.com/philipp-spiess/tailwind-playgrounds) and verified that both dev and prod builds show no issue and the candidate list is properly appended in each case. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-07 16:26:18 +01:00
- Ensure that CSS transforms from other Vite plugins correctly work in full builds (e.g. `:deep()` in Vue) ([#14871](https://github.com/tailwindlabs/tailwindcss/pull/14871))
Allow newlines and tabs in the argument list of the `theme()` function (#14917) We noticed an issue that the `theme()` function wourld not properly parse in CSS if you split the argument list over multiple lines. This is fixed by treating `\n` and `\t` the same as space: ```css .custom-font { font-family: theme( fontFamily.unknown, Helvetica Neue, Helvetica, sans-serif ); } ``` ## Test plan Added tests, but also tried it in the Vite example: <img width="1995" alt="Screenshot 2024-11-08 at 13 46 09" src="https://github.com/user-attachments/assets/f9bf94b0-3f9b-4334-8911-9190987e2df5">
2024-11-08 16:14:11 +01:00
- Ensure the CSS `theme()` function handles newlines and tabs in its arguments list ([#14917](https://github.com/tailwindlabs/tailwindcss/pull/14917))
Don't unset keys like `--font-weight-*` when unsetting `--font-*` (#14906) This PR fixes an issue where unsetting `--font-*` would unset `--font-weight-*` and `--font-size-*`. ```css @theme { --font-weight-bold: bold; --font-size-sm: 14px; --font-sans: sans-serif; --font-serif: serif; } @theme { --font-*: initial; --font-body: Inter; } ``` Up until now this was sort of intended/desired behavior but with recent changes there are now more overlapping theme keys (`--inset-*` and `--inset-shadow-*` as well for example), and we don't want to make it impossible to unset _just_ the default `font-family` values. This PR also simplifies how we were handling making sure that the `inset-*` utility ignored `--inset-shadow-*` variables since it's all really the same problem. This does mean we need to maintain a list of known theme keys so we know when there is a conflict between two keys, which is kind of unfortunate because up until now this was a totally dynamic thing. End users can still add whatever custom stuff they want under `@theme` but we don't really know about those namespaces since we're maintaining a static list so we can't resolve conflicts there. I'm confident there are ways we could solve this if it actually becomes a problem, so content to push forward without solving it right now and just deal with it if/when it actually arises, because it just might not. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-07 10:43:49 -05:00
- Don't unset keys like `--inset-shadow-*` when unsetting keys like `--inset-*` ([#14906](https://github.com/tailwindlabs/tailwindcss/pull/14906))
Ensure spacing utilities with no value (e.g. `px`) don't generate CSS (#14911) This PR fixes an issue where utilities like `px` would read the `--spacing` variable and use its value as the utility value, similar to how `shadow` reads `--shadow` by default. That doesn't make sense for these utilities since `--spacing` is reserved as a special multiplier variable. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-08 09:49:42 -05:00
- Ensure spacing utilities with no value (e.g. `px` or `translate-y`) don't generate CSS ([#14911](https://github.com/tailwindlabs/tailwindcss/pull/14911))
Don't give input elements a transparent background by default (#14913) Early in v4 development we decided to give all form controls a transparent background, but in v3 we only did this for button elements. This PR reverts that decision to make things consistent with v3, as we've noticed this is something that tends to break for people when upgrading from v3 to v4. The default background color of form elements is the [`Field` system color](https://developer.mozilla.org/en-US/docs/Web/CSS/system-color#field) which automatically adapts to light and dark modes if you don't touch it, so it feels reasonable to keep this as the default. Changing it just makes upgrading harder and doesn't really make anything easier for anyone else. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-08 10:19:29 -05:00
- Don't override user-agent background color for input elements in Preflight ([#14913](https://github.com/tailwindlabs/tailwindcss/pull/14913))
Fix opacity modifier using CSS variables (#14916) When using an opacity modifier such as `bg-black/[var(--opacity)]`, then this was translated to: ```css .bg-black\/\[var\(--opacity\)\] { background-color: color-mix( in oklch, var(--color-black, #000) calc(var(--opacity) * 100%), transp } ``` The issue is that this part: `calc(var(--opacity) * 100%)` is invalid _if_ the `var(--opacity)` already contains a percentage value. See: https://play.tailwindcss.com/xz0t This is because this eventually resolves to `calc(20% * 100%)` and `20% 100%` is invalid in CSS. In Catalyst we use variables like that _with_ the `%` included, which means that v4 doesn't work as expected when using this. A variable with a `%` included is probably the better value to support compared to the the unit less one. This also allows you to define your variables using `@property` as a proper `<percentage>` type. Unfortunately the `var(--opacity)` is a value that can change at runtime, so we don't know the type at compile time. In the future we might be able to use `first-valid(…)` (see: https://drafts.csswg.org/css-values-5/#f and generate both versions at the same time. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-08 16:17:03 +01:00
- Don't attempt to convert CSS variables (which should already be percentages) to percentages when used as opacity modifiers ([#14916](https://github.com/tailwindlabs/tailwindcss/pull/14916))
Plugin API: Allow custom utilities to start with `@` (#14793) Closes #14791 Add support to the JS Plugin interop layer for utilities that _start with_ `@`. This ensures no breaking when trying to load plugins that contribute utilities like `@container` from `@tailwindcss/container-queries` (even though the `@container` utility is now part of core). ## Test Plan Added the `@tailwindcss/container-queries` plugin to to the Vite example: ![Screenshot 2024-10-25 at 11.18.19.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/0Y77ilPI2WoJfMLFiAEw/3761c0a8-8c54-42eb-a1fd-213c4215c024.png) However, in order for the Vite example to load the extension, I also had to apply the following patch: ![Screenshot 2024-10-25 at 11.18.54.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/0Y77ilPI2WoJfMLFiAEw/bd151684-ff7b-4805-b305-71ac0378c610.png) I think this is related to our dev system though, the compiled plugin file is going to be a flat file with no requires in our public release. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-11 16:11:44 +01:00
- Ensure custom utilities registered with the plugin API can start with `@` ([#14793](https://github.com/tailwindlabs/tailwindcss/pull/14793))
Install `@tailwindcss/postcss` next to `tailwindcss` (#14830) This PR improves the PostCSS migrations to make sure that we install `@tailwindcss/postcss` in the same bucket as `tailwindcss`. If `tailwindcss` exists in the `dependencies` bucket, we install `@tailwindcss/postcss` in the same bucket. If `tailwindcss` exists in the `devDependencies` bucket, we install `@tailwindcss/postcss` in the same bucket. This also contains an internal refactor that normalizes the package manager to make sure we can install a package to the correct bucket depending on the package manager. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-30 20:32:24 +01:00
- _Upgrade (experimental)_: Install `@tailwindcss/postcss` next to `tailwindcss` ([#14830](https://github.com/tailwindlabs/tailwindcss/pull/14830))
Remove whitespace around `,` separator (#14838) This PR is an improvement/fix by making sure that whitespace around the `,` separator is removed when printing arbitrary values. Before: ```diff - <div class="grid-cols-[min(50%,theme(spacing.80))_auto]"></div> + <div class="grid-cols-[min(50%,_var(--spacing-80))_auto]"></div> ``` After: ```diff - <div class="grid-cols-[min(50%,theme(spacing.80))_auto]"></div> + <div class="grid-cols-[min(50%,var(--spacing-80))_auto]"></div> ``` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-10-31 10:15:52 +01:00
- _Upgrade (experimental)_: Remove whitespace around `,` separator when print arbitrary values ([#14838](https://github.com/tailwindlabs/tailwindcss/pull/14838))
Fix crash during upgrade when content globs escape root of project (#14896) This PR fixes an issue where globs in you `content` configuration escape the current "root" of the project. This can happen if you have a folder, and you need to look up in the tree (e.g.: when looking at another package in a monorepo, or in case of a Laravel project where you want to look at mail templates). This applies a similar strategy we already implement on the Rust side. 1. Expand braces in the globs 2. Move static parts of the `pattern` to the `base` of the glob entry object --- Given a project setup like this: ``` . ├── admin │   ├── my-tailwind.config.ts │   └── src │   ├── abc.jpg │   ├── index.html │   ├── index.js │   └── styles │   └── input.css ├── dashboard │   ├── src │   │   ├── index.html │   │   ├── index.js │   │   ├── input.css │   │   └── pickaday.css │   └── tailwind.config.ts ├── package-lock.json ├── package.json ├── postcss.config.js └── unrelated └── index.html 7 directories, 14 files ``` If you then have this config: ```ts // admin/my-tailwind.config.ts export default { content: { relative: true, files: ['./src/**/*.html', '../dashboard/src/**/*.html'], // ^^ this is the important part, which escapes // the current root of the project. }, theme: { extend: { colors: { primary: 'red', }, }, }, } ``` Then before this change, running the command looks like this: <img width="1760" alt="image" src="https://github.com/user-attachments/assets/60e2dfc7-3751-4432-80e3-8b4b8f1083d4"> After this change, running the command looks like this: <img width="1452" alt="image" src="https://github.com/user-attachments/assets/5c47182c-119c-4732-a253-2dace7086049"> --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-11-07 13:22:25 +01:00
- _Upgrade (experimental)_: Fix crash during upgrade when content globs escape root of project ([#14896](https://github.com/tailwindlabs/tailwindcss/pull/14896))
Fix `theme(…/15%)` to only apply when used on its own (#14922) This PR fixes an issue where our codemod migrations can convert `bg-[theme(colors.white/15%)]` to `bg-[var(--color-white)]/15` where the `15%` from within the `theme(…)` is converted to a candidate modifier (at the end). The idea was that if the `theme(…)` is used with a modifier, then it can only be used with colors. If a candidate uses it, it also means that a color was used and we can use `/15` instead. However this is not true if it is used as part of a bigger value. E.g.: `shadow-[shadow:inset_0_0_0_1px_theme(colors.white/15%)]` would be converted to `shadow-[inset_0_0_0_1px_var(--color-white)]/15` which is not correct because the value isn't a color, the color is _part_ of the value. In this case, we make sure that the `theme(…)` is the only AST node in the value, and if it is we can safely do the conversion. If there are other AST nodes we keep the `theme(…)` call. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-08 17:05:30 +01:00
- _Upgrade (experimental)_: Don't convert `theme(…/15%)` to modifier unless it is the entire arbitrary value of a utility ([#14922](https://github.com/tailwindlabs/tailwindcss/pull/14922))
Convert `,` to ` ` in `grid-cols-[…]`, `grid-rows-[…]`, and `object-[…]` (#14927) This PR converts legacy commas in arbitrary values to spaces. In Tailwind CSS v3, we allowed commas in arbitrary values for `grid-cols-[…]`, `grid-rows-[…]`, and `object-[…]` for backwards compatibility. The underlying CSS value did use spaces instead of commas. This PR adds a code mod where convert the commas to spaces when we see them. Test plan: --- Running this on Catalyst it goes from this: <img width="393" alt="image" src="https://github.com/user-attachments/assets/03cbda73-41f9-4601-b77a-5b511226b876"> To the expected value of: <img width="376" alt="image" src="https://github.com/user-attachments/assets/dd9bbe01-5eb1-4340-937b-70c435e7e4f0"> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-11 16:26:37 +01:00
- _Upgrade (experimental)_: Convert `,` to ` ` in arbitrary `grid-cols-*`, `grid-rows-*`, and `object-*` values ([#14927](https://github.com/tailwindlabs/tailwindcss/pull/14927))
Prepare v4.0.0-alpha.31 release (#14823) Prepare v4.0.0-alpha.31 release
2024-10-30 12:53:51 +01:00
Remove `--drop-shadow-none` from default theme (#14847) This PR removes `--drop-shadow-none` from the default theme which shouldn't ever have been there since we handle all `*-none` utilities as static/permanent utilities in the framework now. I've added `drop-shadow-none` as an explicit static utility, and also slightly improved test coverage for `getClassList` around drop shadows while touching this part of the code. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-10-31 14:24:18 -04:00
### Changed
- Remove `--drop-shadow-none` from the default theme in favor of a static `drop-shadow-none` utility ([#14847](https://github.com/tailwindlabs/tailwindcss/pull/14847))
Adjust shadow, radius, and blur scales to ensure all utilities have a value suffix (#14849) This PR reworks the default `--shadow-*` and `--inset-shadow-*` scales to remove the bare `shadow` and `inset-shadow` utilities, and ensure every shadow has an explicit size as part of the utility name. Here's a complete list of changes: | v3 | v4 Alpha | Proposed | | ----------------- | ----------------- | ------------------ | | _N/A_ | `shadow-xs` | `shadow-2xs` | | `shadow-sm` | `shadow-sm` | `shadow-xs` | | `shadow` | `shadow` | `shadow-sm` | | `shadow-md` | `shadow-md` | `shadow-md` | | `shadow-lg` | `shadow-lg` | `shadow-lg` | | `shadow-xl` | `shadow-xl` | `shadow-xl` | | _N/A_ | `inset-shadow-xs` | `inset-shadow-2xs` | | _N/A_ | `inset-shadow-sm` | `inset-shadow-xs` | | `shadow-inner` | `inset-shadow` | `inset-shadow-sm` | The motivation for this change is just to make the scale more predictable — it's never been intuitive to me that `shadow` sits in between `shadow-sm` and `shadow-md`. This PR doesn't remove the ability to create classes like `shadow` and `inset-shadow` by adding bare `--shadow` and `--inset-shadow` theme variables, but does remove them from the default theme. ## Impact We'll include a codemod for this in our upgrade tool to automate this change for people upgrading from v3 to v4, but this is still sort of an annoying breaking change admittedly and will make lots of educational resources, example components, and LLM tools out of date for v4 😕 At the same time I don't want to feel like we can never correct regrettable legacy decisions just to preserve backward compatibility. We made a similar change like this when we went from the v0.x color palette to the v1.x color palette changing names like `bg-red` to `bg-red-500` and that proved to definitely be the right decision long term, so want to rip the band-aid off here too if we can. Planning to make the same change for `rounded`, `drop-shadow`, and `blur` as well — maybe in separate PRs but maybe just all in this one as well since I don't think we want to do one and not all. _Update_: I've also made the same changes to the `--radius-*`, `--drop-shadow-*`, and `--blur-*` scales now, effectively removed the `rounded`, `drop-shadow`, and `blur` classes by default, and changing the meaning `rounded-sm`, `drop-shadow-sm`, and `blur-sm`. We'll put together a codemod to handle this stuff in a separate PR. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-04 14:04:03 -05:00
- Rename `shadow` to `shadow-sm`, `shadow-sm` to `shadow-xs`, and `shadow-xs` to `shadow-2xs` ([#14849](https://github.com/tailwindlabs/tailwindcss/pull/14849))
- Rename `inset-shadow` to `inset-shadow-sm`, `inset-shadow-sm` to `inset-shadow-xs`, and `inset-shadow-xs` to `inset-shadow-2xs` ([#14849](https://github.com/tailwindlabs/tailwindcss/pull/14849))
- Rename `drop-shadow` to `drop-shadow-sm` and `drop-shadow-sm` to `drop-shadow-xs` ([#14849](https://github.com/tailwindlabs/tailwindcss/pull/14849))
- Rename `rounded` to `rounded-sm` and `rounded-sm` to `rounded-xs` ([#14849](https://github.com/tailwindlabs/tailwindcss/pull/14849))
- Rename `blur` to `blur-sm` and `blur-sm` to `blur-xs` ([#14849](https://github.com/tailwindlabs/tailwindcss/pull/14849))
Ensure font-size utilities with `none` modifier works e.g.: `text-sm/none` (#15921) This PR fixes an issue where classes such as `text-sm/none` don't work as expected. The reason for this is that `leading-none` is the only hardcoded leading utility and is not coming from the `@theme`. This means that `text-sm/none` tries to do a lookup for `none` but it won't resolve. This PR fixes that by allowing `none` as a modifier. While working on this, I noticed that `text-sm/none` _did_ generate CSS: ```css .text-sm\/none { font-size: var(--text-sm); } ``` Notice that the `line-height` is missing. This means that any modifier that can't be resolved doesn't get the `line-height` set, but it _will_ generate CSS. In this case, no CSS should have been generated. Otherwise, all of these generate CSS which will only bloat your CSS and won't work as expected. E.g.: `text-sm/foo`, `text-sm/bar`, and `text-sm/baz`: ```css .text-sm\/bar { font-size: var(--text-sm); } .text-sm\/baz { font-size: var(--text-sm); } .text-sm\/foo { font-size: var(--text-sm); } ``` Fixes: #15911
2025-01-27 14:10:09 +01:00
- Remove fixed line-height theme values and derive `leading-*` utilities from `--spacing-*` scale ([#14857](https://github.com/tailwindlabs/tailwindcss/pull/14857))
Make `ease-linear` a static utility (#14880) This PR removes `--transition-timing-function-linear` from the default theme in favor of a static `ease-linear` utility. Doesn't make sense for this to be a design token since `linear` can only mean `linear`. This is consistent with how we handle basically every other similar case in the framework. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-05 12:34:44 -05:00
- Remove `--transition-timing-function-linear` from the default theme in favor of a static `ease-linear` utility ([#14880](https://github.com/tailwindlabs/tailwindcss/pull/14880))
Replace default explicit spacing scale with multiplier system (#14857) This PR replaces the default spacing scale (`--spacing-*`) with a generative system based on a default spacing _unit_. Instead of the default theme containing values like `--spacing-4`, `--spacing-6`, `--spacing-8`, etc., instead we just define a single `--spacing` value: ```css @theme { --spacing: 0.25rem; } ``` Utilities like `px-4` are derived from this unit by multiplying it by the value in the utility (4 in this case): ```css .px-4 { padding-inline: calc(var(--spacing) * 4); } ``` The biggest consequence of this change is that every value is available now, rather than just the explicitly configured values. This means utilities like `px-42` will work now, whereas prior to this PR only `px-40` and `px-44` were valid utilities. I personally found it very difficult to know which values actually existed at the higher end of the scale without IntelliSense, and in practice even when working with a skilled designer like [Steve](https://x.com/steveschoger) 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. This PR allows you to use any whole number, as well as decimal numbers that are multiples of `0.25` to ensure classes like `px-1.5` continue to work. While this means you can now technically do things like `pt-97.25`, I think the presence of the fractional value will be enough of a signal to developers that they are doing something a little unusual, and they can use their judgment as to whether they are making the right decision or not. I'll update this PR with a lot more detail when I have a chance, as there are a few other things to explain like: - Unifying all of the values for width/min-width/max-width/height/min-height/max-height utilities - Deriving numeric line-height values from the spacing multiplier instead of a separate line-height scale - Using `--spacing: initial` to disable the multiplier - How you can still use an explicit spacing scale and ignore this change - How we plan to use IntelliSense to surface a more curated set of spacing values even if smaller increments work when you type them explicitly --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-05 15:22:50 -05:00
- Remove default `--spacing-*` scale in favor of `--spacing` multiplier ([#14857](https://github.com/tailwindlabs/tailwindcss/pull/14857))
Remove fallbacks from theme `var(...)` calls (#14881) This PR changes how we render `var(...)` calls for theme values, removing the fallback values we were previously including. ```diff .text-white { - color: var(--color-white, #fff); + color: var(--color-white); } ``` We previously included the fallbacks only so you could see the value in dev tools but this feels like a bad reason to bloat the CSS. I'd rather just convince the Chrome team to surface this stuff better in dev tools in the first place. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-05 15:44:21 -05:00
- Remove `var(…)` fallbacks from theme values in utilities ([#14881](https://github.com/tailwindlabs/tailwindcss/pull/14881))
Derive all font-weight values from theme (#14883) This PR removes all of the static `font-weight` utilities that were previously hard-coded into the framework in favor of deriving those utilities from the `--font-weight-*` theme values instead. Biggest motivation for this is giving people a way to explicitly disable font-weight utilities they don't want to use in their project, which previously wasn't possible. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-05 16:06:47 -05:00
- Remove static `font-weight` utilities and add `--font-weight-*` values to the default theme ([#14883](https://github.com/tailwindlabs/tailwindcss/pull/14883))
Rename `--transition-timing-function-*` variables to `--ease-*` (#14886) This PR renames the `--transition-timing-function-*` theme variables to `--ease-*` to more closely match the utility names and be a bit more terse in general. ```diff @theme { - --transition-timing-function-in: cubic-bezier(0.4, 0, 1, 1); - --transition-timing-function-out: cubic-bezier(0, 0, 0.2, 1); - --transition-timing-function-in-out: cubic-bezier(0.4, 0, 0.2, 1); + --ease-in: cubic-bezier(0.4, 0, 1, 1); + --ease-out: cubic-bezier(0, 0, 0.2, 1); + --ease-in-out: cubic-bezier(0.4, 0, 0.2, 1); } ``` This is part of a bigger set of changes where we're renaming other theme variables as well with the same goals, since many existing theme variables like `--shadow-*` and `--radius-*` are already not using the explicit CSS property name. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-06 10:51:34 -05:00
- Rename `--transition-timing-function-*` variables to `--ease-*` ([#14886](https://github.com/tailwindlabs/tailwindcss/pull/14886))
Rename `--width-*` namespace to `--container-*` (#14898) This PR renames all of the `--width-*` variables to `--container-*` to better communicate the purpose of these tokens as layout container sizes. These are the values that were historically stored under `maxWidth` in the v3 and earlier eras, and were also re-used by the container queries plugin. The name `--container-*` feels like a better match alongside the `--breakpoint-*` namespace and since these both serve that same sort of purpose it makes sense to me that the name should be optimized for feeling "right" in that context. I like that this also sort of advertises Tailwind's support for container queries directly in the CSS variables themselves, and helps people understand what these are really intended to be used for. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-06 20:50:30 -05:00
- Rename `--width-*` variables to `--container-*` ([#14898](https://github.com/tailwindlabs/tailwindcss/pull/14898))
Rename `--font-size-*` variables to `--text-*` (#14909) This PR updates all of the `--font-size-*` variables to `--text-*` instead to closer match the utility names. ```diff @theme { - --font-size-xs: 0.75rem; - --font-size-xs--line-height: 1rem; - --font-size-sm: 0.875rem; - --font-size-sm--line-height: 1.25rem; - --font-size-base: 1rem; - --font-size-base--line-height: 1.5rem; - --font-size-lg: 1.125rem; - --font-size-lg--line-height: 1.75rem; - --font-size-xl: 1.25rem; - --font-size-xl--line-height: 1.75rem; /* ... */ + --text-xs: 0.75rem; + --text-xs--line-height: 1rem; + --text-sm: 0.875rem; + --text-sm--line-height: 1.25rem; + --text-base: 1rem; + --text-base--line-height: 1.5rem; + --text-lg: 1.125rem; + --text-lg--line-height: 1.75rem; + --text-xl: 1.25rem; + --text-xl--line-height: 1.75rem; /* ... */ } ``` This is part of a bigger set of changes where we're renaming other theme variables as well with the same goals, since many existing theme variables like `--shadow-*` and `--radius-*` are already not using the explicit CSS property name. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-11-07 14:08:06 -05:00
- Rename `--font-size-*` variables to `--text-*` ([#14909](https://github.com/tailwindlabs/tailwindcss/pull/14909))
Update changelog
2024-11-13 11:33:20 +01:00
- Rename `--font-family-*` variables to `--font-*` ([#14885](https://github.com/tailwindlabs/tailwindcss/pull/14885))
Rename `--letter-spacing-*` variables to `--tracking-*` (#14921) Part of the current changes, we also want to make the `--letter-spacing-*` namespace closer to the utility name so we're renaming it to `--tracking-*`: ```diff @theme { - --letter-spacing-tighter: -0.05em; - --letter-spacing-tight: -0.025em; - --letter-spacing-normal: 0em; - --letter-spacing-wide: 0.025em; - --letter-spacing-wider: 0.05em; - --letter-spacing-widest: 0.1em; /* ... */ + --tracking-tighter: -0.05em; + --tracking-tight: -0.025em; + --tracking-normal: 0em; + --tracking-wide: 0.025em; + --tracking-wider: 0.05em; + --tracking-widest: 0.1em; /* ... */ } ``` ## Test Plan Added cases to the CSS `theme()` variable/JS plugin tests (interop layer) and the integration tests (codemod layer).
2024-11-08 17:02:47 +01:00
- Rename `--letter-spacing-*` variables to `--tracking-*` ([#14921](https://github.com/tailwindlabs/tailwindcss/pull/14921))
Rename `--line-height-*` variables to `--leading-*` (#14925) Part of the current changes, we also want to make the `--line-height-*` namespace closer to the utility name so we're renaming it to `--leading-*`: ```diff @theme { - --line-height-none: 1; - --line-height-tight: 1.25; - --line-height-snug: 1.375; - --line-height-normal: 1.5; - --line-height-relaxed: 1.625; - --line-height-loose: 2; /* ... */ + --leading-none: 1; + --leading-tight: 1.25; + --leading-snug: 1.375; + --leading-normal: 1.5; + --leading-relaxed: 1.625; + --leading-loose: 2; /* ... */ } ``` Notice that we did not change the nested values used in the `--text` type scale, e.g.: ```css @theme { /* Type scale */ --text-xs: 0.75rem; --text-xs--line-height: 1rem; } ``` These do not refer to the `leading` utility and instead refer to nested properties so we're keeping those as-is. ## Test Plan Added cases to the CSS `theme()` variable/JS plugin tests (interop layer) and the integration tests (codemod layer).
2024-11-08 20:00:30 +01:00
- Rename `--line-height-*` variables to `--leading-*` ([#14925](https://github.com/tailwindlabs/tailwindcss/pull/14925))
Increase specificity of `*` and `**` variants (#14920) Increase the specificity of the `*` and `**` variants. This will now use `:is(…)` instead of `:where(…)`. In Tailwind CSS v3 we used `& > *` instead of `:where(& > *)` which means that this isn't a breaking change anymore. This also allows us to use codemod things like `[&>[data-visible]]:flex` and `[&_[data-visible]]:flex` to `*:data-visible:flex` and `**:data-visible:flex` respectively. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-11-08 16:19:55 +01:00
- Revert specificity of `*` variant to match v3 behavior ([#14920](https://github.com/tailwindlabs/tailwindcss/pull/14920))
Replace `outline-none` with `outline-hidden`, add new `outline-none` (#14926) This PR renames the existing `outline-none` utility to `outline-hidden`, and adds a new simpler `outline-none` utility that just sets `outline-style: none`. The existing `outline-none` utility doesn't actually set `outline: none`, and instead creates a 2px invisible outline: ```css .outline-none { outline: 2px solid transparent; outline-offset: 2px; } ``` We implemented it this way because people often use `outline: none` to hide focus rings and replace them with custom shadow-based focus rings, without realizing that that approach leads to no visible focus ring in forced colors mode because box shadows aren't rendered in forced colors mode. While this is sort of helpful and clever, it can be a pain when you really do need `outline: none`, and I think it feels surprising in hindsight to hijack the name of an existing CSS property value and make it mean something else. The name `outline-hidden` feels better because it's a new keyword that CSS doesn't use for outlines, and implies that perhaps there's a bit more going on than just setting `outline-style: none`. This PR includes a codemod to convert any existing use of `outline-none` to `outline-hidden`, and we will be sure to explain what `outline-hidden` does for you in the v4 documentation. Manually tested this in the Vite playground to make sure it behaves as expected 👍 --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-08 14:03:12 -05:00
- Replace `outline-none` with `outline-hidden`, add new simplified `outline-none` utility ([#14926](https://github.com/tailwindlabs/tailwindcss/pull/14926))
Remove input borders by default (#14929) This PR reverts a change we made for v4 that added borders to inputs by default. It feels like we have to go further than this for this to actually be useful to anyone, and since there were no borders in v3 it's also a breaking change. If we wanted to make form elements look more "normal" out of the box I think we need to do something more like this: https://play.tailwindcss.com/icCwFLVp4z?file=css But it's a huge rabbit hole and there are so many stupid details to get right that it feels like an insurmountable task, and if we can't go all the way with it it's better to just maximize compatibility with v3. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-08 15:29:41 -05:00
- Revert adding borders by default to form inputs ([#14929](https://github.com/tailwindlabs/tailwindcss/pull/14929))
Deprecate `shadow-inner` utility (#14933) This PR deprecates the `shadow-inner` value in favor of `inset-shadow-sm` which does the same thing but is composable with other outer shadows. It's still included in the default theme but is registered as `inline reference` and doesn't add any CSS variables to the output. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-09 09:32:04 -05:00
- Deprecate `shadow-inner` utility ([#14933](https://github.com/tailwindlabs/tailwindcss/pull/14933))
Make `leading-none` a static utility (#14934) This PR removes the `--leading-none` variable from the default theme in favor of making `leading-none` a static utility, since it doesn't make sense to change the value of this on a per-project basis. This is consistent with how `none` values work for other utilities in the framework. Some folks in the past have wanted `leading-none` to be `line-height: 0` but technically "leading" is the space between lines, and `line-height: 1` removes all extra space between lines so it feels correct to me (although it means all of the numeric utilities like `leading-6` are not technically correct but I try hard not to think about that too much). If someone wants `line-height: 0` they can use `leading-0` in v4 since the `leading-*` utilities inherit the spacing scale now. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-11-09 09:40:57 -05:00
- Remove `--leading-none` from the default theme in favor of a static `leading-none` utility ([#14934](https://github.com/tailwindlabs/tailwindcss/pull/14934))
Remove `--drop-shadow-none` from default theme (#14847) This PR removes `--drop-shadow-none` from the default theme which shouldn't ever have been there since we handle all `*-none` utilities as static/permanent utilities in the framework now. I've added `drop-shadow-none` as an explicit static utility, and also slightly improved test coverage for `getClassList` around drop shadows while touching this part of the code. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-10-31 14:24:18 -04:00
Prepare v4.0.0-alpha.31 release (#14823) Prepare v4.0.0-alpha.31 release
2024-10-30 12:53:51 +01:00
## [4.0.0-alpha.31] - 2024-10-29
Bump `prettier-plugin-tailwindcss` to latest version during upgrade (#14808) This PR adds a migration to bump the `prettier-plugin-tailwindcss` version to the latest version when upgrading your project. This is to ensure that the plugin is compatible with the latest version of Tailwind CSS. Note: we will only do this _if_ you already used the `prettier-plugin-tailwindcss` plugin in your project.
2024-10-29 00:46:24 +01:00
### Added
Auto source detection improvements (#14820) This PR introduces a new `source(…)` argument and improves on the existing `@source`. The goal of this PR is to make the automatic source detection configurable, let's dig in. By default, we will perform automatic source detection starting at the current working directory. Auto source detection will find plain text files (no binaries, images, ...) and will ignore git-ignored files. If you want to start from a different directory, you can use the new `source(…)` next to the `@import "tailwindcss/utilities" layer(utilities) source(…)`. E.g.: ```css /* ./src/styles/index.css */ @import 'tailwindcss/utilities' layer(utilities) source('../../'); ``` Most people won't split their source files, and will just use the simple `@import "tailwindcss";`, because of this reason, you can use `source(…)` on the import as well: E.g.: ```css /* ./src/styles/index.css */ @import 'tailwindcss' source('../../'); ``` Sometimes, you want to rely on auto source detection, but also want to look in another directory for source files. In this case, yuo can use the `@source` directive: ```css /* ./src/index.css */ @import 'tailwindcss'; /* Look for `blade.php` files in `../resources/views` */ @source '../resources/views/**/*.blade.php'; ``` However, you don't need to specify the extension, instead you can just point the directory and all the same automatic source detection rules will apply. ```css /* ./src/index.css */ @import 'tailwindcss'; @source '../resources/views'; ``` If, for whatever reason, you want to disable the default source detection feature entirely, and only want to rely on very specific glob patterns you define, then you can disable it via `source(none)`. ```css /* Completely disable the default auto source detection */ @import 'tailwindcss' source(none); /* Only look at .blade.php files, nothing else */ @source "../resources/views/**/*.blade.php"; ``` Note: even with `source(none)`, if your `@source` points to a directory, then auto source detection will still be performed in that directory. If you don't want that, then you can simply add explicit files in the globs as seen in the previous example. ```css /* Completely disable the default auto source detection */ @import 'tailwindcss' source(none); /* Run auto source detection in `../resources/views` */ @source "../resources/views"; ``` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-10-29 21:33:34 +01:00
- Support specifying the base path for automatic source detection using a `source(…)` function on `@tailwind utilities` or `@import "tailwindcss"` ([#14820](https://github.com/tailwindlabs/tailwindcss/pull/14820))
- Support disabling automatic source detection with `source(none)` ([#14820](https://github.com/tailwindlabs/tailwindcss/pull/14820))
- Support passing directories to `@source` without needing to pass a complete glob ([#14820](https://github.com/tailwindlabs/tailwindcss/pull/14820))
Bump `prettier-plugin-tailwindcss` to latest version during upgrade (#14808) This PR adds a migration to bump the `prettier-plugin-tailwindcss` version to the latest version when upgrading your project. This is to ensure that the plugin is compatible with the latest version of Tailwind CSS. Note: we will only do this _if_ you already used the `prettier-plugin-tailwindcss` plugin in your project.
2024-10-29 00:46:24 +01:00
- _Upgrade (experimental)_: Bump `prettier-plugin-tailwindcss` to latest version during upgrade ([#14808](https://github.com/tailwindlabs/tailwindcss/pull/14808))
Make `config()` path arg optional in v4 plugin API (#14799) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-28 12:05:57 -04:00
### Fixed
- Support calling `config()` with no arguments in plugin API ([#14799](https://github.com/tailwindlabs/tailwindcss/pull/14799))
Prepare v4.0.0-alpha.30 release (#14789)
2024-10-24 16:22:08 -04:00
Use `inline` and `block` for x/y utilities (#14805) 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>
2024-10-28 13:08:39 -04:00
### Changed
- Use logical `*-inline` and `*-block` properties for all x/y utilities like `px-*`, `my-*`, `scroll-px-*`, and `inset-y-*` ([#14805](https://github.com/tailwindlabs/tailwindcss/pull/14805))
Auto source detection improvements (#14820) This PR introduces a new `source(…)` argument and improves on the existing `@source`. The goal of this PR is to make the automatic source detection configurable, let's dig in. By default, we will perform automatic source detection starting at the current working directory. Auto source detection will find plain text files (no binaries, images, ...) and will ignore git-ignored files. If you want to start from a different directory, you can use the new `source(…)` next to the `@import "tailwindcss/utilities" layer(utilities) source(…)`. E.g.: ```css /* ./src/styles/index.css */ @import 'tailwindcss/utilities' layer(utilities) source('../../'); ``` Most people won't split their source files, and will just use the simple `@import "tailwindcss";`, because of this reason, you can use `source(…)` on the import as well: E.g.: ```css /* ./src/styles/index.css */ @import 'tailwindcss' source('../../'); ``` Sometimes, you want to rely on auto source detection, but also want to look in another directory for source files. In this case, yuo can use the `@source` directive: ```css /* ./src/index.css */ @import 'tailwindcss'; /* Look for `blade.php` files in `../resources/views` */ @source '../resources/views/**/*.blade.php'; ``` However, you don't need to specify the extension, instead you can just point the directory and all the same automatic source detection rules will apply. ```css /* ./src/index.css */ @import 'tailwindcss'; @source '../resources/views'; ``` If, for whatever reason, you want to disable the default source detection feature entirely, and only want to rely on very specific glob patterns you define, then you can disable it via `source(none)`. ```css /* Completely disable the default auto source detection */ @import 'tailwindcss' source(none); /* Only look at .blade.php files, nothing else */ @source "../resources/views/**/*.blade.php"; ``` Note: even with `source(none)`, if your `@source` points to a directory, then auto source detection will still be performed in that directory. If you don't want that, then you can simply add explicit files in the globs as seen in the previous example. ```css /* Completely disable the default auto source detection */ @import 'tailwindcss' source(none); /* Run auto source detection in `../resources/views` */ @source "../resources/views"; ``` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-10-29 21:33:34 +01:00
- Respect automatic source detection heuristics in sources registered with `@source` ([#14820](https://github.com/tailwindlabs/tailwindcss/pull/14820))
Use `inline` and `block` for x/y utilities (#14805) 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>
2024-10-28 13:08:39 -04:00
Prepare v4.0.0-alpha.30 release (#14789)
2024-10-24 16:22:08 -04:00
## [4.0.0-alpha.30] - 2024-10-24
Improve support for custom variants in `group-*`, `peer-*`, `has-*`, and `not-*` variants (#14743) Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-10-24 13:27:27 -04:00
### Added
Update changelog details and naming around the new `not-*` variant (#14785) 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.
2024-10-24 14:50:20 -04:00
- Support `not-*` with all built-in media query and `supports-*` variants ([#14743](https://github.com/tailwindlabs/tailwindcss/pull/14743))
- Support `not-*` with custom variants containing at-rules ([#14743](https://github.com/tailwindlabs/tailwindcss/pull/14743))
- Support `group-*`, `peer-*`, and `has-*` with custom variants containing multiple, non-nested style rules ([#14743](https://github.com/tailwindlabs/tailwindcss/pull/14743))
Improve support for custom variants in `group-*`, `peer-*`, `has-*`, and `not-*` variants (#14743) Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-10-24 13:27:27 -04:00
Ensure individual logical property utilities are sorted later than left/right pair utilities (#14777) 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>
2024-10-24 10:58:41 -04:00
### Fixed
- Ensure individual logical property utilities are sorted later than left/right pair utilities ([#14777](https://github.com/tailwindlabs/tailwindcss/pull/14777))
Upgrade: Improve heuristics around important codemod (#14774) This PR improves the heuristics around the important codemod (e.g. `!border` => `border!`) as we noticed a few more cases where we the current heuristics was not enough. Specifically, we made it not migrate the candidate in the following conditions: - When there's an immediate property access: `{ "foo": !border.something + ""}` - When it's used as condition in the template language: `<div v-if="something && !border"></div>` or `<div x-if="!border"></div>` ## Test plan I added test cases to the unit tests and updated the integration test to contain a more sophisticated example. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-24 17:31:12 +02:00
- Don't migrate important modifiers inside conditional statements in Vue and Alpine (e.g. `<div v-if="!border" />`) ([#14774](https://github.com/tailwindlabs/tailwindcss/pull/14774))
Resolve third-party plugins with `exports` in their `package.json` (#14775) This PR fixes an issue when trying to resolve plugins with `exports` in their `package.json`, like `@headlessui/tailwindcss`. The missing `conditionNames` in the enhanced resolver config would cause it to not properly look up the name. ## Test Plan I added a test using the `postcss` setup (the existing plugin tests are inside the CLI setup but the CLI can only ever run in Module JS mode). To ensure the tests are resolving to the right environment (CJS vs MJS), I added logging of the `import.meta.url` value to the resolver code. When run, this was the output: ![Screenshot 2024-10-24 at 15.28.10.png](https://graphite-user-uploaded-assets-prod.s3.amazonaws.com/0Y77ilPI2WoJfMLFiAEw/c0197934-7b61-47c4-bda5-de037b31d43a.png) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-24 17:34:19 +02:00
- Ensure third-party plugins with `exports` in their `package.json` are resolved correctly ([#14775](https://github.com/tailwindlabs/tailwindcss/pull/14775))
Don't escape underscores for the first parameter of `var()` (#14776) 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>
2024-10-24 17:41:58 +02:00
- Ensure underscores in the `url()` function are never unescaped ([#14776](https://github.com/tailwindlabs/tailwindcss/pull/14776))
Update changelog details and naming around the new `not-*` variant (#14785) 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.
2024-10-24 14:50:20 -04:00
- Ensure complex variants are displayed correctly in IntelliSense completions ([#14743](https://github.com/tailwindlabs/tailwindcss/pull/14743))
Register `migrateImport` to ensure it actually runs (#14769) This PR makes sure the `migrateImport` codemod is properly registered so that it runs as part of the upgrade process. ## Test plan This PR adds a new `v3` playground with an `upgrade` script that you can use to run the upgrade from the local package. When you add a non-prefixed `@import` to the v3 example, the paths are now properly updated with no errors logged: https://github.com/user-attachments/assets/85949bbb-756b-4ee2-8ac0-234fe1b2ca39 --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-10-24 11:00:25 -04:00
- _Upgrade (experimental)_: Ensure `@import` statements for relative CSS files are actually migrated to use relative path syntax ([#14769](https://github.com/tailwindlabs/tailwindcss/pull/14769))
Only generate Preflight compatibility styles when Preflight is used (#14773) This PR improves where we inject the border compatibility CSS. Before this change we injected it if it was necessary in one of these spots: - Above the first `@layer base` to group it together with existing `@layer base` at-rules. - If not present, after the last `@import`, to make sure that we emit valid CSS because `@import` should be at the top (with a few exceptions). However, if you are working with multiple CSS files, then it could be that we injected the border compatibility CSS multiple times if those files met one of the above conditions. To solve this, we now inject the border compatibility CSS with the same rules as above, but we also have another condition: The border compatibility CSS is only injected if the file also has a `@import "tailwindcss";` _or_ `@import "tailwindcss/preflight";` in the current file. --- Added integration tests to make sure that we are generating what we expect in a real environment. Some of the integration tests also use the old `@tailwind` directives to make sure that the order of migrations is correct (first migrate to `@import` syntax, then inject the border compatibility CSS). --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-24 19:19:56 +02:00
- _Upgrade (experimental)_: Only generate Preflight compatibility styles when Preflight is used ([#14773](https://github.com/tailwindlabs/tailwindcss/pull/14773))
Upgrade: Ensure underscores in url() and var() are not escaped (#14778) This PR fixes an issue where currently a `theme()` function call inside an arbitrary value that used a dot in the key path: ```jsx let className = "ml-[theme(spacing[1.5])]" ``` Was causing issues when going though the codemod. The issue is that for candidates, we require `_` to be _escaped_, since otherwise they will be replaced with underscore. When going through the codemods, the above candidate would be translated to the following CSS variable access: ```js let className = "ml-[var(--spacing-1\_5))" ``` Because the underscore was escaped, we now have an invalid string inside a JavaScript file (as the `\` would escape inside the quoted string. To resolve this, we decided that this common case (as its used by the Tailwind CSS default theme) should work without escaping. In https://github.com/tailwindlabs/tailwindcss/pull/14776, we made the changes that CSS variables used via `var()` no longer unescape underscores. This PR extends that so that the Variant printer (that creates the serialized candidate representation after the codemods make changes) take this new encoding into account. This will result in the above example being translated into: ```js let className = "ml-[var(--spacing-1_5))" ``` With no more escaping. Nice! ## Test Plan I have added test for this to the kitchen-sink upgrade tests. Furthermore, to ensure this really works full-stack, I have updated the kitchen-sink test to _actually build the migrated project with Tailwind CSS v4_. After doing so, we can assert that we indeed have the right class name in the generated CSS. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-24 18:49:22 +02:00
- _Upgrade (experimental)_: Don't escape underscores when printing theme values migrated to CSS variables in arbitrary values (e.g. `m-[var(--spacing-1_5)]` instead of `m-[var(--spacing-1\_5)]`) ([#14778](https://github.com/tailwindlabs/tailwindcss/pull/14778))
Ensure `layer(…)` on `@import` is only removed when `@utility` is present (#14783) This PR fixes an issue where `layer(…)` next to imports were removed where they shouldn't have been removed. The issue exists if _any_ of the `@import` nodes in a file contains `@utility`, if that's the case then we removed the `layer(…)` next to _all_ `@import` nodes. Before we were checking if the current sheet contained `@utility` or in any of its children (sub-`@import` nodes). This fixes that by looping over the `@import` nodes in the current sheet, and looking for the `@utility` in the associated/imported file. This way we update each node individually. Test plan: --- Added a dedicated integration test to make sure all codemods together result in the correct result. Input: https://github.com/tailwindlabs/tailwindcss/blob/96e890837809487fecdd713695294cb9961cc1d6/integrations/upgrade/index.test.ts#L2076-L2108 Output: https://github.com/tailwindlabs/tailwindcss/blob/96e890837809487fecdd713695294cb9961cc1d6/integrations/upgrade/index.test.ts#L2116-L2126
2024-10-24 20:33:10 +02:00
- _Upgrade (experimental)_: Ensure `layer(…)` on `@import` is only removed when `@utility` is present ([#14783](https://github.com/tailwindlabs/tailwindcss/pull/14783))
### Changed
- Don't convert underscores in the first argument to `var()` and `theme()` to spaces ([#14776](https://github.com/tailwindlabs/tailwindcss/pull/14776), [#14781](https://github.com/tailwindlabs/tailwindcss/pull/14781))
Sort text wrapping utilities with typography utilities (#14787) 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>
2024-10-24 16:10:20 -04:00
- Sort text alignment and wrapping utilities with typography utilities ([#14787](https://github.com/tailwindlabs/tailwindcss/pull/14787))
- Sort line height and letter spacing utilities before text color utilities ([#14787](https://github.com/tailwindlabs/tailwindcss/pull/14787))
Prepare v4.0.0-alpha.29 release (#14761)
2024-10-23 15:30:26 +02:00
## [4.0.0-alpha.29] - 2024-10-23
Migrate static plugins with options to CSS (#14700) This PR extends our JS configuration to CSS migration by also allowing `plugins` with options. An example of such config would be: ```js import { type Config } from 'tailwindcss' import myPlugin from "./myPlugin"; export default { plugins: [ myPlugin({ class: "tw", }), ], } satisfies Config; ``` If the option object contains only values allowed in our CSS API, we can convert this to CSS entirely: ```css @plugin './myPlugin' { class: 'tw'; } ```
2024-10-18 15:16:27 +02:00
### Added
- _Upgrade (experimental)_: Migrate `plugins` with options to CSS ([#14700](https://github.com/tailwindlabs/tailwindcss/pull/14700))
Upgrade: Allow `corePlugins` in JS config files (#14742) This PR enables JS configuration files with `corePlugins` themes to be migrated. If such option is found in your config, we will warn the user and omit the option from the resulting CSS file as there is no v4 alternative. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-21 22:21:55 +02:00
- _Upgrade (experimental)_: Allow JS configuration files with `corePlugins` options to be migrated to CSS ([#14742](https://github.com/tailwindlabs/tailwindcss/pull/14742))
Upgrade: Rewrite imports of relative files to use relative file paths (#14755) 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>
2024-10-22 22:30:41 +02:00
- _Upgrade (experimental)_: Migrate `@import` statements for relative CSS files to use relative path syntax (e.g. `./file.css`) ([#14755](https://github.com/tailwindlabs/tailwindcss/pull/14755))
Upgrade: Migrate `max-w-screen-*` candidates (#14754) This PR migrates `max-w-screen-*` candidates to the v4 equivalent relying on the breakpoint var: `max-w-[var(--breakpoint-*)]`
2024-10-22 16:40:42 +00:00
- _Upgrade (experimental)_: Migrate `max-w-screen-*` utilities to `max-w-[var(…)]`([#14754](https://github.com/tailwindlabs/tailwindcss/pull/14754))
Add codemod for migrating `@variants` and `@responsive` directives (#14748) This PR migrates the `@variants` and `@responsive` directives. In Tailwind CSS v2, these were used to generate certain variants of responsive variants for the give classes. In Tailwind CSS v3, these still worked but were implemented as a no-op such that these directives don't end up in your final CSS. In Tailwind CSS v4, these don't exist at all anymore, so we can safely get rid of them by replacing them with their contents. Input: ```css @variants hover, focus { .foo { color: red; } } @responsive { .bar { color: blue; } } ``` Output: ```css .foo { color: red; } .bar { color: blue; } ```
2024-10-22 16:09:53 +00:00
- _Upgrade (experimental)_: Migrate `@variants` and `@responsive` directives ([#14748](https://github.com/tailwindlabs/tailwindcss/pull/14748))
Add codemod for migrating the `@screen` directive (#14749) This PR adds a codemod for migrating the old `@screen` directive from Tailwind CSS v2 that also worked in Tailwind CSS v3 but wasn't documented anymore. Internally, this first migrates `@screen md` to `@media screen(md)`, then we rely on the existing migration that migrates the `screen(…)` function. Input: ```css @screen md { .foo { color: red; } } ``` Output (IR): ```css @media screen(md) { .foo { color: red; } } ``` Output: ```css @media theme(--breakpoint-md) { .foo { color: red; } } ```
2024-10-22 16:09:55 +00:00
- _Upgrade (experimental)_: Migrate `@screen` directive ([#14749](https://github.com/tailwindlabs/tailwindcss/pull/14749))
Add codemod for border style compatibility (#14746) This PR adds a codemod that ensures that the border styles from Tailwind CSS v3 work as expected once your project is migrated to Tailwind CSS v4. In Tailwind CSS v3, the default border color is `colors.gray.200` and in Tailwind CSS v4 the default border color is `currentColor`. Similarly in Tailwind CSS v3, DOM elements such as `input`, `select`, and `textarea` have a border width of `0px`, in Tailwind CSS v4, we don't change the border width of these elements and keep them as `1px`. If your project happens to already use the same value for the default border color (`currentColor`) as we use in Tailwind CSS v4, then nothing happens. But this is very unlikely, so we will make sure that we honor your `borderColor.DEFAULT` value. If you didn't change the default values in your `tailwind.config.js`, then we will inject compatibility CSS using the default Tailwind CSS v3 values to ensure the default color and width are applied correctly.
2024-10-22 17:41:50 +00:00
- _Upgrade (experimental)_: Generate compatibility styles for legacy default border color ([#14746](https://github.com/tailwindlabs/tailwindcss/pull/14746))
- _Upgrade (experimental)_: Generate compatibility styles for legacy default border width on form elements ([#14746](https://github.com/tailwindlabs/tailwindcss/pull/14746))
Prepare v4.0.0-alpha.28 release (#14709) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-10-17 17:03:28 -04:00
Ensure existing spaces in attribute selectors are valid (#14703) 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>
2024-10-18 19:51:43 +02:00
### Fixed
- Allow spaces spaces around operators in attribute selector variants ([#14703](https://github.com/tailwindlabs/tailwindcss/pull/14703))
Use `0` instead of `none` in OKLCH values (#14741) 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>
2024-10-21 15:54:27 -04:00
- Ensure color opacity modifiers work with OKLCH colors ([#14741](https://github.com/tailwindlabs/tailwindcss/pull/14741))
Ensure changes to the input CSS file result in a full rebuild (#14744) Fixes #14726 I think we broke this when we changed core so that it can handle `@import "…"` in CSS.
2024-10-21 16:29:33 -04:00
- Ensure changes to the input CSS file result in a full rebuild ([#14744](https://github.com/tailwindlabs/tailwindcss/pull/14744))
Add `postcss` as a dependency of `@tailwindcss/postcss` (#14750) This PR adds `postcss` as a dependency of `@tailwindcss/postcss`. If you are in an environment with Next.js where you can use the `@tailwindcss/postcss` package, then `postcss` is required. If you have `postcss` in your `package.json`, then everything is fine, however if you don't then you will get an error that `postcss` cannot be found. Note: this only happens when you are using `npm`, if you are using `pnpm`, then the `postcss` package can be resolved correctly and you won't run into issues. This is also why the integration tests just worked (because we use `pnpm`). To make sure that this package works for most people in most environments, we explicitly add `postcss` as a dependency of `@tailwindcss/postcss`. --- I wanted to create an integration test for this to make sure this works, but we are currently using `pnpm` with some of `pnpm`'s features to make sure that we can override dependencies that point to `.tgz` files.
2024-10-22 13:20:02 +02:00
- Add `postcss` as a dependency of `@tailwindcss/postcss` ([#14750](https://github.com/tailwindlabs/tailwindcss/pull/14750))
Escape JS theme configuration keys (#14739) 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.
2024-10-22 16:56:16 +00:00
- Ensure the JS `theme()` function can reference CSS theme variables that contain special characters without escaping them (e.g. referencing `--width-1\/2` as `theme('width.1/2')`) ([#14739](https://github.com/tailwindlabs/tailwindcss/pull/14739))
- Ensure JS theme keys containing special characters correctly produce utility classes (e.g. `'1/2': 50%` to `w-1/2`) ([#14739](https://github.com/tailwindlabs/tailwindcss/pull/14739))
Always emit keyframes registered in `addUtilities` (#14747) Fixes #14732 cc @philipp-spiess this look like an okay fix?
2024-10-22 16:34:37 +00:00
- Always emit keyframes registered in `addUtilities` ([#14747](https://github.com/tailwindlabs/tailwindcss/pull/14747))
Vite: Fix issues when loading files via static asset queries (#14716) Fixes: #14558 This PR fixes an issue where our Vite plugin would crash when trying to load stylesheets via certain static asset query parameters: ```ts import raw from './style.css?raw' import url from './style.css?url' ``` The proper behavior for our extension is to _not touch these file at all_. The `?raw` identifier should never transform anything and the `?url` one will emit a module which points to the asset URL. However, if that URL is loaded as a stylesheet, another transform hook is called and the file is properly transformed. I verified this in the Vite setup and have added an integration test ensuring these two features work as expected. I've also greatly reduced the complexity of the Vite playground to make it easier to set up examples like this in the future.
2024-10-22 16:03:07 +00:00
- Ensure loading stylesheets via the `?raw` and `?url` static asset query works when using the Vite plugin ([#14716](https://github.com/tailwindlabs/tailwindcss/pull/14716))
Migrate `flex-grow` -> `grow` and `flex-shrink` -> `shrink` (#14721) This PR adds missing legacy migrations for migrating `flex-grow` to `grow` and `flex-shrink` to `shrink`. We already migrated `flex-grow-0` to `grow-0` and `flex-shrink-0` to `shrink-0`, but forgot about these cases.
2024-10-18 19:58:01 +02:00
- _Upgrade (experimental)_: Migrate `flex-grow` to `grow` and `flex-shrink` to `shrink` ([#14721](https://github.com/tailwindlabs/tailwindcss/pull/14721))
Minify arbitrary values when printing candidates (#14720) 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 #14718 Closes: #14717 Closes: #14718
2024-10-18 22:44:25 +02:00
- _Upgrade (experimental)_: Minify arbitrary values when printing candidates ([#14720](https://github.com/tailwindlabs/tailwindcss/pull/14720))
Ensure we migrate `theme(spacing.1)` to `var(--spacing-1)` correctly (#14724) 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>
2024-10-19 15:19:10 +02:00
- _Upgrade (experimental)_: Ensure legacy theme values ending in `1` (like `theme(spacing.1)`) are correctly migrated to custom properties ([#14724](https://github.com/tailwindlabs/tailwindcss/pull/14724))
Migrate `from`, `via`, and `to` arbitrary values to bare values (#14725) This PR migrates arbitrary values for the `from-*`, `via-*` and `to-*` utilities to bare values. Input: ```html <div class="from-[28%]"></div> <div class="via-[28%]"></div> <div class="to-[28%]"></div> ``` Output: ```html <div class="from-28%"></div> <div class="via-28%"></div> <div class="to-28%"></div> ``` --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-19 15:05:38 +02:00
- _Upgrade (experimental)_: Migrate arbitrary values to bare values for the `from-*`, `via-*`, and `to-*` utilities ([#14725](https://github.com/tailwindlabs/tailwindcss/pull/14725))
Remove `layer(utilities)` if imports contain `@utility` (#14738) We have a migration that adds the `layer(…)` next to the `@import` depending on the order of original values. For example: ```css @import "tailwindcss/utilities": @import "./foo.css": @import "tailwindcss/components": ``` Will be turned into: ```css @import "tailwindcss": @import "./foo.css" layer(utilities): ``` Because it used to exist between `utilities` and `components`. Without this it would be _after_ `components`. This results in an issue if an import has (deeply) nested `@utility` at-rules after migrations. This is because if this is generated: ```css /* ./src/index.css */ @import "tailwindcss"; @import "./foo.css" layer(utilities); /* ./src/foo.css */ @utility foo { color: red; } ``` Once we interpret this (and thus flatten it), the final CSS would look like: ```css @layer utilities { @utility foo { color: red; } } ``` This means that `@utility` is not top-level and an error would occur. This fixes that by removing the `layer(…)` from the import if the imported file (or any of its children) contains an `@utility`. This is to ensure that once everything is imported and flattened, that all `@utility` at-rules are top-level.
2024-10-21 23:46:24 +02:00
- _Upgrade (experimental)_: Ensure `layer(utilities)` is removed from `@import` to keep `@utility` top-level ([#14738](https://github.com/tailwindlabs/tailwindcss/pull/14738))
Upgrade: Migrate JS theme configuration keys with dot and slash in the property name (#14736) 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>
2024-10-22 21:57:08 +02:00
- _Upgrade (experimental)_: Ensure JS theme keys with special characters are escaped when migrated to CSS variables ([#14736](https://github.com/tailwindlabs/tailwindcss/pull/14736))
Upgrade: Reduce number of false-positive migrations of the important modifier (#14737) The important candidate migration is one of the most broad we have since it matches for any utility that are prefixed with an exclamation mark. When running the codemodes on our example projects, we noticed that this was instead creating false-positives with candidates used in code positions, e.g: ```ts export default { shouldNotUse: !border.shouldUse, } ``` To prevent false-positives, this PR adds a heuristics to detect wether or not a candidate is used in a non-code position. We do this by checking the character before and after the modifier and only allow quotes or spaces. This can cause candidates to not migrate that are valid Tailwind CSS classes, e.g.: ```ts let classNames = `!underline${isHovered ? ' font-bold' : ''}` ``` This, however, is not a big issue since v4 can parse the v3 important prefix too.
2024-10-22 16:24:30 +00:00
- _Upgrade (experimental)_: Don't migrate important modifiers that are actually logical negations (e.g. `let foo = !border` to `let foo = border!`) ([#14737](https://github.com/tailwindlabs/tailwindcss/pull/14737))
Ensure existing spaces in attribute selectors are valid (#14703) 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>
2024-10-18 19:51:43 +02:00
`content` rules from the JS config that are also covered by the automatic source detection should not be migrated to CSS (#14714) This PR changes the migration of `content` rules in the JS config to CSS codemods. When a `content` rule is processed which matches files that are _also matched by the automatic content discovery in v4_, we do not need to emit CSS for that rule. Take, for example this v3 configuration file: ```ts import { type Config } from 'tailwindcss' module.exports = { content: [ './src/**/*.{html,js}', './node_modules/my-external-lib/**/*.{html}' ], } satisfies Config ``` Provided the base directories match up, the first rule will also be covered by the automatic content discovery in v4 and thus we only need to convert the second rule to CSS: ```css @import "tailwindcss"; @source '../node_modules/my-external-lib/**/*.{html}'; ```
2024-10-18 15:48:56 +02:00
### Changed
Upgrade: Rewrite imports of relative files to use relative file paths (#14755) 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>
2024-10-22 22:30:41 +02:00
- Require a relative path prefix for importing relative CSS files (e.g. `@import './styles.css'` instead of `@import 'styles.css'`) ([#14755](https://github.com/tailwindlabs/tailwindcss/pull/14755))
`content` rules from the JS config that are also covered by the automatic source detection should not be migrated to CSS (#14714) This PR changes the migration of `content` rules in the JS config to CSS codemods. When a `content` rule is processed which matches files that are _also matched by the automatic content discovery in v4_, we do not need to emit CSS for that rule. Take, for example this v3 configuration file: ```ts import { type Config } from 'tailwindcss' module.exports = { content: [ './src/**/*.{html,js}', './node_modules/my-external-lib/**/*.{html}' ], } satisfies Config ``` Provided the base directories match up, the first rule will also be covered by the automatic content discovery in v4 and thus we only need to convert the second rule to CSS: ```css @import "tailwindcss"; @source '../node_modules/my-external-lib/**/*.{html}'; ```
2024-10-18 15:48:56 +02:00
- _Upgrade (experimental)_: Don't create `@source` rules for `content` paths that are already covered by automatic source detection ([#14714](https://github.com/tailwindlabs/tailwindcss/pull/14714))
Prepare v4.0.0-alpha.28 release (#14709) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-10-17 17:03:28 -04:00
## [4.0.0-alpha.28] - 2024-10-17
Migrate `theme(…)` calls to `var(…)` or the modern `theme(…)` syntax (#14664) 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.
2024-10-16 16:44:21 +02:00
### Added
Add first draft of new wide-gamut color palette (#14693) 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>
2024-10-16 15:24:53 -04:00
- Add first draft of new wide-gamut color palette ([#14693](https://github.com/tailwindlabs/tailwindcss/pull/14693))
Support linear gradient angles as bare values (#14707) 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>
2024-10-17 14:29:32 -04:00
- Support linear gradient angles as bare values ([#14707](https://github.com/tailwindlabs/tailwindcss/pull/14707))
Interpolate gradients using OKLCH by default (#14708) 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>
2024-10-17 16:16:14 -04:00
- Interpolate gradients in OKLCH by default ([#14708](https://github.com/tailwindlabs/tailwindcss/pull/14708))
Migrate `theme(…)` to `var(…)` in CSS (#14695) This PR is a follow up from https://github.com/tailwindlabs/tailwindcss/pull/14664 migrates all the `theme(…)` calls in your CSS to `var(…)` if we can. In at-rules, like `@media` we can't use `var(…)` so we have to use the modern version of `theme(…)`. In declarations, we can convert to `var(…)` unless there is a modifier used in the `theme(…)` function, then we can only convert to the new `theme(…)` syntax without dot notation. Input: ```css @media theme(spacing.4) { .foo { background-color: theme(colors.red.900); color: theme(colors.red.900 / 75%); /* With spaces around the `/` */ border-color: theme(colors.red.200/75%); /* Without spaces around the `/` */ } } ``` Output: ```css @media theme(--spacing-4) { /* ^^^^^^^^^^^^^^^^^^ Use `theme(…)` since `var(…)` is invalid in this position*/ .foo { background-color: var(--color-red-900); /* Converted to var(…) */ color: theme(--color-red-900 / 75%); /* Convert to modern theme(…) */ border-color: theme(--color-red-200 / 75%); /* Convert to modern theme(…) — pretty printed*/ } } ```
2024-10-17 11:50:27 +02:00
- _Upgrade (experimental)_: Migrate `theme(…)` calls to `var(…)` or to the modern `theme(…)` syntax ([#14664](https://github.com/tailwindlabs/tailwindcss/pull/14664), [#14695](https://github.com/tailwindlabs/tailwindcss/pull/14695))
Resolve theme keys when migrating JS config to CSS (#14675) 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>
2024-10-17 22:36:47 +02:00
- _Upgrade (experimental)_: Support migrating JS configurations to CSS that contain functions inside the `theme` object ([#14675](https://github.com/tailwindlabs/tailwindcss/pull/14675))
Migrate `theme(…)` calls to `var(…)` or the modern `theme(…)` syntax (#14664) 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.
2024-10-16 16:44:21 +02:00
Add missing changelog entry (#14686) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2024-10-16 13:25:53 +02:00
### Fixed
Reset `default` @theme values for non `extend` JS theme config (#14672) 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_.
2024-10-16 16:06:09 +02:00
- Ensure `theme` values defined outside of `extend` in JS configuration files overwrite all existing values for that namespace ([#14672](https://github.com/tailwindlabs/tailwindcss/pull/14672))
Remove invalid gradient fallbacks (#14705) 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>
2024-10-17 13:48:58 -04:00
- Remove unnecessary variable fallbacks in gradient utilities ([#14705](https://github.com/tailwindlabs/tailwindcss/pull/14705))
Add missing changelog entry (#14686) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2024-10-16 13:25:53 +02:00
- _Upgrade (experimental)_: Speed up template migrations ([#14679](https://github.com/tailwindlabs/tailwindcss/pull/14679))
Don't generate invalid CSS when migrating a complex `screens` config (#14691) Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-10-16 18:08:27 +02:00
- _Upgrade (experimental)_: Don't generate invalid CSS when migrating a complex `screens` config ([#14691](https://github.com/tailwindlabs/tailwindcss/pull/14691))
Release v4.0.0-alpha.27 (#14671)
2024-10-15 12:28:34 +02:00
## [4.0.0-alpha.27] - 2024-10-15
Support keyframes in JS theme config (#14594) Adds support for defining `keyframes` via the v3 JS config file. E.g.: ```js module.exports = { theme: { extends: { keyframes: { "fade-in": { "0%": { opacity: "0" }, "100%": { opacity: "1" }, }, "fade-out": { "0%": { opacity: "1" }, "100%": { opacity: "0" }, }, }, }, }, }; ```
2024-10-04 13:58:30 +02:00
### Added
Add `*.js` export variants for compat files (#14595) In v3 it was possible to import `*.js` variants of compat files, e.g. `tailwindcss/plugin.js` in addition to `tailwindcss/plugin`. We need to properly map the exports to support this.
2024-10-04 15:38:55 +02:00
- Add support for `tailwindcss/colors.js`, `tailwindcss/defaultTheme.js`, and `tailwindcss/plugin.js` exports ([#14595](https://github.com/tailwindlabs/tailwindcss/pull/14595))
Ensure upgrade tool has access to a JS config (#14597) In order to properly migrate your Tailwind CSS v3 project to v4, we need access to the JavaScript configuration object. This was previously only required for template migrations, but in this PR we're making it so that this is also a prerequisite of the CSS migrations. This is because some migrations, like `@apply`, also need to convert candidates that to the v4 syntax and we need the full config in order to properly validate them. In addition to requiring a JS config, we also now attempt to automatically find the right configuration file inside the current working directory. This is now matching the behavior of the Tailwind CSS v3 CLI where it will find the config automatically if it's in the current directory and called `tailwind.conf.js`. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-10-07 18:02:28 +02:00
- Support `keyframes` in JS config file themes ([#14594](https://github.com/tailwindlabs/tailwindcss/pull/14594))
Support the `color` property in JS theme configuration callbacks (#14651) 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>
2024-10-11 18:07:59 +02:00
- Support the `color` parameter in JS theme configuration callbacks ([#14651](https://github.com/tailwindlabs/tailwindcss/pull/14651))
Callback in theme properties is also the theme function (#14659) 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
2024-10-14 12:29:12 +02:00
- Support using the object parameter in the JS theme configuration callback as `theme()` function ([#14659](https://github.com/tailwindlabs/tailwindcss/pull/14659))
Update CHANGELOG.md
2024-10-11 09:50:53 -04:00
- _Upgrade (experimental)_: Automatically discover JavaScript config files ([#14597](https://github.com/tailwindlabs/tailwindcss/pull/14597))
update CHANGELOG
2024-10-11 15:56:12 +02:00
- _Upgrade (experimental)_: Inject `@config "…"` when a `tailwind.config.{js,ts,…}` is detected ([#14635](https://github.com/tailwindlabs/tailwindcss/pull/14635))
Release v4.0.0-alpha.27 (#14671)
2024-10-15 12:28:34 +02:00
- _Upgrade (experimental)_: Migrate `@media screen(…)` when running codemods ([#14603](https://github.com/tailwindlabs/tailwindcss/pull/14603))
Migrate `aria-*`, `data-*` and `supports-*` variants from arbitrary values to bare values (#14644) This PR adds a new codemod that can migrate `data-*` and `aria-*` variants using arbitrary values to bare values. In Tailwind CSS v3, if you want to conditionally apply a class using data attributes, then you can write `data-[selected]:flex`. This requires the DOM element to have a `data-selected=""` attribute. In Tailwind CSS v4 we can simplify this, by dropping the brackets and by using `data-selected:flex` directly. This migration operates on the internal AST, which means that this also just works for compound variants such as `group-has-data-[selected]:flex` (which turns into `group-has-data-selected:flex`). Additionally, this codemod is also applicable to `aria-*` variants. The biggest difference is that in v4 `aria-selected` maps to an attribute of `aria-selected="true"`. This means that we can only migrate `aria=[selected="true"]:flex` to `aria-selected:flex`. Last but not least, we also migrate `supports-[gap]` to `supports-gap` if the passed in value looks like a property. If not, e.g.: `supports-[display:grid]` then it stays as-is.
2024-10-11 16:41:37 +02:00
- _Upgrade (experimental)_: Migrate `aria-*`, `data-*`, and `supports-*` variants from arbitrary values to bare values ([#14644](https://github.com/tailwindlabs/tailwindcss/pull/14644))
Migrate arbitrary values to bare values (#14669) This PR adds a codemod that can convert arbitrary values to the cleaner bare values if we can. For example, some classes use arbitrary values such as `col-start-[16]`, but in v4 we have bare values for some plugins that don't really need to adhere to your design system. In this case, we can convert `col-start-[16]` to just `col-start-16`. Another use case is for utilities that use fractions. For example the `aspect-*` plugin. A custom aspect ratio such as `aspect-[16/9]` can be converted to `aspect-16/9`. There are some rules attached to this migration: 1. We can only migrate arbitrary values that is a single positive integer, or an arbitrary value that is a fraction where the numerator and denominator are both positive integers. 2. We make sure that some CSS can be generated once its converted to a bare value.
2024-10-15 11:45:03 +02:00
- _Upgrade (experimental)_: Migrate arbitrary values to bare values ([#14669](https://github.com/tailwindlabs/tailwindcss/pull/14669))
Release v4.0.0-alpha.27 (#14671)
2024-10-15 12:28:34 +02:00
- _Upgrade (experimental)_: Migrate legacy classes to the v4 alternative ([#14643](https://github.com/tailwindlabs/tailwindcss/pull/14643))
- _Upgrade (experimental)_: Migrate static JS configurations to CSS ([#14639](https://github.com/tailwindlabs/tailwindcss/pull/14639), [#14650](https://github.com/tailwindlabs/tailwindcss/pull/14650), [#14648](https://github.com/tailwindlabs/tailwindcss/pull/14648), [#14666](https://github.com/tailwindlabs/tailwindcss/pull/14666))
- _Upgrade (experimental)_: Migrate v3 PostCSS setups to v4 in some cases ([#14612](https://github.com/tailwindlabs/tailwindcss/pull/14612))
Support keyframes in JS theme config (#14594) Adds support for defining `keyframes` via the v3 JS config file. E.g.: ```js module.exports = { theme: { extends: { keyframes: { "fade-in": { "0%": { opacity: "0" }, "100%": { opacity: "1" }, }, "fade-out": { "0%": { opacity: "1" }, "100%": { opacity: "0" }, }, }, }, }, }; ```
2024-10-04 13:58:30 +02:00
Don’t crash when scanning candidate matching the prefix (#14588) When a prefix is set in a stylesheet and we found a candidate that is equal to the prefix we would crash: ```css @import "tailwindcss" prefix(tomato); ``` ```js console.log("tomato") ``` This PR fixes this case by ensuring that we have something that looks like a variant before considering a prefix.
2024-10-04 05:58:20 -04:00
### Fixed
- Don’t crash when scanning a candidate equal to the configured prefix ([#14588](https://github.com/tailwindlabs/tailwindcss/pull/14588))
improve CHANGELOG
2024-10-07 11:44:22 +02:00
- Ensure there's always a space before `!important` when stringifying CSS ([#14611](https://github.com/tailwindlabs/tailwindcss/pull/14611))
Fix CLI client crash when a file is removed before we process the change notification (#14616) Fixes #14613 Don't crash when trying to read the modification time of a file that might already be deleted. Note: This fix is purely theoretical right now as I wasn't able to reproduce the issue yet. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-10-09 16:56:08 +02:00
- Don't set `display: none` on elements that use `hidden="until-found"` ([#14631](https://github.com/tailwindlabs/tailwindcss/pull/14631))
Fix CSS `theme()` function resolution issue (#14614) 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).
2024-10-10 12:31:46 +02:00
- Ensure the CSS `theme()` function resolves to the right value in some compatibility situations ([#14614](https://github.com/tailwindlabs/tailwindcss/pull/14614))
Fix CLI client crash when a file is removed before we process the change notification (#14616) Fixes #14613 Don't crash when trying to read the modification time of a file that might already be deleted. Note: This fix is purely theoretical right now as I wasn't able to reproduce the issue yet. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-10-09 16:56:08 +02:00
- Fix issue that could cause the CLI to crash when files are deleted while watching ([#14616](https://github.com/tailwindlabs/tailwindcss/pull/14616))
Ensure custom variants using the JS API have access to modifiers (#14637) Fixes https://github.com/tailwindlabs/tailwindcss/discussions/14623 We didn't properly pass through modifiers for all custom variant calls. This PR fixes that.
2024-10-10 12:14:51 +02:00
- Ensure custom variants using the JS API have access to modifiers ([#14637](https://github.com/tailwindlabs/tailwindcss/pull/14637))
Ensure auto complete suggestions work when using `matchUtilities` (#14589) 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.
2024-10-10 08:51:52 -04:00
- Ensure auto complete suggestions work when using `matchUtilities` ([#14589](https://github.com/tailwindlabs/tailwindcss/pull/14589))
Pass options when using `addComponents` and `matchComponents` (#14590) 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 😬
2024-10-10 08:56:59 -04:00
- Pass options when using `addComponents` and `matchComponents` ([#14590](https://github.com/tailwindlabs/tailwindcss/pull/14590))
Tweak changelog entries (#14649)
2024-10-11 10:38:46 -04:00
- Ensure `boxShadow` and `animation` theme keys in JS config files are accessible under `--shadow-*` and `--animate-*` using the `theme()` function ([#14642](https://github.com/tailwindlabs/tailwindcss/pull/14642))
- Ensure all theme keys with new names are also accessible under their old names when using the `theme()` function with the legacy dot notation syntax ([#14642](https://github.com/tailwindlabs/tailwindcss/pull/14642))
Fix `var(…)` as the opacity value inside the `theme(…)` function (#14653) 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)).
2024-10-14 14:08:41 +02:00
- Ensure `var(…)` can be used as the opacity value inside the `theme([path] / [modifier])` function ([#14653](https://github.com/tailwindlabs/tailwindcss/pull/14653))
Ensure `font-stretch` utilities only accepts positive integer bare values (#14670) 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.
2024-10-15 11:39:05 +02:00
- Ensure `font-stretch` utilities only accepts positive integer bare values ([#14670](https://github.com/tailwindlabs/tailwindcss/pull/14670))
Fix template migration issues (#14600) 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.
2024-10-08 18:06:43 +02:00
- _Upgrade (experimental)_: Ensure CSS before a layer stays unlayered when running codemods ([#14596](https://github.com/tailwindlabs/tailwindcss/pull/14596))
- _Upgrade (experimental)_: Resolve issues where some prefixed candidates were not properly migrated ([#14600](https://github.com/tailwindlabs/tailwindcss/pull/14600))
release v4.0.0-alpha.26
2024-10-03 16:39:59 +02:00
## [4.0.0-alpha.26] - 2024-10-03
Add support for prefixes (#14501) This PR adds support for requiring a custom prefix on utility classes. Prefixes work a bit differently in v4 than they did in v3: - They look like a custom variant: `tw:bg-white` - It is always first in a utility — even before other variants: `tw:hover:bg-white` - It is required on **all** utility classes — even arbitrary properties: `tw:[color:red]` - Prefixes also apply to generated CSS variables which will be separated by a dash: `--tw-color-white: #fff;` - Only alpha (a-z) characters are allowed in a prefix — so no `#tw#` or `__` or similar prefixes are allowed To configure a prefix you can use add `prefix(tw)` to your theme or when importing Tailwind CSS like so: ```css /* when importing `tailwindcss` */ @import 'tailwindcss' prefix(tw); /* when importing the theme separately */ @import 'tailwindcss/theme' prefix(tw); /* or when using an entirely custom theme */ @theme prefix(tw) { --color-white: #fff; --breakpoint-sm: 640px; /* … */ } ``` This will configure Tailwind CSS to require a prefix on all utility classes when used in HTML: ```html <div class="tw:bg-white tw:p-4"> This will have a white background and 4 units of padding. </div> <div class="bg-white p-4"> This will not because the prefix is missing. </div> ``` and when used in CSS via `@apply`: ```css .my-class { @apply tw:bg-white tw:p-4; } ``` Additionally, the prefix will be added to the generated CSS variables. You **do not** need to prefix the variables in the `@theme` block yourself — Tailwind CSS handles this automatically. ```css :root { --tw-color-white: #fff; --tw-breakpoint-sm: 640px; } ``` A prefix is not necessary when using the `theme(…)` function in your CSS or JS given that plugins will not know what the current prefix is and must work with or without a prefix: ```css .my-class { color: theme(--color-white); } ``` However, because the variables themselves are prefixed when outputting the CSS, you **do** need to prefix the variables when using `var(…)` in your CSS: ```css .my-class { color: var(--tw-color-white); } ``` If you want to customize the prefix itself change `tw` to something else: ```css /* my:underline, my:hover:bg-red-500, etc… */ @import 'tailwindcss' prefix(my); ``` --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-09-25 10:06:37 -04:00
### Added
- Add support for prefixes ([#14501](https://github.com/tailwindlabs/tailwindcss/pull/14501))
Expose timing information in debug mode (#14553) This PR exposes when using the the `DEBUG` environment variable. This follows the `DEBUG` conventions where: - `DEBUG=1` - `DEBUG=true` - `DEBUG=*` - `DEBUG=tailwindcss` Will enable the debug information, but when using: - `DEBUG=0` - `DEBUG=false` - `DEBUG=-tailwindcss` It will not. This currently only exposes some timings related to: 1. Scanning for candidates 2. Building the CSS 3. Optimizing the CSS We can implement a more advanced version of this where we also expose more fine grained information such as the files we scanned, the amount of candidates we found and so on. But I believe that this will be enough to start triaging performance related issues.
2024-09-30 16:39:21 +02:00
- Expose timing information in debug mode ([#14553](https://github.com/tailwindlabs/tailwindcss/pull/14553))
Update CHANGELOG.md
2024-10-03 12:52:18 -04:00
- Add support for `blocklist` in JS config files ([#14556](https://github.com/tailwindlabs/tailwindcss/pull/14556))
Add color-scheme utilities (#14567) Replaces #11271 — the merge conflicts are killing me and it's way easier to just do it again (added you as a co-author though @lukewarlow so you're still credited!) This PR adds the following new utilities for the `color-scheme` property: | Class | CSS | | ------------------- | -------------------------- | | `scheme-normal` | `color-scheme: normal` | | `scheme-dark` | `color-scheme: dark` | | `scheme-light` | `color-scheme: light` | | `scheme-light-dark` | `color-scheme: light dark` | | `scheme-only-dark` | `color-scheme: dark only` | | `scheme-only-light` | `color-scheme: light only` | Went with `scheme-*` for the utilities because there are currently no other CSS properties with the word `scheme` in them and `scheme-light-dark` is going to be a common value which is three words already even with the shortened property name. I considered setting `color-scheme: light dark` by default as part of Preflight for this PR but decided against it, at least for this PR. I think that could still be a useful default but we should think about it a bit more because if you're building a light-mode-only site it'll force you to do some extra work. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Luke Warlow <lwarlow@igalia.com>
2024-10-02 06:07:55 -04:00
- Add `color-scheme` utilities ([#14567](https://github.com/tailwindlabs/tailwindcss/pull/14567))
Update CHANGELOG.md
2024-10-03 12:52:18 -04:00
- Add support for `important` option in JS config files ([#14448](https://github.com/tailwindlabs/tailwindcss/pull/14448))
Update CHANGELOG.md
2024-10-03 13:22:21 -04:00
- _Upgrade (experimental)_: Convert `@import "tailwindcss/tailwind.css"` to `@import "tailwindcss"` in CSS files ([#14514](https://github.com/tailwindlabs/tailwindcss/pull/14514))
- _Upgrade (experimental)_: Apply all utility upgrades to `@apply` in CSS files ([#14574](https://github.com/tailwindlabs/tailwindcss/pull/14574))
- _Upgrade (experimental)_: Update variant order in template files ([#14524](https://github.com/tailwindlabs/tailwindcss/pull/14524]))
- _Upgrade (experimental)_: Convert `bg-gradient-*` utilities to `bg-linear-*` in template files ([#14537](https://github.com/tailwindlabs/tailwindcss/pull/14537]))
- _Upgrade (experimental)_: Convert legacy prefixes to variant prefixes in template files ([#14557](https://github.com/tailwindlabs/tailwindcss/pull/14557]))
- _Upgrade (experimental)_: Convert bare CSS variables in arbitrary values to `var(…)` in template files ([#14526](https://github.com/tailwindlabs/tailwindcss/pull/14526))
- _Upgrade (experimental)_: Convert legacy important modifier syntax to trailing syntax ([#14502](https://github.com/tailwindlabs/tailwindcss/pull/14502))
Add support for prefixes (#14501) This PR adds support for requiring a custom prefix on utility classes. Prefixes work a bit differently in v4 than they did in v3: - They look like a custom variant: `tw:bg-white` - It is always first in a utility — even before other variants: `tw:hover:bg-white` - It is required on **all** utility classes — even arbitrary properties: `tw:[color:red]` - Prefixes also apply to generated CSS variables which will be separated by a dash: `--tw-color-white: #fff;` - Only alpha (a-z) characters are allowed in a prefix — so no `#tw#` or `__` or similar prefixes are allowed To configure a prefix you can use add `prefix(tw)` to your theme or when importing Tailwind CSS like so: ```css /* when importing `tailwindcss` */ @import 'tailwindcss' prefix(tw); /* when importing the theme separately */ @import 'tailwindcss/theme' prefix(tw); /* or when using an entirely custom theme */ @theme prefix(tw) { --color-white: #fff; --breakpoint-sm: 640px; /* … */ } ``` This will configure Tailwind CSS to require a prefix on all utility classes when used in HTML: ```html <div class="tw:bg-white tw:p-4"> This will have a white background and 4 units of padding. </div> <div class="bg-white p-4"> This will not because the prefix is missing. </div> ``` and when used in CSS via `@apply`: ```css .my-class { @apply tw:bg-white tw:p-4; } ``` Additionally, the prefix will be added to the generated CSS variables. You **do not** need to prefix the variables in the `@theme` block yourself — Tailwind CSS handles this automatically. ```css :root { --tw-color-white: #fff; --tw-breakpoint-sm: 640px; } ``` A prefix is not necessary when using the `theme(…)` function in your CSS or JS given that plugins will not know what the current prefix is and must work with or without a prefix: ```css .my-class { color: theme(--color-white); } ``` However, because the variables themselves are prefixed when outputting the CSS, you **do** need to prefix the variables when using `var(…)` in your CSS: ```css .my-class { color: var(--tw-color-white); } ``` If you want to customize the prefix itself change `tw` to something else: ```css /* my:underline, my:hover:bg-red-500, etc… */ @import 'tailwindcss' prefix(my); ``` --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-09-25 10:06:37 -04:00
Improve missing layer codemod (#14512) This PR improves the missing layers codemod where everything after the last Tailwind directive can stay as-is without wrapping it in a `@layer` directive. The `@layer` at-rules are only important for CSS that exists between Tailwind directives. E.g.: ```css @tailwind base; html {} @tailwind components; .btn {} @tailwind utilities; .foo {} .bar {} ``` Was transformed into: ```css @import "tailwindcss"; @layer base { html {} } @layer components { .btn {} } @layer utilities { .foo {} .bar {} } ``` But the last `@layer utilities` is already in the correct spot, so we can simplify this to just this instead: ```css @import "tailwindcss"; @layer base { html {} } @layer components { .btn {} } .foo {} .bar {} ```
2024-09-25 10:42:19 +02:00
### Fixed
CLI: Use the right `base` when loading files from `stdin` (#14522) Fixes #14521 When using the CLI to read files from `stdin` like this: ```bash npx tailwindcss --input=- -o bar.css < foo.css ``` We need to set the `base` path to be the current working directory (`process.cwd()`). However, `cwd()` already _is_ a directory and calling `dirname()` on it did go to the parent directory _which might not have the `tailwindcss` dependency installed.
2024-09-26 12:32:46 +02:00
- Use the right import base path when using the CLI to reading files from stdin ([#14522](https://github.com/tailwindlabs/tailwindcss/pull/14522))
CSS codemod: inject `@import` in a more expected location (#14536) This PR inserts the `@import` in a more sensible location when running codemods. The idea is that we replace `@tailwind base; @tailwind components; @tailwind utilities;` with the much simple `@import "tailwindcss";`. We did this by adding the `@import` to the top of the file. While this is correct, this means that the diff might not be as clear. For example, if you have a situation where you have a license comment: ```css /**! My license comment */ @tailwind base; @tailwind components; @tailwind utilities; ``` This resulted in: ```css @import "tailwindcss"; /**! My license comment */ ``` While it is not wrong, it feels weird that this behaves like this. In this commit we make sure that it is injected in-place (the first `@tailwind` at-rule we find) and fixup the position if we can't inject it in-place. The above example results in this: ```css /**! My license comment */ @import "tailwindcss"; ``` However, there are scenario's where you can't replace the `@tailwind` directives directly. E.g.: ```css /**! My license comment */ html { color: red; } @tailwind base; @tailwind components; @tailwind utilities; ``` If we replace the `@tailwind` directives in-place, it would look like this: ```css /**! My license comment */ html { color: red; } @import "tailwindcss"; ``` But this is invalid CSS, because you can't have CSS above an `@import` at-rule. There are some exceptions like: - `@charset` - `@import` - `@layer foo, bar;` (just the order, without a body) - comments In this scenario, we inject the import in the nearest place where it is allowed to. In this case: ```css /**! My license comment */ @import "tailwindcss"; @layer base { html { color: red; } } ``` Additionally, we will wrap the existing CSS in an `@layer` of the first Tailwind directive we saw. In this case an `@layer base`. This ensures that utilities still win from the default styles. Also note that the (license) comment is allowed to exist before the `@import`, therefore we do not put the `@import` above it. This also means that the diff doesn't touch the license header at all, which makes the diffs cleaner and easier to reason about. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-09-30 15:32:30 +02:00
- Ensure that `@utility` is top-level and cannot be nested ([#14525](https://github.com/tailwindlabs/tailwindcss/pull/14525))
Improve `@tailwindcss/postcss` performance for initial builds (#14565) This PR improves the performance of the `@tailwindcss/postcss` plugin. Before this change we created 2 compiler instances instead of a single one. On a project where a `tailwindcss.config.ts` file is used, this means that the timings look like this: ``` [@tailwindcss/postcss] Setup compiler: 137.525ms ⋮ [@tailwindcss/postcss] Setup compiler: 43.95ms ``` This means that with this small change, we can easily shave of ~50ms for initial PostCSS builds. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-10-03 16:21:54 +02:00
- Only setup a single compiler in `@tailwindcss/postcss` for initial builds ([#14565](https://github.com/tailwindlabs/tailwindcss/pull/14565))
Fix `@apply` and CSS functions inside imported files (#14576) Part-of #14558 After handling `@import` of stylesheets in core, we can no longer gate out features based on finding a specific sequence in the input CSS, as this string will not contain contents from other stylesheets. So, consider the following input CSS: ```css @import "tailwindcsss"; @import "./styles.css"; ``` We can't opt-out of the traversal to search for `@apply` based on it because it, of course, does not contain the contents of `./styles.css` yet. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-10-03 15:23:03 +02:00
- Ensure editing imported CSS files triggers a rebuild ([#14561](https://github.com/tailwindlabs/tailwindcss/pull/14561))
- Ensure `@apply` and CSS functions work inside imported stylesheets ([#14576](https://github.com/tailwindlabs/tailwindcss/pull/14576))
Update CHANGELOG.md
2024-10-03 13:22:21 -04:00
- _Upgrade (experimental)_: Don't wrap custom CSS after utilities in a layer ([#14512](https://github.com/tailwindlabs/tailwindcss/pull/14512))
- _Upgrade (experimental)_: Don't add empty `layer()` to `@import` at-rules when the styles do not need to be imported into a layer ([#14513](https://github.com/tailwindlabs/tailwindcss/pull/14513))
- _Upgrade (experimental)_: Don't wrap comment nodes in `@layer` when running codemods ([#14517](https://github.com/tailwindlabs/tailwindcss/pull/14517))
- _Upgrade (experimental)_: Fix scenario where selectors can be lost in multi-selector rules ([#14518](https://github.com/tailwindlabs/tailwindcss/pull/14518))
- _Upgrade (experimental)_: Ensure custom CSS before `@tailwind` rules is wrapped with `@layer base` when prepending `@import "tailwindcss"` to the top of the file ([#14536](https://github.com/tailwindlabs/tailwindcss/pull/14536))
Release v4.0.0-alpha.25 (#14507)
2024-09-24 19:03:00 +02:00
Bare values: Disallow zeros in decimal places (#14562) I noticed some more unexpected values being passed through as _bare values_: Decimal places with zero. These should not generate CSS but currently does: - `from-25.%` - `from-25.0%` - `from-25.00%` - etc.
2024-10-01 16:06:43 +02:00
### Changed
- Disallow bare values with decimal places ([#14562](https://github.com/tailwindlabs/tailwindcss/pull/14562))
Release v4.0.0-alpha.25 (#14507)
2024-09-24 19:03:00 +02:00
## [4.0.0-alpha.25] - 2024-09-24
Create variants for `aria`, `supports`, and `data` JS config theme keys (#14407) This PR adds support for the `aria`, `supports`, and `data` properties found in JS config options. In v3, you could extend the theme to add more variants by using an object syntax like this: ```ts { theme: { extend: { aria: { polite: 'live="polite"', }, supports: { 'child-combinator': 'h2 > p', }, data: { checked: 'ui~="checked"', }, }, } } ``` Since we no longer rely on theme variables for these variants, the way to make this work is by adding custom variants for each of these manually added variants. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-17 17:09:42 +02:00
### Added
- Add support for `aria`, `supports`, and `data` variants defined in JS config files ([#14407](https://github.com/tailwindlabs/tailwindcss/pull/14407))
Add initial codemod tooling (#14434) This PR adds some initial tooling for codemods. We are currently only interested in migrating CSS files, so we will be using PostCSS under the hood to do this. This PR also implements the "migrate `@apply`" codemod from #14412. The usage will look like this: ```sh npx @tailwindcss/upgrade ``` You can pass in CSS files to transform as arguments: ```sh npx @tailwindcss/upgrade src/**/*.css ``` But, if none are provided, it will search for CSS files in the current directory and its subdirectories. ``` ≈ tailwindcss v4.0.0-alpha.24 │ No files provided. Searching for CSS files in the current │ directory and its subdirectories… │ Migration complete. Verify the changes and commit them to │ your repository. ``` The tooling also requires the Git repository to be in a clean state. This is a common convention to ensure that everything is undo-able. If we detect that the git repository is dirty, we will abort the migration. ``` ≈ tailwindcss v4.0.0-alpha.24 │ Git directory is not clean. Please stash or commit your │ changes before migrating. │ You may use the `--force` flag to override this safety │ check. ``` --- This PR alsoo adds CSS codemods for migrating existing `@apply` directives to the new version. This PR has the ability to migrate the following cases: --- In v4, the convention is to put the important modifier `!` at the end of the utility class instead of right before it. This makes it easier to reason about, especially when you are variants. Input: ```css .foo { @apply !flex flex-col! hover:!items-start items-center; } ``` Output: ```css .foo { @apply flex! flex-col! hover:items-start! items-center; } ``` --- In v4 we don't support `!important` as a marker at the end of `@apply` directives. Instead, you can append the `!` to each utility class to make it `!important`. Input: ```css .foo { @apply flex flex-col !important; } ``` Output: ```css .foo { @apply flex! flex-col!; } ```
2024-09-18 16:45:43 +02:00
- Add `@tailwindcss/upgrade` tooling ([#14434](https://github.com/tailwindlabs/tailwindcss/pull/14434))
Add support for setting `screens` in JS config (#14415) This PR adds support for the _simple_ case of the `screens` option inside JS config paths. This allows JS configs to extend the responsive theme by adding custom breakpoints. Here's an example from our v3 docs: ```js { theme: { screens: { 'sm': '640px', // => @media (min-width: 640px) { ... } 'md': '768px', // => @media (min-width: 768px) { ... } 'lg': '1024px', // => @media (min-width: 1024px) { ... } 'xl': '1280px', // => @media (min-width: 1280px) { ... } '2xl': '1536px', // => @media (min-width: 1536px) { ... } } } } ``` For simple breakpoints, this will extend the core breakpoints and will work with the `min-*` and `max-*` utilities. However, we also support complex ways of setting up custom screens like this: ```js { theme: { extend: { screens: { sm: { max: '639px' }, md: [ { min: '668px', max: '767px' }, { min: '868px' }, ], lg: { min: '868px' }, xl: { min: '1024px', max: '1279px' }, tall: { raw: '(min-height: 800px)' }, }, }, }, } ``` For these complex setups, we _only_ generate the shorthand variant (e.g. `tall`) but those won't integrate within `min-*` and `max-*`. In v3, adding any of these complex configurations would omit any `min-*` and `max-*` variants.
2024-09-18 16:56:03 +02:00
- Support `screens` in JS config files ([#14415](https://github.com/tailwindlabs/tailwindcss/pull/14415))
Add radial and conic gradient utilities (#14467) This PR adds new `bg-radial-*` and `bg-conic-*` utilities for radial and conic gradients. It also adds support for "arbitrary gradients", where gradient utilities like `bg-linear-*`, `bg-radial-*`, and `bg-conic-*` can now accept a complete gradient definition as their arbitrary value. ## Radial gradients Radial gradients are created with the `bg-radial` utility, or the `bg-radial-[…]` utility, combined with the existing `from-*`, `via-*`, and `to-*` utilities. The simple `bg-radial` utility just creates a radial gradient with no position information, which defaults to `center`: ``` radial-gradient({from}, {via}, {to}); ``` If you use the arbitrary value format, whatever you provide as the arbitrary value is inserted into the first position: ``` radial-gradient({arbitrary value}, {from}, {via}, {to}); ``` So a utility like `bg-radial-[at_top_left]` would produce this: ``` radial-gradient(at top left, {from}, {via}, {to}); ``` This makes it possible to use some of the `radial-gradient(…)` features that this PR doesn't add first class support for, like using values like `circle at center` or providing a specific interpolation color space like `in hsl longer hue`. We may add explicit APIs for these in the future, but I'm proposing this PR first since those changes would be purely additive and none of the decisions here would create any conflict with those APIs. ## Conic gradients Conic gradients are created with the `bg-conic`, `bg-conic-{bareNumber}`, and `bg-conic-[…]` utilities, combined with the existing `from-*`, `via-*`, and `to-*` utilities. The `bg-conic` utility creates a conic gradient with no angle, which defaults to `0deg`: ``` conic-gradient({from}, {via}, {to}); ``` The `bg-conic-{bareNumber}` utilities create conic gradients using the bare number as the angle: ``` conic-gradient(from {bareNumber}deg, {from}, {via}, {to}); ``` The `bg-conic-[…]` arbitrary value utilities insert whatever you provide as the arbitrary value into the first position verbatim: ``` conic-gradient({arbitraryValue}, {from}, {via}, {to}); ``` So a utility like `bg-conic-[from_45deg_in_hsl]` would produce this: ``` conic-gradient(from 45deg in hsl, {from}, {via}, {to}); ``` Note that the `from` keyword needs to be provided by the user when using arbitrary values, but not when using bare values. This makes it possible to use some of the `conic-gradient(…)` features that this PR doesn't add first class support for, like using values like `at 0 0` or providing a specific interpolation color space like `in hsl longer hue`. We may add explicit APIs for these in the future, but I'm proposing this PR first since those changes would be purely additive and none of the decisions here would create any conflict with those APIs. ## Arbitrary gradients Prior to this PR, utilities like `bg-linear-[…]` could only accept positional information as their arbitrary value, like `bg-linear-[to_top_right]`. All of the color stops could only be provided using the `from-*`, `via-*`, and `to-*` utilities. If you wanted to provide the complete gradient in one class, you needed to use `bg-[…]` and write out the gradient function yourself: ```html <div class="bg-[linear-gradient(to_right,var(--color-red-500),var(--color-yellow-400))]"> ``` This PR refactors some things internally to make it possible to provide the entire gradient as the arbitrary value to each background gradient utility, like this: ```html <div class="bg-linear-[to_right,var(--color-red-500),var(--color-yellow-400)]"> ``` This is nice if you're doing something very custom and you want to be able to look at the whole value together, while still avoiding some of the boilerplate you'd have if you had to write out the entire gradient function yourself. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-20 10:34:54 -04:00
- Add `bg-radial-*` and `bg-conic-*` utilities for radial and conic gradients ([#14467](https://github.com/tailwindlabs/tailwindcss/pull/14467))
Add `shadow-initial` and `inset-shadow-initial` utilities (#14468) This PR complements #14458 by adding new `shadow-initial` and `inset-shadow-initial` utilities that make it possible to "undo" a custom shadow color and revert to the default shadow color for the current shadow size. For example, in this example the shadow will be red on hover even though the default color for the `shadow` utility is `rgb(0 0 0 / 5%)`: ```html <div class="shadow-sm shadow-red-500 hover:shadow"> <!-- … --> </div> ``` This is usually what you want, but if you actually want `hover:shadow` to apply its default color, you need to know what the color is and add it yourself: ```html <div class="shadow-sm shadow-red-500 hover:shadow hover:shadow-black/5"> <!-- … --> </div> ``` Using `shadow-initial`, you can achieve the same thing without having to know what the original color was: ```html <div class="shadow-sm shadow-red-500 hover:shadow hover:shadow-initial"> <!-- … --> </div> ``` The `inset-shadow-initial` utility does the same thing for the `inset-shadow-*` utilities. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-20 10:36:22 -04:00
- Add new `shadow-initial` and `inset-shadow-initial` utilities for resetting shadow colors ([#14468](https://github.com/tailwindlabs/tailwindcss/pull/14468))
Add `field-sizing` utilities (#14469) This PR adds support for the [`field-sizing`](https://developer.mozilla.org/en-US/docs/Web/CSS/field-sizing) property which can be used to fit a text inputs, file inputs, textareas, and selects to the size of the text rather than some implicit default width. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-20 10:50:41 -04:00
- Add `field-sizing-*` utilities ([#14469](https://github.com/tailwindlabs/tailwindcss/pull/14469))
Include gradient color properties in color transitions (#14489) This PR adds our custom gradient color properties (`--tw-gradient-from`, `--tw-gradient-via`, and `--tw-gradient-to`) to the list of color properties we transition in the `transition` and `transition-colors` utilities. As part of this I noticed that we had duplicate `@property` declarations for these custom properties, so I've removed the duplicates. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-23 09:07:54 -04:00
- Include gradient color properties in color transitions ([#14489](https://github.com/tailwindlabs/tailwindcss/pull/14489))
Update CHANGELOG.md
2024-10-03 13:22:21 -04:00
- _Upgrade (experimental)_: Convert important syntax in `@apply` in CSS files ([#14411](https://github.com/tailwindlabs/tailwindcss/pull/14434))
- _Upgrade (experimental)_: Convert `@tailwind` directives to `@import` rules in CSS files ([#14411](https://github.com/tailwindlabs/tailwindcss/pull/14411), [#14504](https://github.com/tailwindlabs/tailwindcss/pull/14504))
- _Upgrade (experimental)_: Convert custom CSS in `@layer utilities` and `@layer components` to use `@utility` in CSS files ([#14455](https://github.com/tailwindlabs/tailwindcss/pull/14455))
Add support for setting `screens` in JS config (#14415) This PR adds support for the _simple_ case of the `screens` option inside JS config paths. This allows JS configs to extend the responsive theme by adding custom breakpoints. Here's an example from our v3 docs: ```js { theme: { screens: { 'sm': '640px', // => @media (min-width: 640px) { ... } 'md': '768px', // => @media (min-width: 768px) { ... } 'lg': '1024px', // => @media (min-width: 1024px) { ... } 'xl': '1280px', // => @media (min-width: 1280px) { ... } '2xl': '1536px', // => @media (min-width: 1536px) { ... } } } } ``` For simple breakpoints, this will extend the core breakpoints and will work with the `min-*` and `max-*` utilities. However, we also support complex ways of setting up custom screens like this: ```js { theme: { extend: { screens: { sm: { max: '639px' }, md: [ { min: '668px', max: '767px' }, { min: '868px' }, ], lg: { min: '868px' }, xl: { min: '1024px', max: '1279px' }, tall: { raw: '(min-height: 800px)' }, }, }, }, } ``` For these complex setups, we _only_ generate the shorthand variant (e.g. `tall`) but those won't integrate within `min-*` and `max-*`. In v3, adding any of these complex configurations would omit any `min-*` and `max-*` variants.
2024-09-18 16:56:03 +02:00
Resolve `borderRadius` when using dot notation inside the `theme()` function (#14436) Fixes an issue where `borderRadius` was not properly upgraded when using it in the `theme()` function like this: ``` rounded-[theme(borderRadius.lg)] ``` --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-17 10:54:36 +02:00
### Fixed
- Support `borderRadius.*` as an alias for `--radius-*` when using dot notation inside the `theme()` function ([#14436](https://github.com/tailwindlabs/tailwindcss/pull/14436))
Fix stacking variant order when variants inside a group are treated as equal (#14431) This PR fixes an issue with the order of CSS when using stacked variants when two variants have the same order (as defined by the custom comperator function). ## The problem Take, for example, our breakpoint variants. Those are split into `max-*` variants and a group containing all `min-*` variants as well as the unprefixed static ones (e.g. `lg`, `sm`). We currently define a custom sort order for all breakpoints variants that will compare their order based on the resolved value provided. So if you define `--breakpoint-sm: 100px` and `--breakpoint-lg: 200px`, we first check if both breakpoints have the same unit and then we rank based on the numerical value, making `sm` appear before `lg`. But since the `min-*` variant and the `sm` variant share the same group, this also means that `min-sm` and `sm` as well as `min-lg` and `lg` will always have the same order (which makes sense—they also have the exact same CSS they generate!) The issue now arises when you use these together with variant stacking. So, say you want to stack the two variants `max-lg:min-sm`. We always want stacked variants to appear _after_ their non-stacked individual parts (since they are more specific). To do this right now, we generate a bitfield based on the variant order. If you have four variants like this: | Order | Variant | | ------------- | ------------- | | 0 | `max-lg` | | 1 | `max-sm` | | 2 | `min-sm` | | 3 | `min-lg` | We will assign one bit for each used variant starting from the lowest bit, so for the stack `max-lg:min-sm` we will set the bitfield to `0101` and those for the individual variants would result in `0100` (for `min-sm`) and `0001` (for `max-lg`). We then convert this bitfield to a number and order based on that number. This ensures that the stack always sorts higher. The issue now arises from the fact that the variant order also include the unprefixed variants for a breakpoint. So in our case of `lg` and `sm`, the full list would look like this: | Order | Variant | | ------------- | ------------- | | 0 | `max-lg` | | 1 | `max-sm` | | 2 | `min-sm` | | 3 | `sm` | | 4 | `min-lg` | | 5 | `lg` | This logic now breaks when you start to compute a stack for something like `max-lg:min-lg` _while also using the `lg` utility: | Stack | Bitmap | Integer Value | | ------------- | ------------- | ------------- | | `max-lg:min-lg` | `010001` | 17 | | `lg` | `100000` | 18 | As you can see here, the sole `lg` variant will now sort higher than the compound of `max-lg:min-lg`. That's not something we want! ## Proposed solution To fix this, we need to encode the information of _same_ variant order somehow. A single array like the example above is not sufficient for this, since it will remove the information of the similar sort order. Instead, we now computed a list of nested arrays for the order lookup that will combine variants of similar values (while keeping the order the same). So from the 6 item array above, we now have the following nested array: | Order | Variant | | ------------- | ------------- | | 0 | [`max-lg`] | | 1 | [`max-sm`] | | 2 | [`min-sm`, `sm`] | | 3 | [`min-lg`, `lg`] | When we use the first layer index for the bitfield, we can now see how this solves the issue: | Stack | Bitmap | Integer Value | | ------------- | ------------- | ------------- | | `max-lg:min-lg` | `1001` | 9 | | `lg` | `1000` | 8 | That's pretty-much it! There are a few other changes in this PR that mostly handles with a small regression by this change where now, named `group` variants and unnamed `group` variants would now have the same order (something that was undefined behavior before). --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-17 17:00:12 +02:00
- Ensure individual variants from groups are always sorted earlier than stacked variants from the same groups ([#14431](https://github.com/tailwindlabs/tailwindcss/pull/14431))
Allow `anchor-size(…)` in arbitrary values (#14394) This PR fixes an issue where using `anchor-size` in arbitrary values resulted in the incorrect css. Input: `w-[calc(anchor-size(width)+8px)]` Output: ```css .w-\[calc\(anchor-size\(width\)\+8px\)\] { width: calc(anchor - size(width) + 8px); } ``` This PR fixes that, by generating the correct CSS: ```css .w-\[calc\(anchor-size\(width\)\+8px\)\] { width: calc(anchor-size(width) + 8px); } ```
2024-09-17 17:44:17 +02:00
- Allow `anchor-size(…)` in arbitrary values ([#14394](https://github.com/tailwindlabs/tailwindcss/pull/14394))
Skip candidates with invalid `theme()` calls (#14437) Right now when we encounter a candidates with invalid `theme()` calls we throw an error which stops the build entirely. This is not ideal because, especially in the case of `node_modules`, if one file in one package has an error it will stop the build for an entire project and tracking this down can be quite difficult. Now, after this PR, any candidates that use `theme(…)` with non-existent theme keys (e.g. `rounded-[theme(--radius-does-not-exist)]`) will be skipped instead of breaking the build. Before: ```html <div class="underline rounded-[theme(--radius-does-not-exist)]"></div> ``` ```css /* No CSS was generated because an error was thrown */ /* Error: Invalid theme key: --radius-does-not-exist */ ``` After: ```html <div class="underline rounded-[theme(--radius-does-not-exist)]"></div> ``` ```css .underline { text-decoration-line: underline; } ``` --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-17 12:46:42 -04:00
- Skip candidates with invalid `theme()` calls ([#14437](https://github.com/tailwindlabs/tailwindcss/pull/14437))
Explicitly ignore `--inset-shadow` and `--inset-ring` variables in `inset` handler (#14447) Resolves #14440. This PR fixes an issue where registering a custom `inset-shadow-*` utility value in your theme like this: ```css @theme { --inset-shadow-potato: inset 0px 2px 6px #7a4724; } ``` …mistakenly generates both an `inset-shadow-*` and `inset-*` utility with that value: ```css .inset-shadow-potato { inset: inset 0px 2px 6px #7a4724; } .inset-shadow-potato { box-shadow: inset 0px 2px 6px #7a4724; } ``` This replaces #14445 which turns out to not be the ideal solution. Now we just explicitly ignore variables like `--inset-shadow-*` and `--inset-ring-*` in the `inset` handler. Kind of a gross patch but I can live with it because the whole existence of the `--inset-*` key is kind of a backwards compatibility thing anyways. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-09-18 08:59:39 -04:00
- Don't generate `inset-*` utilities for `--inset-shadow-*` and `--inset-ring-*` theme values ([#14447](https://github.com/tailwindlabs/tailwindcss/pull/14447))
Include `--default-transition-*` variables in `transition-*` utility output (#14482) Fixes #14479. Back in March we made a change to the `transition-*` utilities that inlined the values of the `--default-transition-*` variables to fix a bug where things would break if those variables didn't exist in your CSS. At the time though we weren't outputting CSS variables as part of the values of any utilities, for example `bg-red-500` didn't actually reference the `--color-red-500` variable. We later changed that but missed this situation, so these variables were still inlined even though nothing else was. This PR fixes that and makes things more consistent, so these variables will be used as expected unless using the `@theme inline` option, like with everything else. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-20 12:40:44 -04:00
- Include `--default-transition-*` variables in `transition-*` utility output ([#14482](https://github.com/tailwindlabs/tailwindcss/pull/14482))
Fix rtl/ltr to work with dir=auto (#14306) This fixes the following issue https://github.com/tailwindlabs/tailwindcss/issues/14305 by using `:dir()` --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-23 18:29:42 +03:00
- Ensure `rtl` and `ltr` variants work with `[dir=auto]` ([#14306](https://github.com/tailwindlabs/tailwindcss/pull/14306))
Release v4.0.0-alpha.24 (#14395)
2024-09-12 16:10:56 +02:00
Don't override explicit `leading-*`, `tracking-*`, or `font-{weight}` utilities with font-size utility defaults (#14403) This PR improves how the `text-{size}` utilities interact with the `leading-*`, `tracking-*`, and `font-{weight}` utilities, ensuring that if the user explicitly uses any of those utilities that those values are not squashed by any defaults baked into the `text-{size}` utilities. Prior to this PR, if you wrote something like this: ```html <div class="text-lg leading-none md:text-2xl"> ``` …the `leading-none` class would be overridden by the default line-height value baked into the `text-2xl` utility at the `md` breakpoint. This has been a point of confusion and frustration for people [in the past](https://github.com/tailwindlabs/tailwindcss/issues/6504) who are annoyed they have to keep repeating their custom `leading-*` value like this: ```html <div class="text-lg leading-none md:text-2xl md:leading-none lg:text-4xl lg:leading-none"> ``` This PR lets you write this HTML instead but get the same behavior as above: ```html <div class="text-lg leading-none md:text-2xl lg:text-4xl"> ``` It's important to note that this change _only_ applies to line-height values set explicitly with a `leading-*` utility, and does not apply to the line-height modifier. In this example, the line-height set by `text-sm/6` does _not_ override the default line-height included in the `md:text-lg` utility: ```html <div class="text-sm/6 md:text-lg"> ``` That means these two code snippets behave differently: ```html <div class="text-sm/6 md:text-lg">…</div> <div class="text-sm leading-6 md:text-lg">…</div> ``` In the top one, the line-height `md:text-lg` overrides the line-height set by `text-sm/6`, but in the bottom one, the explicit `leading-6` utility takes precedence. This PR applies the same improvements to `tracking-*` and `font-{weight}` as well, since all font size utilities can also optionally specify default `letter-spacing` and `font-weight` values. We achieve this using new semi-private CSS variables like we do for things like transforms, shadows, etc., which are set by the `leading-*`, `tracking-*`, and `font-{weight}` utilities respectively. The `text-{size}` utilities always use these values first if they are defined, and the default values become fallbacks for those variables if they aren't present. We use `@property` to make sure these variables are reset to `initial` on a per element basis so that they are never inherited, like with every other variable we define. This PR does slightly increase the amount of CSS generated, because now utilities like `leading-5` look like this: ```diff .leading-5 { + --tw-leading: 1.25rem; line-height: 1.25rem; } ``` …and utilites like `text-sm` include a `var(…)` lookup that they didn't include before: ```diff .text-sm { font-size: 0.875rem; - line-height: var(--font-size-sm--line-height, 1.25rem); + line-height: var(--tw-leading, var(--font-size-sm--line-height, 1.25rem)); } ``` If this extra CSS doesn't feel worth it for the small improvement in behavior, we may consider just closing this PR and keeping things as they are. This PR is also a breaking change for anyone who was depending on the old behavior, and expected the line-height baked into the `md:text-lg` class to take precedence over the explicit `leading-6` class: ```html <div class="text-sm leading-6 md:text-lg">…</div> ``` Personally I am comfortable with this because of the fact that you can still get the old behavior by preferring a line-height modifier: ```html <div class="text-sm/6 md:text-lg">…</div> ``` --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-18 09:20:04 -04:00
### Changed
Preserve shadow color when overriding shadow size (#14458) This PR changes how shadow color and shadow size utilities interact when used with variants. Take this HTML: ```html <div class="shadow-lg shadow-red-500 hover:shadow-xl"> <!-- … --> </div> ``` Currently this shadow would be red by default, but revert to the default semi-transparent black color on hover. This PR changes this behavior such that the shadow remains red on hover, and only the shadow size changes. We deliberately didn't do this originally because making things behave this way makes it very difficult to get the default shadow color back once you've changed it. The default color for `shadow-xl` for instance is `rgb(0 0 0 / 0.1)`, and the only way to get that color back after changing it is to know that value and explicitly bring it back: ```html <div class="shadow-lg shadow-red-500 hover:shadow-xl hover:shadow-black/10"> <!-- … --> </div> ``` To make things more difficult, the default shadow color is not the same across shadow sizes. For `shadow-sm` it's `black/5`, and for `shadow-2xl` it's `black/25`. In practice though you basically never need to bring back the default shadow color, so I'm reconsidering this trade-off in v4, and think I prefer this new behavior where the color is preserved but you have to bring back the default color if you actually need it. A simple workaround if you don't know the color is to reset the `--tw-shadow-color` variable like this: ```html <div class="shadow-lg shadow-red-500 hover:shadow-xl hover:[--tw-shadow-color:initial]"> <!-- … --> </div> ``` This relies on semi-private internals though, so perhaps we can introduce a utility for this, like `shadow-default` or `shadow-initial` that just unsets the shadow color. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-19 09:43:48 -04:00
- Preserve explicit `leading-*`, `tracking-*`, and `font-{weight}` value when overriding font-size ([#14403](https://github.com/tailwindlabs/tailwindcss/pull/14403))
Disallow negative bare values (#14453) Right now, it is possible to type `grid-cols--8` which maps to: ```css /* Specificity: (0, 1, 0) */ .grid-cols--8 { grid-template-columns: repeat(-8, minmax(0, 1fr)); } ``` This doesn't make sense so we used this opportunity to audit all variants and utilities and properly disallow negative bare values. Utilities where negative values are supported still work by using the negative utility syntax, e.g.: `-inset-4`.
2024-09-18 16:49:27 +02:00
- Disallow negative bare values in core utilities and variants ([#14453](https://github.com/tailwindlabs/tailwindcss/pull/14453))
Preserve shadow color when overriding shadow size (#14458) This PR changes how shadow color and shadow size utilities interact when used with variants. Take this HTML: ```html <div class="shadow-lg shadow-red-500 hover:shadow-xl"> <!-- … --> </div> ``` Currently this shadow would be red by default, but revert to the default semi-transparent black color on hover. This PR changes this behavior such that the shadow remains red on hover, and only the shadow size changes. We deliberately didn't do this originally because making things behave this way makes it very difficult to get the default shadow color back once you've changed it. The default color for `shadow-xl` for instance is `rgb(0 0 0 / 0.1)`, and the only way to get that color back after changing it is to know that value and explicitly bring it back: ```html <div class="shadow-lg shadow-red-500 hover:shadow-xl hover:shadow-black/10"> <!-- … --> </div> ``` To make things more difficult, the default shadow color is not the same across shadow sizes. For `shadow-sm` it's `black/5`, and for `shadow-2xl` it's `black/25`. In practice though you basically never need to bring back the default shadow color, so I'm reconsidering this trade-off in v4, and think I prefer this new behavior where the color is preserved but you have to bring back the default color if you actually need it. A simple workaround if you don't know the color is to reset the `--tw-shadow-color` variable like this: ```html <div class="shadow-lg shadow-red-500 hover:shadow-xl hover:[--tw-shadow-color:initial]"> <!-- … --> </div> ``` This relies on semi-private internals though, so perhaps we can introduce a utility for this, like `shadow-default` or `shadow-initial` that just unsets the shadow color. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-19 09:43:48 -04:00
- Preserve explicit shadow color when overriding shadow size ([#14458](https://github.com/tailwindlabs/tailwindcss/pull/14458))
Preserve explicit transition duration and timing function when overriding transition property (#14490) This PR changes the behavior of the `transition-{property}` utilities to respect any explicit timing function or duration set by the user using the `ease-*` and `duration-*` utilities. Say you have this HTML: ```html <div class="transition-colors duration-500 ease-out lg:transition-all"> ``` Currently, the `transition-duration` and `transition-timing-functions` will be reset to their default values at the `lg` breakpoint even though you've provided explicit values for them. After this PR is merged, those values will be preserved at the `lg` breakpoint. This PR also adds `duration-initial` and `ease-initial` utilities to "unset" explicit duration/timing-function values so that the defaults from classes like `transition-all` will kick in, without having to specify their explicit values. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-23 10:43:28 -04:00
- Preserve explicit transition duration and timing function when overriding transition property ([#14490](https://github.com/tailwindlabs/tailwindcss/pull/14490))
Resolve `@import` in core (#14446) This PR brings `@import` resolution into Tailwind CSS core. This means that our clients (PostCSS, Vite, and CLI) no longer need to depend on `postcss` and `postcss-import` to resolve `@import`. Furthermore this simplifies the handling of relative paths for `@source`, `@plugin`, or `@config` in transitive CSS files (where the relative root should always be relative to the CSS file that contains the directive). This PR also fixes a plugin resolution bug where non-relative imports (e.g. directly importing node modules like `@plugin '@tailwindcss/typography';`) would not work in CSS files that are based in a different npm package. ### Resolving `@import` The core of the `@import` resolution is inside `packages/tailwindcss/src/at-import.ts`. There, to keep things performant, we do a two-step process to resolve imports. Imagine the following input CSS file: ```css @import "tailwindcss/theme.css"; @import "tailwindcss/utilities.css"; ``` Since our AST walks are synchronous, we will do a first traversal where we start a loading request for each `@import` directive. Once all loads are started, we will await the promise and do a second walk where we actually replace the AST nodes with their resolved stylesheets. All of this is recursive, so that `@import`-ed files can again `@import` other files. The core `@import` resolver also includes extensive test cases for [various combinations of media query and supports conditionals as well als layered imports](https://developer.mozilla.org/en-US/docs/Web/CSS/@import). When the same file is imported multiple times, the AST nodes are duplicated but duplicate I/O is avoided on a per-file basis, so this will only load one file, but include the `@theme` rules twice: ```css @import "tailwindcss/theme.css"; @import "tailwindcss/theme.css"; ``` ### Adding a new `context` node to the AST One limitation we had when working with the `postcss-import` plugin was the need to do an additional traversal to rewrite relative `@source`, `@plugin`, and `@config` directives. This was needed because we want these paths to be relative to the CSS file that defines the directive but when flattening a CSS file, this information is no longer part of the stringifed CSS representation. We worked around this by rewriting the content of these directives to be relative to the input CSS file, which resulted in added complexity and caused a lot of issues with Windows paths in the beginning. Now that we are doing the `@import` resolution in core, we can use a different data structure to persist this information. This PR adds a new `context` node so that we can store arbitrary context like this inside the Ast directly. This allows us to share information with the sub tree _while doing the Ast walk_. Here's an example of how the new `context` node can be used to share information with subtrees: ```ts const ast = [ rule('.foo', [decl('color', 'red')]), context({ value: 'a' }, [ rule('.bar', [ decl('color', 'blue'), context({ value: 'b' }, [ rule('.baz', [decl('color', 'green')]), ]), ]), ]), ] walk(ast, (node, { context }) => { if (node.kind !== 'declaration') return switch (node.value) { case 'red': assert(context.value === undefined) case 'blue': assert(context.value === 'a') case 'green': assert(context.value === 'b') } }) ``` In core, we use this new Ast node specifically to persist the `base` path of the current CSS file. We put the input CSS file `base` at the root of the Ast and then overwrite the `base` on every `@import` substitution. ### Removing the dependency on `postcss-import` Now that we support `@import` resolution in core, our clients no longer need a dependency on `postcss-import`. Furthermore, most dependencies also don't need to know about `postcss` at all anymore (except the PostCSS client, of course!). This also means that our workaround for rewriting `@source`, the `postcss-fix-relative-paths` plugin, can now go away as a shared dependency between all of our clients. Note that we still have it for the PostCSS plugin only, where it's possible that users already have `postcss-import` running _before_ the `@tailwindcss/postcss` plugin. Here's an example of the changes to the dependencies for our Vite client ✨ : <img width="854" alt="Screenshot 2024-09-19 at 16 59 45" src="https://github.com/user-attachments/assets/ae1f9d5f-d93a-4de9-9244-61af3aff1237"> ### Performance Since our Vite and CLI clients now no longer need to use `postcss` at all, we have also measured a significant improvement to the initial build times. For a small test setup that contains only a hand full of files (nothing super-complex), we measured an improvement in the **3.5x** range: <img width="1334" alt="Screenshot 2024-09-19 at 14 52 49" src="https://github.com/user-attachments/assets/06071fb0-7f2a-4de6-8ec8-f202d2cc78e5"> The code for this is in the commit history if you want to reproduce the results. The test was based on the Vite client. ### Caveats One thing to note is that we previously relied on finding specific symbols in the input CSS to _bail out of Tailwind processing completely_. E.g. if a file does not contain a `@tailwind` or `@apply` directive, it can never be a Tailwind file. Since we no longer have a string representation of the flattened CSS file, we can no longer do this check. However, the current implementation was already inconsistent with differences on the allowed symbol list between our clients. Ideally, Tailwind CSS should figure out wether a CSS file is a Tailwind CSS file. This, however, is left as an improvement for a future API since it goes hand-in-hand with our planned API changes for the core `tailwindcss` package. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-23 17:05:55 +02:00
- Change the implementation for `@import` resolution to speed up initial builds ([#14446](https://github.com/tailwindlabs/tailwindcss/pull/14446))
Remove automatic `var(…)` injection (#13657) This PR is a continuation of #13537. Currently we reverted the merged changes so that we can get a new alpha version out without this change. --- This PR removes automatic `var(…)` injection for arbitrary properties, values and modifiers. There are a few properties that use "dashed-ident" values, this means that you can use `--my-thing` as-is without the `var(…)` around it. E.g.: ```css .foo { /* Notice that these don't have `var(…)` */ view-timeline-name: --timeline-name; anchor-name: --sidebar; } ``` This causes issues because we are now injecting a `var(…)` where it's not needed. One potential solution is to create a list of properties where dashed idents can be used. However, they can _also_ use CSS custom properties that point to another dashed ident. E.g.: ```css .foo { --target: --sidebar; anchor-name: var(--target); } ``` A workaround that some people used is adding a `_` in front of the variable: `mt-[_--my-thing]` this way we don't automatically inject the `var(…)` around it. This is a workaround and gross. While the idea of automatic var injection is neat, this causes more trouble than it's worth. Adding `var(…)` explicitly is better. A side effect of this is that we can simplify the internals for the `candidate` data structure because we don't need to track `dashedIdent` separately anymore. <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2024-09-23 21:57:29 +02:00
- Remove automatic `var(…)` injection ([#13657](https://github.com/tailwindlabs/tailwindcss/pull/13657))
Only apply hover on devices that support hover (#14500) This PR updates the `hover` variant to only apply when `@media (hover: hover)` matches. ```diff .hover\:bg-black { &:hover { + @media (hover: hover) { background: black; + } } } ``` This is technically a breaking change because you may have built your site in a way where some interactions depend on hover (like opening a dropdown menu), and were relying on the fact that tapping on mobile triggers hover. To bring back the old hover behavior, users can override the `hover` variant in their CSS file back to the simpler implementation: ```css @import "tailwindcss"; @variant hover (&:hover); ``` I've opted to go with just `@media (hover: hover)` for this because it seems like the best trade-off between the available options. Using `(any-hover: hover)` would mean users would get sticky hover states when tapping on an iPad if they have a mouse or trackpad connected, which feels wrong to me because in those cases touch is still likely the primary method of interaction. Sites built with this feature in mind will be treating hover styles as progressive enhancement, so it seems better to me that using an iPad with a mouse would not have hover styles, vs. having sticky hover styles in the same situation. Of course users can always override this with whatever they want, so making this the default isn't locking anyone in to a particular choice. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-24 11:43:57 -04:00
- Only apply `:hover` states on devices that support `@media (hover: hover)` ([#14500](https://github.com/tailwindlabs/tailwindcss/pull/14500))
Don't override explicit `leading-*`, `tracking-*`, or `font-{weight}` utilities with font-size utility defaults (#14403) This PR improves how the `text-{size}` utilities interact with the `leading-*`, `tracking-*`, and `font-{weight}` utilities, ensuring that if the user explicitly uses any of those utilities that those values are not squashed by any defaults baked into the `text-{size}` utilities. Prior to this PR, if you wrote something like this: ```html <div class="text-lg leading-none md:text-2xl"> ``` …the `leading-none` class would be overridden by the default line-height value baked into the `text-2xl` utility at the `md` breakpoint. This has been a point of confusion and frustration for people [in the past](https://github.com/tailwindlabs/tailwindcss/issues/6504) who are annoyed they have to keep repeating their custom `leading-*` value like this: ```html <div class="text-lg leading-none md:text-2xl md:leading-none lg:text-4xl lg:leading-none"> ``` This PR lets you write this HTML instead but get the same behavior as above: ```html <div class="text-lg leading-none md:text-2xl lg:text-4xl"> ``` It's important to note that this change _only_ applies to line-height values set explicitly with a `leading-*` utility, and does not apply to the line-height modifier. In this example, the line-height set by `text-sm/6` does _not_ override the default line-height included in the `md:text-lg` utility: ```html <div class="text-sm/6 md:text-lg"> ``` That means these two code snippets behave differently: ```html <div class="text-sm/6 md:text-lg">…</div> <div class="text-sm leading-6 md:text-lg">…</div> ``` In the top one, the line-height `md:text-lg` overrides the line-height set by `text-sm/6`, but in the bottom one, the explicit `leading-6` utility takes precedence. This PR applies the same improvements to `tracking-*` and `font-{weight}` as well, since all font size utilities can also optionally specify default `letter-spacing` and `font-weight` values. We achieve this using new semi-private CSS variables like we do for things like transforms, shadows, etc., which are set by the `leading-*`, `tracking-*`, and `font-{weight}` utilities respectively. The `text-{size}` utilities always use these values first if they are defined, and the default values become fallbacks for those variables if they aren't present. We use `@property` to make sure these variables are reset to `initial` on a per element basis so that they are never inherited, like with every other variable we define. This PR does slightly increase the amount of CSS generated, because now utilities like `leading-5` look like this: ```diff .leading-5 { + --tw-leading: 1.25rem; line-height: 1.25rem; } ``` …and utilites like `text-sm` include a `var(…)` lookup that they didn't include before: ```diff .text-sm { font-size: 0.875rem; - line-height: var(--font-size-sm--line-height, 1.25rem); + line-height: var(--tw-leading, var(--font-size-sm--line-height, 1.25rem)); } ``` If this extra CSS doesn't feel worth it for the small improvement in behavior, we may consider just closing this PR and keeping things as they are. This PR is also a breaking change for anyone who was depending on the old behavior, and expected the line-height baked into the `md:text-lg` class to take precedence over the explicit `leading-6` class: ```html <div class="text-sm leading-6 md:text-lg">…</div> ``` Personally I am comfortable with this because of the fact that you can still get the old behavior by preferring a line-height modifier: ```html <div class="text-sm/6 md:text-lg">…</div> ``` --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-18 09:20:04 -04:00
Release v4.0.0-alpha.24 (#14395)
2024-09-12 16:10:56 +02:00
## [4.0.0-alpha.24] - 2024-09-11
Support CSS `theme()` functions inside `@custom-media` rules (#14358) This PR will now also scan `@custom-media` rules for invocations of the CSS `theme()` function.
2024-09-06 19:05:48 +02:00
### Added
Release v4.0.0-alpha.24 (#14395)
2024-09-12 16:10:56 +02:00
- Support CSS `theme()` functions inside other `@custom-media`, `@container`, and `@supports` rules ([#14358](https://github.com/tailwindlabs/tailwindcss/pull/14358))
- Export `Config` type from `tailwindcss` for JS config files ([#14360](https://github.com/tailwindlabs/tailwindcss/pull/14360))
Add `matchVariant` API (#14371) This PR adds support for the `matchVariant` plugin API. I've copied over all [V3 tests](https://github.com/tailwindlabs/tailwindcss/blob/f07dbff2a7f78fd75c53c6cfe01b58b6c0419f22/tests/match-variants.test.js) and made sure they still pass. ## Sorted order of stacked arbitrary variants The only difference in behavior is regarding the sort order of stacked arbitrary variants: Sorting in this case now works by the latest defined `matchVariant` taking precedence. So, if you define a plugin like this: ```ts matchVariant('testmin', (value) => `@media (min-width: ${value})`, { sort(a, z) { return parseInt(a.value) - parseInt(z.value) }, }) matchVariant('testmax', (value) => `@media (max-width: ${value})`, { sort(a, z) { return parseInt(z.value) - parseInt(a.value) }, }) ``` The resulting CSS is first sorted by the `testmax` values descending and then the `testmin` values ascending, so these candidates: ```txt testmin-[150px]:testmax-[400px]:order-2 testmin-[100px]:testmax-[350px]:order-3 testmin-[100px]:testmax-[300px]:order-4 testmin-[100px]:testmax-[400px]:order-1 ``` Will resolve to the order outlined by the `order-` utility. ## At-rules and placeholders support Since we added support for at-rules and placeholders in the `matchVariant` syntax like this: ```ts matchVariant( 'potato', (flavor) => `@media (potato: ${flavor}) { @supports (font:bold) { &:large-potato } }`, ) ``` We also added support for the same syntax to the `addVariant` API: ```ts addVariant( 'potato', '@media (max-width: 400px) { @supports (font:bold) { &:large-potato } }', ) ``` The only change necessary in core was to call functional variants for when the variant value is set to `null`. This allows functional variants to define the un-parameterized implementation like `potato:underline` as opposed to `potato[big]:underline`. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-11 16:45:07 +02:00
- Add support for `matchVariant` plugins using the `@plugin` directive ([#14371](https://github.com/tailwindlabs/tailwindcss/pull/14371))
Update change log to match release notes
2024-09-12 16:29:17 +02:00
- Warn when the `tailwindcss` package is used as a PostCSS plugin ([#14378](https://github.com/tailwindlabs/tailwindcss/pull/14378))
Support CSS `theme()` functions inside `@custom-media` rules (#14358) This PR will now also scan `@custom-media` rules for invocations of the CSS `theme()` function.
2024-09-06 19:05:48 +02:00
Improve the CLI output when nothing changed (#14351) When we observe that no new candidates were found, then we can return early because nothing really changed. There is also no need to re-optimize (use Lightning CSS) in this case. But this had a side effect that when no new candidates were detected, that you didn't see any output either. This feels like nothing is working from a DX perspective. Typically you are changing things, so it's not really a problem. But the moment you use a class that already existed (e.g.: in another file) you also don't get any output because we have a shared cache. This PR solves that by always showing the output. But it still doesn't write to disk if nothing changed. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-05 23:00:57 +02:00
### Fixed
- Ensure there is always CLI feedback on save even when no new classes were found ([#14351](https://github.com/tailwindlabs/tailwindcss/pull/14351))
Properly resolve `theme('someKey.DEFAULT')` when only `--some-key-*` keys exist (#14354) This PR fixes an issue where theme function calls like `theme('transitionTimingFunction.DEFAULT')` would incorrectly resolve to an object when the set of defined CSS theme values looked like this: ```css @theme { --transition-timing-function-in: ease-in; --transition-timing-function-out: ease-out; --transition-timing-function-in-out: ease-out; } ``` We were mistakenly retrieving the entire `--transition-timing-function-*` namespace in this case and returning an object, even though the user is explicitly asking for a single value by including `.DEFAULT` in their call. This ensures it resolves to null instead. Fixes an issue I ran into on this live stream earlier today: https://x.com/adamwathan/status/1831740214051799281 --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-06 09:00:28 -04:00
- Properly resolve `theme('someKey.DEFAULT')` when all `--some-key-*` keys have a suffix ([#14354](https://github.com/tailwindlabs/tailwindcss/pull/14354))
Allow configs to override default CSS theme values in `theme()` function provided to plugins and configs (#14359) Previously, given the following CSS and configuration: ```css /* app.css */ @theme default { --font-size-base: 1.25rem; --font-size-base--line-height: 1.5rem; } @tailwind utilities; @config "./config.js"; ``` ```js // config.js export default { theme: { fontSize: { // … base: ['1rem', { lineHeight: '1.75rem' }], }, // … }, }; ``` When a config or a plugin asked for the value of `theme(fontSize.base)` like so: ```js // config.js export default { theme: { // … typography: ({ theme }) => ({ css: { '[class~="lead"]': { fontSize: theme('fontSize.base')[0], ...theme('fontSize.base')[1], }, } }), }, }; ``` We would instead pull the values from the CSS theme even through they're marked with `@theme default`. This would cause the incorrect font size and line height to be used resulting in something like this (in the case of the typography plugin with custom styles): ```css .prose [class~="lead"] { font-size: 1.25rem; line-height: 1.5rem; } ``` After this change we'll now pull the values from the appropriate place (the config in this case) and the correct font size and line height will be used: ```css .prose [class~="lead"] { font-size: 1rem; line-height: 1.75rem; } ``` This will work even when some values are overridden in the CSS theme: ```css /* app.css */ @theme default { --font-size-base: 1.25rem; --font-size-base--line-height: 1.5rem; } @theme { --font-size-base: 2rem; } @tailwind utilities; @config "./config.js"; ``` which would result in the following CSS: ```css .prose [class~="lead"] { font-size: 2rem; line-height: 1.75rem; } ``` --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-06 16:05:26 -04:00
- Make sure tuple theme values in JS configs take precedence over `@theme default` values ([#14359](https://github.com/tailwindlabs/tailwindcss/pull/14359))
Intellisense: Add example bare values to border completions (#14370) Closes https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1048 This PR adds a few bare value examples for border width completions. The examples are taken from [our docs](https://tailwindcss.com/docs/border-width).
2024-09-11 16:59:18 +02:00
- Improve IntelliSense completions for `border` utilities ([#14370](https://github.com/tailwindlabs/tailwindcss/pull/14370))
v4.0.0-alpha.23
2024-09-05 10:41:29 -04:00
## [4.0.0-alpha.23] - 2024-09-05
Fix changelog
2024-09-05 10:40:00 -04:00
### Added
- Add opacity modifier support to the `theme()` function in plugins ([#14348](https://github.com/tailwindlabs/tailwindcss/pull/14348))
v4.0.0-alpha.22
2024-09-04 15:50:57 -04:00
v4.0.0-alpha.23
2024-09-05 10:41:29 -04:00
## [4.0.0-alpha.22] - 2024-09-04
v4.0.0-alpha.22
2024-09-04 15:50:57 -04:00
Allow `@plugin` and `@config` to point to TS files (#14317) Tailwind V3 used [jiti](https://github.com/unjs/jiti/) to allow importing of TypeScript files for the config and plugins. This PR adds the new Jiti V2 beta to our `@tailwindcss/node` and uses it if a native `import()` fails. I added a new integration test to the CLI config setup, to ensure it still works with our module cache cleanup.
2024-09-03 18:35:39 +02:00
### Added
- Support TypeScript for `@plugin` and `@config` files ([#14317](https://github.com/tailwindlabs/tailwindcss/pull/14317))
Add `default` option to `@theme` to support overriding default theme values from plugins/JS config files (#14327) This PR adds a new `default` option to `@theme` to make it possible for plugins/JS config files to override default theme values, and also ensures that the final set of CSS variables we output takes into account any theme values added by plugins/JS config files. --- Previously, if you were using the default theme but also had a JS config file that overrode any of those defaults like this: ```js // ./tailwind.config.js export default { theme: { extend: { colors: { red: { '500': 'tomato', }, } } } } ``` …then utilities like `text-red-500` would correctly use `color: tomato`, but the `--color-red-500` CSS variable would still be set to the default value: ```css :root { --color-red-500: #ef4444; } ``` This feels like a straight-up bug — if `#ef4444` is not part of your design system because you've overridden it, it shouldn't show up in your set of CSS variables anywhere. So this PR fixes this issue by making sure we don't print the final set of CSS variables until all of your plugins and config files have had a chance to update the theme. --- The second issue is that we realized people have different expectations about how plugin/config theme values should interact with Tailwind's _default_ theme vs. explicitly user-configured theme values. Take this setup for instance: ```css @import "tailwindcss"; @config "./tailwind.config.js"; ``` If `tailwind.config.js` overrides `red-500` to be `tomato`, you'd expect `text-red-500` to actually be `tomato`, not the default `#ef4444` color. But in this setup: ```css @import "tailwindcss"; @config "./tailwind.config.js"; @theme { --color-red-500: #f00; } ``` …you'd expect `text-red-500` to be `#f00`. This is despite the fact that currently in Tailwind there is no difference here — they are both just `@theme` blocks, one just happens to be coming from an imported file (`@import "tailwindcss"`). So to resolve this ambiguity, I've added a `default` option to `@theme` for explicitly registering theme values as "defaults" that are safe to override with plugin/JS config theme values: ```css @import "tailwindcss"; @config "./tailwind.config.js"; @theme default { --color-red-500: #f00; } ``` Now `text-red-500` would be `tomato` here as per the config file. This API is not something users are generally going to interact with — they will almost never want to use `default` explicitly. But in this PR I've updated the default theme we ship with to include `default` so that it interacts in a more intuitive way with plugins and JS config files. --- Finally, this PR makes sure all theme values registered by plugins/configs are registered with `isReference: true` to make sure they do not end up in the final CSS at all. This is important to make sure that the super weird shit we used to do in configs in v3 doesn't get translated into nonsense variables that pollute your output (hello typography plugin I'm looking at you). If we don't do this, you'll end up with CSS variables like this: ```css :root { --typography-sm-css-blockquote-padding-inline-start: 1.25em; } ``` Preventing theme values registered in plugins/configs from outputting CSS values also serves the secondary purpose of nudging users to migrate to the CSS config if they do want CSS variables for their theme values. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 11:49:50 -04:00
- Add `default` option to `@theme` to support overriding default theme values from plugins/JS config files ([#14327](https://github.com/tailwindlabs/tailwindcss/pull/14327))
Vite: Add support for `<style>` tags in Astro files (#14340) This works similar to the Vue setup. The styles that Astro will receive might still contain Tailwind CSS APIs but since it's not picky, we can pass that through to the regular Vite `transform` handlers for now. This, however, will have issues like https://github.com/tailwindlabs/tailwindcss/issues/14205. We have to fix this together with Vue and other similar extensions later. For now, it will break when syntax is used that lightningcss rewrites (like `@apply text-3xl/tight;`) --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-04 19:14:05 +02:00
- Add support for `<style>` tags in Astro files to the Vite plugin ([#14340](https://github.com/tailwindlabs/tailwindcss/pull/14340))
Allow `@plugin` and `@config` to point to TS files (#14317) Tailwind V3 used [jiti](https://github.com/unjs/jiti/) to allow importing of TypeScript files for the config and plugins. This PR adds the new Jiti V2 beta to our `@tailwindcss/node` and uses it if a native `import()` fails. I added a new integration test to the CLI config setup, to ensure it still works with our module cache cleanup.
2024-09-03 18:35:39 +02:00
Ensure content globs defined in `@config` files are relative to that file (#14314) When you configure custom content globs inside an `@config` file, we want to tread these globs as being relative to that config file and not the CSS file that requires the content file. A config can be used by multiple CSS configs. --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-03 16:54:08 +02:00
### Fixed
- Ensure content globs defined in `@config` files are relative to that file ([#14314](https://github.com/tailwindlabs/tailwindcss/pull/14314))
Update CHANGELOG.md
2024-09-04 15:45:25 -04:00
- Ensure CSS `theme()` functions are evaluated in media query ranges with collapsed whitespace ([#14321](https://github.com/tailwindlabs/tailwindcss/pull/14321))
Fix Nuxt integration (#14319) We noticed that Nuxt projects were not working with the tailwindcss project. The issue was traced down to the fact that Nuxt starts multiple Vite dev servers and calling the experimental `waitForRequestsIdle()` on one of the test servers would never resolve. This was fixed upstream and is part of the latest Vite/Nuxt release: https://github.com/vitejs/vite/issues/17980. We still need to handle the fact that Vite can spawn multiple dev servers. This is necessary because when we invalidate all roots, we need to find that module inside all of the spawned servers. If we only look at the _last server_ (what we have done before), we would not find the module and thus could not invalidate it.
2024-09-04 16:53:15 +02:00
- Fix support for Nuxt projects in the Vite plugin (requires Nuxt 3.13.1+) ([#14319](https://github.com/tailwindlabs/tailwindcss/pull/14319))
Evaluate theme functions in plugins (#14326) This PR fixes a bug where CSS `theme()` functions were not evaluated when present in rules added by plugins, using either `@plugin` or registering a plugin in a JS config file. For example, prior to this PR the `theme()` functions in this plugin would make it into the final CSS without being evaluated: ```js // ./my-plugin.js export default plugin(({ addBase }) => { addBase({ '.my-rule': { background: 'theme(colors.primary)', color: 'theme(colors.secondary)', }, }) }) ``` --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 11:49:01 -04:00
- Evaluate theme functions in plugins and JS config files ([#14326](https://github.com/tailwindlabs/tailwindcss/pull/14326))
Add `default` option to `@theme` to support overriding default theme values from plugins/JS config files (#14327) This PR adds a new `default` option to `@theme` to make it possible for plugins/JS config files to override default theme values, and also ensures that the final set of CSS variables we output takes into account any theme values added by plugins/JS config files. --- Previously, if you were using the default theme but also had a JS config file that overrode any of those defaults like this: ```js // ./tailwind.config.js export default { theme: { extend: { colors: { red: { '500': 'tomato', }, } } } } ``` …then utilities like `text-red-500` would correctly use `color: tomato`, but the `--color-red-500` CSS variable would still be set to the default value: ```css :root { --color-red-500: #ef4444; } ``` This feels like a straight-up bug — if `#ef4444` is not part of your design system because you've overridden it, it shouldn't show up in your set of CSS variables anywhere. So this PR fixes this issue by making sure we don't print the final set of CSS variables until all of your plugins and config files have had a chance to update the theme. --- The second issue is that we realized people have different expectations about how plugin/config theme values should interact with Tailwind's _default_ theme vs. explicitly user-configured theme values. Take this setup for instance: ```css @import "tailwindcss"; @config "./tailwind.config.js"; ``` If `tailwind.config.js` overrides `red-500` to be `tomato`, you'd expect `text-red-500` to actually be `tomato`, not the default `#ef4444` color. But in this setup: ```css @import "tailwindcss"; @config "./tailwind.config.js"; @theme { --color-red-500: #f00; } ``` …you'd expect `text-red-500` to be `#f00`. This is despite the fact that currently in Tailwind there is no difference here — they are both just `@theme` blocks, one just happens to be coming from an imported file (`@import "tailwindcss"`). So to resolve this ambiguity, I've added a `default` option to `@theme` for explicitly registering theme values as "defaults" that are safe to override with plugin/JS config theme values: ```css @import "tailwindcss"; @config "./tailwind.config.js"; @theme default { --color-red-500: #f00; } ``` Now `text-red-500` would be `tomato` here as per the config file. This API is not something users are generally going to interact with — they will almost never want to use `default` explicitly. But in this PR I've updated the default theme we ship with to include `default` so that it interacts in a more intuitive way with plugins and JS config files. --- Finally, this PR makes sure all theme values registered by plugins/configs are registered with `isReference: true` to make sure they do not end up in the final CSS at all. This is important to make sure that the super weird shit we used to do in configs in v3 doesn't get translated into nonsense variables that pollute your output (hello typography plugin I'm looking at you). If we don't do this, you'll end up with CSS variables like this: ```css :root { --typography-sm-css-blockquote-padding-inline-start: 1.25em; } ``` Preventing theme values registered in plugins/configs from outputting CSS values also serves the secondary purpose of nudging users to migrate to the CSS config if they do want CSS variables for their theme values. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 11:49:50 -04:00
- Ensure theme values overridden with `reference` values don't generate stale CSS variables ([#14327](https://github.com/tailwindlabs/tailwindcss/pull/14327))
Update CHANGELOG.md
2024-09-04 15:46:39 -04:00
- Don’t suggest named opacity modifiers in IntelliSense ([#14339](https://github.com/tailwindlabs/tailwindcss/pull/14339))
Fix a crash with older Node.js versions (#14342) Closes #14341 --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-09-04 19:43:18 +02:00
- Fix a crash with older Node.js versions ([#14342](https://github.com/tailwindlabs/tailwindcss/pull/14342))
Support arrays in JS config values (#14343) This PR fixes a small bug where theme values could not be defined as arrays in JS config files, for example: ```js export default { theme: { fontFamily: { sans: ['Inter', 'system-ui', 'sans-serif'], }, }, } ``` --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 15:03:46 -04:00
- Support defining theme values as arrays of strings in JS config files ([#14343](https://github.com/tailwindlabs/tailwindcss/pull/14343))
Ensure `--default-font-*` and `--default-mono-font-*` variables respect theme customizations in JS config files (#14344) This PR fixes an issue where variables like `--default-font-family` wouldn't behave as expected when customizing `fontFamily.sans` or `fontFamily.mono` in a JS config. Because theme values added by JS config files are added as `reference`, customizing `fontFamily.sans` means the `--font-family-sans` variable no longer exists in the generated CSS. The `--default-font-family` variable is set to `var(--font-family-sans)` by default, so because that variable doesn't exist, `--default-font-family` is effectively undefined and the browser default font stack is used. This is unexpected because historically customizing `fontFamily.sans` has updated your default font for your entire project. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 15:30:21 -04:00
- Ensure `--default-font-*` and `--default-mono-font-*` variables respect theme customizations in JS config files ([#14344](https://github.com/tailwindlabs/tailwindcss/pull/14344))
Prepare `v4.0.0-alpha.21` (#14313) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-02 15:43:28 -04:00
## [4.0.0-alpha.21] - 2024-09-02
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
### Added
- Add new standalone builds of Tailwind CSS v4 ([#14270](https://github.com/tailwindlabs/tailwindcss/pull/14270))
Support loading config files via `@config` (#14239) In Tailwind v4 the CSS file is the main entry point to your project and is generally configured via `@theme`. However, given that all v3 projects were configured via a `tailwind.config.js` file we definitely need to support those. This PR adds support for loading existing Tailwind config files by adding an `@config` directive to the CSS — similar to how v3 supported multiple config files except that this is now _required_ to use a config file. You can load a config file like so: ``` @import "tailwindcss"; @config "./path/to/tailwind.config.js"; ``` A few notes: - Both CommonJS and ESM config files are supported (loaded directly via `import()` in Node) - This is not yet supported in Intellisense or Prettier — should hopefully land next week - TypeScript is **not yet** supported in the config file — this will be handled in a future PR. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 12:03:16 -04:00
- Support JavaScript configuration files using `@config` ([#14239](https://github.com/tailwindlabs/tailwindcss/pull/14239))
Support plugin options in CSS (#14264) Builds on #14239 — that PR needs to be merged first. This PR allows plugins defined with `plugin.withOptions` to receive options in CSS when using `@plugin` as long as the options are simple key/value pairs. For example, the following is now valid and will include the forms plugin with only the base styles enabled: ```css @plugin "@tailwindcss/forms" { strategy: base; } ``` We handle `null`, `true`, `false`, and numeric values as expected and will convert them to their JavaScript equivalents. Comma separated values are turned into arrays. All other values are converted to strings. For example, in the following plugin definition, the options that are passed to the plugin will be the correct types: - `debug` will be the boolean value `true` - `threshold` will be the number `0.5` - `message` will be the string `"Hello world"` - `features` will be the array `["base", "responsive"]` ```css @plugin "my-plugin" { debug: false; threshold: 0.5; message: Hello world; features: base, responsive; } ``` If you need to pass a number or boolean value as a string, you can do so by wrapping the value in quotes: ```css @plugin "my-plugin" { debug: "false"; threshold: "0.5"; message: "Hello world"; } ``` When duplicate options are encountered the last value wins: ```css @plugin "my-plugin" { message: Hello world; message: Hello plugin; /* this will be the value of `message` */ } ``` It's important to note that this feature is **only available for plugins defined with `plugin.withOptions`**. If you try to pass options to a plugin that doesn't support them, you'll get an error message when building: ```css @plugin "my-plugin" { debug: false; threshold: 0.5; } /* Error: The plugin "my-plugin" does not accept options */ ``` Additionally, if you try to pass in more complex values like objects or selectors you'll get an error message: ```css @plugin "my-plugin" { color: { red: 100; green: 200; blue: 300 }; } /* Error: Objects are not supported in `@plugin` options. */ ``` ```css @plugin "my-plugin" { .some-selector > * { primary: "blue"; secondary: "green"; } } /* Error: `@plugin` can only contain declarations. */ ``` --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-09-02 12:49:09 -04:00
- Support plugin options in `@plugin` ([#14264](https://github.com/tailwindlabs/tailwindcss/pull/14264))
Rework Vite plugin to support lightningcss pre processor and fast rebuilds (#14269) Fixes #14205 Fixes #14106 This PR reworks the Vite extension in order to supprt `lightningcss` as the pre-processor, enable faster rebuilds, and adds support for `vite build --watch` mode. To make this change possible, we've done two major changes to the extension that have caused the other changes. ## 1. Tailwind CSS is a preprocessor We now run all of our modifications in `enforce: 'pre'`. This means that Tailwind CSS now gets the untransformed CSS files rather than the one already going through postcss or lightningcss. We do this because Tailwind CSS _is_ a preprocessor at the same level as those tools and we do sometimes use the language in ways that [creates problems when it's the input for other bundlers](https://github.com/tailwindlabs/tailwindcss/pull/14269). The correct solution here is to make Tailwind not depend on any other transformations. The main reason we were not using the `enforce: 'pre'` phase in Vite before was becuase we relied on the `@import` flattening of postcss so we now have to do this manually. `@import` flattening is now a concern that every Tailwind V4 client has to deal with so this might actually be something we want to inline into tailwindcss in the future. ## 2. A Vite config can have multiple Tailwind roots This is something that we have not made very explicit in the previous iteration of the Vite plugin but we have to support multiple Tailwind roots in a single Vite workspace. A Tailwind root is a CSS file that is used to configure Tailwind. Technically, any CSS file can be the input for `tailwindcss` but you have to add certain rules (e.g. `@import "tailwindcss";`) to make the compiler do something. A workspace can have multiple of these rules (e.g. by having different Tailwind configures for different sub-pages). With the addition of [support for `@source` rules](https://github.com/tailwindlabs/tailwindcss/pull/14078) and [JS config files](https://github.com/tailwindlabs/tailwindcss/pull/14239), Tailwind roots become more complex and can have a custom list of _dependencies_ (that is other JavaScript modules the compiler includes as part of these new rules). In order to _only rebuild the roots we need to_, we have to make this separation very clear. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 10:09:24 +02:00
- Add support for using the Vite extension with `css.transformer` set to `lightningcss` ([#14269](https://github.com/tailwindlabs/tailwindcss/pull/14269))
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
Postcss: Bring back proper type exports (#14256) Closes #14253 Since we changed the export strategy for the postcss client in #14132, we accidentally no longer generated type exports for this package. This PR adds a type export back. We now use a similar pattern to the `./colors` and `./defaultTheme` exports in the tailwindcss package where we have a separate cjs entrypoint. The changes were validated manually in a playground project that were installing the updated dependencies from tarballs. Here is one example of it working as expected: <img width="750" alt="Screenshot 2024-08-26 at 14 10 07" src="https://github.com/user-attachments/assets/83de15f2-1543-4805-9231-9b8df1636c5e">
2024-08-26 15:54:07 +02:00
### Fixed
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
- Bring back type exports for the cjs build of `@tailwindcss/postcss` ([#14256](https://github.com/tailwindlabs/tailwindcss/pull/14256))
Correctly merge tuple values when using the plugin API (#14260) We noticed that when the `defaultTheme` (change for this is coming in #14257) defines a tuple that is also defined in the CSS theme, the values are incorrectly merged as objects instead of overwritten. However, CSS theme values should take precedence, even when they use tuple syntax. Proper coverage of this will come once `#14257` is merged when calling `theme(fontSize.xs[1].lineHeight)` will also have a default value passed in from the `defaultTheme`.
2024-08-26 16:23:52 +02:00
- Correctly merge tuple values when using the plugin API ([#14260](https://github.com/tailwindlabs/tailwindcss/pull/14260))
Fix issues with the CSS `theme()` function (#14262) While working on #14257, we noticed two issues with the CSS `theme()` function: 1. In V3 it's possible to set arrays inside the theme object. An example for this is the default font families as defined here: https://github.com/tailwindlabs/tailwindcss/blob/main/stubs/config.full.js#L303-L311. We now properly join these arrays that are not tuples. 2. We noticed that in the case where there are no modifiers, the fallback values for the CSS `theme()` function had the first word removed. A regression test for this was added.
2024-08-26 18:55:27 +02:00
- Handle arrays in the CSS `theme()` function when using plugins ([#14262](https://github.com/tailwindlabs/tailwindcss/pull/14262))
- Fix fallback values when using the CSS `theme()` function ([#14262](https://github.com/tailwindlabs/tailwindcss/pull/14262))
Fix support for declaration fallbacks in plugins (#14265) This PR fixes support for "fallback" values for declarations in plugins. A plugin using `addUtilities`, `matchUtilities`, `addComponents`, etc… should be able to specify "fallback" values for declarations by passing an array as the value of a declaration however this does not currently work in v4 (but it does in v3): ```js export default { plugins: [ function ({ addUtilities }) { addUtilities({ '.outlined': { outline: ['1px solid ButtonText', '1px auto -webkit-focus-ring-color'], }, }) }, ], }; ``` After this PR the candidate `outlined` will now produce the following CSS — like it does in v3: ```css .outlined { outline: 1px solid ButtonText; outline: 1px auto -webkit-focus-ring-color; } ```
2024-08-27 06:18:53 -04:00
- Fix support for declaration fallbacks in plugins ([#14265](https://github.com/tailwindlabs/tailwindcss/pull/14265))
Spreading `tailwindcss/defaultTheme` exports keeps bare values (#14257) In #14221 we added a new export to the `tailwindcss` package: `tailwindcss/defaultTheme`. This is build on top of the full config from V3 and will allow plugins to keep being compatible. However, spreading in from this package has overwritten the bare value callback handler. This PR fixes it by sharing the bare value callbacks with the compat config.
2024-08-29 14:05:41 +02:00
- Support bare values when using `tailwindcss/defaultTheme` ([#14257](https://github.com/tailwindlabs/tailwindcss/pull/14257))
Rework Vite plugin to support lightningcss pre processor and fast rebuilds (#14269) Fixes #14205 Fixes #14106 This PR reworks the Vite extension in order to supprt `lightningcss` as the pre-processor, enable faster rebuilds, and adds support for `vite build --watch` mode. To make this change possible, we've done two major changes to the extension that have caused the other changes. ## 1. Tailwind CSS is a preprocessor We now run all of our modifications in `enforce: 'pre'`. This means that Tailwind CSS now gets the untransformed CSS files rather than the one already going through postcss or lightningcss. We do this because Tailwind CSS _is_ a preprocessor at the same level as those tools and we do sometimes use the language in ways that [creates problems when it's the input for other bundlers](https://github.com/tailwindlabs/tailwindcss/pull/14269). The correct solution here is to make Tailwind not depend on any other transformations. The main reason we were not using the `enforce: 'pre'` phase in Vite before was becuase we relied on the `@import` flattening of postcss so we now have to do this manually. `@import` flattening is now a concern that every Tailwind V4 client has to deal with so this might actually be something we want to inline into tailwindcss in the future. ## 2. A Vite config can have multiple Tailwind roots This is something that we have not made very explicit in the previous iteration of the Vite plugin but we have to support multiple Tailwind roots in a single Vite workspace. A Tailwind root is a CSS file that is used to configure Tailwind. Technically, any CSS file can be the input for `tailwindcss` but you have to add certain rules (e.g. `@import "tailwindcss";`) to make the compiler do something. A workspace can have multiple of these rules (e.g. by having different Tailwind configures for different sub-pages). With the addition of [support for `@source` rules](https://github.com/tailwindlabs/tailwindcss/pull/14078) and [JS config files](https://github.com/tailwindlabs/tailwindcss/pull/14239), Tailwind roots become more complex and can have a custom list of _dependencies_ (that is other JavaScript modules the compiler includes as part of these new rules). In order to _only rebuild the roots we need to_, we have to make this separation very clear. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 10:09:24 +02:00
- Correctly update builds when using the Vite extension with `build --watch` ([#14269](https://github.com/tailwindlabs/tailwindcss/pull/14269))
Prepare `v4.0.0-alpha.20` (#14244) Prepare next `4.0.0-alpha.20` release
2024-08-23 15:51:53 +02:00
Fix changelog
2024-09-02 17:36:04 +02:00
### Changed
Remove named opacity support for color opacity modifiers (#14278) Right now if you have a custom opacity theme value configured like this… ```css @theme { --opacity-disabled: 50%; } ``` …then you can use that named opacity value as a color opacity modifier like this: ```html <div class="bg-red-500/disabled"> ``` We think this behavior is confusing. The color opacity modifier is not setting opacity but the alpha value of a color. Opacity is for setting the opacity of an element, so the custom names you'd come up with are named after those situations, which makes them not seem appropriate for color modifiers.
2024-09-02 16:41:38 +02:00
- Remove named opacity support for color opacity modifiers ([#14278](https://github.com/tailwindlabs/tailwindcss/pull/14278))
Prepare `v4.0.0-alpha.20` (#14244) Prepare next `4.0.0-alpha.20` release
2024-08-23 15:51:53 +02:00
## [4.0.0-alpha.20] - 2024-08-23
Add support for `addBase` in plugins (#14172) This PR adds support for `addBase` in JS plugins which adds styles into the CSS base layer using `@layer base`. This exists for backwards compatibility with v3 but is not something we will encourage people to use going forward — in v4 it's better to just write these styles in a CSS file. In v3, `@layer base` was something we compiled away and was only used for determining where to add some styles in the final CSS, but in v4 we are using native CSS layers. This means that `addBase` in v4 expects you to have a _real_ `@layer base` in your final CSS, which you will have as long as you are using `@import "tailwindcss"` to add Tailwind to your project. Now something like this works: ```js function ({ addBase }) { addBase({ 'h1': { fontSize: '2em' }, 'h2': { fontSize: '1.5em' }, }) } ``` Which will emit the following CSS: ```css @layer base { h1 { font-size: 2em; } h2 { font-size: 1.5em; } } ``` The only limitation compared to v3 is that there is no way for you to wrap these styles in another custom layer. In v3 you could do this: ```css @layer my-base { @tailwind base; } ``` …and then anything you added with `addBase` would end up exactly where `@tailwind base` was in your source CSS. But in v4 there is no `@tailwind base`, so there's no way to wrap these styles in `@layer my-base` like in the example above. All base styles added by plugins are simply appended to the end of the stylesheet but wrapped in `@layer base` so they behave as if they are co-located with other base styles. Odds of this impacting anyone are extremely low, but if it proves to be an actual issue I think we could output these styles at the location of an optional `@tailwind base` rule if we detect it exists.
2024-08-12 14:44:44 -04:00
### Added
- Add support for `addBase` plugins using the `@plugin` directive ([#14172](https://github.com/tailwindlabs/tailwindcss/pull/14172))
Add support for the `tailwindcss/plugin` export (#14173) This PR adds support for the `tailwindcss/plugin` import which has historically been used to define custom plugins: ```js import plugin from "tailwindcss/plugin"; export default plugin(function ({ addBase }) { addBase({ // ... }); }); ``` This also adds support for `plugin.withOptions` which was used to define plugins that took optional initilization options when they were registered in your `tailwind.config.js` file: ```js import plugin from "tailwindcss/plugin"; export default plugin.withOptions((options = {}) => { return function ({ addBase }) { addBase({ // ... }); }; }); ``` We've stubbed out support for the `config` argument but we're not actually doing anything with it at the time of this PR. The scope of this PR is just to allow people to create plugins that currently work using the raw function syntax but using the `plugin` and `plugin.withOptions` APIs. Support for `config` will land separately. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-08-13 10:25:29 -04:00
- Add support for the `tailwindcss/plugin` export ([#14173](https://github.com/tailwindlabs/tailwindcss/pull/14173))
Add support for the `theme()` function in the plugin API (#14207) This PR adds support for the [`theme()` function](https://tailwindcss.com/docs/plugins#dynamic-utilities) from the v3 plugin API, used for configuring which values functional utilities support: ```js plugin(function({ matchUtilities, theme }) { matchUtilities( { tab: (value) => ({ tabSize: value }), }, { values: theme('tabSize') } ) }) ``` Things this handles: - "Upgrading" theme keys to their v4 names, so if you do `theme('colors')` that will correctly retrieve all the colors from the `--color-*` namespace with the new CSS variable based configuration - Polyfilling dependent keys, so `theme('backgroundColor')` will still pull everything in `--color-*` even though there is no values in the `backgroundColor` namespace in v4 by default - Polyfilling theme values that are now handled by "bare values" internally, so even though there is no `flexShrink` theme values in v4, `theme('flexShrink')` will still configure your plugin to properly support any value that the built-in `shrink-*` utilities support Things that aren't handled: - Theme values that have been replaced by static utilities can't be retrieved yet, so for example `theme('cursor')` returns nothing right now because there are no values for the `cursor-*` utilities in the theme anymore, they are all just baked in to the framework. This will be handled in a future PR. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-20 11:05:08 -04:00
- Add support for the `theme()` function in plugins ([#14207](https://github.com/tailwindlabs/tailwindcss/pull/14207))
Improve compatibility with `@tailwindcss/typography` and `@tailwindcss/forms` (#14221) This PR enables compatibility for the `@tailwindcss/typography` and `@tailwindcss/forms` plugins. This required the addition of new Plugin APIs and new package exports. ## New Plugin APIs and compatibility improvements We added support for `addComponents`, `matchComponents`, and `prefix`. The component APIs are an alias for the utilities APIs because the sorting in V4 is different and emitting components in a custom `@layer` is not necessary. Since `prefix` is not supported in V4, the `prefix()` API is currently an identity function. ```js addComponents({ '.btn': { padding: '.5rem 1rem', borderRadius: '.25rem', fontWeight: '600', }, '.btn-blue': { backgroundColor: '#3490dc', color: '#fff', '&:hover': { backgroundColor: '#2779bd', }, }, '.btn-red': { backgroundColor: '#e3342f', color: '#fff', '&:hover': { backgroundColor: '#cc1f1a', }, }, }) ``` The behavioral changes effect the `addUtilities` and `matchUtilities` functions, we now: - Allow arrays of CSS property objects to be emitted: ```js addUtilities({ '.text-trim': [ {'text-box-trim': 'both'}, {'text-box-edge': 'cap alphabetic'}, ], }) ``` - Allow arrays of utilities ```js addUtilities([ { '.text-trim':{ 'text-box-trim': 'both', 'text-box-edge': 'cap alphabetic', }, } ]) ``` - Allow more complicated selector names ```js addUtilities({ '.form-input, .form-select, .form-radio': { /* styles here */ }, '.form-input::placeholder': { /* styles here */ }, '.form-checkbox:indeterminate:checked': { /* styles here */ } }) ``` ## New `tailwindcss/color` and `tailwindcss/defaultTheme` export To be compatible to v3, we're adding two new exports to the tailwindcss package. These match the default theme values as defined in v3: ```ts import colors from 'tailwindcss/colors' console.log(colors.red[600]) ``` ```ts import theme from 'tailwindcss/defaultTheme' console.log(theme.spacing[4]) ``` --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-08-22 08:06:21 -04:00
- Add support for `addComponents`, `matchComponents`, `prefix` plugin APIs ([#14221](https://github.com/tailwindlabs/tailwindcss/pull/14221))
- Add support for `tailwindcss/colors` and `tailwindcss/defaultTheme` exports for use with plugins ([#14221](https://github.com/tailwindlabs/tailwindcss/pull/14221))
- Add support for the `@tailwindcss/typography` and `@tailwindcss/forms` plugins ([#14221](https://github.com/tailwindlabs/tailwindcss/pull/14221))
Add support for the CSS `theme()` function (#14177) This PR adds the CSS `theme()` function to Tailwind V4. It's intended use is to get the raw value of a theme variable. This can be handy when trying to reference theme values in places where `var()` is not supported, for example: ```css @media (min-width: theme(--breakpoint-md)) { /*...*/ } ``` The CSS `theme()` function is backward compatible with Tailwind V3 which means that it can also be used with the old key path syntax, like: `theme(colors.red.500)`. The lookup for this is shared with the plugin `theme()` function and this PR adds a bunch of edge cases to validate the backward compatibility. Here are a few interesting cases that we found to be valid in Tailwind V3 and are now also valid in Tailwind V4: ```js // First argument can be inside quotes theme('colors.red.500') // Square brackets are valid separators in V3, even when chained with dots theme(color[red].500) // Slashes can be used for adding opacity to colors. This can also be inside quotes theme('colors.red.500 / 75%') // Oh yeah and there's also the tuple syntax for accessing v3 scoped variables theme(fontSize.xs[1].lineHeight) // themes can also define fallback values which could be theme calls again... theme(colors.red.unknown / 75%, theme(colors.red.500 / 25%)) // ... or list of values: theme(fontFamily.sans, 'Helvetica Neue', Helvetica, sans-serif) // Theme function can also be used in candidate class names... sm:[--color:theme(colors.red[500]) // ... and of course @media queries @media (min-width: theme(breakpoint.md)) and (max-width: theme(--breakpoint-lg)) ``` The way this is implemented right now is by adding a separate walk that scans all declaration values. If these values look like they could have a `theme()` function call, we will parse these values using a new `ValueParser` into a small AST that can be used to substitute function calls.
2024-08-22 15:46:44 +02:00
- Add support for the `theme()` function in CSS and class names ([#14177](https://github.com/tailwindlabs/tailwindcss/pull/14177))
Add support for matching multiple utility definitions for one candidate (#14231) Currently if a plugin adds a utility called `duration` it will take precedence over the built-in utilities — or any utilities with the same name in previously included plugins. However, in v3, we emitted matches from _all_ plugins where possible. Take this plugin for example which adds utilities for `animation-duration` via the `duration-*` class: ```ts import plugin from 'tailwindcss/plugin' export default plugin( function ({ matchUtilities, theme }) { matchUtilities( { duration: (value) => ({ animationDuration: value }) }, { values: theme("animationDuration") }, ) }, { theme: { extend: { animationDuration: ({ theme }) => ({ ...theme("transitionDuration"), }), } }, } ) ``` Before this PR this plugin's `duration` utility would override the built-in `duration` utility so you'd get this for a class like `duration-3500`: ```css .duration-3000 { animation-duration: 3500ms; } ``` Now, after this PR, we'll emit rules for `transition-duration` (Tailwind's built-in `duration-*` utility) and `animation-duration` (from the above plugin) and you'll get this instead: ```css .duration-3000 { transition-duration: 3500ms; } .duration-3000 { animation-duration: 3500ms; } ``` These are output as separate rules to ensure that they can all be sorted appropriately against other utilities. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-08-22 10:22:12 -04:00
- Add support for matching multiple utility definitions for one candidate ([#14231](https://github.com/tailwindlabs/tailwindcss/pull/14231))
Prepare `v4.0.0-alpha.19` (#14162) Prepare next `4.0.0-alpha.19` release
2024-08-09 17:58:30 +02:00
Don't wrap relative selectors in arbitrary variants with `:is(…)` (#14203) Prior to this PR, we weren't accounting for the fact that `:has(…)` supports [relative selectors](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_selectors/Selector_structure#relative_selector), which are sort of like partial selectors that can start with a combinator like `>`, `+`, or `~`. Before, a class like `has-[>img]:flex` would generate this: ```css .has-\[\>img\]\:flex:has(*:is(> img)) { display: flex; } ``` This was incorrect because `*:is(> img)` isn't even valid CSS at all, so the rule would do nothing. After this change, we generate this instead: ```css .has-\[\>img\]\:flex:has(> img) { display: flex; } ``` This PR also ensures that relative selectors are recognized as invalid in places where they are not supported, so classes like `group-[>img]:flex` for example will produce nothing now instead of invalid CSS. This is mostly a simple change but it did involve storing some additional information in the variant AST. Fixes #14202. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-16 13:42:04 -04:00
### Fixed
- Don't wrap relative selectors in arbitrary variants with `:is(…)` ([#14203](https://github.com/tailwindlabs/tailwindcss/pull/14203))
Prepare `v4.0.0-alpha.19` (#14162) Prepare next `4.0.0-alpha.19` release
2024-08-09 17:58:30 +02:00
## [4.0.0-alpha.19] - 2024-08-09
Add support for `inline` option when defining `@theme` values (#14095) This PR adds support for a new `inline` option when defining a `@theme` block that tells Tailwind to use raw theme values for utilities instead of referencing the corresponding generated CSS variable. ```css /* Input */ @theme inline { --color-red-500: #ef4444; /* ... */ } /* Example output */ :root { --color-red-500: #ef4444; } .text-red-500 { color: #ef4444; } ``` This can be composed with the existing `reference` option in case you want to define a `@theme` block as both `reference` (so the variables aren't generated) and `inline`: ```css /* Input */ @theme inline reference { --color-red-500: #ef4444; /* ... */ } /* Example output */ .text-red-500 { color: #ef4444; } ``` Since you can have multiple `@theme` blocks, you can even define some values normally and some as inline based on how you're using them. For example you might want to use `inline` for defining literal tokens like `--color-red-500`, but include the variable for tokens that you want to be able to theme like `--color-primary`: ```css /* Input */ @theme inline { --color-red-500: #ef4444; /* ... */ } @theme { --color-primary: var(--color-red-500); } /* Example output */ :root { --color-red-500: #ef4444; --color-primary: var(--color-red-500); } .text-red-500 { color: #ef4444; } .text-primary { color: var(--color-primary, var(--color-red-500)); } ``` ## Breaking changes Prior to this PR, you could `@import` a stylesheet that contained `@theme` blocks as reference by adding the `reference` keyword to your import: ```css @import "./my-theme.css" reference; ``` Now that `reference` isn't the only possible option when declaring your `@theme`, this syntax has changed to a new `theme(…)` function that accepts `reference` and `inline` as potential space-separated values: ```css @import "./my-theme.css"; @import "./my-theme.css" theme(reference); @import "./my-theme.css" theme(inline); @import "./my-theme.css" theme(reference inline); ``` If you are using the `@import … reference` option with an earlier alpha release, you'll need to update your code to `@import … theme(reference)` once this PR lands in a release. ## Motivation This PR is designed to solve an issue pointed out in #14091. Prior to this PR, generated utilities would always reference variables directly, with the raw value as a fallback: ```css /* Input */ @theme { --color-red-500: #ef4444; /* ... */ } /* Example output */ :root { --color-red-500: #ef4444; } .text-red-500 { color: var(--color-red-500, #ef4444); } ``` But this can create issues with variables resolving to an unexpected value when a theme value is referencing another variable defined on `:root`. For example, say you have a CSS file like this: ```css :root, .light { --text-fg: #000; } .dark { --text-fg: #fff; } @theme { --color-fg: var(--text-fg); } ``` Without `@theme inline`, we'd generate this output if you used the `text-fg` utility: ```css :root, .light { --text-fg: #000; } .dark { --text-fg: #fff; } :root { --color-fg: var(--text-fg); } .text-fg { color: var(--color-fg, var(--text-fg)); } ``` Now if you wrote this HTML, you're probably expecting your text to be the dark mode color: ```html <div class="dark"> <h1 class="text-fg">Hello world</h1> </div> ``` But you'd actually get the light mode color because of this rule: ```css :root { --color-fg: var(--text-fg); } .text-fg { color: var(--color-fg, var(--text-fg)); } ``` The browser will try to resolve the `--color-fg` variable, which is defined on `:root`. When it tries to resolve the value, _it uses the value of `var(--text-fg)` as it would resolve at `:root`_, not what it would resolve to based on the element that has the `text-fg` class. So `var(--color-fg)` resolves to `#000` because `var(--text-fg)` resolved to `#000` at the point in the tree where the browser resolved the value of `var(--color-fg)`. By using `@theme inline`, the `.text-fg` class looks like this: ```css .text-fg { color: var(--text-fg); } ``` With this definition, the browser doesn't try to resolve `--color-fg` at all and instead resolves `--text-fg` directly which correctly resolves to `#fff` as expected. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-02 09:37:30 -04:00
### Added
- Add support for `inline` option when defining `@theme` values ([#14095](https://github.com/tailwindlabs/tailwindcss/pull/14095))
Add `inert` variant (#14129) This PR adds a new `inert` variant. We use `:where([inert], [inert] *)`, because the element with the `inert` attribute and any of its descendants will be inert. For example, both these buttons will have `opacity-50`: ```html <button inert class="inert:opacity-50">I am inert</button> <div inert> <button class="inert:opacity-50">I am also inert</button> </div> ``` See: https://play.tailwindcss.com/Jqedv6phGn
2024-08-07 16:09:01 +02:00
- Add `inert` variant ([#14129](https://github.com/tailwindlabs/tailwindcss/pull/14129))
Add `@source` support (#14078) This PR is an umbrella PR where we will add support for the new `@source` directive. This will allow you to add explicit content glob patterns if you want to look for Tailwind classes in other files that are not automatically detected yet. Right now this is an addition to the existing auto content detection that is automatically enabled in the `@tailwindcss/postcss` and `@tailwindcss/cli` packages. The `@tailwindcss/vite` package doesn't use the auto content detection, but uses the module graph instead. From an API perspective there is not a lot going on. There are only a few things that you have to know when using the `@source` directive, and you probably already know the rules: 1. You can use multiple `@source` directives if you want. 2. The `@source` accepts a glob pattern so that you can match multiple files at once 3. The pattern is relative to the current file you are in 4. The pattern includes all files it is matching, even git ignored files 1. The motivation for this is so that you can explicitly point to a `node_modules` folder if you want to look at `node_modules` for whatever reason. 6. Right now we don't support negative globs (starting with a `!`) yet, that will be available in the near future. Usage example: ```css /* ./src/input.css */ @import "tailwindcss"; @source "../laravel/resources/views/**/*.blade.php"; @source "../../packages/monorepo-package/**/*.js"; ``` It looks like the PR introduced a lot of changes, but this is a side effect of all the other plumbing work we had to do to make this work. For example: 1. We added dedicated integration tests that run on Linux and Windows in CI (just to make sure that all the `path` logic is correct) 2. We Have to make sure that the glob patterns are always correct even if you are using `@import` in your CSS and use `@source` in an imported file. This is because we receive the flattened CSS contents where all `@import`s are inlined. 3. We have to make sure that we also listen for changes in the files that match any of these patterns and trigger a rebuild. PRs: - [x] https://github.com/tailwindlabs/tailwindcss/pull/14063 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14085 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14079 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14067 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14076 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14080 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14127 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14135 Once all the PRs are merged, then this umbrella PR can be merged. > [!IMPORTANT] > Make sure to merge this without rebasing such that each individual PR ends up on the main branch. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-08-07 16:38:44 +02:00
- Add support for explicitly registering content paths using new `@source` at-rule ([#14078](https://github.com/tailwindlabs/tailwindcss/pull/14078))
Vite: Support Tailwind in Vue <style> blocks (#14158) This PR adds support to transforming `<style>` blocks emitted by Vue components with tailwindcss when the `@tailwindcss/vite` is used. Example: ```vue <style> @import 'tailwindcss/utilities'; @import 'tailwindcss/theme' theme(reference); .foo { @apply text-red-500; } </style> <template> <div class="underline foo">Hello Vue!</div> </template> ``` Additionally, this PR also adds an integration test. --------- Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-09 12:41:58 +02:00
- Add support for scanning `<style>` tags in Vue files to the Vite plugin ([#14158](https://github.com/tailwindlabs/tailwindcss/pull/14158))
Add `matchUtilities` and `addUtilities` APIs (#14114) This PR introduces support for the v3-like `addUtilities` and `matchUtilities` APIs in v4. We anticipate designing a new API that feels more native to the way v4 works before shipping v4.0 stable, but we're continuing to support these APIs for backwards compatibility. We've tried to make the behavior as identical as possible, but because of fundamental differences between the v3 and v4 engines there are a few things that work differently: ## Only simple single-class selectors are supported In v3 you could pass a complex CSS selector to `addUtilities` and we would generate a utility for every class in the selector. In v4 we only allow you to use a simple, single-class selector. You should use nesting if you need a more complex selector, or need to include at-rules like `@media` or `@supports`. ```js // v3 function ({ addUtilities }) { addUtilities({ '.scrollbar-none::-webkit-scrollbar': { display: 'none', }, }) } // v4 function ({ addUtilities }) { addUtilities({ '.scrollbar-none': { '&::-webkit-scrollbar': { display: 'none', }, }, }) } ``` If you were adding custom utilities that included two classes and were depending on both of those classes behaving like utilities (they could each be used with variants), those custom utilities will need to be rewritten as two separate utilities that each use nesting: ```js // v3 function ({ addUtilities }) { addUtilities({ '.section > .row': { color: 'red', }, }) } // v4 function ({ addUtilities }) { addUtilities({ '.section': { '& > .row': { color: 'red', }, }, '.row': { 'section > &': { color: 'red', }, }, }) } ``` We may introduce support for this in the future if this limitation turns out to be a huge pain in the ass, but crossing our fingers that people were mostly doing simple stuff here. ## Opacity modifiers support bare values To be consistent with how built-in utilities work in v4, custom utilities that specify `type: "color"` now get "bare value" support for opacity modifiers. This means that a utility like `foo-black/33` will work out of the box without having to either add `--opacity-33` to your theme nor would you need to add it to the `modifiers` option. ## The `preferOnConflict` type option is gone In v3 we introduced an internal API called `preferOnConflict` for types. This was used as a way to disambiguate between two utilities with the same "root" but which produced different properties which used the same CSS data types. This was only applicable to arbitrary values and was only used for disambiguating between `background-position` and `background-size`. In v4, both of these properties are handled by a single plugin meaning this feature is no longer necessary. No one should've really been using this option anyway as it was never documented so we're dropping the feature. ## The options `respectPrefix` and `respectImportant` are not yet supported Neither the `prefix` nor `important` features exist in any form in v4 at this time. Therefore, they are not currently supported by this PR. We will look into supporting them if/when those features return. ## The `theme(…)` function is not currently supported Custom utilities defined using `matchUtilities` often use the `theme(…)` function to define their default values, but we haven't implemented support for `theme(…)` yet in v4. This means that as of this PR, default values for custom utilities must be hardcoded: ```js function ({ matchUtilities }) { matchUtilities({ 'tab': (value) => { return { 'tab-size': value, } }, }, { values: { 2: '2', 4: '4', 8: '8', }, }) } ``` Getting `theme(…)` working is a big project so we're going to tackle it in a separate PR. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-08-09 11:34:27 -04:00
- Add support for basic `addUtilities` and `matchUtilities` plugins using the `@plugin` directive ([#14114](https://github.com/tailwindlabs/tailwindcss/pull/14114))
Prepare for v4.0.0-alpha.18 release (#14057) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-07-25 10:19:13 -04:00
Ensure `@apply` works inside `@utility` (#14144) This PR fixes an issue where `@apply` was not handled if it was used inside of `@utility`. You should now be able to do something like this: ```css @utility btn { @apply flex flex-col bg-white p-4 rounded-lg shadow-md; } ``` If you then use `btn` as a class, the following CSS will be generated: ```css .btn { border-radius: var(--radius-lg, .5rem); background-color: var(--color-white, #fff); padding: var(--spacing-4, 1rem); --tw-shadow: 0 4px 6px -1px #0000001a, 0 2px 4px -2px #0000001a; --tw-shadow-colored: 0 4px 6px -1px var(--tw-shadow-color), 0 2px 4px -2px var(--tw-shadow-color); box-shadow: var(--tw-inset-shadow), var(--tw-inset-ring-shadow), var(--tw-ring-offset-shadow), var(--tw-ring-shadow), var(--tw-shadow); flex-direction: column; display: flex; } ``` This PR also makes sure that you can use custom `@utility` inside other `@utility` via `@apply`. E.g.: ```css @utility foo { color: red; } @utility bar { color: red; @apply hover:foo; } ``` If we detect a circular dependency, then we will throw an error since circular dependencies are not allowed. E.g.: ```css @utility foo { @apply hover:bar; } @utility bar { @apply focus:baz; } @utility baz { @apply dark:foo; } ``` Regardless of which utility you use, eventually it will apply itself. Fixes: #14143
2024-08-09 16:09:25 +02:00
### Fixed
- Ensure `@apply` works inside `@utility` ([#14144](https://github.com/tailwindlabs/tailwindcss/pull/14144))
Prepare for v4.0.0-alpha.18 release (#14057) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-07-25 10:19:13 -04:00
## [4.0.0-alpha.18] - 2024-07-25
Update CHANGELOG.md
2024-08-08 10:05:15 -04:00
### Added
- Add support for basic `addVariant` plugins with new `@plugin` directive ([#13982](https://github.com/tailwindlabs/tailwindcss/pull/13982), [#14008](https://github.com/tailwindlabs/tailwindcss/pull/14008))
- Add `@variant` at-rule for defining custom variants in CSS ([#13992](https://github.com/tailwindlabs/tailwindcss/pull/13992), [#14008](https://github.com/tailwindlabs/tailwindcss/pull/14008))
- Add `@utility` at-rule for defining custom utilities in CSS ([#14044](https://github.com/tailwindlabs/tailwindcss/pull/14044))
Discard invalid classes such as `bg-red-[#000]` (#13970) * add test that verifies that parsing `bg-red-[#0088cc]` should not work * improve parsing of arbitrary values, root is known When using arbitrary values such as `bg-[#0088cc]` then we know that everything before the `-[` part is the `root` of the utility. This also means that this should exist in the design system as-is. If we use `findRoot` instead, it means that `bg-red-[#0088cc]` would also just parse fine and we don't want. * small refactor: define `important` and `negative` directly It's not necessary to track state in a state object. Let's use the variables directly. * small refactor: use return on same line for consistency * add test that verifies that parsing `bg-` should not work * move `value === ''` check up The value doesn't change anymore, which means we can discard early and don't need to start creating candidate objects. * adjust comment with example * update changelog
2024-07-10 10:01:23 +02:00
### Fixed
- Discard invalid classes such as `bg-red-[#000]` ([#13970](https://github.com/tailwindlabs/tailwindcss/pull/13970))
Fix parsing body-less at-rule without terminating semicolon (#13978) * ensure body-less at-rules without semicolon are parsed correctly * update changelog
2024-07-10 15:44:28 +02:00
- Fix parsing body-less at-rule without terminating semicolon ([#13978](https://github.com/tailwindlabs/tailwindcss/pull/13978))
Ensure opacity modifier with variables work with `color-mix()` (#13972) * ensure opacity modifier variables work as expected We use `color-mix()` in v4 which means that we can use this for the opacity modifier. One thing we do already is convert values such as `0.5` to `50%` because that's what the `color-mix()` function expects. However, if you use a variable like this: ```html <div class="[--opacity:0.5] bg-red-500/[var(--opacity)]"></div> ``` This currently generates: ```css .bg-red-500\/\[var\(--opacity\)\] { background-color: color-mix( in srgb, var(--color-red-500, #ef4444) var(--opacity), transparent ); } .\[--opacity\:0\.5\] { --opacity: 0.5; } ``` Which won't work because the opacity variable resolves to `0.5` instead of the expected`50%`. This commit fixes that by always ensuring that we use `* 100%`. - If you already had a percentage, we would have `calc(50% * 100%)` which is `50%`. - If we have `0.5` then we would have `calc(0.5 * 100%)` which is also `50%`. * wrap everything but percentages in `calc(… * 100%)` * use `else if` * update changelog
2024-07-10 15:52:05 +02:00
- Ensure opacity modifier with variables work with `color-mix()` ([#13972](https://github.com/tailwindlabs/tailwindcss/pull/13972))
Discard invalid `variants` and `utilities` with modifiers (#13977) * ensure that static utilities do not take a `modifier` * do not allow multiple segments for now Right now, `bg-red-1/2/3` should not parse * add tests for variants that don't accept a modifier * ensure static variants do not accept a modifier * do not accept a modifier for some variants * add tests for utilities that don't accept a modifier * do not accept a modifier for some utilities * update changelog * re-add sorting related test
2024-07-10 15:56:33 +02:00
- Discard invalid `variants` and `utilities` with modifiers ([#13977](https://github.com/tailwindlabs/tailwindcss/pull/13977))
Add missing utilities that exist in v3 (#13971) * replace `resize-both` with `resize` * add missing `fill-none` * add missing `accent-auto` * add missing `blur-0` and `backdrop-blur-0` We already have `blur-none`, but that sets the blur to `' '`, whereas `blur-0` sets it to `blur(0)`. * add missing `drop-shadow-none` * support negative `hue-rotate` utilities * support negative `backdrop-hue-rotate` utilities * add missing `max-w-screen-*` utilities * update changelog * Revert "add missing `blur-0` and `backdrop-blur-0`" This reverts commit 7c42e4e25d3c06b312107afb5325df4b452086a6. * Revert "add missing `max-w-screen-*` utilities" This reverts commit 0c68e890ccfb68d104b252bdb3a8a2b2c34a0793.
2024-07-10 16:05:16 +02:00
- Add missing utilities that exist in v3, such as `resize`, `fill-none`, `accent-none`, `drop-shadow-none`, and negative `hue-rotate` and `backdrop-hue-rotate` utilities ([#13971](https://github.com/tailwindlabs/tailwindcss/pull/13971))
Don’t allow at-rule-only variants to be compounded (#14015) * Don’t allow at-rule-only variants to be compounded * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-07-17 14:52:29 -04:00
- Don’t allow at-rule-only variants to be compounded ([#14015](https://github.com/tailwindlabs/tailwindcss/pull/14015))
Ensure compound variants work with variants with multiple selectors (#14016) * Ensure compound variants work with variants with multiple selectors * Update changelog
2024-07-17 15:03:57 -04:00
- Ensure compound variants work with variants with multiple selectors ([#14016](https://github.com/tailwindlabs/tailwindcss/pull/14016))
Tweak changelog entry
2024-07-25 10:03:29 -04:00
- Ensure attribute values in `data-*` and `aria-*` modifiers are always quoted in the generated CSS ([#14040](https://github.com/tailwindlabs/tailwindcss/pull/14037))
Prep next release: `4.0.0-alpha.17` (#13951) * bump to version `4.0.0-alpha.17` * update changelog
2024-07-04 19:08:10 +02:00
Reduce specificity of * variant (#14056) This PR reduces the specificity of the * variant so that classes directly on the child elements take precedence over the styles applied by the parent. Previously a utility like `*:flex` would generate this CSS: ```css .\*\:flex > * { display: flex; } ``` This selector has a specificity of `0,1,0`, which is the same as the specificity for a bare utility class like `flex`, `block`, or `grid`. Because variants always appear later in the CSS file than bare utilities, this means that given this HTML, the `grid` class on the child element would have no effect: ```html <div class="*:flex"> <div>...</div> <div class="grid">...</div> <div>...</div> </div> ``` After this PR, the `*:flex` utility generates this CSS instead: ```css :where(.\*\:flex > *) { display: flex; } ``` This selector has a specificity of `0,0,0`, so even though it appears later in the CSS, a bare utility with a specificity of `0,1,0` will still take precedence. This is something we wanted to do when we first introduced the `*` variant in the v3 series, but couldn't because having such a low specificity meant that styles in Preflight would take precedence over utilities like `*:flex`, which is not would anyone would want. We can make this change for v4 because now all of Preflight is wrapped in a dedicated `@layer`, and rules from later layers always take precedence over rules from earlier layers even if the rule in the later layer has a lower specificity. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-07-25 10:09:47 -04:00
### Changed
- Reduce the specificity of the `*` variant so those styles can be overridden by child elements ([#14056](https://github.com/tailwindlabs/tailwindcss/pull/14056))
Prep next release: `4.0.0-alpha.17` (#13951) * bump to version `4.0.0-alpha.17` * update changelog
2024-07-04 19:08:10 +02:00
## [4.0.0-alpha.17] - 2024-07-04
Add `rounded-4xl` utility (#13827) * add `rounded-4xl` * update tests to reflect change * update changelog
2024-06-12 18:22:37 +02:00
### Added
- Add `rounded-4xl` utility ([#13827](https://github.com/tailwindlabs/tailwindcss/pull/13827))
Add `backdrop-blur-none` and `blur-none` utilities (#13831) * add `backdrop-blur-none` and `blur-none` utilities * update changelog
2024-06-13 15:27:45 +02:00
- Add `backdrop-blur-none` and `blur-none` utilities ([#13831](https://github.com/tailwindlabs/tailwindcss/pull/13831))
Fix spacing
2024-06-14 12:05:15 -04:00
- Include variable in output for bare utilities like `rounded` ([#13836](https://github.com/tailwindlabs/tailwindcss/pull/13836))
Prepare next alpha release: `4.0.0-alpha.16` (#13810) * bump version to 4.0.0-alpha.16 * update changelog
2024-06-07 18:38:44 +02:00
Support combining arbitrary shadows without a color with shadow color utilities (#13876) * Support combining arbitrary shadows without a color with shadow color utilities * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-06-21 17:36:59 -04:00
### Fixed
- Support combining arbitrary shadows without a color with shadow color utilities ([#13876](https://github.com/tailwindlabs/tailwindcss/pull/13876))
Use `initial` for `@property` fallbacks instead of ` ` (#13949) * Use `initial` for `@property` fallbacks instead of ` ` * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-07-04 11:20:05 -04:00
- Ensure `@property` fallbacks work correctly with properties with no `initial-value` ([#13949](https://github.com/tailwindlabs/tailwindcss/pull/13949))
Support combining arbitrary shadows without a color with shadow color utilities (#13876) * Support combining arbitrary shadows without a color with shadow color utilities * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-06-21 17:36:59 -04:00
Prepare next alpha release: `4.0.0-alpha.16` (#13810) * bump version to 4.0.0-alpha.16 * update changelog
2024-06-07 18:38:44 +02:00
## [4.0.0-alpha.16] - 2024-06-07
Update CHANGELOG.md
2024-08-08 10:05:15 -04:00
### Added
- Add `nth-*` variants ([#13661](https://github.com/tailwindlabs/tailwindcss/pull/13661))
- Add `bg-linear-*` utilities as an alias for the existing `bg-gradient-*` utilities ([#13783](https://github.com/tailwindlabs/tailwindcss/pull/13783))
- Support arbitrary linear gradient angles (e.g. `bg-linear-[125deg]`) ([#13783](https://github.com/tailwindlabs/tailwindcss/pull/13783))
Use `length` data type for `background-size` instead of `background-position` (#13771) * move `length` data type from `background-position` to `background-size` This way it's backwards compatible with v3. * sort data types * update changelog * make sure `length` is inferred later Otherwise `bg-[120px]` would be inferred as `length` instead of `position`. In v3 this maps to `position` instead of `length`. ```css .bg-\[120px\] { background-position: 120px; } ``` * add explicit test cases for `length` and `size` data types
2024-05-31 17:42:27 +02:00
### Fixed
- Use `length` data type for `background-size` instead of `background-position` ([#13771](https://github.com/tailwindlabs/tailwindcss/pull/13771))
[v4] Support negative values for `{col,row}-{start,end}` utilities (#13780) * Support negative values for `{col,row}-{start,end}` utilities * Update changelog
2024-06-03 11:34:16 -04:00
- Support negative values for `{col,row}-{start,end}` utilities ([#13780](https://github.com/tailwindlabs/tailwindcss/pull/13780))
Use long form `<length> | <percentage>` syntax for properties (#13660) * Use longform length + percentage syntax for properties Using properties that declare the shorthand syntax `<length-percentage>` has a bug where two properties side-by-side e.g. `var(—foo)var(—bar)` invalidate the property value when it should not. Switching the `@property` definition to use the long form syntax `<length> | <percentage>` fixes this. * Update changelog * Update tests
2024-06-03 11:49:33 -04:00
- Use long form `<length> | <percentage>` syntax for properties ([#13660](https://github.com/tailwindlabs/tailwindcss/pull/13660))
update changelog Add missing changelog entry for #13806
2024-06-07 10:23:14 +02:00
- Fix background position value of `bg-right-top`, `bg-right-bottom`, `bg-left-bottom` and `bg-left-top` ([#13806](https://github.com/tailwindlabs/tailwindcss/pull/13806))
4.0.0-alpha.15 (#13658)
2024-05-08 19:26:59 +02:00
## [4.0.0-alpha.15] - 2024-05-08
Fix contain-* utilities (#13521) * Fix contain-* utilities Fixes #13520. * Update changelog * Update CHANGELOG.md --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-04-13 10:56:15 +01:00
### Fixed
- Make sure `contain-*` utility variables resolve to a valid value ([#13521](https://github.com/tailwindlabs/tailwindcss/pull/13521))
Ensure strings are consumed as-is when using internal `segment()` (#13608) * ensure we handle strings as-in When encountering strings when using `segment` we didn't really treat them as actual strings. This means that if you used any parens, brackets, or curlies then we wanted them to be properly balanced. This should not be the case, whenever we encounter a string, we want to consume it as-is and don't want to worry about bracket balancing. We will now consume it until the end of the string (and make sure that escaped closing quotes are not seen as real closing quotes). * update changelog * drop unnecessary test Already had this test * ensure we utilities and variants defined * add example test that parses with unbalanced brackets inside quotes * improve changelog entry * hoist comment
2024-04-30 18:22:11 +02:00
- Support unbalanced parentheses and braces in quotes in arbitrary values and variants ([#13608](https://github.com/tailwindlabs/tailwindcss/pull/13608))
Add fallbacks for `@property` rules for Firefox (#13655) * Add `@property` fallbacks for Firefox * Update tests * Update changelog
2024-05-08 12:39:10 -04:00
- Add fallbacks for `@property` rules for Firefox ([#13655](https://github.com/tailwindlabs/tailwindcss/pull/13655))
Fix contain-* utilities (#13521) * Fix contain-* utilities Fixes #13520. * Update changelog * Update CHANGELOG.md --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-04-13 10:56:15 +01:00
Update CHANGELOG.md
2024-08-08 10:05:38 -04:00
### Changed
Update changelog
2024-04-09 21:05:15 -04:00
- Use `rem` units for breakpoints by default instead of `px` ([#13469](https://github.com/tailwindlabs/tailwindcss/pull/13469))
Further improve natural sorting of classes (#13532) * skip initial character we just saw Thanks Richard for noticing! Co-authored-by: Richard van Velzen <richard@frank.nl> * prevent calling `charCodeAt()` if we already computed the value * update changelog --------- Co-authored-by: Richard van Velzen <richard@frank.nl>
2024-04-16 18:12:42 +02:00
- Use natural sorting when sorting classes ([#13507](https://github.com/tailwindlabs/tailwindcss/pull/13507), [#13532](https://github.com/tailwindlabs/tailwindcss/pull/13532))
4.0.0-alpha.14 (#13487)
2024-04-09 20:55:54 +02:00
## [4.0.0-alpha.14] - 2024-04-09
Ensure deterministic SSR builds in `@tailwindcss/vite` (#13457) * ensure we wait in the `build` step as well It looks like when running `astro build` we only run this `build` step and not the `dev` step where we already use the `waitForRequestsIdle` code. Adding this to the `build` part as well does generate the correct result. * update changelog * fix typo * add comment * Don’t run transforms more than necessary * Don’t remove modules from the graph during SSR * Update changelog * Add `preview` script --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-04-09 00:10:08 +02:00
### Fixed
- Ensure deterministic SSR builds in `@tailwindcss/vite` ([#13457](https://github.com/tailwindlabs/tailwindcss/pull/13457))
Update changelog
2024-04-04 18:04:29 -04:00
Invert variant order application (#13478) * reverse order of variants This way variants work similar to how you would write them in CSS itself. This also allows us to remove the special "fixup" code that fixes the position of some variants because they have to be in a specific order (the end). Since the order wasn't intuitive we had to solve this with a fixup. This commit should allow us to remove this entirely, because now it is intuitive. * update tests to reflect variant order change * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-04-09 17:37:56 +02:00
### Changed
- Apply variants from left to right instead of inside-out ([#13478](https://github.com/tailwindlabs/tailwindcss/pull/13478))
Don't accommodate hidden elements in space/divide (#13459) * Don't accommodate hidden elements in space/divide * Update tests * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-04-09 12:59:08 -04:00
- Don't special-case `[hidden]` elements in `space-*`/`divide-*` utilities ([#13459](https://github.com/tailwindlabs/tailwindcss/pull/13459))
Invert variant order application (#13478) * reverse order of variants This way variants work similar to how you would write them in CSS itself. This also allows us to remove the special "fixup" code that fixes the position of some variants because they have to be in a specific order (the end). Since the order wasn't intuitive we had to solve this with a fixup. This commit should allow us to remove this entirely, because now it is intuitive. * update tests to reflect variant order change * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-04-09 17:37:56 +02:00
Update changelog
2024-04-04 18:04:29 -04:00
## [4.0.0-alpha.13] - 2024-04-04
Fix entry in wrong spot in changelog
2024-04-04 18:02:24 -04:00
### Fixed
- Always inline values for `shadow-*` utilities to ensure shadow colors work correctly ([#13449](https://github.com/tailwindlabs/tailwindcss/pull/13449))
4.0.0-alpha.12 (#13448)
2024-04-04 17:43:02 +02:00
## [4.0.0-alpha.12] - 2024-04-04
Enable Vite's `waitForRequestsIdle()` for client requests only (#13394) * Enable `waitForRequestsIdle` but only when not doing SSR * Cleanup comment * Update changelog
2024-03-28 22:57:16 -04:00
### Fixed
- Enable Vite's `waitForRequestsIdle()` for client requests only ([#13394](https://github.com/tailwindlabs/tailwindcss/pull/13394))
Fix typo in changelog
2024-04-04 18:01:55 -04:00
- Make sure `::first-letter` respects `::selection` styles ([#13408](https://github.com/tailwindlabs/tailwindcss/pull/13408))
Prepare next release: `4.0.0-alpha.11` (#13382) * bump versions to `4.0.0-alpha.11` * Update changelog * Update changelog * Update changelog * Update changelog
2024-03-27 13:32:10 -04:00
## [4.0.0-alpha.11] - 2024-03-27
[v4] Make 3D rotations composable (#13319) * Reorganize to co-locate rotate/skew/transform * Make 3D rotations composable * Uppercase axis in rotate functions * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-22 13:31:57 -04:00
### Added
- Make `rotate-x/y/z-*` utilities composable ([#13319](https://github.com/tailwindlabs/tailwindcss/pull/13319))
Prepare next release: `4.0.0-alpha.11` (#13382) * bump versions to `4.0.0-alpha.11` * Update changelog * Update changelog * Update changelog * Update changelog
2024-03-27 13:32:10 -04:00
- Apply Vite's CSS plugin transform to Tailwind-generated CSS in `@tailwindcss/vite` (e.g. inlining images) ([#13218](https://github.com/tailwindlabs/tailwindcss/pull/13218))
Add variant for @starting-style (#13329) * Add variant for @starting-style Co-Authored-By: Han Yeong-woo <han@yeongwoo.dev> * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Han Yeong-woo <han@yeongwoo.dev>
2024-03-22 15:38:06 -04:00
- Add `starting` variant for `@starting-style` ([#13329](https://github.com/tailwindlabs/tailwindcss/pull/13329))
Include `:popover-open` in `open` variant (#13331) * Include :popover-open in open variant Co-Authored-By: Luke Warlow <lwarlow@igalia.com> * Update changelog * Remove accidental package.json change * Revert playground changes --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Luke Warlow <lwarlow@igalia.com>
2024-03-22 16:00:07 -04:00
- Target `:popover-open` in existing `open` variant ([#13331](https://github.com/tailwindlabs/tailwindcss/pull/13331))
[v4] Make 3D rotations composable (#13319) * Reorganize to co-locate rotate/skew/transform * Make 3D rotations composable * Uppercase axis in rotate functions * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-22 13:31:57 -04:00
Remove percentage values for `translate-z` utilities (#13321) * handle `translate-z` separately * do not support fractions for `translate-z` * update changelog
2024-03-22 17:19:18 +01:00
### Fixed
Fix incorrect syntax for `translate-z`'s `@property` definition (#13327) * fix incorrect syntax for `translate-z` This used to be `<length-percentage>`, but we dropped percentage support because it's not valid in #13321 and I forgot about this one. * update changelog
2024-03-22 19:49:46 +01:00
- Remove percentage values for `translate-z` utilities ([#13321](https://github.com/tailwindlabs/tailwindcss/pull/13321), [#13327](https://github.com/tailwindlabs/tailwindcss/pull/13327))
Prepare next release: `4.0.0-alpha.11` (#13382) * bump versions to `4.0.0-alpha.11` * Update changelog * Update changelog * Update changelog * Update changelog
2024-03-27 13:32:10 -04:00
- Generate unique CSS bundle hashes in `@tailwindcss/vite` when Tailwind-generated CSS changes ([#13218](https://github.com/tailwindlabs/tailwindcss/pull/13218))
Inherit letter spacing in form controls (#13328) * Inherit letter spacing in form controls * Update changelog * Update snapshots
2024-03-22 16:01:39 -04:00
- Inherit letter spacing in form controls ([#13328](https://github.com/tailwindlabs/tailwindcss/pull/13328))
Ensure `build` command is executed when using `--output` instead of `-o` (#13369)
2024-03-27 16:10:55 +01:00
- Ensure `build` command is executed when using `--output` instead of `-o` ([#13369](https://github.com/tailwindlabs/tailwindcss/pull/13369))
Prepare next release: `4.0.0-alpha.11` (#13382) * bump versions to `4.0.0-alpha.11` * Update changelog * Update changelog * Update changelog * Update changelog
2024-03-27 13:32:10 -04:00
- Prevent `@tailwindcss/vite` from hanging in serve mode ([#13380](https://github.com/tailwindlabs/tailwindcss/pull/13380))
Prepare next release: `4.0.0-alpha.10` (#13281) * bump versions to `4.0.0-alpha.10` * update changelog * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-21 18:32:03 +01:00
## [4.0.0-alpha.10] - 2024-03-19
Add `inherit` as a universal color (#13258) * add `inherit` as a hardcoded color * add `inherit` to suggestions * update changelog * re-order changelog sections
2024-03-15 19:31:36 +01:00
### Added
Inline the `tailwindcss/index.css` contents at publish time (#13233) * add `pre-publish-optimizations` script * handle `@import` ourselves This implementation is fairly simple right now, because we don't have to worry about resolving folders or modules since we don't use them. * pretty print index.css file * update changelog * Revert "handle `@import` ourselves" This reverts commit 13a46404c16ee67e4e1b7eaf58ae67321113eb07. * drop the `1.` * Update scripts/pre-publish-optimizations.mjs Co-authored-by: Jordan Pittman <jordan@cryptica.me> * Update CHANGELOG.md Co-authored-by: Adam Wathan <adam.wathan@gmail.com> * run prettier --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-03-13 22:26:10 +01:00
Add `inherit` as a universal color (#13258) * add `inherit` as a hardcoded color * add `inherit` to suggestions * update changelog * re-order changelog sections
2024-03-15 19:31:36 +01:00
- Add `inherit` as a universal color ([#13258](https://github.com/tailwindlabs/tailwindcss/pull/13258))
Remove bare value handling for perspective utilities (#13288) * Remove bare value handling for perspective utilities * move `perspective-123` example This is now moved to the spot where we ensure that nothing is generated at all. This prevents us from accidentally updating a snapshot and missing a potential bug. * update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-03-20 10:25:24 -04:00
- Add 3D transform utilities ([#13248](https://github.com/tailwindlabs/tailwindcss/pull/13248), [#13288](https://github.com/tailwindlabs/tailwindcss/pull/13288))
Prepare `4.0.0-alpha.9` release (#13231) * update changelog * bump versions to `4.0.0-alpha.9` * move the optimizeCss change to `Changed`
2024-03-13 18:11:06 +01:00
Validate bare values (#13245) * add validation for bare values * add bare value validation to `row-span`, `row-start`, `row-end`, `row-span`, `row-start`, and `row-end` * update changelog * validate bare values in `utilities.functional` utilities * mark candidates as invalid if the leftover value is an empty string * Update packages/tailwindcss/src/candidate.ts Co-authored-by: Jordan Pittman <jordan@cryptica.me> * validate `from`, `via` and `to` This way we make sure that the bare value ends with `%`, and the value before it is a number. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-03-15 15:08:26 +01:00
### Fixed
- Validate bare values ([#13245](https://github.com/tailwindlabs/tailwindcss/pull/13245))
Parse candidates in `.svelte` files with `class:abc="condition"` syntax (#13274) * handle `.svelte` file In svelte there is a convention where you can use `<div class:px-4="condition" />` which means that we extract `class:px-4` as a utility where `class` is a variant. This is obviously incorrect, to solve this we can ignore the `class:` part before parsing the whole file. This is also what we do in v3. Ideally we have completely separate parsers for various programming languages (based on file type) and fallback to the generic one we have now. Implementing that, is a much bigger scope. * flatten match arms * add test to verify we can parse `class:px-4="condition"` * explicitly ingore everything but the svelte file * merge tests There is some funky stuff happening when running `cargo test` where it sees contents from another test. Maybe a bug in the tmpdir crate. I don't see this problem locally when running `cargo nextest run`, but when using the native `cargo test` command it fails. * update changelog * run prettier * Update oxide/crates/core/src/lib.rs Co-authored-by: Jordan Pittman <jordan@cryptica.me> * fixup syntax errors --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-03-18 23:24:22 +01:00
- Parse candidates in `.svelte` files with `class:abc="condition"` syntax ([#13274](https://github.com/tailwindlabs/tailwindcss/pull/13274))
Validate bare values (#13245) * add validation for bare values * add bare value validation to `row-span`, `row-start`, `row-end`, `row-span`, `row-start`, and `row-end` * update changelog * validate bare values in `utilities.functional` utilities * mark candidates as invalid if the leftover value is an empty string * Update packages/tailwindcss/src/candidate.ts Co-authored-by: Jordan Pittman <jordan@cryptica.me> * validate `from`, `via` and `to` This way we make sure that the bare value ends with `%`, and the value before it is a number. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-03-15 15:08:26 +01:00
Add `inherit` as a universal color (#13258) * add `inherit` as a hardcoded color * add `inherit` to suggestions * update changelog * re-order changelog sections
2024-03-15 19:31:36 +01:00
### Changed
- Inline `@import` rules in `tailwindcss/index.css` at publish time for better performance ([#13233](https://github.com/tailwindlabs/tailwindcss/pull/13233))
Prepare next release: `4.0.0-alpha.10` (#13281) * bump versions to `4.0.0-alpha.10` * update changelog * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-21 18:32:03 +01:00
- Include custom properties with fallbacks in utility class values ([#13177](https://github.com/tailwindlabs/tailwindcss/pull/13177))
Add `inherit` as a universal color (#13258) * add `inherit` as a hardcoded color * add `inherit` to suggestions * update changelog * re-order changelog sections
2024-03-15 19:31:36 +01:00
Prepare `4.0.0-alpha.9` release (#13231) * update changelog * bump versions to `4.0.0-alpha.9` * move the optimizeCss change to `Changed`
2024-03-13 18:11:06 +01:00
## [4.0.0-alpha.9] - 2024-03-13
Support `@theme reference` without `@import` (#13222) * Support `@theme reference` without `@import` * Fix test * Update tests * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-12 14:07:01 -04:00
### Added
- Support `@theme reference { … }` for defining theme values without emitting variables ([#13222](https://github.com/tailwindlabs/tailwindcss/pull/13222))
Prepare alpha.8 release (#13203) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-11 15:10:21 -04:00
Don't rely on existence of --default-transition-* variables in transition utilities (#13219) * Don't rely on existence of --default-transition-* variables in transition utilities * Update changelog * Add test with no default transition values defined * Inline value for --default-transition-timing-function This is more consistent with how things worked in v3 and ensures things will still work if the user suppresses the output of all CSS variables. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-13 12:14:05 -04:00
### Fixed
Move `optimizeCss` to the packages where it's used (#13230) * add `@tailwindcss/optimize` as a separate package * remove lightningcss from `tailwindcss` * import `optimizeCss` from `@tailwindcss/optimize` * ensure we use `src/` files in development * move `devDependencies` after `dependencies` Just for consistency * inline `optimizeCss` in leaf packages Instead of introducing a custom `@tailwindcss/optimize` package * update changelog * fix changelog
2024-03-13 17:25:16 +01:00
- Fix incorrect properties in line-clamp utilities ([#13220](https://github.com/tailwindlabs/tailwindcss/pull/13220))
Don't rely on existence of --default-transition-* variables in transition utilities (#13219) * Don't rely on existence of --default-transition-* variables in transition utilities * Update changelog * Add test with no default transition values defined * Inline value for --default-transition-timing-function This is more consistent with how things worked in v3 and ensures things will still work if the user suppresses the output of all CSS variables. --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-13 12:14:05 -04:00
- Don't rely on existence of `--default-transition-*` variables in `transition-*` utilities ([#13219](https://github.com/tailwindlabs/tailwindcss/pull/13219))
Prepare `4.0.0-alpha.9` release (#13231) * update changelog * bump versions to `4.0.0-alpha.9` * move the optimizeCss change to `Changed`
2024-03-13 18:11:06 +01:00
### Changed
- Move `optimizeCss` to the packages where it's used ([#13230](https://github.com/tailwindlabs/tailwindcss/pull/13230))
Prepare alpha.8 release (#13203) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-11 15:10:21 -04:00
## [4.0.0-alpha.8] - 2024-03-11
Ensure scale utilities support percentages (#13182) * Ensure scale utilities support percentages * Update changelog * Fix changelog entry --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com> Co-authored-by: wongjn <11310624+wongjn@users.noreply.github.com>
2024-03-11 13:14:10 -04:00
### Fixed
- Ensure `scale-*` utilities support percentage values ([#13182](https://github.com/tailwindlabs/tailwindcss/pull/13182))
Prevent `content-none` from being overridden when conditionally styling `::before`/`::after` (#13187) * Prevent content-none from being overridden when conditionally styling before/after * Update changelog * Fix changelog entry --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-11 14:09:50 -04:00
- Prevent `content-none` from being overridden when conditionally styling `::before`/`::after` ([#13187](https://github.com/tailwindlabs/tailwindcss/pull/13187))
Reset borders, padding, and margin universally (#13189) * Reset borders, padding, and margin universally Noticed iframes have a default border we weren't resetting, feels safest to just remove borders across the board and reintroduce them for form controls. We were also resetting padding on an element by element basis but I can't think of any elements we are actually trying to avoid resetting padding on, so just reset it everywhere. This also removes the left margin on file buttons that separates the button from the meta data about the currently selected file but I think this is fine, let the user decide how much space to put there intentionally like we do with other things. * Include ::first-letter Supports margin/padding/border (but not box-sizing) so should be in reset list. * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-11 14:17:19 -04:00
- Remove default borders from `iframe` elements ([#13189](https://github.com/tailwindlabs/tailwindcss/pull/13189))
Prepare next `4.0.0-alpha.7` release (#13163) * bump versions to `4.0.0-alpha.7` * update changelog
2024-03-08 21:46:03 +01:00
Remove static radius values from theme (#13186) * Remove static radius values from theme * Update snapshots * Update changelog * Use static utilities + a big loop --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-11 14:02:18 -04:00
### Changed
- Replace `--radius-none` and `--radius-full` theme values with static `rounded-none` and `rounded-full` utilities ([#13186](https://github.com/tailwindlabs/tailwindcss/pull/13186))
Add incremental rebuilds to `@tailwindcss/cli` (#13169) * ensure the root CSS file part of the `cssImportPaths` * add incremental rebuilds to `@tailwindcss/cli` * update changelog
2024-03-11 19:32:41 +01:00
### Added
- Improve performance of incremental rebuilds for `@tailwindcss/cli` ([#13169](https://github.com/tailwindlabs/tailwindcss/pull/13169))
Add incremental rebuilds to `@tailwindcss/postcss` (#13170) * rename PostCSS plugin name from `tailwindcss-v4` to `@tailwindcss/postcss` * add incremental rebuilds to `@tailwindcss/postcss` * improve comment * update changelog * Simplify nested conditionals * Simplify more conditionals * Refactor file modification tracking --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-11 20:01:28 +01:00
- Improve performance of incremental rebuilds for `@tailwindcss/postcss` ([#13170](https://github.com/tailwindlabs/tailwindcss/pull/13170))
Add incremental rebuilds to `@tailwindcss/cli` (#13169) * ensure the root CSS file part of the `cssImportPaths` * add incremental rebuilds to `@tailwindcss/cli` * update changelog
2024-03-11 19:32:41 +01:00
Prepare next `4.0.0-alpha.7` release (#13163) * bump versions to `4.0.0-alpha.7` * update changelog
2024-03-08 21:46:03 +01:00
## [4.0.0-alpha.7] - 2024-03-08
Tweak changelog entries
2024-03-08 15:38:03 -05:00
### Added
- Add `font-stretch` utilities ([#13153](https://github.com/tailwindlabs/tailwindcss/pull/13153))
- Publish packages with [npm provenance](https://docs.npmjs.com/generating-provenance-statements) ([#13160](https://github.com/tailwindlabs/tailwindcss/pull/13160))
- Build native packages for Android ([#13115](https://github.com/tailwindlabs/tailwindcss/pull/13115), [#13161](https://github.com/tailwindlabs/tailwindcss/pull/13161))
- Make CSS optimization and minification configurable in PostCSS plugin and CLI ([#13130](https://github.com/tailwindlabs/tailwindcss/pull/13130))
Don't error on `@apply` with extra whitespace (#13144) * Don't crash on @apply with extra whitespace * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-07 22:00:15 -05:00
### Fixed
- Don't error on `@apply` with leading/trailing whitespace ([#13144](https://github.com/tailwindlabs/tailwindcss/pull/13144))
Parse CSS files with CRLF line endings (#13162) * Parse CSS files with CRLF line endings * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-08 15:28:58 -05:00
- Correctly parse CSS using Windows line endings ([#13162](https://github.com/tailwindlabs/tailwindcss/pull/13162))
Don't error on `@apply` with extra whitespace (#13144) * Don't crash on @apply with extra whitespace * Update changelog --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-03-07 22:00:15 -05:00
v4 changelog (#13131) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-03-07 14:26:35 -05:00
## [4.0.0-alpha.6] - 2024-03-07
### Fixed
- Only set `border-style` for appropriate border side ([#13124](https://github.com/tailwindlabs/tailwindcss/pull/13124))
### Changed
- Error when `@theme` contains unsupported rules/declarations ([#13125](https://github.com/tailwindlabs/tailwindcss/pull/13125))
## [4.0.0-alpha.5] - 2024-03-06
### Fixed
- Don't scan ignored files even if a `.git` folder is not present ([#13119](https://github.com/tailwindlabs/tailwindcss/pull/13119))
## [4.0.0-alpha.4] - 2024-03-06
### Fixed
- Support importing framework CSS files without including a `.css` extension ([#13110](https://github.com/tailwindlabs/tailwindcss/pull/13110))
## [4.0.0-alpha.3] - 2024-03-06
### Added
- Support putting the important modifier at the beginning of a utility ([#13103](https://github.com/tailwindlabs/tailwindcss/pull/13103))
### Fixed
Prep next release: `4.0.0-alpha.17` (#13951) * bump to version `4.0.0-alpha.17` * update changelog
2024-07-04 19:08:10 +02:00
- Node compatibility fix ([#13104](https://github.com/tailwindlabs/tailwindcss/pull/13104))
v4 changelog (#13131) --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-03-07 14:26:35 -05:00
### Changes
- Drop deprecated `decoration-slice` and `decoration-clone` utilities ([#13107](https://github.com/tailwindlabs/tailwindcss/pull/13107))
## [4.0.0-alpha.2] - 2024-03-06
### Changed
- Move the CLI into a separate `@tailwindcss/cli` package ([#13095](https://github.com/tailwindlabs/tailwindcss/pull/13095))
## [4.0.0-alpha.1] - 2024-03-06
Ensure `Symbol.dispose` and `Symbol.asyncDispose` are available (#15404) We recently introduced some better instrumentation (https://github.com/tailwindlabs/tailwindcss/pull/15303) which uses the new `using` keyword. I made sure that this was compiled correctly for environments where `using` is not available yet. The issue is that this also relies on `Symbol.dispose` being available. In my testing on our minimal required Node.js version (18) it did work fine. However, turns out that I was using `18.20.x` locally where `Symbol.dispose` **_is_** available, but on older version of Node.js 18 (e.g.: `18.17.x`) it is **_not_** available. This now results in some completely broken builds, e.g.: when running on Cloudflare Pages. See: #15399 I could reproduce this error in CI, by temporarily downgrading the used Node.js version to `18.17.0`. See: <img width="1142" alt="image" src="https://github.com/user-attachments/assets/5bf30f80-9ca0-40d9-ad02-d1ffb4e0e5dd" /> Implementing the proper polyfill, as recommended by the TypeScript docs ( see: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-2.html#:~:text=Symbol.dispose,-??=%20Symbol(%22Symbol.dispose ), the error goes away. (If you look at CI after the polyfill, it still fails but for different reasons unrelated to this change) Fixes: #15399 --- ## Test plan 1. I reproduced it in CI, and I kept the commits so that you can take a look where it fails with the `Object not disposable`. 2. Using the provided reproduction from #15399: ### Before It works on Node.js v18.20.x, but switching to Node.js v18.17.x you can see it fail: <img width="1607" alt="image" src="https://github.com/user-attachments/assets/cb6ab73a-8eb2-4003-bab7-b2390f1c879d" /> ### After Using pnpm's overrides, we can apply the fix from this PR and test it in the reproduction. You'll notice that it now works in both Node.js v18.20.x and v18.17.x <img width="1604" alt="image" src="https://github.com/user-attachments/assets/b3a65557-0658-4cb0-a2f9-e3079c7936d5" />
2024-12-16 14:17:44 +01:00
Prepare v4.0.0-beta.8 release (#15418)
2024-12-17 13:31:28 +01:00
- First 4.0.0-alpha.1 release
Merge changelogs (#15698) This PR makes sure all v3 and earlier versions are visible in the changelog as well as the v4 changelog entries.
2025-01-27 12:54:26 +01:00
## [3.4.17] - 2024-12-17
### Fixed
- Work around Node v22.12+ issue ([#15421](https://github.com/tailwindlabs/tailwindcss/pull/15421))
## [3.4.16] - 2024-12-03
### Fixed
- Ensure the TypeScript types for `PluginsConfig` allow `undefined` values ([#14668](https://github.com/tailwindlabs/tailwindcss/pull/14668))
# Changed
- Bumped lilconfig to v3.x ([#15289](https://github.com/tailwindlabs/tailwindcss/pull/15289))
## [3.4.15] - 2024-11-14
- Bump versions for security vulnerabilities ([#14697](https://github.com/tailwindlabs/tailwindcss/pull/14697))
- Ensure the TypeScript types for the `boxShadow` theme configuration allows arrays ([#14856](https://github.com/tailwindlabs/tailwindcss/pull/14856))
- Set fallback for opacity variables to ensure setting colors with the `selection:*` variant works in Chrome 131 ([#15003](https://github.com/tailwindlabs/tailwindcss/pull/15003))
## [3.4.14] - 2024-10-15
### Fixed
- Don't set `display: none` on elements that use `hidden="until-found"` ([#14625](https://github.com/tailwindlabs/tailwindcss/pull/14625))
## [3.4.13] - 2024-09-23
### Fixed
- Improve source glob verification performance ([#14481](https://github.com/tailwindlabs/tailwindcss/pull/14481))
## [3.4.12] - 2024-09-17
### Fixed
- Ensure using `@apply` with utilities that use `@defaults` works with rules defined in the base layer when using `optimizeUniversalDefaults` ([#14427](https://github.com/tailwindlabs/tailwindcss/pull/14427))
## [3.4.11] - 2024-09-11
### Fixed
- Allow `anchor-size(…)` in arbitrary values ([#14393](https://github.com/tailwindlabs/tailwindcss/pull/14393))
## [3.4.10] - 2024-08-13
### Fixed
- Bump versions of plugins in the Standalone CLI ([#14185](https://github.com/tailwindlabs/tailwindcss/pull/14185))
## [3.4.9] - 2024-08-08
### Fixed
- No longer warns when broad glob patterns are detecting `vendor` folders
## [3.4.8] - 2024-08-07
### Fixed
- Fix minification when using nested CSS ([#14105](https://github.com/tailwindlabs/tailwindcss/pull/14105))
- Warn when broad glob patterns are used in the content configuration ([#14140](https://github.com/tailwindlabs/tailwindcss/pull/14140))
## [3.4.7] - 2024-07-25
### Fixed
- Fix class detection in Slim templates with attached attributes and ID ([#14019](https://github.com/tailwindlabs/tailwindcss/pull/14019))
- Ensure attribute values in `data-*` and `aria-*` modifiers are always quoted in the generated CSS ([#14037](https://github.com/tailwindlabs/tailwindcss/pull/14037))
## [3.4.6] - 2024-07-16
### Fixed
- Fix detection of some utilities in Slim/Pug templates ([#14006](https://github.com/tailwindlabs/tailwindcss/pull/14006))
### Changed
- Loosen `:is()` wrapping rules when using an important selector ([#13900](https://github.com/tailwindlabs/tailwindcss/pull/13900))
## [3.4.5] - 2024-07-15
### Fixed
- Disable automatic `var()` injection for anchor properties ([#13826](https://github.com/tailwindlabs/tailwindcss/pull/13826))
- Use no value instead of `blur(0px)` for `backdrop-blur-none` and `blur-none` utilities ([#13830](https://github.com/tailwindlabs/tailwindcss/pull/13830))
- Add `.mts` and `.cts` config file detection ([#13940](https://github.com/tailwindlabs/tailwindcss/pull/13940))
- Don't generate utilities like `px-1` unnecessarily when using utilities like `px-1.5` ([#13959](https://github.com/tailwindlabs/tailwindcss/pull/13959))
- Always generate `-webkit-backdrop-filter` for `backdrop-*` utilities ([#13997](https://github.com/tailwindlabs/tailwindcss/pull/13997))
## [3.4.4] - 2024-06-05
### Fixed
- Make it possible to use multiple `<alpha-value>` placeholders in a single color definition ([#13740](https://github.com/tailwindlabs/tailwindcss/pull/13740))
- Don't prefix classes in arbitrary values of `has-*`, `group-has-*`, and `peer-has-*` variants ([#13770](https://github.com/tailwindlabs/tailwindcss/pull/13770))
- Support negative values for `{col,row}-{start,end}` utilities ([#13781](https://github.com/tailwindlabs/tailwindcss/pull/13781))
- Update embedded browserslist database ([#13792](https://github.com/tailwindlabs/tailwindcss/pull/13792))
## [3.4.3] - 2024-03-27
### Fixed
- Revert changes to glob handling ([#13384](https://github.com/tailwindlabs/tailwindcss/pull/13384))
## [3.4.2] - 2024-03-27
### Fixed
- Ensure max specificity of `0,0,1` for button and input Preflight rules ([#12735](https://github.com/tailwindlabs/tailwindcss/pull/12735))
- Improve glob handling for folders with `(`, `)`, `[` or `]` in the file path ([#12715](https://github.com/tailwindlabs/tailwindcss/pull/12715))
- Split `:has` rules when using `experimental.optimizeUniversalDefaults` ([#12736](https://github.com/tailwindlabs/tailwindcss/pull/12736))
- Sort arbitrary properties alphabetically across multiple class lists ([#12911](https://github.com/tailwindlabs/tailwindcss/pull/12911))
- Add `mix-blend-plus-darker` utility ([#12923](https://github.com/tailwindlabs/tailwindcss/pull/12923))
- Ensure dashes are allowed in variant modifiers ([#13303](https://github.com/tailwindlabs/tailwindcss/pull/13303))
- Fix crash showing completions in Intellisense when using a custom separator ([#13306](https://github.com/tailwindlabs/tailwindcss/pull/13306))
- Transpile `import.meta.url` in config files ([#13322](https://github.com/tailwindlabs/tailwindcss/pull/13322))
- Reset letter spacing for form elements ([#13150](https://github.com/tailwindlabs/tailwindcss/pull/13150))
- Fix missing `xx-large` and remove double `x-large` absolute size ([#13324](https://github.com/tailwindlabs/tailwindcss/pull/13324))
- Don't error when encountering nested CSS unless trying to `@apply` a class that uses nesting ([#13325](https://github.com/tailwindlabs/tailwindcss/pull/13325))
- Ensure that arbitrary properties respect `important` configuration ([#13353](https://github.com/tailwindlabs/tailwindcss/pull/13353))
- Change dark mode selector so `@apply` works correctly with pseudo elements ([#13379](https://github.com/tailwindlabs/tailwindcss/pull/13379))
## [3.4.1] - 2024-01-05
### Fixed
- Don't remove keyframe stops when using important utilities ([#12639](https://github.com/tailwindlabs/tailwindcss/pull/12639))
- Don't add spaces to gradients and grid track names when followed by `calc()` ([#12704](https://github.com/tailwindlabs/tailwindcss/pull/12704))
- Restore old behavior for `class` dark mode strategy ([#12717](https://github.com/tailwindlabs/tailwindcss/pull/12717))
- Improve glob handling for folders with `(`, `)`, `[` or `]` in the file path ([#12715](https://github.com/tailwindlabs/tailwindcss/pull/12715))
### Added
- Add new `selector` and `variant` strategies for dark mode ([#12717](https://github.com/tailwindlabs/tailwindcss/pull/12717))
### Changed
- Support `rtl` and `ltr` variants on same element as `dir` attribute ([#12717](https://github.com/tailwindlabs/tailwindcss/pull/12717))
## [3.4.0] - 2023-12-19
### Added
- Add `svh`, `lvh`, and `dvh` values to default `height`/`min-height`/`max-height` theme ([#11317](https://github.com/tailwindlabs/tailwindcss/pull/11317))
- Add `has-*` variants for `:has(...)` pseudo-class ([#11318](https://github.com/tailwindlabs/tailwindcss/pull/11318))
- Add `text-wrap` utilities including `text-balance` and `text-pretty` ([#11320](https://github.com/tailwindlabs/tailwindcss/pull/11320), [#12031](https://github.com/tailwindlabs/tailwindcss/pull/12031))
- Extend default `opacity` scale to include all steps of 5 ([#11832](https://github.com/tailwindlabs/tailwindcss/pull/11832))
- Update Preflight `html` styles to include shadow DOM `:host` pseudo-class ([#11200](https://github.com/tailwindlabs/tailwindcss/pull/11200))
- Increase default values for `grid-rows-*` utilities from 1–6 to 1–12 ([#12180](https://github.com/tailwindlabs/tailwindcss/pull/12180))
- Add `size-*` utilities ([#12287](https://github.com/tailwindlabs/tailwindcss/pull/12287))
- Add utilities for CSS subgrid ([#12298](https://github.com/tailwindlabs/tailwindcss/pull/12298))
- Add spacing scale to `min-w-*`, `min-h-*`, and `max-w-*` utilities ([#12300](https://github.com/tailwindlabs/tailwindcss/pull/12300))
- Add `forced-color-adjust` utilities ([#11931](https://github.com/tailwindlabs/tailwindcss/pull/11931))
- Add `forced-colors` variant ([#11694](https://github.com/tailwindlabs/tailwindcss/pull/11694), [#12582](https://github.com/tailwindlabs/tailwindcss/pull/12582))
- Add `appearance-auto` utility ([#12404](https://github.com/tailwindlabs/tailwindcss/pull/12404))
- Add logical property values for `float` and `clear` utilities ([#12480](https://github.com/tailwindlabs/tailwindcss/pull/12480))
- Add `*` variant for targeting direct children ([#12551](https://github.com/tailwindlabs/tailwindcss/pull/12551))
### Changed
- Simplify the `sans` font-family stack ([#11748](https://github.com/tailwindlabs/tailwindcss/pull/11748))
- Disable the tap highlight overlay on iOS ([#12299](https://github.com/tailwindlabs/tailwindcss/pull/12299))
- Improve relative precedence of `rtl`, `ltr`, `forced-colors`, and `dark` variants ([#12584](https://github.com/tailwindlabs/tailwindcss/pull/12584))
## [3.3.7] - 2023-12-18
### Fixed
- Fix support for container query utilities with arbitrary values ([#12534](https://github.com/tailwindlabs/tailwindcss/pull/12534))
- Fix custom config loading in Standalone CLI ([#12616](https://github.com/tailwindlabs/tailwindcss/pull/12616))
## [3.3.6] - 2023-12-04
### Fixed
- Don’t add spaces to negative numbers following a comma ([#12324](https://github.com/tailwindlabs/tailwindcss/pull/12324))
- Don't emit `@config` in CSS when watching via the CLI ([#12327](https://github.com/tailwindlabs/tailwindcss/pull/12327))
- Improve types for `resolveConfig` ([#12272](https://github.com/tailwindlabs/tailwindcss/pull/12272))
- Ensure configured `font-feature-settings` for `mono` are included in Preflight ([#12342](https://github.com/tailwindlabs/tailwindcss/pull/12342))
- Improve candidate detection in minified JS arrays (without spaces) ([#12396](https://github.com/tailwindlabs/tailwindcss/pull/12396))
- Don't crash when given applying a variant to a negated version of a simple utility ([#12514](https://github.com/tailwindlabs/tailwindcss/pull/12514))
- Fix support for slashes in arbitrary modifiers ([#12515](https://github.com/tailwindlabs/tailwindcss/pull/12515))
- Fix source maps of variant utilities that come from an `@layer` rule ([#12508](https://github.com/tailwindlabs/tailwindcss/pull/12508))
- Fix loading of built-in plugins when using an ESM or TypeScript config with the Standalone CLI ([#12506](https://github.com/tailwindlabs/tailwindcss/pull/12506))
## [3.3.5] - 2023-10-25
### Fixed
- Fix incorrect spaces around `-` in `calc()` expression ([#12283](https://github.com/tailwindlabs/tailwindcss/pull/12283))
## [3.3.4] - 2023-10-24
### Fixed
- Improve normalisation of `calc()`-like functions ([#11686](https://github.com/tailwindlabs/tailwindcss/pull/11686))
- Skip `calc()` normalisation in nested `theme()` calls ([#11705](https://github.com/tailwindlabs/tailwindcss/pull/11705))
- Fix incorrectly generated CSS when using square brackets inside arbitrary properties ([#11709](https://github.com/tailwindlabs/tailwindcss/pull/11709))
- Make `content` optional for presets in TypeScript types ([#11730](https://github.com/tailwindlabs/tailwindcss/pull/11730))
- Handle variable colors that have variable fallback values ([#12049](https://github.com/tailwindlabs/tailwindcss/pull/12049))
- Batch reading content files to prevent `too many open files` error ([#12079](https://github.com/tailwindlabs/tailwindcss/pull/12079))
- Skip over classes inside `:not(…)` when nested in an at-rule ([#12105](https://github.com/tailwindlabs/tailwindcss/pull/12105))
- Update types to work with `Node16` module resolution ([#12097](https://github.com/tailwindlabs/tailwindcss/pull/12097))
- Don’t crash when important and parent selectors are equal in `@apply` ([#12112](https://github.com/tailwindlabs/tailwindcss/pull/12112))
- Eliminate irrelevant rules when applying variants ([#12113](https://github.com/tailwindlabs/tailwindcss/pull/12113))
- Improve RegEx parser, reduce possibilities as the key for arbitrary properties ([#12121](https://github.com/tailwindlabs/tailwindcss/pull/12121))
- Fix sorting of utilities that share multiple candidates ([#12173](https://github.com/tailwindlabs/tailwindcss/pull/12173))
- Ensure variants with arbitrary values and a modifier are correctly matched in the RegEx based parser ([#12179](https://github.com/tailwindlabs/tailwindcss/pull/12179))
- Fix crash when watching renamed files on FreeBSD ([#12193](https://github.com/tailwindlabs/tailwindcss/pull/12193))
- Allow plugins from a parent document to be used in an iframe ([#12208](https://github.com/tailwindlabs/tailwindcss/pull/12208))
- Add types for `tailwindcss/nesting` ([#12269](https://github.com/tailwindlabs/tailwindcss/pull/12269))
- Bump `jiti`, `fast-glob`, and `browserlist` dependencies ([#11550](https://github.com/tailwindlabs/tailwindcss/pull/11550))
- Improve automatic `var` injection for properties that accept a `<dashed-ident>` ([#12236](https://github.com/tailwindlabs/tailwindcss/pull/12236))
## [3.3.3] - 2023-07-13
### Fixed
- Fix issue where some pseudo-element variants generated the wrong selector ([#10943](https://github.com/tailwindlabs/tailwindcss/pull/10943), [#10962](https://github.com/tailwindlabs/tailwindcss/pull/10962), [#11111](https://github.com/tailwindlabs/tailwindcss/pull/11111))
- Make font settings propagate into buttons, inputs, etc. ([#10940](https://github.com/tailwindlabs/tailwindcss/pull/10940))
- Fix parsing of `theme()` inside `calc()` when there are no spaces around operators ([#11157](https://github.com/tailwindlabs/tailwindcss/pull/11157))
- Ensure `repeating-conic-gradient` is detected as an image ([#11180](https://github.com/tailwindlabs/tailwindcss/pull/11180))
- Move unknown pseudo-elements outside of `:is` by default ([#11345](https://github.com/tailwindlabs/tailwindcss/pull/11345))
- Escape animation names when prefixes contain special characters ([#11470](https://github.com/tailwindlabs/tailwindcss/pull/11470))
- Don't prefix arbitrary classes in `group` and `peer` variants ([#11454](https://github.com/tailwindlabs/tailwindcss/pull/11454))
- Sort classes using position of first matching rule ([#11504](https://github.com/tailwindlabs/tailwindcss/pull/11504))
- Allow variant to be an at-rule without a prelude ([#11589](https://github.com/tailwindlabs/tailwindcss/pull/11589))
- Make PostCSS plugin async to improve performance ([#11548](https://github.com/tailwindlabs/tailwindcss/pull/11548))
- Don’t error when a config file is missing ([f97759f](https://github.com/tailwindlabs/tailwindcss/commit/f97759f808d15ace66647b1405744fcf95a392e5))
### Added
- Add `aria-busy` utility ([#10966](https://github.com/tailwindlabs/tailwindcss/pull/10966))
### Changed
- Reset padding for `<dialog>` elements in preflight ([#11069](https://github.com/tailwindlabs/tailwindcss/pull/11069))
## [3.3.2] - 2023-04-25
### Fixed
- Don’t move unknown pseudo-elements to the end of selectors ([#10943](https://github.com/tailwindlabs/tailwindcss/pull/10943), [#10962](https://github.com/tailwindlabs/tailwindcss/pull/10962))
- Inherit gradient stop positions when using variants ([#11002](https://github.com/tailwindlabs/tailwindcss/pull/11002))
- Honor default `to` position of gradient when using implicit transparent colors ([#11002](https://github.com/tailwindlabs/tailwindcss/pull/11002))
- Ensure `@tailwindcss/oxide` doesn't leak in the stable engine ([#10988](https://github.com/tailwindlabs/tailwindcss/pull/10988))
- Ensure multiple `theme(spacing[5])` calls with bracket notation in arbitrary properties work ([#11039](https://github.com/tailwindlabs/tailwindcss/pull/11039))
- Normalize arbitrary modifiers ([#11057](https://github.com/tailwindlabs/tailwindcss/pull/11057))
### Changed
- Drop support for Node.js v12 ([#11089](https://github.com/tailwindlabs/tailwindcss/pull/11089))
## [3.3.1] - 2023-03-30
### Fixed
- Fix edge case bug when loading a TypeScript config file with webpack ([#10898](https://github.com/tailwindlabs/tailwindcss/pull/10898))
- Fix variant, `@apply`, and `important` selectors when using `:is()` or `:has()` with pseudo-elements ([#10903](https://github.com/tailwindlabs/tailwindcss/pull/10903))
- Fix `safelist` config types ([#10901](https://github.com/tailwindlabs/tailwindcss/pull/10901))
- Fix build errors caused by `@tailwindcss/line-clamp` warning ([#10915](https://github.com/tailwindlabs/tailwindcss/pull/10915), [#10919](https://github.com/tailwindlabs/tailwindcss/pull/10919))
- Fix "process is not defined" error ([#10919](https://github.com/tailwindlabs/tailwindcss/pull/10919))
## [3.3.0] - 2023-03-27
### Added
- Support ESM and TypeScript config files ([#10785](https://github.com/tailwindlabs/tailwindcss/pull/10785))
- Extend default color palette with new 950 shades ([#10879](https://github.com/tailwindlabs/tailwindcss/pull/10879))
- Add `line-height` modifier support to `font-size` utilities ([#9875](https://github.com/tailwindlabs/tailwindcss/pull/9875))
- Add support for using variables as arbitrary values without `var(...)` ([#9880](https://github.com/tailwindlabs/tailwindcss/pull/9880), [#9962](https://github.com/tailwindlabs/tailwindcss/pull/9962))
- Add logical properties support for inline direction ([#10166](https://github.com/tailwindlabs/tailwindcss/pull/10166))
- Add `hyphens` utilities ([#10071](https://github.com/tailwindlabs/tailwindcss/pull/10071))
- Add `from-{position}`, `via-{position}` and `to-{position}` utilities ([#10886](https://github.com/tailwindlabs/tailwindcss/pull/10886))
- Add `list-style-image` utilities ([#10817](https://github.com/tailwindlabs/tailwindcss/pull/10817))
- Add `caption-side` utilities ([#10470](https://github.com/tailwindlabs/tailwindcss/pull/10470))
- Add `line-clamp` utilities from `@tailwindcss/line-clamp` to core ([#10768](https://github.com/tailwindlabs/tailwindcss/pull/10768), [#10876](https://github.com/tailwindlabs/tailwindcss/pull/10876), [#10862](https://github.com/tailwindlabs/tailwindcss/pull/10862))
- Add `delay-0` and `duration-0` utilities ([#10294](https://github.com/tailwindlabs/tailwindcss/pull/10294))
- Add `justify-normal` and `justify-stretch` utilities ([#10560](https://github.com/tailwindlabs/tailwindcss/pull/10560))
- Add `content-normal` and `content-stretch` utilities ([#10645](https://github.com/tailwindlabs/tailwindcss/pull/10645))
- Add `whitespace-break-spaces` utility ([#10729](https://github.com/tailwindlabs/tailwindcss/pull/10729))
- Add support for configuring default `font-variation-settings` for a `font-family` ([#10034](https://github.com/tailwindlabs/tailwindcss/pull/10034), [#10515](https://github.com/tailwindlabs/tailwindcss/pull/10515))
### Fixed
- Disallow using multiple selectors in arbitrary variants ([#10655](https://github.com/tailwindlabs/tailwindcss/pull/10655))
- Sort class lists deterministically for Prettier plugin ([#10672](https://github.com/tailwindlabs/tailwindcss/pull/10672))
- Ensure CLI builds have a non-zero exit code on failure ([#10703](https://github.com/tailwindlabs/tailwindcss/pull/10703))
- Ensure module dependencies for value `null`, is an empty `Set` ([#10877](https://github.com/tailwindlabs/tailwindcss/pull/10877))
- Fix format assumption when resolving module dependencies ([#10878](https://github.com/tailwindlabs/tailwindcss/pull/10878))
### Changed
- Mark `rtl` and `ltr` variants as stable and remove warnings ([#10764](https://github.com/tailwindlabs/tailwindcss/pull/10764))
- Use `inset` instead of `top`, `right`, `bottom`, and `left` properties ([#10765](https://github.com/tailwindlabs/tailwindcss/pull/10765))
- Make `dark` and `rtl`/`ltr` variants insensitive to DOM order ([#10766](https://github.com/tailwindlabs/tailwindcss/pull/10766))
- Use `:is` to make important selector option insensitive to DOM order ([#10835](https://github.com/tailwindlabs/tailwindcss/pull/10835))
## [3.2.7] - 2023-02-16
### Fixed
- Fix use of `:where(.btn)` when matching `!btn` ([#10601](https://github.com/tailwindlabs/tailwindcss/pull/10601))
- Revert including `outline-color` in `transition` and `transition-colors` by default ([#10604](https://github.com/tailwindlabs/tailwindcss/pull/10604))
## [3.2.6] - 2023-02-08
### Fixed
- Fix installation failing with yarn and pnpm by dropping `oxide-api-shim` ([add1636](https://github.com/tailwindlabs/tailwindcss/commit/add16364b4b1100e1af23ad1ca6900a0b53cbba0))
## [3.2.5] - 2023-02-08
### Added
- Add standalone CLI build for 64-bit Windows on ARM (`node16-win-arm64`) ([#10001](https://github.com/tailwindlabs/tailwindcss/pull/10001))
### Fixed
- Cleanup unused `variantOrder` ([#9829](https://github.com/tailwindlabs/tailwindcss/pull/9829))
- Fix `foo-[abc]/[def]` not being handled correctly ([#9866](https://github.com/tailwindlabs/tailwindcss/pull/9866))
- Add container queries plugin to standalone CLI ([#9865](https://github.com/tailwindlabs/tailwindcss/pull/9865))
- Support renaming of output files by PostCSS plugins in CLI ([#9944](https://github.com/tailwindlabs/tailwindcss/pull/9944))
- Improve return value of `resolveConfig`, unwrap `ResolvableTo` ([#9972](https://github.com/tailwindlabs/tailwindcss/pull/9972))
- Clip unbalanced brackets in arbitrary values ([#9973](https://github.com/tailwindlabs/tailwindcss/pull/9973))
- Don’t reorder webkit scrollbar pseudo elements ([#9991](https://github.com/tailwindlabs/tailwindcss/pull/9991))
- Deterministic sorting of arbitrary variants ([#10016](https://github.com/tailwindlabs/tailwindcss/pull/10016))
- Add `data` key to theme types ([#10023](https://github.com/tailwindlabs/tailwindcss/pull/10023))
- Prevent invalid arbitrary variant selectors from failing the build ([#10059](https://github.com/tailwindlabs/tailwindcss/pull/10059))
- Properly handle subtraction followed by a variable ([#10074](https://github.com/tailwindlabs/tailwindcss/pull/10074))
- Fix missing `string[]` in the `theme.dropShadow` types ([#10072](https://github.com/tailwindlabs/tailwindcss/pull/10072))
- Update list of length units ([#10100](https://github.com/tailwindlabs/tailwindcss/pull/10100))
- Fix not matching arbitrary properties when closely followed by square brackets ([#10212](https://github.com/tailwindlabs/tailwindcss/pull/10212))
- Allow direct nesting in `root` or `@layer` nodes ([#10229](https://github.com/tailwindlabs/tailwindcss/pull/10229))
- Don't prefix classes in arbitrary variants ([#10214](https://github.com/tailwindlabs/tailwindcss/pull/10214))
- Fix perf regression when checking for changed content ([#10234](https://github.com/tailwindlabs/tailwindcss/pull/10234))
- Fix missing `blocklist` member in the `Config` type ([#10239](https://github.com/tailwindlabs/tailwindcss/pull/10239))
- Escape group names in selectors ([#10276](https://github.com/tailwindlabs/tailwindcss/pull/10276))
- Consider earlier variants before sorting functions ([#10288](https://github.com/tailwindlabs/tailwindcss/pull/10288))
- Allow variants with slashes ([#10336](https://github.com/tailwindlabs/tailwindcss/pull/10336))
- Ensure generated CSS is always sorted in the same order for a given set of templates ([#10382](https://github.com/tailwindlabs/tailwindcss/pull/10382))
- Handle variants when the same class appears multiple times in a selector ([#10397](https://github.com/tailwindlabs/tailwindcss/pull/10397))
- Handle group/peer variants with quoted strings ([#10400](https://github.com/tailwindlabs/tailwindcss/pull/10400))
- Parse alpha value from rgba/hsla colors when using variables ([#10429](https://github.com/tailwindlabs/tailwindcss/pull/10429))
- Sort by `layer` inside `variants` layer ([#10505](https://github.com/tailwindlabs/tailwindcss/pull/10505))
- Add `--watch=always` option to prevent exit when stdin closes ([#9966](https://github.com/tailwindlabs/tailwindcss/pull/9966))
### Changed
- Alphabetize `theme` keys in default config ([#9953](https://github.com/tailwindlabs/tailwindcss/pull/9953))
- Update esbuild to v17 ([#10368](https://github.com/tailwindlabs/tailwindcss/pull/10368))
- Include `outline-color` in `transition` and `transition-colors` utilities ([#10385](https://github.com/tailwindlabs/tailwindcss/pull/10385))
## [3.2.4] - 2022-11-11
### Added
- Add `blocklist` option to prevent generating unwanted CSS ([#9812](https://github.com/tailwindlabs/tailwindcss/pull/9812))
### Fixed
- Fix watching of files on Linux when renames are involved ([#9796](https://github.com/tailwindlabs/tailwindcss/pull/9796))
- Make sure errors are always displayed when watching for changes ([#9810](https://github.com/tailwindlabs/tailwindcss/pull/9810))
## [3.2.3] - 2022-11-09
### Fixed
- Fixed use of `raw` content in the CLI ([#9773](https://github.com/tailwindlabs/tailwindcss/pull/9773))
- Pick up changes from files that are both context and content deps ([#9787](https://github.com/tailwindlabs/tailwindcss/pull/9787))
- Sort pseudo-elements ONLY after classes when using variants and `@apply` ([#9765](https://github.com/tailwindlabs/tailwindcss/pull/9765))
- Support important utilities in the safelist (pattern must include a `!`) ([#9791](https://github.com/tailwindlabs/tailwindcss/pull/9791))
## [3.2.2] - 2022-11-04
### Fixed
- Escape special characters in resolved content base paths ([#9650](https://github.com/tailwindlabs/tailwindcss/pull/9650))
- Don't reuse container for array returning variant functions ([#9644](https://github.com/tailwindlabs/tailwindcss/pull/9644))
- Exclude non-relevant selectors when generating rules with the important modifier ([#9677](https://github.com/tailwindlabs/tailwindcss/issues/9677))
- Fix merging of arrays during config resolution ([#9706](https://github.com/tailwindlabs/tailwindcss/issues/9706))
- Ensure configured `font-feature-settings` are included in Preflight ([#9707](https://github.com/tailwindlabs/tailwindcss/pull/9707))
- Fix fractional values not being parsed properly inside arbitrary properties ([#9705](https://github.com/tailwindlabs/tailwindcss/pull/9705))
- Fix incorrect selectors when using `@apply` in selectors with combinators and pseudos ([#9722](https://github.com/tailwindlabs/tailwindcss/pull/9722))
- Fix cannot read properties of undefined (reading 'modifier') ([#9656](https://github.com/tailwindlabs/tailwindcss/pull/9656), [aa979d6](https://github.com/tailwindlabs/tailwindcss/commit/aa979d645f8bf4108c5fc938d7c0ba085b654c31))
## [3.2.1] - 2022-10-21
### Fixed
- Fix missing `supports` in types ([#9616](https://github.com/tailwindlabs/tailwindcss/pull/9616))
- Fix missing PostCSS dependencies in the CLI ([#9617](https://github.com/tailwindlabs/tailwindcss/pull/9617))
- Ensure `micromatch` is a proper CLI dependency ([#9620](https://github.com/tailwindlabs/tailwindcss/pull/9620))
- Ensure modifier values exist when using a `modifiers` object for `matchVariant` ([ba6551d](https://github.com/tailwindlabs/tailwindcss/commit/ba6551db0f2726461371b4f3c6cd4c7090888504))
## [3.2.0] - 2022-10-19
### Added
- Add new `@config` directive ([#9405](https://github.com/tailwindlabs/tailwindcss/pull/9405))
- Add new `relative: true` option to resolve content paths relative to the config file ([#9396](https://github.com/tailwindlabs/tailwindcss/pull/9396))
- Add new `supports-*` variant ([#9453](https://github.com/tailwindlabs/tailwindcss/pull/9453))
- Add new `min-*` and `max-*` variants ([#9558](https://github.com/tailwindlabs/tailwindcss/pull/9558))
- Add new `aria-*` variants ([#9557](https://github.com/tailwindlabs/tailwindcss/pull/9557), [#9588](https://github.com/tailwindlabs/tailwindcss/pull/9588))
- Add new `data-*` variants ([#9559](https://github.com/tailwindlabs/tailwindcss/pull/9559), [#9588](https://github.com/tailwindlabs/tailwindcss/pull/9588))
- Add new `break-keep` utility for `word-break: keep-all` ([#9393](https://github.com/tailwindlabs/tailwindcss/pull/9393))
- Add new `collapse` utility for `visibility: collapse` ([#9181](https://github.com/tailwindlabs/tailwindcss/pull/9181))
- Add new `fill-none` utility for `fill: none` ([#9403](https://github.com/tailwindlabs/tailwindcss/pull/9403))
- Add new `stroke-none` utility for `stroke: none` ([#9403](https://github.com/tailwindlabs/tailwindcss/pull/9403))
- Add new `place-content-baseline` utility for `place-content: baseline` ([#9498](https://github.com/tailwindlabs/tailwindcss/pull/9498))
- Add new `place-items-baseline` utility for `place-items: baseline` ([#9507](https://github.com/tailwindlabs/tailwindcss/pull/9507))
- Add new `content-baseline` utility for `align-content: baseline` ([#9507](https://github.com/tailwindlabs/tailwindcss/pull/9507))
- Add support for configuring default `font-feature-settings` for a font family ([#9039](https://github.com/tailwindlabs/tailwindcss/pull/9039))
- Add standalone CLI build for 32-bit Linux on ARM (`node16-linux-armv7`) ([#9084](https://github.com/tailwindlabs/tailwindcss/pull/9084))
- Add future flag to disable color opacity utility plugins ([#9088](https://github.com/tailwindlabs/tailwindcss/pull/9088))
- Add negative value support for `outline-offset` ([#9136](https://github.com/tailwindlabs/tailwindcss/pull/9136))
- Add support for modifiers to `matchUtilities` ([#9541](https://github.com/tailwindlabs/tailwindcss/pull/9541))
- Allow negating utilities using `min`/`max`/`clamp` ([#9237](https://github.com/tailwindlabs/tailwindcss/pull/9237))
- Implement fallback plugins when there is ambiguity between plugins when using arbitrary values ([#9376](https://github.com/tailwindlabs/tailwindcss/pull/9376))
- Support `sort` function in `matchVariant` ([#9423](https://github.com/tailwindlabs/tailwindcss/pull/9423))
- Upgrade to `postcss-nested` v6.0 ([#9546](https://github.com/tailwindlabs/tailwindcss/pull/9546))
### Fixed
- Use absolute paths when resolving changed files for resilience against working directory changes ([#9032](https://github.com/tailwindlabs/tailwindcss/pull/9032))
- Fix ring color utility generation when using `respectDefaultRingColorOpacity` ([#9070](https://github.com/tailwindlabs/tailwindcss/pull/9070))
- Sort tags before classes when `@apply`-ing a selector with joined classes ([#9107](https://github.com/tailwindlabs/tailwindcss/pull/9107))
- Remove invalid `outline-hidden` utility ([#9147](https://github.com/tailwindlabs/tailwindcss/pull/9147))
- Honor the `hidden` attribute on elements in preflight ([#9174](https://github.com/tailwindlabs/tailwindcss/pull/9174))
- Don't stop watching atomically renamed files ([#9173](https://github.com/tailwindlabs/tailwindcss/pull/9173), [#9215](https://github.com/tailwindlabs/tailwindcss/pull/9215))
- Fix duplicate utilities issue causing memory leaks ([#9208](https://github.com/tailwindlabs/tailwindcss/pull/9208))
- Fix `fontFamily` config TypeScript types ([#9214](https://github.com/tailwindlabs/tailwindcss/pull/9214))
- Handle variants on complex selector utilities ([#9262](https://github.com/tailwindlabs/tailwindcss/pull/9262))
- Fix shared config mutation issue ([#9294](https://github.com/tailwindlabs/tailwindcss/pull/9294))
- Fix ordering of parallel variants ([#9282](https://github.com/tailwindlabs/tailwindcss/pull/9282))
- Handle variants in utility selectors using `:where()` and `:has()` ([#9309](https://github.com/tailwindlabs/tailwindcss/pull/9309))
- Improve data type analysis for arbitrary values ([#9320](https://github.com/tailwindlabs/tailwindcss/pull/9320))
- Don't emit generated utilities with invalid uses of theme functions ([#9319](https://github.com/tailwindlabs/tailwindcss/pull/9319))
- Revert change that only listened for stdin close on TTYs ([#9331](https://github.com/tailwindlabs/tailwindcss/pull/9331))
- Ignore unset values (like `null` or `undefined`) when resolving the classList for intellisense ([#9385](https://github.com/tailwindlabs/tailwindcss/pull/9385))
- Improve type checking for formal syntax ([#9349](https://github.com/tailwindlabs/tailwindcss/pull/9349), [#9448](https://github.com/tailwindlabs/tailwindcss/pull/9448))
- Fix incorrect required `content` key in custom plugin configs ([#9502](https://github.com/tailwindlabs/tailwindcss/pull/9502), [#9545](https://github.com/tailwindlabs/tailwindcss/pull/9545))
- Fix content path detection on Windows ([#9569](https://github.com/tailwindlabs/tailwindcss/pull/9569))
- Ensure `--content` is used in the CLI when passed ([#9587](https://github.com/tailwindlabs/tailwindcss/pull/9587))
## [3.1.8] - 2022-08-05
### Fixed
- Don’t prefix classes within reused arbitrary variants ([#8992](https://github.com/tailwindlabs/tailwindcss/pull/8992))
- Fix usage of alpha values inside single-named colors that are functions ([#9008](https://github.com/tailwindlabs/tailwindcss/pull/9008))
- Fix `@apply` of user utilities when negative and non-negative versions both exist ([#9027](https://github.com/tailwindlabs/tailwindcss/pull/9027))
## [3.1.7] - 2022-07-29
### Fixed
- Don't rewrite source maps for `@layer` rules ([#8971](https://github.com/tailwindlabs/tailwindcss/pull/8971))
### Added
- Added types for `resolveConfig` ([#8924](https://github.com/tailwindlabs/tailwindcss/pull/8924))
## [3.1.6] - 2022-07-11
### Fixed
- Fix usage on Node 12.x ([b4e637e](https://github.com/tailwindlabs/tailwindcss/commit/b4e637e2e096a9d6f2210efba9541f6fd4f28e56))
- Handle theme keys with slashes when using `theme()` in CSS ([#8831](https://github.com/tailwindlabs/tailwindcss/pull/8831))
## [3.1.5] - 2022-07-07
### Added
- Support configuring a default `font-weight` for each font size utility ([#8763](https://github.com/tailwindlabs/tailwindcss/pull/8763))
- Add support for alpha values in safe list ([#8774](https://github.com/tailwindlabs/tailwindcss/pull/8774))
### Fixed
- Improve types to support fallback values in the CSS-in-JS syntax used in plugin APIs ([#8762](https://github.com/tailwindlabs/tailwindcss/pull/8762))
- Support including `tailwindcss` and `autoprefixer` in `postcss.config.js` in standalone CLI ([#8769](https://github.com/tailwindlabs/tailwindcss/pull/8769))
- Fix using special-characters as prefixes ([#8772](https://github.com/tailwindlabs/tailwindcss/pull/8772))
- Don’t prefix classes used within arbitrary variants ([#8773](https://github.com/tailwindlabs/tailwindcss/pull/8773))
- Add more explicit types for the default theme ([#8780](https://github.com/tailwindlabs/tailwindcss/pull/8780))
## [3.1.4] - 2022-06-21
### Fixed
- Provide default to `<alpha-value>` when using `theme()` ([#8652](https://github.com/tailwindlabs/tailwindcss/pull/8652))
- Detect arbitrary variants with quotes ([#8687](https://github.com/tailwindlabs/tailwindcss/pull/8687))
- Don’t add spaces around raw `/` that are preceded by numbers ([#8688](https://github.com/tailwindlabs/tailwindcss/pull/8688))
## [3.1.3] - 2022-06-14
### Fixed
- Fix extraction of multi-word utilities with arbitrary values and quotes ([#8604](https://github.com/tailwindlabs/tailwindcss/pull/8604))
- Fix casing of import of `corePluginList` type definition ([#8587](https://github.com/tailwindlabs/tailwindcss/pull/8587))
- Ignore PostCSS nodes returned by `addVariant` ([#8608](https://github.com/tailwindlabs/tailwindcss/pull/8608))
- Fix missing spaces around arithmetic operators ([#8615](https://github.com/tailwindlabs/tailwindcss/pull/8615))
- Detect alpha value in CSS `theme()` function when using quotes ([#8625](https://github.com/tailwindlabs/tailwindcss/pull/8625))
- Fix "Maximum call stack size exceeded" bug ([#8636](https://github.com/tailwindlabs/tailwindcss/pull/8636))
- Allow functions returning parallel variants to mutate the container ([#8622](https://github.com/tailwindlabs/tailwindcss/pull/8622))
- Remove text opacity CSS variables from `::marker` ([#8622](https://github.com/tailwindlabs/tailwindcss/pull/8622))
## [3.1.2] - 2022-06-10
### Fixed
- Ensure `\` is a valid arbitrary variant token ([#8576](https://github.com/tailwindlabs/tailwindcss/pull/8576))
- Enable `postcss-import` in the CLI by default in watch mode ([#8574](https://github.com/tailwindlabs/tailwindcss/pull/8574), [#8580](https://github.com/tailwindlabs/tailwindcss/pull/8580))
## [3.1.1] - 2022-06-09
### Fixed
- Fix candidate extractor regression ([#8558](https://github.com/tailwindlabs/tailwindcss/pull/8558))
- Split `::backdrop` into separate defaults group ([#8567](https://github.com/tailwindlabs/tailwindcss/pull/8567))
- Fix postcss plugin type ([#8564](https://github.com/tailwindlabs/tailwindcss/pull/8564))
- Fix class detection in markdown code fences and slim templates ([#8569](https://github.com/tailwindlabs/tailwindcss/pull/8569))
## [3.1.0] - 2022-06-08
### Fixed
- Types: allow for arbitrary theme values (for 3rd party plugins) ([#7926](https://github.com/tailwindlabs/tailwindcss/pull/7926))
- Don’t split vars with numbers in them inside arbitrary values ([#8091](https://github.com/tailwindlabs/tailwindcss/pull/8091))
- Require matching prefix when detecting negatives ([#8121](https://github.com/tailwindlabs/tailwindcss/pull/8121))
- Handle duplicate At Rules without children ([#8122](https://github.com/tailwindlabs/tailwindcss/pull/8122))
- Allow arbitrary values with commas in `@apply` ([#8125](https://github.com/tailwindlabs/tailwindcss/pull/8125))
- Fix intellisense for plugins with multiple `@apply` rules ([#8213](https://github.com/tailwindlabs/tailwindcss/pull/8213))
- Improve type detection for arbitrary color values ([#8201](https://github.com/tailwindlabs/tailwindcss/pull/8201))
- Support PostCSS config options in config file in CLI ([#8226](https://github.com/tailwindlabs/tailwindcss/pull/8226))
- Remove default `[hidden]` style in preflight ([#8248](https://github.com/tailwindlabs/tailwindcss/pull/8248))
- Only check selectors containing base apply candidates for circular dependencies ([#8222](https://github.com/tailwindlabs/tailwindcss/pull/8222))
- Rewrite default class extractor ([#8204](https://github.com/tailwindlabs/tailwindcss/pull/8204))
- Move `important` selector to the front when `@apply`-ing selector-modifying variants in custom utilities ([#8313](https://github.com/tailwindlabs/tailwindcss/pull/8313))
- Error when registering an invalid custom variant ([#8345](https://github.com/tailwindlabs/tailwindcss/pull/8345))
- Create tailwind.config.cjs file in ESM package when running init ([#8363](https://github.com/tailwindlabs/tailwindcss/pull/8363))
- Fix `matchVariant` that use at-rules and placeholders ([#8392](https://github.com/tailwindlabs/tailwindcss/pull/8392))
- Improve types of the `tailwindcss/plugin` ([#8400](https://github.com/tailwindlabs/tailwindcss/pull/8400))
- Allow returning parallel variants from `addVariant` or `matchVariant` callback functions ([#8455](https://github.com/tailwindlabs/tailwindcss/pull/8455))
- Try using local `postcss` installation first in the CLI ([#8270](https://github.com/tailwindlabs/tailwindcss/pull/8270))
- Allow default ring color to be a function ([#7587](https://github.com/tailwindlabs/tailwindcss/pull/7587))
- Don't inherit `to` value from parent gradients ([#8489](https://github.com/tailwindlabs/tailwindcss/pull/8489))
- Remove process dependency from log functions ([#8530](https://github.com/tailwindlabs/tailwindcss/pull/8530))
- Ensure we can use `@import 'tailwindcss/...'` without node_modules ([#8537](https://github.com/tailwindlabs/tailwindcss/pull/8537))
### Changed
- Only apply hover styles when supported (future) ([#8394](https://github.com/tailwindlabs/tailwindcss/pull/8394))
- Respect default ring color opacity (future) ([#8448](https://github.com/tailwindlabs/tailwindcss/pull/8448), [3f4005e](https://github.com/tailwindlabs/tailwindcss/commit/3f4005e833445f7549219eb5ae89728cbb3a2630))
### Added
- Support PostCSS `Document` nodes ([#7291](https://github.com/tailwindlabs/tailwindcss/pull/7291))
- Add `text-start` and `text-end` utilities ([#6656](https://github.com/tailwindlabs/tailwindcss/pull/6656))
- Support customizing class name when using `darkMode: 'class'` ([#5800](https://github.com/tailwindlabs/tailwindcss/pull/5800))
- Add `--poll` option to the CLI ([#7725](https://github.com/tailwindlabs/tailwindcss/pull/7725))
- Add new `border-spacing` utilities ([#7102](https://github.com/tailwindlabs/tailwindcss/pull/7102))
- Add `enabled` variant ([#7905](https://github.com/tailwindlabs/tailwindcss/pull/7905))
- Add TypeScript types for the `tailwind.config.js` file ([#7891](https://github.com/tailwindlabs/tailwindcss/pull/7891))
- Add `backdrop` variant ([#7924](https://github.com/tailwindlabs/tailwindcss/pull/7924), [#8526](https://github.com/tailwindlabs/tailwindcss/pull/8526))
- Add `grid-flow-dense` utility ([#8193](https://github.com/tailwindlabs/tailwindcss/pull/8193))
- Add `mix-blend-plus-lighter` utility ([#8288](https://github.com/tailwindlabs/tailwindcss/pull/8288))
- Add arbitrary variants ([#8299](https://github.com/tailwindlabs/tailwindcss/pull/8299))
- Add experimental `matchVariant` API ([#8310](https://github.com/tailwindlabs/tailwindcss/pull/8310), [34fd0fb8](https://github.com/tailwindlabs/tailwindcss/commit/34fd0fb82aa574cddc5c7aa3ad7d1af5e3735e5d))
- Add `prefers-contrast` media query variants ([#8410](https://github.com/tailwindlabs/tailwindcss/pull/8410))
- Add opacity support when referencing colors with `theme` function ([#8416](https://github.com/tailwindlabs/tailwindcss/pull/8416))
- Add `postcss-import` support to the CLI ([#8437](https://github.com/tailwindlabs/tailwindcss/pull/8437))
- Add `optional` variant ([#8486](https://github.com/tailwindlabs/tailwindcss/pull/8486))
- Add `<alpha-value>` placeholder support for custom colors ([#8501](https://github.com/tailwindlabs/tailwindcss/pull/8501))
## [3.0.24] - 2022-04-12
### Fixed
- Prevent nesting plugin from breaking other plugins ([#7563](https://github.com/tailwindlabs/tailwindcss/pull/7563))
- Recursively collapse adjacent rules ([#7565](https://github.com/tailwindlabs/tailwindcss/pull/7565))
- Preserve source maps for generated CSS ([#7588](https://github.com/tailwindlabs/tailwindcss/pull/7588))
- Split box shadows on top-level commas only ([#7479](https://github.com/tailwindlabs/tailwindcss/pull/7479))
- Use local user CSS cache for `@apply` ([#7524](https://github.com/tailwindlabs/tailwindcss/pull/7524))
- Invalidate context when main CSS changes ([#7626](https://github.com/tailwindlabs/tailwindcss/pull/7626))
- Only add `!` to selector class matching template candidate when using important modifier with multi-class selectors ([#7664](https://github.com/tailwindlabs/tailwindcss/pull/7664))
- Correctly parse and prefix animation names with dots ([#7163](https://github.com/tailwindlabs/tailwindcss/pull/7163))
- Fix extraction from template literal/function with array ([#7481](https://github.com/tailwindlabs/tailwindcss/pull/7481))
- Don't output unparsable arbitrary values ([#7789](https://github.com/tailwindlabs/tailwindcss/pull/7789))
- Fix generation of `div:not(.foo)` if `.foo` is never defined ([#7815](https://github.com/tailwindlabs/tailwindcss/pull/7815))
- Allow for custom properties in `rgb`, `rgba`, `hsl` and `hsla` colors ([#7933](https://github.com/tailwindlabs/tailwindcss/pull/7933))
- Remove autoprefixer as explicit peer-dependency to avoid invalid warnings in situations where it isn't actually needed ([#7949](https://github.com/tailwindlabs/tailwindcss/pull/7949))
- Ensure the `percentage` data type is validated correctly ([#8015](https://github.com/tailwindlabs/tailwindcss/pull/8015))
- Make sure `font-weight` is inherited by form controls in all browsers ([#8078](https://github.com/tailwindlabs/tailwindcss/pull/8078))
### Changed
- Replace `chalk` with `picocolors` ([#6039](https://github.com/tailwindlabs/tailwindcss/pull/6039))
- Replace `cosmiconfig` with `lilconfig` ([#6039](https://github.com/tailwindlabs/tailwindcss/pull/6038))
- Update `cssnano` to avoid removing empty variables when minifying ([#7818](https://github.com/tailwindlabs/tailwindcss/pull/7818))
## [3.0.23] - 2022-02-16
### Fixed
- Remove opacity variables from `:visited` pseudo class ([#7458](https://github.com/tailwindlabs/tailwindcss/pull/7458))
- Support arbitrary values + calc + theme with quotes ([#7462](https://github.com/tailwindlabs/tailwindcss/pull/7462))
- Don't duplicate layer output when scanning content with variants + wildcards ([#7478](https://github.com/tailwindlabs/tailwindcss/pull/7478))
- Implement `getClassOrder` instead of `sortClassList` ([#7459](https://github.com/tailwindlabs/tailwindcss/pull/7459))
## [3.0.22] - 2022-02-11
### Fixed
- Temporarily move `postcss` to dependencies ([#7424](https://github.com/tailwindlabs/tailwindcss/pull/7424))
## [3.0.21] - 2022-02-10
### Fixed
- Move prettier plugin to dev dependencies ([#7418](https://github.com/tailwindlabs/tailwindcss/pull/7418))
## [3.0.20] - 2022-02-10
### Added
- Expose `context.sortClassList(classes)` ([#7412](https://github.com/tailwindlabs/tailwindcss/pull/7412))
## [3.0.19] - 2022-02-07
### Fixed
- Fix preflight border color fallback ([#7288](https://github.com/tailwindlabs/tailwindcss/pull/7288))
- Correctly parse shadow lengths without a leading zero ([#7289](https://github.com/tailwindlabs/tailwindcss/pull/7289))
- Don't crash when scanning extremely long class candidates ([#7331](https://github.com/tailwindlabs/tailwindcss/pull/7331))
- Use less hacky fix for URLs detected as custom properties ([#7275](https://github.com/tailwindlabs/tailwindcss/pull/7275))
- Correctly generate negative utilities when dash is before the prefix ([#7295](https://github.com/tailwindlabs/tailwindcss/pull/7295))
- Detect prefixed negative utilities in the safelist ([#7295](https://github.com/tailwindlabs/tailwindcss/pull/7295))
## [3.0.18] - 2022-01-28
### Fixed
- Fix `@apply` order regression (in `addComponents`, `addUtilities`, ...) ([#7232](https://github.com/tailwindlabs/tailwindcss/pull/7232))
- Quick fix for incorrect arbitrary properties when using URLs ([#7252](https://github.com/tailwindlabs/tailwindcss/pull/7252))
## [3.0.17] - 2022-01-26
### Fixed
- Remove false positive warning in CLI when using the `--content` option ([#7220](https://github.com/tailwindlabs/tailwindcss/pull/7220))
## [3.0.16] - 2022-01-24
### Fixed
- Ensure to transpile the PostCSS Nesting plugin (tailwindcss/nesting) ([#7080](https://github.com/tailwindlabs/tailwindcss/pull/7080))
- Improve various warnings ([#7118](https://github.com/tailwindlabs/tailwindcss/pull/7118))
- Fix grammatical mistake ([cca5a38](https://github.com/tailwindlabs/tailwindcss/commit/cca5a3804e1d3ee0214491921e1aec35bf62a813))
## [3.0.15] - 2022-01-15
### Fixed
- Temporarily remove optional chaining in nesting plugin ([#7077](https://github.com/tailwindlabs/tailwindcss/pull/7077))
## [3.0.14] - 2022-01-14
### Added
- Show warnings for invalid content config ([#7065](https://github.com/tailwindlabs/tailwindcss/pull/7065))
### Fixed
- Only emit utility/component variants when those layers exist ([#7066](https://github.com/tailwindlabs/tailwindcss/pull/7066))
- Ensure nesting plugins can receive options ([#7016](https://github.com/tailwindlabs/tailwindcss/pull/7016))
## [3.0.13] - 2022-01-11
### Fixed
- Fix consecutive builds with at apply producing different CSS ([#6999](https://github.com/tailwindlabs/tailwindcss/pull/6999))
## [3.0.12] - 2022-01-07
### Fixed
- Allow use of falsy values in theme config ([#6917](https://github.com/tailwindlabs/tailwindcss/pull/6917))
- Ensure we can apply classes that are grouped with non-class selectors ([#6922](https://github.com/tailwindlabs/tailwindcss/pull/6922))
- Improve standalone CLI compatibility on Linux by switching to the `linuxstatic` build target ([#6914](https://github.com/tailwindlabs/tailwindcss/pull/6914))
- Ensure `@apply` works consistently with or without `@layer` ([#6938](https://github.com/tailwindlabs/tailwindcss/pull/6938))
- Only emit defaults when using base layer ([#6926](https://github.com/tailwindlabs/tailwindcss/pull/6926))
- Emit plugin defaults regardless of usage ([#6926](https://github.com/tailwindlabs/tailwindcss/pull/6926))
- Move default border color back to preflight ([#6926](https://github.com/tailwindlabs/tailwindcss/pull/6926))
- Change `experimental.optimizeUniversalDefaults` to only work with `@tailwind base` ([#6926](https://github.com/tailwindlabs/tailwindcss/pull/6926))
## [3.0.11] - 2022-01-05
### Fixed
- Preserve casing of CSS variables added by plugins ([#6888](https://github.com/tailwindlabs/tailwindcss/pull/6888))
- Ignore content paths that are passed in but don't actually exist ([#6901](https://github.com/tailwindlabs/tailwindcss/pull/6901))
- Revert change that applies Tailwind's defaults in isolated environments like CSS modules ([9fdc391](https://github.com/tailwindlabs/tailwindcss/commit/9fdc391d4ff93e7e350f5ce439060176b1f0162f))
## [3.0.10] - 2022-01-04
### Fixed
- Fix `@apply` in files without `@tailwind` directives ([#6580](https://github.com/tailwindlabs/tailwindcss/pull/6580), [#6875](https://github.com/tailwindlabs/tailwindcss/pull/6875))
- CLI: avoid unnecessary writes to output files ([#6550](https://github.com/tailwindlabs/tailwindcss/pull/6550))
### Added
- Allow piping data into the CLI ([#6876](https://github.com/tailwindlabs/tailwindcss/pull/6876))
## [3.0.9] - 2022-01-03
### Fixed
- Improve `DEBUG` flag ([#6797](https://github.com/tailwindlabs/tailwindcss/pull/6797), [#6804](https://github.com/tailwindlabs/tailwindcss/pull/6804))
- Ensure we can use `<` and `>` characters in modifiers ([#6851](https://github.com/tailwindlabs/tailwindcss/pull/6851))
- Validate `theme()` works in arbitrary values ([#6852](https://github.com/tailwindlabs/tailwindcss/pull/6852))
- Properly detect `theme()` value usage in arbitrary properties ([#6854](https://github.com/tailwindlabs/tailwindcss/pull/6854))
- Improve collapsing of duplicate declarations ([#6856](https://github.com/tailwindlabs/tailwindcss/pull/6856))
- Remove support for `TAILWIND_MODE=watch` ([#6858](https://github.com/tailwindlabs/tailwindcss/pull/6858))
## [3.0.8] - 2021-12-28
### Fixed
- Reduce specificity of `abbr` rule in preflight ([#6671](https://github.com/tailwindlabs/tailwindcss/pull/6671))
- Support HSL with hue units in arbitrary values ([#6726](https://github.com/tailwindlabs/tailwindcss/pull/6726))
- Add `node16-linux-arm64` target for standalone CLI ([#6693](https://github.com/tailwindlabs/tailwindcss/pull/6693))
## [3.0.7] - 2021-12-17
### Fixed
- Don't mutate custom color palette when overriding per-plugin colors ([#6546](https://github.com/tailwindlabs/tailwindcss/pull/6546))
- Improve circular dependency detection when using `@apply` ([#6588](https://github.com/tailwindlabs/tailwindcss/pull/6588))
- Only generate variants for non-`user` layers ([#6589](https://github.com/tailwindlabs/tailwindcss/pull/6589))
- Properly extract classes with arbitrary values in arrays and classes followed by escaped quotes ([#6590](https://github.com/tailwindlabs/tailwindcss/pull/6590))
- Improve jsx interpolation candidate matching ([#6593](https://github.com/tailwindlabs/tailwindcss/pull/6593))
- Ensure `@apply` of a rule inside an AtRule works ([#6594](https://github.com/tailwindlabs/tailwindcss/pull/6594))
## [3.0.6] - 2021-12-16
### Fixed
- Support square bracket notation in paths ([#6519](https://github.com/tailwindlabs/tailwindcss/pull/6519))
- Ensure all plugins are executed for a given candidate ([#6540](https://github.com/tailwindlabs/tailwindcss/pull/6540))
## [3.0.5] - 2021-12-15
### Fixed
- Revert: add `li` to list-style reset ([9777562d](https://github.com/tailwindlabs/tailwindcss/commit/9777562da37ee631bbf77374c0d14825f09ef9af))
## [3.0.4] - 2021-12-15
### Fixed
- Insert always-on defaults layer in correct spot ([#6526](https://github.com/tailwindlabs/tailwindcss/pull/6526))
## [3.0.3] - 2021-12-15
### Added
- Warn about invalid globs in `content` ([#6449](https://github.com/tailwindlabs/tailwindcss/pull/6449))
- Add standalone tailwindcss CLI ([#6506](https://github.com/tailwindlabs/tailwindcss/pull/6506))
- Add `li` to list-style reset ([00f60e6](https://github.com/tailwindlabs/tailwindcss/commit/00f60e61013c6e4e3419e4b699371a13eb30b75d))
### Fixed
- Don't output unparsable values ([#6469](https://github.com/tailwindlabs/tailwindcss/pull/6469))
- Fix text decoration utilities from overriding the new text decoration color/style/thickness utilities when used with a modifier ([#6378](https://github.com/tailwindlabs/tailwindcss/pull/6378))
- Move defaults to their own always-on layer ([#6500](https://github.com/tailwindlabs/tailwindcss/pull/6500))
- Support negative values in safelist patterns ([#6480](https://github.com/tailwindlabs/tailwindcss/pull/6480))
## [3.0.2] - 2021-12-13
### Fixed
- Temporarily disable optimize universal defaults, fixes issue with transforms/filters/rings not being `@apply`-able in CSS modules/Svelte components/Vue components ([#6461](https://github.com/tailwindlabs/tailwindcss/pull/6461))
## [3.0.1] - 2021-12-10
### Fixed
- Ensure complex variants with multiple classes work ([#6311](https://github.com/tailwindlabs/tailwindcss/pull/6311))
- Re-add `default` interop to public available functions ([#6348](https://github.com/tailwindlabs/tailwindcss/pull/6348))
- Detect circular dependencies when using `@apply` ([#6365](https://github.com/tailwindlabs/tailwindcss/pull/6365))
- Fix defaults optimization when vendor prefixes are involved ([#6369](https://github.com/tailwindlabs/tailwindcss/pull/6369))
## [3.0.0] - 2021-12-09
### Fixed
- Enforce the order of some variants (like `before` and `after`) ([#6018](https://github.com/tailwindlabs/tailwindcss/pull/6018))
### Added
- Add `placeholder` variant ([#6106](https://github.com/tailwindlabs/tailwindcss/pull/6106))
- Add composable `touch-action` utilities ([#6115](https://github.com/tailwindlabs/tailwindcss/pull/6115))
- Add support for "arbitrary properties" ([#6161](https://github.com/tailwindlabs/tailwindcss/pull/6161))
- Add `portrait` and `landscape` variants ([#6046](https://github.com/tailwindlabs/tailwindcss/pull/6046))
- Add `text-decoration-style`, `text-decoration-thickness`, and `text-underline-offset` utilities ([#6004](https://github.com/tailwindlabs/tailwindcss/pull/6004))
- Add `menu` reset to preflight ([#6213](https://github.com/tailwindlabs/tailwindcss/pull/6213))
- Allow `0` as a valid `length` value ([#6233](https://github.com/tailwindlabs/tailwindcss/pull/6233), [#6259](https://github.com/tailwindlabs/tailwindcss/pull/6259))
- Add CSS functions to data types ([#6258](https://github.com/tailwindlabs/tailwindcss/pull/6258))
- Support negative values for `scale-*` utilities ([c48e629](https://github.com/tailwindlabs/tailwindcss/commit/c48e629955585ad18dadba9f470fda59cc448ab7))
- Improve `length` data type, by validating each value individually ([#6283](https://github.com/tailwindlabs/tailwindcss/pull/6283))
### Changed
- Deprecate `decoration-slice` and `decoration-break` in favor `box-decoration-slice` and `box-decoration-break` _(non-breaking)_ ([#6004](https://github.com/tailwindlabs/tailwindcss/pull/6004))
## [3.0.0-alpha.2] - 2021-11-08
### Changed
- Don't use pointer cursor on disabled buttons by default ([#5772](https://github.com/tailwindlabs/tailwindcss/pull/5772))
- Set default content value in preflight instead of within each before/after utility ([#5820](https://github.com/tailwindlabs/tailwindcss/pull/5820))
- Remove `prefix` as a function ([#5829](https://github.com/tailwindlabs/tailwindcss/pull/5829))
### Added
- Add `flex-basis` utilities ([#5671](https://github.com/tailwindlabs/tailwindcss/pull/5671))
- Make negative values a first-class feature ([#5709](https://github.com/tailwindlabs/tailwindcss/pull/5709))
- Add `fit-content` values for `min/max-width/height` utilities ([#5638](https://github.com/tailwindlabs/tailwindcss/pull/5638))
- Add `min/max-content` values for `min/max-height` utilities ([#5729](https://github.com/tailwindlabs/tailwindcss/pull/5729))
- Add all standard `cursor-*` values by default ([#5734](https://github.com/tailwindlabs/tailwindcss/pull/5734))
- Add `grow-*` and `shrink-*` utilities, deprecate `flex-grow-*` and `flex-shrink-*` ([#5733](https://github.com/tailwindlabs/tailwindcss/pull/5733))
- Add `text-decoration-color` utilities ([#5760](https://github.com/tailwindlabs/tailwindcss/pull/5760))
- Add new declarative `addVariant` API ([#5809](https://github.com/tailwindlabs/tailwindcss/pull/5809))
- Add first-class `print` variant for targeting printed media ([#5885](https://github.com/tailwindlabs/tailwindcss/pull/5885))
- Add `outline-style`, `outline-color`, `outline-width` and `outline-offset` utilities ([#5887](https://github.com/tailwindlabs/tailwindcss/pull/5887))
- Add full color palette for `fill-*` and `stroke-*` utilities (#5933[](https://github.com/tailwindlabs/tailwindcss/pull/5933))
- Add composable API for colored box shadows ([#5979](https://github.com/tailwindlabs/tailwindcss/pull/5979))
### Fixed
- Configure chokidar's `awaitWriteFinish` setting to avoid occasional stale builds on Windows ([#5774](https://github.com/tailwindlabs/tailwindcss/pull/5774))
- Fix CLI `--content` option ([#5775](https://github.com/tailwindlabs/tailwindcss/pull/5775))
- Fix before/after utilities overriding custom content values at larger breakpoints ([#5820](https://github.com/tailwindlabs/tailwindcss/pull/5820))
- Cleanup duplicate properties ([#5830](https://github.com/tailwindlabs/tailwindcss/pull/5830))
- Allow `_` inside `url()` when using arbitrary values ([#5853](https://github.com/tailwindlabs/tailwindcss/pull/5853))
- Prevent crashes when using comments in `@layer` AtRules ([#5854](https://github.com/tailwindlabs/tailwindcss/pull/5854))
- Handle color transformations properly with `theme(...)` for all relevant plugins ([#4533](https://github.com/tailwindlabs/tailwindcss/pull/4533), [#5871](https://github.com/tailwindlabs/tailwindcss/pull/5871))
- Ensure `@apply`-ing a utility with multiple definitions works ([#5870](https://github.com/tailwindlabs/tailwindcss/pull/5870))
## [3.0.0-alpha.1] - 2021-10-01
### Changed
- Remove AOT engine, make JIT the default ([#5340](https://github.com/tailwindlabs/tailwindcss/pull/5340))
- Throw when trying to `@apply` the `group` class ([#4666](https://github.com/tailwindlabs/tailwindcss/pull/4666))
- Remove dependency on `modern-normalize`, inline and consolidate with Preflight ([#5358](https://github.com/tailwindlabs/tailwindcss/pull/5358))
- Enable extended color palette by default with updated color names ([#5384](https://github.com/tailwindlabs/tailwindcss/pull/5384))
- Move `vertical-align` values to config file instead of hard-coding ([#5487](https://github.com/tailwindlabs/tailwindcss/pull/5487))
- Rename `overflow-clip` to `text-clip` and `overflow-ellipsis` to `text-ellipsis` ([#5630](https://github.com/tailwindlabs/tailwindcss/pull/5630))
### Added
- Add native `aspect-ratio` utilities ([#5359](https://github.com/tailwindlabs/tailwindcss/pull/5359))
- Unify config callback helpers into single object ([#5382](https://github.com/tailwindlabs/tailwindcss/pull/5382))
- Preserve original color format when adding opacity whenever possible ([#5154](https://github.com/tailwindlabs/tailwindcss/pull/5154))
- Add `accent-color` utilities ([#5387](https://github.com/tailwindlabs/tailwindcss/pull/5387))
- Add `scroll-behavior` utilities ([#5388](https://github.com/tailwindlabs/tailwindcss/pull/5388))
- Add `will-change` utilities ([#5448](https://github.com/tailwindlabs/tailwindcss/pull/5448))
- Add `text-indent` utilities ([#5449](https://github.com/tailwindlabs/tailwindcss/pull/5449))
- Add `column` utilities ([#5457](https://github.com/tailwindlabs/tailwindcss/pull/5457))
- Add `border-hidden` utility ([#5485](https://github.com/tailwindlabs/tailwindcss/pull/5485))
- Add `align-sub` and `align-super` utilities by default ([#5486](https://github.com/tailwindlabs/tailwindcss/pull/5486))
- Add `break-before`, `break-inside` and `break-after` utilities ([#5530](https://github.com/tailwindlabs/tailwindcss/pull/5530))
- Add `file` variant for `::file-selector-button` pseudo element ([#4936](https://github.com/tailwindlabs/tailwindcss/pull/4936))
- Add comprehensive arbitrary value support ([#5568](https://github.com/tailwindlabs/tailwindcss/pull/5568))
- Add `touch-action` utilities ([#5603](https://github.com/tailwindlabs/tailwindcss/pull/5603))
- Add `inherit` to default color palette ([#5597](https://github.com/tailwindlabs/tailwindcss/pull/5597))
- Add `overflow-clip`, `overflow-x-clip` and `overflow-y-clip` utilities ([#5630](https://github.com/tailwindlabs/tailwindcss/pull/5630))
- Add `[open]` variant ([#5627](https://github.com/tailwindlabs/tailwindcss/pull/5627))
- Add `scroll-snap` utilities ([#5637](https://github.com/tailwindlabs/tailwindcss/pull/5637))
- Add `border-x` and `border-y` width and color utilities ([#5639](https://github.com/tailwindlabs/tailwindcss/pull/5639))
### Fixed
- Fix defining colors as functions when color opacity plugins are disabled ([#5470](https://github.com/tailwindlabs/tailwindcss/pull/5470))
- Fix using negated `content` globs ([#5625](https://github.com/tailwindlabs/tailwindcss/pull/5625))
- Fix using backslashes in `content` globs ([#5628](https://github.com/tailwindlabs/tailwindcss/pull/5628))
## [2.2.19] - 2021-10-29
### Fixed
- Ensure `corePlugins` order is consistent in AOT mode ([#5928](https://github.com/tailwindlabs/tailwindcss/pull/5928))
## [2.2.18] - 2021-10-29
### Fixed
- Bump versions for security vulnerabilities ([#5924](https://github.com/tailwindlabs/tailwindcss/pull/5924))
## [2.2.17] - 2021-10-13
### Fixed
- Configure chokidar's `awaitWriteFinish` setting to avoid occasional stale builds on Windows ([#5758](https://github.com/tailwindlabs/tailwindcss/pull/5758))
## [2.2.16] - 2021-09-26
### Fixed
- JIT: Properly handle animations that use CSS custom properties ([#5602](https://github.com/tailwindlabs/tailwindcss/pull/5602))
## [2.2.15] - 2021-09-10
### Fixed
- Ensure using CLI without `-i` for input file continues to work even though deprecated ([#5464](https://github.com/tailwindlabs/tailwindcss/pull/5464))
## [2.2.14] - 2021-09-08
### Fixed
- Only use `@defaults` in JIT, switch back to `clean-css` in case there's any meaningful differences in the output ([bf248cb](https://github.com/tailwindlabs/tailwindcss/commit/bf248cb0de889d48854fbdd26536f4a492556efd))
## [2.2.13] - 2021-09-08
### Fixed
- Replace `clean-css` with `cssnano` for CDN builds to fix minified builds ([75cc3ca](https://github.com/tailwindlabs/tailwindcss/commit/75cc3ca305aedddc8a85f3df1a420fefad3fb5c4))
## [2.2.12] - 2021-09-08
### Fixed
- Ensure that divide utilities inject a default border color ([#5438](https://github.com/tailwindlabs/tailwindcss/pull/5438))
## [2.2.11] - 2021-09-07
### Fixed
- Rebundle to fix missing CLI peer dependencies
## [2.2.10] - 2021-09-06
### Fixed
- Fix build error when using `presets: []` in config file ([#4903](https://github.com/tailwindlabs/tailwindcss/pull/4903))
### Added
- Reintroduce universal selector optimizations under experimental `optimizeUniversalDefaults` flag ([a9e160c](https://github.com/tailwindlabs/tailwindcss/commit/a9e160cf9acb75a2bbac34f8864568b12940f89a))
## [2.2.9] - 2021-08-30
### Fixed
- JIT: Fix `@apply`ing utilities that contain variants + the important modifier ([#4854](https://github.com/tailwindlabs/tailwindcss/pull/4854))
- JIT: Don't strip "null" when parsing tracked file paths ([#5008](https://github.com/tailwindlabs/tailwindcss/pull/5008))
- Pin `clean-css` to v5.1.4 to fix empty CSS variables in CDN builds ([#5338](https://github.com/tailwindlabs/tailwindcss/pull/5338))
## [2.2.8] - 2021-08-27
### Fixed
- Improve accessibility of default link focus styles in Firefox ([#5082](https://github.com/tailwindlabs/tailwindcss/pull/5082))
- JIT: Fix animation variants corrupting keyframes rules ([#5223](https://github.com/tailwindlabs/tailwindcss/pull/5223))
- JIT: Ignore escaped commas when splitting selectors to apply prefixes ([#5239](https://github.com/tailwindlabs/tailwindcss/pull/5239/))
- Nesting: Maintain PostCSS node sources when handling `@apply` ([#5249](https://github.com/tailwindlabs/tailwindcss/pull/5249))
- JIT: Fix support for animation lists ([#5252](https://github.com/tailwindlabs/tailwindcss/pull/5252))
- JIT: Fix arbitrary value support for `object-position` utilities ([#5245](https://github.com/tailwindlabs/tailwindcss/pull/5245))
- CLI: Abort watcher if stdin is closed to avoid zombie processes ([#4997](https://github.com/tailwindlabs/tailwindcss/pull/4997))
- JIT: Ignore arbitrary values with unbalanced brackets ([#5293](https://github.com/tailwindlabs/tailwindcss/pull/5293))
## [2.2.7] - 2021-07-23
### Fixed
- Temporarily revert runtime performance optimizations introduced in v2.2.5, use universal selector again ([#5060](https://github.com/tailwindlabs/tailwindcss/pull/5060))
## [2.2.6] - 2021-07-21
### Fixed
- Fix issue where base styles not generated for translate transforms in JIT ([#5038](https://github.com/tailwindlabs/tailwindcss/pull/5038))
## [2.2.5] - 2021-07-21
### Added
- Added `self-baseline` utility (I know this is a patch release, no one's going to die relax) ([#5000](https://github.com/tailwindlabs/tailwindcss/pull/5000))
### Changed
- JIT: Optimize universal selector usage by inlining only the relevant selectors ([#4850](https://github.com/tailwindlabs/tailwindcss/pull/4850)))
This provides a very significant performance boost on pages with a huge number of DOM nodes, but there's a chance it could be a breaking change in very rare edge cases we haven't thought of. Please open an issue if anything related to shadows, rings, transforms, filters, or backdrop-filters seems to be behaving differently after upgrading.
### Fixed
- Fix support for `step-start` and `step-end` in animation utilities ([#4795](https://github.com/tailwindlabs/tailwindcss/pull/4795)))
- JIT: Prevent presence of `!*` in templates from ruining everything ([#4816](https://github.com/tailwindlabs/tailwindcss/pull/4816)))
- JIT: Improve support for quotes in arbitrary values ([#4817](https://github.com/tailwindlabs/tailwindcss/pull/4817)))
- Fix filter/backdrop-filter/transform utilities being inserted into the wrong position if not all core plugins are enabled ([#4852](https://github.com/tailwindlabs/tailwindcss/pull/4852)))
- JIT: Fix `@layer` rules being mistakenly inserted during incremental rebuilds ([#4853](https://github.com/tailwindlabs/tailwindcss/pull/4853)))
- Improve build performance for projects with many small non-Tailwind stylesheets ([#4644](https://github.com/tailwindlabs/tailwindcss/pull/4644))
- Ensure `[hidden]` works as expected on elements where we override the default `display` value in Preflight ([#4873](https://github.com/tailwindlabs/tailwindcss/pull/4873))
- Fix variant configuration not being applied to `backdropOpacity` utilities ([#4892](https://github.com/tailwindlabs/tailwindcss/pull/4892))
## [2.2.4] - 2021-06-23
### Fixed
- Remove `postinstall` script that was preventing people from installing the library ([1eacfb9](https://github.com/tailwindlabs/tailwindcss/commit/1eacfb98849c0d4737e0af3595ddec8c73addaac))
## [2.2.3] - 2021-06-23
### Added
- Pass extended color palette to theme closures so it can be used without installing Tailwind when using `npx tailwindcss` ([359252c](https://github.com/tailwindlabs/tailwindcss/commit/359252c9b429e81217c28eb3ca7bab73d8f81e6d))
### Fixed
- JIT: Explicitly error when `-` is used as a custom separator ([#4704](https://github.com/tailwindlabs/tailwindcss/pull/4704))
- JIT: Don't add multiple `~` when stacking `peer-*` variants ([#4757](https://github.com/tailwindlabs/tailwindcss/pull/4757))
- Remove outdated focus style fix in Preflight ([#4780](https://github.com/tailwindlabs/tailwindcss/pull/4780))
- Enable `purge` if provided on the CLI ([#4772](https://github.com/tailwindlabs/tailwindcss/pull/4772))
- JIT: Fix error when not using a config file with postcss-cli ([#4773](https://github.com/tailwindlabs/tailwindcss/pull/4773))
- Fix issue with `resolveConfig` not being importable in Next.js pages ([#4725](https://github.com/tailwindlabs/tailwindcss/pull/4725))
## [2.2.2] - 2021-06-18
### Fixed
- JIT: Reintroduce `transform`, `filter`, and `backdrop-filter` classes purely to create stacking contexts to minimize the impact of the breaking change ([#4700](https://github.com/tailwindlabs/tailwindcss/pull/4700))
## [2.2.1] - 2021-06-18
### Fixed
- Recover from errors gracefully in CLI watch mode ([#4693](https://github.com/tailwindlabs/tailwindcss/pull/4693))
- Fix issue with media queries not being generated properly when using PostCSS 7 ([#4695](https://github.com/tailwindlabs/tailwindcss/pull/4695))
## [2.2.0] - 2021-06-17
### Changed
- JIT: Use "tracking" context by default instead of "watching" context for improved reliability with most bundlers ([#4514](https://github.com/tailwindlabs/tailwindcss/pull/4514))
Depending on which tooling you use, you may need to explicitly set `TAILWIND_MODE=watch` until your build runner has been updated to support PostCSS's `dir-dependency` message type.
### Added
- Add `background-origin` utilities ([#4117](https://github.com/tailwindlabs/tailwindcss/pull/4117))
- Improve `@apply` performance in projects that process many CSS sources ([#3178](https://github.com/tailwindlabs/tailwindcss/pull/3718))
- JIT: Don't use CSS variables for color utilities if color opacity utilities are disabled ([#3984](https://github.com/tailwindlabs/tailwindcss/pull/3984))
- JIT: Redesign `matchUtilities` API to make it more suitable for third-party use ([#4232](https://github.com/tailwindlabs/tailwindcss/pull/4232))
- JIT: Support applying important utility variants ([#4260](https://github.com/tailwindlabs/tailwindcss/pull/4260))
- JIT: Support coercing arbitrary values when the type isn't detectable ([#4263](https://github.com/tailwindlabs/tailwindcss/pull/4263))
- JIT: Support for `raw` syntax in `purge` config ([#4272](https://github.com/tailwindlabs/tailwindcss/pull/4272))
- Add `empty` variant ([#3298](https://github.com/tailwindlabs/tailwindcss/pull/3298))
- Update `modern-normalize` to v1.1 ([#4287](https://github.com/tailwindlabs/tailwindcss/pull/4287))
- Implement `theme` function internally, remove `postcss-functions` dependency ([#4317](https://github.com/tailwindlabs/tailwindcss/pull/4317))
- Add `screen` function to improve nesting plugin compatibility ([#4318](https://github.com/tailwindlabs/tailwindcss/pull/4318))
- JIT: Add universal shorthand color opacity syntax ([#4348](https://github.com/tailwindlabs/tailwindcss/pull/4348))
- JIT: Add `@tailwind variants` directive to replace `@tailwind screens` ([#4356](https://github.com/tailwindlabs/tailwindcss/pull/4356))
- JIT: Add support for PostCSS `dir-dependency` messages in `TAILWIND_DISABLE_TOUCH` mode ([#4388](https://github.com/tailwindlabs/tailwindcss/pull/4388))
- JIT: Add per-side border color utilities ([#4404](https://github.com/tailwindlabs/tailwindcss/pull/4404))
- JIT: Add support for `before` and `after` pseudo-element variants and `content` utilities ([#4461](https://github.com/tailwindlabs/tailwindcss/pull/4461))
- Add new `transform` and `extract` APIs to simplify PurgeCSS/JIT customization ([#4469](https://github.com/tailwindlabs/tailwindcss/pull/4469))
- JIT: Add exhaustive pseudo-class and pseudo-element variant support ([#4482](https://github.com/tailwindlabs/tailwindcss/pull/4482))
- JIT: Add `caret-color` utilities ([#4499](https://github.com/tailwindlabs/tailwindcss/pull/4499))
- Rename `lightBlue` to `sky`, emit console warning when using deprecated name ([#4513](https://github.com/tailwindlabs/tailwindcss/pull/4513))
- New CLI with improved JIT support, `--watch` mode, and more ([#4526](https://github.com/tailwindlabs/tailwindcss/pull/4526), [4558](https://github.com/tailwindlabs/tailwindcss/pull/4558))
- JIT: Add new `peer-*` variants for styling based on sibling state ([#4556](https://github.com/tailwindlabs/tailwindcss/pull/4556))
- Expose `safelist` as a top-level option under `purge` for both JIT and classic engines ([#4580](https://github.com/tailwindlabs/tailwindcss/pull/4580))
- JIT: Remove need for `transform` class when using classes like `scale-*`, `rotate-*`, etc. ([#4604](https://github.com/tailwindlabs/tailwindcss/pull/4604))
- JIT: Remove need for `filter` and `backdrop-filter` classes when using classes like `contrast-*`, `backdrop-blur-*`, etc. ([#4614](https://github.com/tailwindlabs/tailwindcss/pull/4614))
- Support passing a custom path for your PostCSS configuration in the Tailwind CLI ([#4607](https://github.com/tailwindlabs/tailwindcss/pull/4607))
- Add `blur-none` by default with intent to deprecate `blur-0` ([#4614](https://github.com/tailwindlabs/tailwindcss/pull/4614))
### Fixed
- JIT: Improve support for Svelte class bindings ([#4187](https://github.com/tailwindlabs/tailwindcss/pull/4187))
- JIT: Improve support for `calc` and `var` in arbitrary values ([#4147](https://github.com/tailwindlabs/tailwindcss/pull/4147))
- Convert `hsl` colors to `hsla` when transforming for opacity support instead of `rgba` ([#3850](https://github.com/tailwindlabs/tailwindcss/pull/3850))
- Fix `backdropBlur` variants not being generated ([#4188](https://github.com/tailwindlabs/tailwindcss/pull/4188))
- Improve animation value parsing ([#4250](https://github.com/tailwindlabs/tailwindcss/pull/4250))
- Ignore unknown object types when hashing config ([82f4eaa](https://github.com/tailwindlabs/tailwindcss/commit/82f4eaa6832ef8a4e3fd90869e7068efdf6e34f2))
- Ensure variants are grouped properly for plugins with order-dependent utilities ([#4273](https://github.com/tailwindlabs/tailwindcss/pull/4273))
- JIT: Fix temp file storage when node temp directories are kept on a different drive than the project itself ([#4044](https://github.com/tailwindlabs/tailwindcss/pull/4044))
- Support border-opacity utilities alongside default `border` utility ([#4277](https://github.com/tailwindlabs/tailwindcss/pull/4277))
- JIT: Fix source maps for expanded `@tailwind` directives ([2f15411](https://github.com/tailwindlabs/tailwindcss/commit/2f1541123dea29d8a2ab0f1411bf60c79eeb96b4))
- JIT: Ignore whitespace when collapsing adjacent rules ([15642fb](https://github.com/tailwindlabs/tailwindcss/commit/15642fbcc885eba9cc50b7678a922b09c90d6b51))
- JIT: Generate group parent classes correctly when using custom separator ([#4508](https://github.com/tailwindlabs/tailwindcss/pull/4508))
- JIT: Fix incorrect stacking of multiple `group` variants ([#4551](https://github.com/tailwindlabs/tailwindcss/pull/4551))
- JIT: Fix memory leak due to holding on to unused contexts ([#4571](https://github.com/tailwindlabs/tailwindcss/pull/4571))
### Internals
- Add integration tests for popular build runners ([#4354](https://github.com/tailwindlabs/tailwindcss/pull/4354))
## [2.1.4] - 2021-06-02
### Fixed
- Skip `raw` PurgeCSS sources when registering template dependencies ([#4542](https://github.com/tailwindlabs/tailwindcss/pull/4542))
## [2.1.3] - 2021-06-01
### Fixed
- Register PurgeCSS paths as PostCSS dependencies to guarantee proper cache-busting in webpack 5 ([#4530](https://github.com/tailwindlabs/tailwindcss/pull/4530))
## [2.1.2] - 2021-04-23
### Fixed
- Fix issue where JIT engine would generate the wrong CSS when using PostCSS 7 ([#4078](https://github.com/tailwindlabs/tailwindcss/pull/4078))
## [2.1.1] - 2021-04-05
### Fixed
- Fix issue where JIT engine would fail to compile when a source path isn't provided by the build runner for the current input file ([#3978](https://github.com/tailwindlabs/tailwindcss/pull/3978))
## [2.1.0] - 2021-04-05
### Added
- Add alternate JIT engine (in preview) ([#3905](https://github.com/tailwindlabs/tailwindcss/pull/3905))
- Add new `mix-blend-mode` and `background-blend-mode` utilities ([#3920](https://github.com/tailwindlabs/tailwindcss/pull/3920))
- Add new `box-decoration-break` utilities ([#3911](https://github.com/tailwindlabs/tailwindcss/pull/3911))
- Add new `isolation` utilities ([#3914](https://github.com/tailwindlabs/tailwindcss/pull/3914))
- Add `inline-table` display utility ([#3563](https://github.com/tailwindlabs/tailwindcss/pull/3563))
- Add `list-item` display utility ([#3929](https://github.com/tailwindlabs/tailwindcss/pull/3929))
- Add new `filter` and `backdrop-filter` utilities ([#3923](https://github.com/tailwindlabs/tailwindcss/pull/3923))
## [2.0.4] - 2021-03-17
### Fixed
- Pass full `var(--bg-opacity)` value as `opacityValue` when defining colors as functions
## [2.0.3] - 2021-02-07
### Fixed
- Ensure sourcemap input is deterministic when using `@apply` in Vue components ([#3356](https://github.com/tailwindlabs/tailwindcss/pull/3356))
- Ensure placeholder opacity is consistent across browsers ([#3308](https://github.com/tailwindlabs/tailwindcss/pull/3308))
- Fix issue where `theme()` didn't work with colors defined as functions ([#2919](https://github.com/tailwindlabs/tailwindcss/pull/2919))
- Enable `dark` variants by default for color opacity utilities ([#2975](https://github.com/tailwindlabs/tailwindcss/pull/2975))
### Added
- Add support for a `tailwind.config.cjs` file in Node ESM projects ([#3181](https://github.com/tailwindlabs/tailwindcss/pull/3181))
- Add version comment to Preflight ([#3255](https://github.com/tailwindlabs/tailwindcss/pull/3255))
- Add `cursor-help` by default ([#3199](https://github.com/tailwindlabs/tailwindcss/pull/3199))
## [2.0.2] - 2020-12-11
### Fixed
- Fix issue with `@apply` not working as expected with `!important` inside an at-rule ([#2824](https://github.com/tailwindlabs/tailwindcss/pull/2824))
- Fix issue with `@apply` not working as expected with defined classes ([#2832](https://github.com/tailwindlabs/tailwindcss/pull/2832))
- Fix memory leak, and broken `@apply` when splitting up files ([#3032](https://github.com/tailwindlabs/tailwindcss/pull/3032))
### Added
- Add default values for the `ring` utility ([#2951](https://github.com/tailwindlabs/tailwindcss/pull/2951))
## [2.0.1] - 2020-11-18
- Nothing, just the only thing I could do when I found out npm won't let me publish the same version under two tags.
## [2.0.0] - 2020-11-18
### Added
- Add redesigned color palette ([#2623](https://github.com/tailwindlabs/tailwindcss/pull/2623), [700866c](https://github.com/tailwindlabs/tailwindcss/commit/700866ce5e0c0b8d140be161c4d07fc6f31242bc), [#2633](https://github.com/tailwindlabs/tailwindcss/pull/2633))
- Add dark mode support ([#2279](https://github.com/tailwindlabs/tailwindcss/pull/2279), [#2631](https://github.com/tailwindlabs/tailwindcss/pull/2631))
- Add `overflow-ellipsis` and `overflow-clip` utilities ([#1289](https://github.com/tailwindlabs/tailwindcss/pull/1289))
- Add `transform-gpu` to force hardware acceleration on transforms when desired ([#1380](https://github.com/tailwindlabs/tailwindcss/pull/1380))
- Extend default spacing scale ([#2630](https://github.com/tailwindlabs/tailwindcss/pull/2630), [7f05204](https://github.com/tailwindlabs/tailwindcss/commit/7f05204ce7a5581b6845591448265c3c21afde86))
- Add spacing scale to `inset` plugin ([#2630](https://github.com/tailwindlabs/tailwindcss/pull/2630))
- Add percentage sizes to `translate`, `inset`, and `height` plugins ([#2630](https://github.com/tailwindlabs/tailwindcss/pull/2630), [5259560](https://github.com/tailwindlabs/tailwindcss/commit/525956065272dc53e8f8395f55f9ad13077a38d1))
- Extend default font size scale ([#2609](https://github.com/tailwindlabs/tailwindcss/pull/2609), [#2619](https://github.com/tailwindlabs/tailwindcss/pull/2619))
- Support using `@apply` with complex classes, including variants like `lg:hover:bg-blue-500` ([#2159](https://github.com/tailwindlabs/tailwindcss/pull/2159))
- Add new `2xl` breakpoint at 1536px by default ([#2609](https://github.com/tailwindlabs/tailwindcss/pull/2609))
- Add default line-height values for font-size utilities ([#2609](https://github.com/tailwindlabs/tailwindcss/pull/2609))
- Support defining theme values using arrays for CSS properties that support comma separated values ([e13f083c4](https://github.com/tailwindlabs/tailwindcss/commit/e13f083c4bc48bf9870d27c966136a9584943127))
- Enable `group-hover` for color plugins, `boxShadow`, and `textDecoration` by default ([28985b6](https://github.com/tailwindlabs/tailwindcss/commit/28985b6cd592e72d4849fdb9ce97eb045744e09c), [f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
- Enable `focus` for z-index utilities by default ([ae5b3d3](https://github.com/tailwindlabs/tailwindcss/commit/ae5b3d312d5000ae9c2065001f3df7add72dc365))
- Support `extend` in `variants` configuration ([#2651](https://github.com/tailwindlabs/tailwindcss/pull/2651))
- Add `max-w-prose` class by default ([#2574](https://github.com/tailwindlabs/tailwindcss/pull/2574))
- Support flattening deeply nested color objects ([#2148](https://github.com/tailwindlabs/tailwindcss/pull/2148))
- Support defining presets as functions ([#2680](https://github.com/tailwindlabs/tailwindcss/pull/2680))
- Support deep merging of objects under `extend` ([#2679](https://github.com/tailwindlabs/tailwindcss/pull/2679), [#2700](https://github.com/tailwindlabs/tailwindcss/pull/2700))
- Enable `focus-within` for all plugins that have `focus` enabled by default ([1a21f072](https://github.com/tailwindlabs/tailwindcss/commit/1a21f0721c7368d61fa3feef33d616de3f78c7d7), [f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
- Added new `ring` utilities for creating outline/focus rings using box shadows ([#2747](https://github.com/tailwindlabs/tailwindcss/pull/2747), [879f088](https://github.com/tailwindlabs/tailwindcss/commit/879f088), [e0788ef](https://github.com/tailwindlabs/tailwindcss/commit/879f088))
- Added `5` and `95` to opacity scale ([#2747](https://github.com/tailwindlabs/tailwindcss/pull/2747))
- Add support for default duration and timing function values whenever enabling transitions ([#2755](https://github.com/tailwindlabs/tailwindcss/pull/2755))
### Changed
- Completely redesign color palette ([#2623](https://github.com/tailwindlabs/tailwindcss/pull/2623), [700866c](https://github.com/tailwindlabs/tailwindcss/commit/700866ce5e0c0b8d140be161c4d07fc6f31242bc), [#2633](https://github.com/tailwindlabs/tailwindcss/pull/2633))
- Drop support for Node 8 and 10 ([#2582](https://github.com/tailwindlabs/tailwindcss/pull/2582))
- Removed `target` feature and dropped any compatibility with IE 11 ([#2571](https://github.com/tailwindlabs/tailwindcss/pull/2571))
- Upgrade to PostCSS 8 (but include PostCSS 7 compatibility build) ([729b400](https://github.com/tailwindlabs/tailwindcss/commit/729b400a685973f46af73c8a68b364f20f7c5e1e), [1d8679d](https://github.com/tailwindlabs/tailwindcss/commit/1d8679d37e0eb1ba8281b2076bade5fc754f47dd), [c238ed1](https://github.com/tailwindlabs/tailwindcss/commit/c238ed15b5c02ff51978965511312018f2bc2cae))
- Removed `shadow-outline`, `shadow-solid`, and `shadow-xs` by default in favor of new `ring` API ([#2747](https://github.com/tailwindlabs/tailwindcss/pull/2747))
- Switch `normalize.css` to `modern-normalize` ([#2572](https://github.com/tailwindlabs/tailwindcss/pull/2572))
- Rename `whitespace-no-wrap` to `whitespace-nowrap` ([#2664](https://github.com/tailwindlabs/tailwindcss/pull/2664))
- Rename `flex-no-wrap` to `flex-nowrap` ([#2676](https://github.com/tailwindlabs/tailwindcss/pull/2676))
- Remove `clearfix` utility, recommend `flow-root` instead ([#2766](https://github.com/tailwindlabs/tailwindcss/pull/2766))
- Disable `hover` and `focus` for `fontWeight` utilities by default ([f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
- Remove `grid-gap` fallbacks needed for old versions of Safari ([5ec45fa](https://github.com/tailwindlabs/tailwindcss/commit/5ec45fa))
- Change special use of 'default' in config to 'DEFAULT' ([#2580](https://github.com/tailwindlabs/tailwindcss/pull/2580))
- New `@apply` implementation, slight backwards incompatibilities with previous behavior ([#2159](https://github.com/tailwindlabs/tailwindcss/pull/2159))
- Make `theme` retrieve the expected resolved value when theme value is complex ([e13f083c4](https://github.com/tailwindlabs/tailwindcss/commit/e13f083c4bc48bf9870d27c966136a9584943127))
- Move `truncate` class to `textOverflow` core plugin ([#2562](https://github.com/tailwindlabs/tailwindcss/pull/2562))
- Remove `scrolling-touch` and `scrolling-auto` utilities ([#2573](https://github.com/tailwindlabs/tailwindcss/pull/2573))
- Modernize default system font stacks ([#1711](https://github.com/tailwindlabs/tailwindcss/pull/1711))
- Upgrade to PurgeCSS 3.0 ([8e4e0a0](https://github.com/tailwindlabs/tailwindcss/commit/8e4e0a0eb8dcbf84347c7562988b4f9afd344081))
- Change default `text-6xl` font-size to 3.75rem instead of 4rem ([#2619](https://github.com/tailwindlabs/tailwindcss/pull/2619))
- Ignore `[hidden]` elements within `space` and `divide` utilities instead of `template` elements ([#2642](https://github.com/tailwindlabs/tailwindcss/pull/2642))
- Automatically prefix keyframes and animation names when a prefix is configured ([#2621](https://github.com/tailwindlabs/tailwindcss/pull/2621), [#2641](https://github.com/tailwindlabs/tailwindcss/pull/2641))
- Merge `extend` objects deeply by default ([#2679](https://github.com/tailwindlabs/tailwindcss/pull/2679))
- Respect `preserveHtmlElements` option even when using custom PurgeCSS extractor ([#2704](https://github.com/tailwindlabs/tailwindcss/pull/2704))
- Namespace all internal custom properties under `tw-` to avoid collisions with end-user custom properties ([#2771](https://github.com/tailwindlabs/tailwindcss/pull/2771))
## [2.0.0-alpha.25] - 2020-11-17
### Fixed
- Fix issue where `ring-offset-0` didn't work due to unitless `0` in `calc` function ([3de0c48](https://github.com/tailwindlabs/tailwindcss/commit/3de0c48))
## [2.0.0-alpha.24] - 2020-11-16
### Changed
- Don't override ring color when overriding ring width with a variant ([e40079a](https://github.com/tailwindlabs/tailwindcss/commit/e40079a))
### Fixed
- Prevent shadow/ring styles from cascading to children ([e40079a](https://github.com/tailwindlabs/tailwindcss/commit/e40079a))
- Ensure rings have a default color even if `colors.blue.500` is not present in config ([e40079a](https://github.com/tailwindlabs/tailwindcss/commit/e40079a))
## [2.0.0-alpha.23] - 2020-11-16
### Added
- Add scripts for generating a PostCSS 7 compatible build alongside PostCSS 8 version ([#2773](https://github.com/tailwindlabs/tailwindcss/pull/2773))
### Changed
- All custom properties have been internally namespaced under `tw-` to avoid collisions with end-user custom properties ([#2771](https://github.com/tailwindlabs/tailwindcss/pull/2771))
## [2.0.0-alpha.22] - 2020-11-16
### Changed
- ~~All custom properties have been internally namespaced under `tw-` to avoid collisions with end-user custom properties ([#2771](https://github.com/tailwindlabs/tailwindcss/pull/2771))~~ I made a git boo-boo, check alpha.23 instead
## [2.0.0-alpha.21] - 2020-11-15
### Changed
- Upgrade to PostCSS 8, Autoprefixer 10, move `postcss` and `autoprefixer` to peerDependencies ([729b400](https://github.com/tailwindlabs/tailwindcss/commit/729b400))
## [2.0.0-alpha.20] - 2020-11-13
### Changed
- Remove `clearfix` utility, recommend `flow-root` instead ([#2766](https://github.com/tailwindlabs/tailwindcss/pull/2766))
## [2.0.0-alpha.19] - 2020-11-13
### Fixed
- Don't crash when color palette is empty ([278c203](https://github.com/tailwindlabs/tailwindcss/commit/278c203))
## [2.0.0-alpha.18] - 2020-11-13
### Changed
- `black` and `white` have been added to `colors.js` ([b3ed724](https://github.com/tailwindlabs/tailwindcss/commit/b3ed724))
### Fixed
- Add support for colors as closures to `ringColor` and `ringOffsetColor`, previously would crash build ([62a47f9](https://github.com/tailwindlabs/tailwindcss/commit/62a47f9))
## [2.0.0-alpha.17] - 2020-11-13
### Changed
- Remove `grid-gap` fallbacks needed for old versions of Safari ([5ec45fa](https://github.com/tailwindlabs/tailwindcss/commit/5ec45fa))
## [2.0.0-alpha.16] - 2020-11-12
### Added
- Enable `focus`, `focus-within`, and `dark` variants (when enabled) for all ring utilities by default ([e0788ef](https://github.com/tailwindlabs/tailwindcss/commit/879f088))
## [2.0.0-alpha.15] - 2020-11-11
### Added
- Added `ring-inset` utility for rendering rings as inset shadows ([879f088](https://github.com/tailwindlabs/tailwindcss/commit/879f088))
### Changed
- `ringWidth` utilities always reset ring styles to ensure no accidental variable inheritance through the cascade ([879f088](https://github.com/tailwindlabs/tailwindcss/commit/879f088))
## [2.0.0-alpha.14] - 2020-11-11
### Added
- Enable `focus-within` for `outline` utilities by default ([f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
- Enable `focus-within` for `ringWidth` utilities by default ([f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
- Enable `group-hover` for `boxShadow` utilities by default ([f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
- Enable `group-hover` and `focus-within` for `textDecoration` utilities by default ([f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
### Changed
- Disable `hover` and `focus` for `fontWeight` utilities by default ([f6923b1](https://github.com/tailwindlabs/tailwindcss/commit/f6923b1))
## [2.0.0-alpha.13] - 2020-11-11
### Added
- Add support for default duration and timing function values whenever enabling transitions ([#2755](https://github.com/tailwindlabs/tailwindcss/pull/2755))
## [2.0.0-alpha.12] - 2020-11-10
### Fixed
- Prevent `boxShadow` utilities from overriding ring shadows added by components like in the custom forms plugin ([c3dd3b6](https://github.com/tailwindlabs/tailwindcss/commit/c3dd3b68454ad418833a9edf7f3409cad66fb5b0))
## [2.0.0-alpha.11] - 2020-11-09
### Fixed
- Convert `none` to `0 0 #0000` when used for shadows to ensure compatibility with `ring` utilities ([4eecc27](https://github.com/tailwindlabs/tailwindcss/commit/4eecc2751ca0c461e8da5bd5772ae650197a2e5d))
## [2.0.0-alpha.10] - 2020-11-09
### Added
- Added new `ring` utilities ([#2747](https://github.com/tailwindlabs/tailwindcss/pull/2747))
- Added `5` and `95` to opacity scale ([#2747](https://github.com/tailwindlabs/tailwindcss/pull/2747))
### Changed
- Removed `shadow-outline`, `shadow-solid`, and `shadow-xs` in favor of new `ring` API ([#2747](https://github.com/tailwindlabs/tailwindcss/pull/2747))
## [2.0.0-alpha.9] - 2020-11-07
### Added
- Added `shadow-solid` utility, a 2px solid shadow that uses the current text color ([369cfae](https://github.com/tailwindlabs/tailwindcss/commit/369cfae2905a577033529c46a5e8ca58c69f5623))
- Enable `focus-within` where useful by default ([1a21f072](https://github.com/tailwindlabs/tailwindcss/commit/1a21f0721c7368d61fa3feef33d616de3f78c7d7))
### Changed
- Update `shadow-outline` to use the new blue ([b078238](https://github.com/tailwindlabs/tailwindcss/commit/b0782385c9832d35a10929b38b4fcaf27e055d6b))
## [2.0.0-alpha.8] - 2020-11-06
### Added
- Add `11` to spacing scale ([7f05204](https://github.com/tailwindlabs/tailwindcss/commit/7f05204ce7a5581b6845591448265c3c21afde86))
- Add percentage-based height values ([5259560](https://github.com/tailwindlabs/tailwindcss/commit/525956065272dc53e8f8395f55f9ad13077a38d1))
- Add indigo to the color palette by default ([700866c](https://github.com/tailwindlabs/tailwindcss/commit/700866ce5e0c0b8d140be161c4d07fc6f31242bc))
### Changed
- Use `coolGray` as the default gray ([700866c](https://github.com/tailwindlabs/tailwindcss/commit/700866ce5e0c0b8d140be161c4d07fc6f31242bc))
## [2.0.0-alpha.7] - 2020-11-05
### Changed
- Revert upgrading to PostCSS 8 lol
## [2.0.0-alpha.6] - 2020-11-04
### Changed
- Respect `preserveHtmlElements` option even when using custom PurgeCSS extractor ([#2704](https://github.com/tailwindlabs/tailwindcss/pull/2704))
- Set font-family and line-height to `inherit` on `body` to behave more like v1.x ([#2729](https://github.com/tailwindlabs/tailwindcss/pull/2729))
## [2.0.0-alpha.5] - 2020-10-30
### Changed
- Upgrade to PostCSS 8 ([59aa484](https://github.com/tailwindlabs/tailwindcss/commit/59aa484dfea0607d96bff6ef41b1150c78576c37))
## [2.0.0-alpha.4] - 2020-10-29
### Added
- Support deep merging of arrays of objects under `extend` ([#2700](https://github.com/tailwindlabs/tailwindcss/pull/2700))
## [2.0.0-alpha.3] - 2020-10-27
### Added
- Support flattening deeply nested color objects ([#2148](https://github.com/tailwindlabs/tailwindcss/pull/2148))
- Support defining presets as functions ([#2680](https://github.com/tailwindlabs/tailwindcss/pull/2680))
### Changed
- Merge `extend` objects deeply by default ([#2679](https://github.com/tailwindlabs/tailwindcss/pull/2679))
- Rename `flex-no-wrap` to `flex-nowrap` ([#2676](https://github.com/tailwindlabs/tailwindcss/pull/2676))
## [2.0.0-alpha.2] - 2020-10-25
### Added
- Support `extend` in `variants` configuration ([#2651](https://github.com/tailwindlabs/tailwindcss/pull/2651))
- Add `max-w-prose` class by default ([#2574](https://github.com/tailwindlabs/tailwindcss/pull/2574))
### Changed
- Revert use of logical properties for `space` and `divide` utilities ([#2644](https://github.com/tailwindlabs/tailwindcss/pull/2644))
- `space` and `divide` utilities ignore elements with `[hidden]` now instead of only ignoring `template` elements ([#2642](https://github.com/tailwindlabs/tailwindcss/pull/2642))
- Set default font on `body`, not just `html` ([#2643](https://github.com/tailwindlabs/tailwindcss/pull/2643))
- Automatically prefix keyframes and animation names when a prefix is configured ([#2621](https://github.com/tailwindlabs/tailwindcss/pull/2621), [#2641](https://github.com/tailwindlabs/tailwindcss/pull/2641))
- Rename `whitespace-no-wrap` to `whitespace-nowrap` ([#2664](https://github.com/tailwindlabs/tailwindcss/pull/2664))
## [1.9.6] - 2020-10-23
### Changed
- The `presets` feature had unexpected behavior where a preset config without its own `presets` key would not extend the default config. ([#2662](https://github.com/tailwindlabs/tailwindcss/pull/2662))
If you were depending on this unexpected behavior, just add `presets: []` to your own preset to exclude the default configuration.
## [2.0.0-alpha.1] - 2020-10-20
### Added
- Added dark mode support ([#2279](https://github.com/tailwindlabs/tailwindcss/pull/2279), [#2631](https://github.com/tailwindlabs/tailwindcss/pull/2631))
- Added `overflow-ellipsis` and `overflow-clip` utilities ([#1289](https://github.com/tailwindlabs/tailwindcss/pull/1289))
- Add `transform-gpu` to force hardware acceleration on transforms when beneficial ([#1380](https://github.com/tailwindlabs/tailwindcss/pull/1380))
- Extended spacing scale ([#2630](https://github.com/tailwindlabs/tailwindcss/pull/2630))
- Add spacing scale to `inset` plugin ([#2630](https://github.com/tailwindlabs/tailwindcss/pull/2630))
- Enable useful relative sizes for more plugins ([#2630](https://github.com/tailwindlabs/tailwindcss/pull/2630))
- Extend font size scale ([#2609](https://github.com/tailwindlabs/tailwindcss/pull/2609), [#2619](https://github.com/tailwindlabs/tailwindcss/pull/2619))
- Support using `@apply` with complex classes ([#2159](https://github.com/tailwindlabs/tailwindcss/pull/2159))
- Add new `2xl` breakpoint ([#2609](https://github.com/tailwindlabs/tailwindcss/pull/2609))
- Add default line-height values for font-size utilities ([#2609](https://github.com/tailwindlabs/tailwindcss/pull/2609))
- Support defining theme values using arrays wherever it makes sense (box-shadow, transition-property, etc.) ([e13f083c4](https://github.com/tailwindlabs/tailwindcss/commit/e13f083c4bc48bf9870d27c966136a9584943127))
- Enable `group-hover` for color utilities by default ([28985b6](https://github.com/tailwindlabs/tailwindcss/commit/28985b6cd592e72d4849fdb9ce97eb045744e09c))
- Enable `focus` for z-index utilities by default ([ae5b3d3](https://github.com/tailwindlabs/tailwindcss/commit/ae5b3d312d5000ae9c2065001f3df7add72dc365))
### Changed
- New `@apply` implementation, slight backwards incompatibilities with previous behavior ([#2159](https://github.com/tailwindlabs/tailwindcss/pull/2159))
- Move `truncate` class to `textOverflow` core plugin ([#2562](https://github.com/tailwindlabs/tailwindcss/pull/2562))
- Removed `target` feature and dropped any compatibility with IE 11 ([#2571](https://github.com/tailwindlabs/tailwindcss/pull/2571))
- Switch `normalize.css` to `modern-normalize` ([#2572](https://github.com/tailwindlabs/tailwindcss/pull/2572))
- Remove `scrolling-touch` and `scrolling-auto` utilities ([#2573](https://github.com/tailwindlabs/tailwindcss/pull/2573))
- Change special use of 'default' in config to 'DEFAULT' ([#2580](https://github.com/tailwindlabs/tailwindcss/pull/2580))
- Drop support for Node 8 and 10 ([#2582](https://github.com/tailwindlabs/tailwindcss/pull/2582))
- Modernize default system font stacks ([#1711](https://github.com/tailwindlabs/tailwindcss/pull/1711))
- Upgrade to PurgeCSS 3.0
- ~~Upgrade to PostCSS 8.0~~ Reverted for now
- Use logical properties for `space` and `divide` utilities ([#1883](https://github.com/tailwindlabs/tailwindcss/pull/1883))
- Make `theme` retrieve the expected resolved value when theme value is complex ([e13f083c4](https://github.com/tailwindlabs/tailwindcss/commit/e13f083c4bc48bf9870d27c966136a9584943127))
- Adjust default font-size scale to include 60px instead of 64px ([#2619](https://github.com/tailwindlabs/tailwindcss/pull/2619))
- Update default colors in Preflight to match new color palette ([#2633](https://github.com/tailwindlabs/tailwindcss/pull/2633))
## [1.9.5] - 2020-10-19
### Fixed
- Fix issue where using `theme` with default line-heights did not resolve correctly
## [1.9.4] - 2020-10-17
### Fixed
- Fix issue changing plugins defined using the `withOptions` API would not trigger rebuilds in watch processes
## [1.9.3] - 2020-10-16
### Fixed
- Fix issue where `tailwindcss init --full` scaffolded a corrupt config file (https://github.com/tailwindlabs/tailwindcss/issues/2556)
### Changed
- Remove console warnings about upcoming breaking changes
## [1.9.2] - 2020-10-14
### Fixed
- Merge plugins when merging config with preset ([#2561](https://github.com/tailwindlabs/tailwindcss/pulls/#2561)
- Use `word-wrap` and `overflow-wrap` together, not one or the other since `word-wrap` is IE-only
## [1.9.1] - 2020-10-14
### Fixed
- Don't import `corePlugins` in `resolveConfig` to avoid bundling browser-incompatible code ([#2548](https://github.com/tailwindlabs/tailwindcss/pull/2548))
## [1.9.0] - 2020-10-12
### Added
- Add new `presets` config option ([#2474](https://github.com/tailwindlabs/tailwindcss/pull/2474))
- Scaffold new `tailwind.config.js` files with available `future` flags commented out ([#2379](https://github.com/tailwindlabs/tailwindcss/pull/2379))
- Add `col-span-full` and `row-span-full` ([#2471](https://github.com/tailwindlabs/tailwindcss/pull/2471))
- Make `outline` configurable, `outline-none` more accessible by default, and add `outline-black` and `outline-white` ([#2460](https://github.com/tailwindlabs/tailwindcss/pull/2460))
- Add additional small `rotate` and `skew` values ([#2528](https://github.com/tailwindlabs/tailwindcss/pull/2528))
- Add `xl`, `2xl`, and `3xl` border radius values ([#2529](https://github.com/tailwindlabs/tailwindcss/pull/2529))
- Add new utilities for `grid-auto-columns` and `grid-auto-rows` ([#2531](https://github.com/tailwindlabs/tailwindcss/pull/2531))
- Promote `defaultLineHeights` and `standardFontWeights` from experimental to future
### Fixed
- Don't escape keyframe values ([#2432](https://github.com/tailwindlabs/tailwindcss/pull/2432))
- Use `word-wrap` instead of `overflow-wrap` in `ie11` target mode ([#2391](https://github.com/tailwindlabs/tailwindcss/pull/2391))
### Experimental
- Add experimental `2xl` breakpoint ([#2468](https://github.com/tailwindlabs/tailwindcss/pull/2468))
- Rename `{u}-max-content` and `{u}-min-content` utilities to `{u}-max` and `{u}-min` in experimental extended spacing scale ([#2532](https://github.com/tailwindlabs/tailwindcss/pull/2532))
- Support disabling dark mode variants globally ([#2530](https://github.com/tailwindlabs/tailwindcss/pull/2530))
## [1.8.13] - 2020-10-09
### Fixed
- Support defining colors as closures even when opacity variables are not supported ([#2536](https://github.com/tailwindlabs/tailwindcss/pull/2515))
## [1.8.12] - 2020-10-07
### Fixed
- Reset color opacity variable in utilities generated using closure colors ([#2515](https://github.com/tailwindlabs/tailwindcss/pull/2515))
## [1.8.11] - 2020-10-06
- Make `tailwindcss.plugin` work in ESM environments for reasons
## [1.8.10] - 2020-09-14
### Fixed
- Prevent new `dark` experiment from causing third-party `dark` variants to inherit stacking behavior ([#2382](https://github.com/tailwindlabs/tailwindcss/pull/2382))
## [1.8.9] - 2020-09-13
### Fixed
- Add negative spacing values to inset plugin in the `extendedSpacingScale` experiment ([#2358](https://github.com/tailwindlabs/tailwindcss/pull/2358))
- Fix issue where `!important` was stripped from declarations within rules that used `@apply` with `applyComplexClasses` ([#2376](https://github.com/tailwindlabs/tailwindcss/pull/2376))
### Changed
- Add `future` section to config stubs ([#2372](https://github.com/tailwindlabs/tailwindcss/pull/2372), [3090b98](https://github.com/tailwindlabs/tailwindcss/commit/3090b98ece766b1046abe5bbaa94204e811f7fac))
## [1.8.8] - 2020-09-11
### Fixed
- Register dark mode plugin outside of `resolveConfig` code path ([#2368](https://github.com/tailwindlabs/tailwindcss/pull/2368))
## [1.8.7] - 2020-09-10
### Fixed
- Fix issue where classes in escaped strings (like `class=\"block\"`) weren't extracted properly for purging ([#2364](https://github.com/tailwindlabs/tailwindcss/pull/2364))
## [1.8.6] - 2020-09-09
### Fixed
- Fix issue where container padding not applied when using object syntax ([#2353](https://github.com/tailwindlabs/tailwindcss/pull/2353))
## [1.8.5] - 2020-09-07
### Fixed
- Fix issue where `resolveConfig` didn't take into account configs added by feature flags ([#2347](https://github.com/tailwindlabs/tailwindcss/pull/2347))
## [1.8.4] - 2020-09-06
### Fixed
- Fix [issue](https://github.com/tailwindlabs/tailwindcss/issues/2258) where inserting extra PurgeCSS control comments could break integrated PurgeCSS support
- Fix issue where dark variant in 'class' mode was incompatible with 'group-hover' variant ([#2337](https://github.com/tailwindlabs/tailwindcss/pull/2337))
- Support basic nesting structure with `@apply` when using the `applyComplexClasses` experiment ([#2271](https://github.com/tailwindlabs/tailwindcss/pull/2271))
### Changed
- Rename `font-hairline` and `font-thin` to `font-thin` and `font-extralight` behind `standardFontWeights` flag (experimental until v1.9.0) ([#2333](https://github.com/tailwindlabs/tailwindcss/pull/2333))
## [1.8.3] - 2020-09-05
### Fixed
- Fix issue where `font-variant-numeric` utilities would break in combination with most CSS minifier configurations ([f3660ce](https://github.com/tailwindlabs/tailwindcss/commit/f3660ceed391cfc9390ca4ea1a729a955e64b895))
- Only warn about `conservative` purge mode being deprecated once per process ([58781b5](https://github.com/tailwindlabs/tailwindcss/commit/58781b517daffbaf80fc5c0791d311f53b2d67d8))
## [1.8.2] - 2020-09-04
### Fixed
- Fix bug where dark mode variants would cause an error if you had a `plugins` array in your config ([#2322](https://github.com/tailwindlabs/tailwindcss/pull/2322))
## [1.8.1] - 2020-09-04
### Fixed
- Fix bug in the new font-variant-numeric utilities which broke the whole rule ([#2318](https://github.com/tailwindlabs/tailwindcss/pull/2318))
- Fix bug while purging ([#2320](https://github.com/tailwindlabs/tailwindcss/pull/2320))
## [1.8.0] - 2020-09-04
### Added
- Dark mode variant (experimental) ([#2279](https://github.com/tailwindlabs/tailwindcss/pull/2279))
- New `preserveHtmlElements` option for `purge` ([#2283](https://github.com/tailwindlabs/tailwindcss/pull/2283))
- New `layers` mode for `purge` ([#2288](https://github.com/tailwindlabs/tailwindcss/pull/2288))
- New `font-variant-numeric` utilities ([#2305](https://github.com/tailwindlabs/tailwindcss/pull/2305))
- New `place-items`, `place-content`, `place-self`, `justify-items`, and `justify-self` utilities ([#2306](https://github.com/tailwindlabs/tailwindcss/pull/2306))
- Support configuring variants as functions ([#2309](https://github.com/tailwindlabs/tailwindcss/pull/2309))
### Changed
- CSS within `@layer` at-rules are now grouped with the corresponding `@tailwind` at-rule ([#2312](https://github.com/tailwindlabs/tailwindcss/pull/2312))
### Deprecated
- `conservative` purge mode, deprecated in favor of `layers`
## [1.7.6] - 2020-08-29
### Fixed
- Fix bug where the new experimental `@apply` implementation broke when applying a variant class with the important option globally enabled
## [1.7.5] - 2020-08-28
### Changed
- Update lodash to latest to silence security warnings
## [1.7.4] - 2020-08-26
### Added
- Add new -p flag to CLI to quickly scaffold a `postcss.config.js` file
### Changed
- Make `@apply` insensitive to whitespace in the new `applyComplexClasses` experiment
### Fixed
- Fix bug where the new `applyComplexClasses` experiment didn't behave as expected with rules with multiple selectors, like `.foo, .bar { color: red }`
## [1.7.3] - 2020-08-20
### Changed
- Log feature flag notices to stderr instead of stdout to preserve compatibility with pipe-based build systems
- Add missing bg-none utility for disabling background images
### Fixed
- Fix bug that prevented defining colors as closures when the `gradientColorStops` plugin was enabled
## [1.7.2] - 2020-08-19
### Added
- Reuse generated CSS as much as possible in long-running processes instead of needlessly recalculating
## [1.7.1] - 2020-08-28
### Changed
- Don't issue duplicate flag notices in long-running build processes
## [1.7.0] - 2020-08-28
### Added
- Gradients
- New background-clip utilities
- New `contents` display utility
- Default letter-spacing per font-size
- Divide border styles
- Access entire config object from plugins
- Define colors as closures
- Use `@apply` with variants and other complex classes (experimental)
- New additional color-palette (experimental)
- Extended spacing scale (experimental)
- Default line-heights per font-size by default (experimental)
- Extended font size scale (experimental)
### Deprecated
- Deprecated gap utilities
## [1.6.3] - 2020-08-18
### Fixed
- Fixes issue where motion-safe and motion-reduce variants didn't stack correctly with group-hover variants
## [1.6.2] - 2020-08-03
### Fixed
- Fixes issue where `@keyframes` respecting the important option would break animations in Chrome
## [1.6.1] - 2020-08-02
### Fixed
- Fixes an issue where animation keyframes weren't included in the build without @tailwind base (#2108)
## [1.6.0] - 2020-07-28
### Added
- Animation support
- New `prefers-reduced-motion` variants
- New `overscroll-behaviour` utilities
- Generate CSS without an input file
## [1.5.2] - 2020-07-21
### Fixed
- Fixes issue where you could no longer use `@apply` with unprefixed class names if you had configured a prefix
## [1.5.1] - 2020-07-15
### Fixed
- Fixes accidental breaking change where adding component variants using the old manual syntax (as recommended in the docs) stopped working
## [1.5.0] - 2020-07-15
### Added
- Component `variants` support
- Responsive `container` variants
- New `focus-visible` variant
- New `checked` variant
## v0.0.0-658250a96 - 2020-07-12 [YANKED]
No release notes
## [1.4.6] - 2020-05-08
### Changed
- Explicitly error when using a class as the important config option instead of just generating the wrong CSS
## [1.4.5] - 2020-05-06
### Fixed
- Fix bug where the `divideColor` plugin was using the wrong '' in IE11 target mode
## [1.4.4] - 2020-05-01
### Fixed
- Fix bug where target: 'browserslist' didn't work, only `target: ['browserslist', {...}]` did
## [1.4.3] - 2020-05-01
### Changed
- Don't generate unnecessary CSS in color plugins when color opacity utilities are disabled
## [1.4.2] - 2020-05-01
### Fixed
- Fix issue where `purge: { enabled: false }` was ignored, add `purge: false` shorthand
## [1.4.1] - 2020-04-30
### Changed
- Improve built-in PurgeCSS extractor to better support Haml and Slim templates
## [1.4.0] - 2020-04-29
### Added
- New color opacity utilities
- Built-in PurgeCSS
- IE 11 target mode (experimental)
## [1.3.5] - 2020-04-23
### Removed
- Drop `fs-extra` dependency to `^8.0.0` to preserve Node 8 compatibility until Tailwind 2.0
### Fixed
- Fix missing unit in calc bug in space plugin (`space-x-0` didn't work for example)
## [1.3.4] - 2020-04-21
### Fixed
- Fix bug where `divide-{x/y}-0` utilities didn't work due to missing unit in `calc` call
## [1.3.3] - 2020-04-21
### Added
- Add forgotten responsive variants for `space`, `divideWidth`, and `divideColor` utilities
## [1.3.1] - 2020-04-21
### Fixed
- Fix bug where the `space-x` utilities were not being applied correctly due to referencing `--space-y-reverse` instead of `--space-x-reverse`
## [1.3.0] - 2020-04-21
### Added
- New `space` and `divide` layout utilities
- New `transition-delay` utilities
- New `group-focus` variant
- Support for specifying a default line-height for each font-size utility
- Support for breakpoint-specific padding for `container` class
- Added `current` to the default color palette
- New `inline-grid` utility
- New `flow-root` display utility
- New `clear-none` utility
## [1.2.0] - 2020-02-05
### Added
- CSS Transition support
- CSS Transform support
- CSS Grid support
- Added `max-w-{screen}` utilities
- Added `max-w-none` utility
- Added `rounded-md` utility
- Added `shadow-sm` utility
- Added `shadow-xs` utility
- Added `stroke-width` utilities
- Added fixed line-height utilities
- Added additional display utilities for table elements
- Added box-sizing utilities
- Added clear utilities
- Config file dependencies are now watchable
- Added new `plugin` and `plugin.withOptions` APIs
### Changed
- Allow plugins to extend the user's config
## [1.2.0-canary.8] - 2020-02-05
### Added
- Add additional fixed-size line-height utilities
## [1.2.0-canary.7] - 2020-02-04
### Removed
- Remove Inter from font-sans, plan to add later under new class
## [1.2.0-canary.6] - 2020-02-03
### Added
- Add system-ui to default font stack
- Add shadow-xs, increase shadow-sm alpha to 0.05
- Support import syntax even without postcss-import
- Alias tailwind bin to tailwindcss
- Add fill/stroke to transition-colors
- Add transition-shadow, add box-shadow to default transition
- Combine gap/columnGap/rowGap
- Add grid row utilities
- Add skew utilities
### Changed
- Use font-sans as default font
## [1.2.0-canary.5] - 2020-01-08
### Added
- Adds missing dependency `resolve` which is required for making config dependencies watchable
## [1.2.0-canary.4] - 2020-01-08
### Added
- CSS Transition support
- CSS Transform support
- CSS Grid support
- New `max-w-{screen}` utilities
- Added `max-w-none` utility
- Added "Inter" to the default sans-serif font stack
- Add `rounded-md` utility
- Add `shadow-sm` utility
- Added stroke-width utilities
- Added additional display utilities for table elements
- Added box-sizing utilities
- Added clear utilities
- Config file dependencies are now watchable
- Allow plugins to extend the user's config
- Add new `plugin` and `plugin.withOptions` APIs
## [v1.2.0-canary.3] - 2020-01-08 [YANKED]
No release notes
## [1.1.4] - 2019-11-25
### Changed
- Note: Although this is a bugfix it could affect your site if you were working around the bug in your own code by not prefixing the `.group` class. I'm sorry 😞
### Fixed
- Fixes a bug where the `.group` class was not receiving the user's configured prefix when using the `prefix` option
## [1.2.0-canary.1] - 2019-10-22
### Changed
- Don't watch `node_modules` files for changes
### Fixed
- Fixes significant build performance regression in `v1.2.0-canary.0`
## [1.1.3] - 2019-10-22
### Fixed
- Fixes an issue where in some cases function properties in the user's `theme` config didn't receive the second utils argument
## [1.2.0-canary.0] - 2019-10-14
### Added
- Automatically watch all config file dependencies (plugins, design tokens imported from other files, etc.) for changes when build watcher is running
- Add `justify-evenly` utility
### Changed
- Allow plugins to add their own config file to be resolved with the user's custom config
## [1.1.2] - 2019-08-14
### Fixed
- Fixes a bug with horizontal rules where they were displayed with a 2px border instead of a 1px border
- Fixes a bug with horizontal rules where they were rendered with default top/bottom margin
## [1.1.1] - 2019-08-09
### Fixed
- Fixes issue where values like `auto` would fail to make it through the default negative margin config
## [1.1.0] - 2019-08-06
### Added
- Added utilities for screenreader visibility
- Added utilities for placeholder color
- First, last, even, and odd child variants
- Disabled variant
- Visited variant
- Increase utility specificity using a scope instead of !important
- Add hover/focus variants for opacity by default
- Added `border-double` utility
- Support negative prefix for boxShadow and letterSpacing plugins
- Support passing config path via object
### Fixed
- Placeholders no longer have a default opacity
- Make horizontal rules visible by default
- Generate correct negative margins when using calc
## [1.0.6] - 2019-08-01
### Fixed
- Fixes issue where modifiers would mutate nested rules
## [1.0.5] - 2019-07-11
### Added
- Support built-in variants for utilities that include pseudo-elements
### Changed
- Update several dependencies, including postcss-js which fixes an issue with using `!important` directly in Tailwind utility plugins
## [1.0.4] - 2019-06-11
### Changed
- Increase precision of percentage width values to avoid 1px rounding issues in grid layouts
## [1.0.3] - 2019-06-01
### Changed
- Throws an error when someone tries to use `@tailwind preflight` instead of `@tailwind base`, this is the source of many support requests
## [1.0.2] - 2019-05-27
### Fixed
- Fixes a bug where `@screen` rules weren't bubbled properly when nested in plugins
## [1.0.1] - 2019-05-13
### Fixed
- Fixes a bug where global variants weren't properly merged
## [1.0.0] - 2019-05-13
No release notes
## [1.0.0-beta.10] - 2019-05-12
### Changed
- Use `9999` and `-9999` for `order-last` and `order-first` utilities respectively
## [1.0.0-beta.9] - 2019-05-12
### Added
- Add `bg-repeat-round` and `bg-repeat-space` utilities
- Add `select-all` and `select-auto` utilities
### Changed
- Make all utilities responsive by default
## [1.0.0-beta.8] - 2019-04-28
### Added
- Adds `responsive` variants for the new order utilities by default, should have been there all along
## [1.0.0-beta.7] - 2019-04-27
### Fixed
- Fixes a bug where you couldn't extend the margin config
## [1.0.0-beta.6] - 2019-04-27
### Added
- Added support for negative inset (`-top-6`, `-right-4`) and z-index (`-z-10`) utilities, using the same negative key syntax supported by the margin plugin
- Add missing fractions as well as x/12 fractions to width scale
- Add `order` utilities
- Add `cursor-text` class by default
### Changed
- Make it possible to access your fully merged config file in JS
### Removed
- Removed `negativeMargin` plugin, now the regular `margin` plugin supports generating negative classes (like `-mx-6`) by using negative keys in the config, like `-6`
## [1.0.0-beta.5] - 2019-04-18
### Changed
- Make it possible to disable all core plugins using `corePlugins: false`
- Make it possible to configure a single list of variants that applies to all utility plugins
- Make it possible to safelist which core plugins should be enabled
### Fixed
- Fix a bug where stroke and fill plugins didn't properly handle the next object syntax for color definitions
- Fix a bug where you couldn't have comments near `@apply` directives
## [1.0.0-beta.4] - 2019-03-29
### Added
- Add the `container` key to the scaffolded config file when generated with `--full`
### Changed
- Bumps node dependency to 8.9.0 so we can keep our default config file clean, 6.9.0 is EOL next month anyways
### Removed
- Removes `SFMono-Regular` from the beginning of the default monospace font stack, it has no italic support and Menlo looks better anyways
### Fixed
- Fixes an issue where the user's config object was being mutated during processing (only affects @bradlc 😅)
- Fixes an issue where you couldn't use a closure to define theme sections under `extend`
## [1.0.0-beta.3] - 2019-03-18
### Added
- Support lazy evaluation in `theme.extend`
### Changed
- Use lighter default border color
- Revert #745 and use `bolder` for strong tags by default instead of `fontWeight.bold`
## [1.0.0-beta.2] - 2019-03-17
### Changed
- Closures in the `theme` section of the config file are now passed a `theme` function instead of an object
### Fixed
- Fix issue where `@screen` didn't work at all 🙃
## [1.0.0-beta.1] - 2019-03-17
### Added
- New config file structure
- New expanded default color palette
- New default `maxWidth` scale
- Added utilities for `list-style-type` and `list-style-position`
- Added `break-all` utility
### Changed
- `object-position` utilities are now customizable under `theme.objectPosition`
- `cursor` utilities are now customizable under `theme.cursors`
- `flex-grow/shrink` utilities are now customizable under `theme.flexGrow/flexShrink`
- Default variant output position can be customized
- Extended default line-height scale
- Extended default letter-spacing scale
## [0.7.4] - 2019-01-23
### Changed
- Update our PostCSS related dependencies
### Fixed
- Fix bug where class names containing a `.`character had the responsive prefix added in the wrong place
## [0.7.3] - 2018-12-03
### Changed
- Update Normalize to v8.0.1
## [0.7.2] - 2018-11-05
### Added
- Add `--no-autoprefixer` option to CLI `build` command
## [0.7.1] - 2018-11-05
### Changed
- Update autoprefixer dependency
## [0.7.0] - 2018-10-31
### Added
- Registering new variants from plugins
- Variant order can be customized per module
- Added focus-within variant
- Fancy CLI updates
- Option to generate config without comments
- Make configured prefix optional when using @apply
- Improve Flexbox behavior in IE 10/11
### Changed
- Variant order in modules is now significant
- Normalize.css updated to v8.0.0
- Removed CSS fix for Chrome 62 button border radius change
## [0.6.6] - 2018-09-21
### Changed
- Promote `shadowLookup` from experiment to official feature
## [0.6.5] - 2018-08-18
### Fixed
- Fixes an issue where units were stripped from zero value properties
## [0.6.4] - 2018-07-16
### Fixed
- Fixes an issue where changes to your configuration file were ignored when using `webpack --watch`
## [0.6.3] - 2018-07-11
### Fixed
- Fixes an issue where `@tailwind utilities` generated no output
## [0.6.2] - 2018-03-11
### Added
- Added table layout utilities for styling tables
- Configuration can now be passed as an object
- Registering new variants from plugins (experimental)
- Allow `@apply`-ing classes that aren't defined but would be generated (experimental)
### Changed
- Default config file changes
## [0.6.1] - 2018-06-22
### Fixed
- Fix incorrect box-shadow syntax for the `.shadow-outline` utility 🤦‍♂️
## [0.6.0] - 2018-06-21
### Added
- Added border collapse utilities for styling tables
- Added more axis-specific overflow utilities
- Added `.outline-none` utility for suppressing focus styles
- Added `.shadow-outline` utility as an alternative to default browser focus styles
- Extended default padding, margin, negative margin, width, and height scales
- Enable focus and hover variants for more modules by default
### Changed
- Removed default `outline: none !important` styles from focusable but keyboard-inaccessible elements
- Moved screen prefix for responsive `group-hover` variants
- Default config file changes
## [0.5.3] - 2018-05-07
### Changed
- Improve sourcemaps for replaced styles like `preflight`
### Fixed
- Fix bug where informational messages were being logged to stdout during build, preventing the ability to use Tailwind's output in Unix pipelines
## [0.5.2] - 2018-03-29
### Fixed
- Fixes an issue with a dependency that had a security vulnerability
## [0.5.1] - 2018-03-13
### Removed
- Reverts a change that renamed the `.roman` class to `.not-italic` due to the fact that it breaks compatibility with cssnext: [postcss/postcss-selector-not#10](https://github.com/postcss/postcss-selector-not/issues/10). We'll stick with `.roman` for now with a plan to switch to `.not-italic` in another breaking version should that issue get resolved in postcss-selector-not.
## [0.5.0] - 2018-03-13
### Added
- Plugin system
- Added `.sticky position` utility
- Added `.cursor-wait` and `.cursor-move` utilities
- Added `.bg-auto` background size utility
- Background sizes are now customizable
- Support for active variants
- Better postcss-import support
- Configuration options for the `.container` component
### Changed
- The `.container` component is now a built-in plugin
- State variant precedence changes
- New config file keys
- `.overflow-x/y-scroll` now set `overflow: scroll` instead of `overflow: auto`
- `.roman` renamed to `.not-italic`
## [0.4.3] - 2018-03-13
### Changed
- Use `global.Object` to avoid issues with polyfills when importing the Tailwind config into other JS
## [0.4.2] - 2018-03-01
### Added
- Add support for using a function to define class prefixes in addition to a simple string
### Changed
- Improve the performance of @apply by using a lookup table instead of searching
### Fixed
- Fix an issue where borders couldn't be applied to `img` tags without specifying a border style
## [0.4.1] - 2018-01-22
### Changed
- Make default sans-serif font stack more future proof and safe to use with CSS `font` shorthand
- Replace stylefmt with Perfectionist to avoid weird stylelint conflicts
## [0.4.0] - 2017-12-15
### Added
- `@apply`'d classes can now be made `!important` explicitly
### Changed
- `@apply` now strips `!important` from any mixed in classes
- Default color palette tweaks
## [0.3.0] - 2017-12-01
### Added
- Enable/disable modules and control which variants are generated for each
- Focus variants
- Group hover variants
- New `@variants` at-rule
- Customize the separator character
- Missing config keys now fallback to their default values
- New utilities
### Changed
- Lists now have no margins by default
- `.pin` no longer sets width and height to 100%
Replace currentColor with currentcolor (lowercase) (#17510) Replaces `currentColor` with `currentcolor` (lowercase) to match what's defined in [CSS Color Module Level 4](https://www.w3.org/TR/css-color-4/#currentcolor-color) and [MDN](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#currentcolor_keyword) (see: https://github.com/mdn/content/pull/16592). --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-04-03 10:09:12 -04:00
- SVG `fill` no longer defaults to currentcolor
Merge changelogs (#15698) This PR makes sure all v3 and earlier versions are visible in the changelog as well as the v4 changelog entries.
2025-01-27 12:54:26 +01:00
## [0.2.2] - 2017-11-19
### Fixed
- Fix issue with dist files not being published due to bug in latest npm
## [0.2.1] - 2017-11-18
### Fixed
- Fix overly specific border-radius reset for Chrome 62 button styles
## [0.2.0] - 2017-11-17
### Added
- Add a custom prefix to all utilities
- Optionally make all utilities `!important`
- Round element corners independently
- Cascading border colors and styles
### Changed
- `auto` is no longer a hard-coded margin value
- The `defaultConfig` function is now a separate module
- Rounded utilities now combine position and radius size
- Border width utilities no longer affect border color/style
- `@apply` is now very strict about what classes can be applied
- Add `options` key to your config
- Spacing, radius, and border width utility declaration order changes
## [0.1.6] - 2017-11-09
### Fixed
- Fix CDN files not being published to npm
## [0.1.5] - 2017-11-08
### Changed
- Apply the same default placeholder styling that's applied to inputs to textareas
### Fixed
- Fix CLI tool not loading config files properly
## [0.1.4] - 2017-11-06
### Added
- Autoprefix dist assets for quick hacking and prototyping
- Add `my-auto`, `mt-auto`, and `mb-auto` margin utilities
- Add `sans-serif` to end of default `sans` font stack
### Changed
- If using Webpack, it will now watch your config file changes
- When running `tailwind init [filename]`, automatically append `.js` to filename if not present
- Support default fallback value in `config(...)` function, ie. `config('colors.blue', #0000ff)`
- Don't output empty media queries if Tailwind processes a file that doesn't use Tailwind
### Fixed
- Move list utilities earlier in stylesheet to allow overriding with spacing utilities
## [0.1.3] - 2017-11-02
### Added
- Add new `.scrolling-touch` and `.scrolling-auto` utilities for controlling inertial scroll behavior on WebKit touch devices
- Generate separate dist files for preflight, utilities, and tailwind for CDN usage
## [0.1.2] - 2017-11-01
### Changed
- Target Node 6.9.0 explicitly (instead of 8.6 implicitly) to support more users
### Fixed
- Fix issue with config option not being respected in `tailwind build`
## [0.1.1] - 2017-11-01
### Fixed
- Fix `tailwind build` CLI command not writing output files
## [0.1.0] - 2017-11-01
### Added
- Everything!
Prepare v4.1.12 release (#18728) Co-authored-by: Jordan Pittman <thecrypticace@gmail.com> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-08-14 14:35:49 +02:00
[unreleased]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.12...HEAD
[4.1.12]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.11...v4.1.12
Prepare 4.1.11 (#18397)
2025-06-26 12:43:17 +02:00
[4.1.11]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.10...v4.1.11
Prepare v4.1.10 (#18290)
2025-06-11 22:26:51 +02:00
[4.1.10]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.9...v4.1.10
Prepare v4.1.9 (#18285) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-06-11 15:57:38 +02:00
[4.1.9]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.8...v4.1.9
Release v4.1.8 (#18164) Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2025-05-28 17:01:27 +02:00
[4.1.8]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.7...v4.1.8
Prepare v4.1.7 release (#18040) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-15 15:31:18 +02:00
[4.1.7]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.6...v4.1.7
Prepare v4.1.6 release (#17951) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-05-09 15:39:18 +02:00
[4.1.6]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.5...v4.1.6
Prepare v4.1.5 release (#17830) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-30 16:57:44 +02:00
[4.1.5]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.4...v4.1.5
Prepare v4.1.4 release (#17669) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-14 17:32:30 +02:00
[4.1.4]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.3...v4.1.4
Prepare v4.1.3 release (#17563) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-04 19:54:23 +02:00
[4.1.3]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.2...v4.1.3
Prepare release v4.1.2 (#17530) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-04-03 17:36:42 +02:00
[4.1.2]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.1...v4.1.2
Prepare release v4.1.1 (#17503)
2025-04-02 11:27:58 +02:00
[4.1.1]: https://github.com/tailwindlabs/tailwindcss/compare/v4.1.0...v4.1.1
[4.1.0]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.17...v4.1.0
Prepare v4.0.17 release
2025-03-26 11:03:16 +01:00
[4.0.17]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.16...v4.0.17
Prepare v4.0.16 release (#17372) Prepare the 4.0.16 release. ~~Also added a commit to mark the `--value('…')` and `--modifier('…')` with literals strings as an experimental feature (aka not shipped in this PR). But we can revert that commit if we still want to ship it in 4.0.16 instead of 4.1.~~ --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-25 15:30:32 +01:00
[4.0.16]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.15...v4.0.16
Prepare v4.0.15 release (#17302) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md -->
2025-03-20 17:51:30 +01:00
[4.0.15]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.14...v4.0.15
Prepare v4.0.14 release (#17173)
2025-03-13 12:36:34 +01:00
[4.0.14]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.13...v4.0.14
Prepare release 4.0.13 (#17132)
2025-03-11 17:58:53 +01:00
[4.0.13]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.12...v4.0.13
Prepare v4.0.12 release (#17033) Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2025-03-07 12:38:53 +01:00
[4.0.12]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.11...v4.0.12
Prepare v4.0.11 release (#16987)
2025-03-06 12:09:39 +01:00
[4.0.11]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.10...v4.0.11
Prepare v4.0.10 release (#16963) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-03-05 18:32:15 +01:00
[4.0.10]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.9...v4.0.10
Prepare v4.0.9 release (#16804) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-25 17:33:28 +01:00
[4.0.9]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.8...v4.0.9
Prepare v4.0.8 release (#16713) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-21 16:06:37 +01:00
[4.0.8]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.7...v4.0.8
[4.0.7]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.6...v4.0.7
Prepare v4.0.6 (#16407)
2025-02-10 14:09:00 +01:00
[4.0.6]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.5...v4.0.6
Prepare v4.0.5 (#16373) <!-- 👋 Hey, thanks for your interest in contributing to Tailwind! **Please ask first before starting work on any significant new features.** It's never a fun experience to have your pull request declined after investing a lot of time and effort into a new feature. To avoid this from happening, we request that contributors create an issue to first discuss any significant new features. This includes things like adding new utilities, creating new at-rules, or adding new component examples to the documentation. https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md --> --------- Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2025-02-08 13:48:34 -05:00
[4.0.5]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.4...v4.0.5
Prepare v4.0.4 (#16302) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-02-06 15:18:11 +01:00
[4.0.4]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.3...v4.0.4
Prepare v4.0.3 (#16146)
2025-02-01 12:38:55 +01:00
[4.0.3]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.2...v4.0.3
Prepare for v4.0.2 release (#16131) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-31 19:30:36 +01:00
[4.0.2]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.1...v4.0.2
Prepare v4.0.1 release (#16018) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-29 20:14:35 +01:00
[4.0.1]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0...v4.0.1
Merge changelogs (#15698) This PR makes sure all v3 and earlier versions are visible in the changelog as well as the v4 changelog entries.
2025-01-27 12:54:26 +01:00
[4.0.0]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.10...v4.0.0
[4.0.0-beta.10]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.9...v4.0.0-beta.10
[4.0.0-beta.9]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.8...v4.0.0-beta.9
[4.0.0-beta.8]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.7...v4.0.0-beta.8
[4.0.0-beta.7]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.6...v4.0.0-beta.7
[4.0.0-beta.6]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.5...v4.0.0-beta.6
[4.0.0-beta.5]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.4...v4.0.0-beta.5
[4.0.0-beta.4]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.3...v4.0.0-beta.4
[4.0.0-beta.3]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.2...v4.0.0-beta.3
[4.0.0-beta.2]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-beta.1...v4.0.0-beta.2
[4.0.0-beta.1]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.36...v4.0.0-beta.1
[4.0.0-alpha.36]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.35...v4.0.0-alpha.36
[4.0.0-alpha.35]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.34...v4.0.0-alpha.35
[4.0.0-alpha.34]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.33...v4.0.0-alpha.34
[4.0.0-alpha.33]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.32...v4.0.0-alpha.33
[4.0.0-alpha.32]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.31...v4.0.0-alpha.32
[4.0.0-alpha.31]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.30...v4.0.0-alpha.31
[4.0.0-alpha.30]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.29...v4.0.0-alpha.30
[4.0.0-alpha.29]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.28...v4.0.0-alpha.29
[4.0.0-alpha.28]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.27...v4.0.0-alpha.28
[4.0.0-alpha.27]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.26...v4.0.0-alpha.27
[4.0.0-alpha.26]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.25...v4.0.0-alpha.26
[4.0.0-alpha.25]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.24...v4.0.0-alpha.25
[4.0.0-alpha.24]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.23...v4.0.0-alpha.24
[4.0.0-alpha.23]: https://github.com/tailwindlabs/tailwindcss/compare/v4.0.0-alpha.22...v4.0.0-alpha.23
[4.0.0-alpha.22]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.17...v4.0.0-alpha.22
[3.4.17]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.16...v3.4.17
[3.4.16]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.15...v3.4.16
[3.4.15]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.14...v3.4.15
[3.4.14]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.13...v3.4.14
[3.4.13]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.12...v3.4.13
[3.4.12]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.11...v3.4.12
[3.4.11]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.10...v3.4.11
[3.4.10]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.9...v3.4.10
[3.4.9]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.8...v3.4.9
[3.4.8]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.7...v3.4.8
[3.4.7]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.6...v3.4.7
[3.4.6]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.5...v3.4.6
[3.4.5]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.4...v3.4.5
[3.4.4]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.3...v3.4.4
[3.4.3]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.2...v3.4.3
[3.4.2]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.1...v3.4.2
[3.4.1]: https://github.com/tailwindlabs/tailwindcss/compare/v3.4.0...v3.4.1
[3.4.0]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.7...v3.4.0
[3.3.7]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.6...v3.3.7
[3.3.6]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.5...v3.3.6
[3.3.5]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.4...v3.3.5
[3.3.4]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.3...v3.3.4
[3.3.3]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.2...v3.3.3
[3.3.2]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.1...v3.3.2
[3.3.1]: https://github.com/tailwindlabs/tailwindcss/compare/v3.3.0...v3.3.1
[3.3.0]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.7...v3.3.0
[3.2.7]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.6...v3.2.7
[3.2.6]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.5...v3.2.6
[3.2.5]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.4...v3.2.5
[3.2.4]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.3...v3.2.4
[3.2.3]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.2...v3.2.3
[3.2.2]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.1...v3.2.2
[3.2.1]: https://github.com/tailwindlabs/tailwindcss/compare/v3.2.0...v3.2.1
[3.2.0]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.8...v3.2.0
[3.1.8]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.7...v3.1.8
[3.1.7]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.6...v3.1.7
[3.1.6]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.5...v3.1.6
[3.1.5]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.4...v3.1.5
[3.1.4]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.3...v3.1.4
[3.1.3]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.2...v3.1.3
[3.1.2]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.1...v3.1.2
[3.1.1]: https://github.com/tailwindlabs/tailwindcss/compare/v3.1.0...v3.1.1
[3.1.0]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.24...v3.1.0
[3.0.24]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.23...v3.0.24
[3.0.23]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.22...v3.0.23
[3.0.22]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.21...v3.0.22
[3.0.21]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.20...v3.0.21
[3.0.20]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.19...v3.0.20
[3.0.19]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.18...v3.0.19
[3.0.18]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.17...v3.0.18
[3.0.17]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.16...v3.0.17
[3.0.16]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.15...v3.0.16
[3.0.15]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.14...v3.0.15
[3.0.14]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.13...v3.0.14
[3.0.13]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.12...v3.0.13
[3.0.12]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.11...v3.0.12
[3.0.11]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.10...v3.0.11
[3.0.10]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.9...v3.0.10
[3.0.9]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.8...v3.0.9
[3.0.8]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.7...v3.0.8
[3.0.7]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.6...v3.0.7
[3.0.6]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.5...v3.0.6
[3.0.5]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.4...v3.0.5
[3.0.4]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.3...v3.0.4
[3.0.3]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.2...v3.0.3
[3.0.2]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.1...v3.0.2
[3.0.1]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.0...v3.0.1
[3.0.0]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.0-alpha.2...v3.0.0
[3.0.0-alpha.2]: https://github.com/tailwindlabs/tailwindcss/compare/v3.0.0-alpha.1...v3.0.0-alpha.2
[3.0.0-alpha.1]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.19...v3.0.0-alpha.1
[2.2.19]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.18...v2.2.19
[2.2.18]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.17...v2.2.18
[2.2.17]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.16...v2.2.17
[2.2.16]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.15...v2.2.16
[2.2.15]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.14...v2.2.15
[2.2.14]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.13...v2.2.14
[2.2.13]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.12...v2.2.13
[2.2.12]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.11...v2.2.12
[2.2.11]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.10...v2.2.11
[2.2.10]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.9...v2.2.10
[2.2.9]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.8...v2.2.9
[2.2.8]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.7...v2.2.8
[2.2.7]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.6...v2.2.7
[2.2.6]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.5...v2.2.6
[2.2.5]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.4...v2.2.5
[2.2.4]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.3...v2.2.4
[2.2.3]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.2...v2.2.3
[2.2.2]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.1...v2.2.2
[2.2.1]: https://github.com/tailwindlabs/tailwindcss/compare/v2.2.0...v2.2.1
[2.2.0]: https://github.com/tailwindlabs/tailwindcss/compare/v2.1.4...v2.2.0
[2.1.4]: https://github.com/tailwindlabs/tailwindcss/compare/v2.1.3...v2.1.4
[2.1.3]: https://github.com/tailwindlabs/tailwindcss/compare/v2.1.2...v2.1.3
[2.1.2]: https://github.com/tailwindlabs/tailwindcss/compare/v2.1.1...v2.1.2
[2.1.1]: https://github.com/tailwindlabs/tailwindcss/compare/v2.1.0...v2.1.1
[2.1.0]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.4...v2.1.0
[2.0.4]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.3...v2.0.4
[2.0.3]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.2...v2.0.3
[2.0.2]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.1...v2.0.2
[2.0.1]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0...v2.0.1
[2.0.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.6...v2.0.0
[2.0.0-alpha.25]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.24...v2.0.0-alpha.25
[2.0.0-alpha.24]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.23...v2.0.0-alpha.24
[2.0.0-alpha.23]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.22...v2.0.0-alpha.23
[2.0.0-alpha.22]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.21...v2.0.0-alpha.22
[2.0.0-alpha.21]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.20...v2.0.0-alpha.21
[2.0.0-alpha.20]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.19...v2.0.0-alpha.20
[2.0.0-alpha.19]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.18...v2.0.0-alpha.19
[2.0.0-alpha.18]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.17...v2.0.0-alpha.18
[2.0.0-alpha.17]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.16...v2.0.0-alpha.17
[2.0.0-alpha.16]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.15...v2.0.0-alpha.16
[2.0.0-alpha.15]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.14...v2.0.0-alpha.15
[2.0.0-alpha.14]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.13...v2.0.0-alpha.14
[2.0.0-alpha.13]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.12...v2.0.0-alpha.13
[2.0.0-alpha.12]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.11...v2.0.0-alpha.12
[2.0.0-alpha.11]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.10...v2.0.0-alpha.11
[2.0.0-alpha.10]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.9...v2.0.0-alpha.10
[2.0.0-alpha.9]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.8...v2.0.0-alpha.9
[2.0.0-alpha.8]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.7...v2.0.0-alpha.8
[2.0.0-alpha.7]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.6...v2.0.0-alpha.7
[2.0.0-alpha.6]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.5...v2.0.0-alpha.6
[2.0.0-alpha.5]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.4...v2.0.0-alpha.5
[2.0.0-alpha.4]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.3...v2.0.0-alpha.4
[2.0.0-alpha.3]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.2...v2.0.0-alpha.3
[2.0.0-alpha.2]: https://github.com/tailwindlabs/tailwindcss/compare/v2.0.0-alpha.1...v2.0.0-alpha.2
[1.9.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.5...v1.9.6
[2.0.0-alpha.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.5...v2.0.0-alpha.1
[1.9.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.4...v1.9.5
[1.9.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.3...v1.9.4
[1.9.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.2...v1.9.3
[1.9.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.1...v1.9.2
[1.9.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.9.0...v1.9.1
[1.9.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.13...v1.9.0
[1.8.13]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.12...v1.8.13
[1.8.12]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.11...v1.8.12
[1.8.11]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.10...v1.8.11
[1.8.10]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.9...v1.8.10
[1.8.9]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.8...v1.8.9
[1.8.8]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.7...v1.8.8
[1.8.7]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.6...v1.8.7
[1.8.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.5...v1.8.6
[1.8.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.4...v1.8.5
[1.8.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.3...v1.8.4
[1.8.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.2...v1.8.3
[1.8.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.1...v1.8.2
[1.8.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.8.0...v1.8.1
[1.8.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.6...v1.8.0
[1.7.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.5...v1.7.6
[1.7.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.4...v1.7.5
[1.7.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.3...v1.7.4
[1.7.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.2...v1.7.3
[1.7.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.1...v1.7.2
[1.7.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.7.0...v1.7.1
[1.7.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.6.3...v1.7.0
[1.6.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.6.2...v1.6.3
[1.6.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.6.1...v1.6.2
[1.6.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.6.0...v1.6.1
[1.6.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.5.2...v1.6.0
[1.5.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.5.1...v1.5.2
[1.5.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.5.0...v1.5.1
[1.5.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.6...v1.5.0
[1.4.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.5...v1.4.6
[1.4.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.4...v1.4.5
[1.4.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.3...v1.4.4
[1.4.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.2...v1.4.3
[1.4.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.1...v1.4.2
[1.4.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.4.0...v1.4.1
[1.4.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.3.5...v1.4.0
[1.3.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.3.4...v1.3.5
[1.3.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.3.3...v1.3.4
[1.3.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.3.1...v1.3.3
[1.3.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.3.0...v1.3.1
[1.3.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0...v1.3.0
[1.2.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.1.4...v1.2.0
[1.2.0-canary.8]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0-canary.7...v1.2.0-canary.8
[1.2.0-canary.7]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0-canary.6...v1.2.0-canary.7
[1.2.0-canary.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0-canary.5...v1.2.0-canary.6
[1.2.0-canary.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0-canary.4...v1.2.0-canary.5
[1.2.0-canary.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0-canary.3...v1.2.0-canary.4
[1.1.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.1.3...v1.1.4
[1.2.0-canary.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.2.0-canary.0...v1.2.0-canary.1
[1.1.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.1.2...v1.1.3
[1.2.0-canary.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.1.2...v1.2.0-canary.0
[1.1.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.1.1...v1.1.2
[1.1.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.1.0...v1.1.1
[1.1.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.6...v1.1.0
[1.0.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.5...v1.0.6
[1.0.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.4...v1.0.5
[1.0.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.3...v1.0.4
[1.0.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.2...v1.0.3
[1.0.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.1...v1.0.2
[1.0.1]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0...v1.0.1
[1.0.0]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.10...v1.0.0
[1.0.0-beta.10]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.9...v1.0.0-beta.10
[1.0.0-beta.9]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.8...v1.0.0-beta.9
[1.0.0-beta.8]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.7...v1.0.0-beta.8
[1.0.0-beta.7]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.6...v1.0.0-beta.7
[1.0.0-beta.6]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.5...v1.0.0-beta.6
[1.0.0-beta.5]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.4...v1.0.0-beta.5
[1.0.0-beta.4]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.3...v1.0.0-beta.4
[1.0.0-beta.3]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.2...v1.0.0-beta.3
[1.0.0-beta.2]: https://github.com/tailwindlabs/tailwindcss/compare/v1.0.0-beta.1...v1.0.0-beta.2
[1.0.0-beta.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.7.4...v1.0.0-beta.1
[0.7.4]: https://github.com/tailwindlabs/tailwindcss/compare/v0.7.3...v0.7.4
[0.7.3]: https://github.com/tailwindlabs/tailwindcss/compare/v0.7.2...v0.7.3
[0.7.2]: https://github.com/tailwindlabs/tailwindcss/compare/v0.7.1...v0.7.2
[0.7.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.7.0...v0.7.1
[0.7.0]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.6...v0.7.0
[0.6.6]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.5...v0.6.6
[0.6.5]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.4...v0.6.5
[0.6.4]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.3...v0.6.4
[0.6.3]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.2...v0.6.3
[0.6.2]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.1...v0.6.2
[0.6.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.6.0...v0.6.1
[0.6.0]: https://github.com/tailwindlabs/tailwindcss/compare/v0.5.3...v0.6.0
[0.5.3]: https://github.com/tailwindlabs/tailwindcss/compare/v0.5.2...v0.5.3
[0.5.2]: https://github.com/tailwindlabs/tailwindcss/compare/v0.5.1...v0.5.2
[0.5.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.5.0...v0.5.1
[0.5.0]: https://github.com/tailwindlabs/tailwindcss/compare/v0.4.3...v0.5.0
[0.4.3]: https://github.com/tailwindlabs/tailwindcss/compare/v0.4.2...v0.4.3
[0.4.2]: https://github.com/tailwindlabs/tailwindcss/compare/v0.4.1...v0.4.2
[0.4.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.4.0...v0.4.1
[0.4.0]: https://github.com/tailwindlabs/tailwindcss/compare/v0.3.0...v0.4.0
[0.3.0]: https://github.com/tailwindlabs/tailwindcss/compare/v0.2.2...v0.3.0
[0.2.2]: https://github.com/tailwindlabs/tailwindcss/compare/v0.2.1...v0.2.2
[0.2.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.2.0...v0.2.1
[0.2.0]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.6...v0.2.0
[0.1.6]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.5...v0.1.6
[0.1.5]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.4...v0.1.5
[0.1.4]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.3...v0.1.4
[0.1.3]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.2...v0.1.3
[0.1.2]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.1...v0.1.2
[0.1.1]: https://github.com/tailwindlabs/tailwindcss/compare/v0.1.0...v0.1.1
[0.1.0]: https://github.com/tailwindlabs/tailwindcss/releases/tag/v0.1.0
Reference in a new issue Copy permalink