This works around an issue in Chrome where `::selection` does not read
from variables defined on `::selection` thus breaking all uses of color
utilities with the selection variant. e.g. `selection::bg-red-200`.
We now add a fallback value of `1` to all uses of
`var(--tw-bg-opacity)`, `var(--tw-text-opacity)`,
`var(--tw-border-opacity)`, etc… since Chrome treats the variable as if
it did not exist because it's not defined on the parent.
In Chrome 131 (until the change is rolled back) existing utilities like
these will not work:
- `selection:text-opacity-50`
- `selection:[--tw-text-opacity:0.5]`
Fixes#15000
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* remove all oxide related code
* Update lightningcss to version 1.24.1
* update tests to match bumped Lightning CSS output
---------
Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
* replace `env.OXIDE` with global `__OXIDE__`
This will allow us to replace the `__OXIDE__` at build time, and fully
remove the branches from the final code so that there is not even any
reference to `@tailwindcss/oxide` on the stable engine.
* update changelog
* use `env.ENGINE` in integration tests
* drop oxide branching for the PostCSS plugin for now
This is currently a redirect to the same file, so doesn't hurt.
* Enable better dead-code elimination
* Update CLI tests
Fix indentation
* Fix indentation
---------
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* disable color opacity plugins by default for the `oxide` engine
* update tests to reflect this change in the `oxide` engine
* update changelog
* reflect changes in integration tests
* bump lightningcss
* use `lightningcss` in the main PostCss Plugin
* use lightningcss in our custom matchers
Now that we are using `lightningcss` and nesting in the new `oxide`
engine, the generated output _will_ be different in the majority of test
cases.
Using a combination of `prettier` and `lightningcss` will make the
output consistent.
The moment we are fully using the `oxide` engine, we can drop
`lightningcss` or `prettier` again to improve the performance of the
tests.
* update tests to apply `lightningcss` related changes
* update changelog
* add `lightningcss` and `browserslist` as dev dependencies to stable package.json
* only use `lightningcss` in tests (without prettier)
We will only fallback to prettier if lightningcss fails somehow.
* apply side effect chagnes due to only using lightningcss for tests
* make CI happy (integration tests)
Apply changes to integration tests now that we are using lightningcss
* transform `lightningcss` for Node 12 when running tests
* run prettier on failing tests for `toMatchFormattedCss`
This will result in better diffs because diffs are typically per block
and/or per line. But lightningcss will simplify certain selectors and
the diff won't be as clear.
We will only apply the prettier formatting for failing tests in the diff
view so that diffs are cleaner and we don't pay for the additional
prettier calls when tests pass.
* Add content glob integration tests
* Use tagged version in parcel integration tests
* Upgrade postcss-cli integration tests
* upgrade integration test deps
* Fix CS
* Fix tests
* Update lockfile
* Fix vite test in CI
