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>
Prior to this PR, we'd put all of the `@defaults` (the CSS variables and
stuff) _after_ the `base` rules. This creates an issue when using
`optimizeUniversalDefaults` with CSS that looks like this:
```css
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer base {
input {
@apply shadow;
}
}
```
…because the default shadow stuff ends up after the base `input` rules,
so the generated styles are like this:
```css
input {
--tw-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1);
--tw-shadow-colored: 0 1px 3px 0 var(--tw-shadow-color),
0 1px 2px -1px var(--tw-shadow-color);
box-shadow: var(--tw-ring-offset-shadow, 0 0 #0000), var(--tw-ring-shadow, 0 0 #0000),
var(--tw-shadow);
}
input {
--tw-ring-offset-shadow: 0 0 #0000;
--tw-ring-shadow: 0 0 #0000;
--tw-shadow: 0 0 #0000;
--tw-shadow-colored: 0 0 #0000;
}
```
This means all of the actual shadow values for the input are reset and
the shadow doesn't work.
Fixes https://github.com/tailwindlabs/tailwindcss/issues/14426.
Lots of failing tests right because this changes a ton of stuff, albeit
in a totally inconsequential way. @thecrypticace if you could update
these for me this week that would be a huge help, just banging this fix
out quick while the kids are napping 😴
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* 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>
* 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
* drop empty lines when diffing output
* replace expected css with optimized lightningcss output
Lightning CSS generates a more optimal CSS output.
Right now the tests are setup in a way that both the generated css and
expected css are run through `lightningcss` to make sure that the output
is concistent for the `stable` and `oxide` engines. But this also means
that the expected output _could_ be larger (aka not optimized) and still
matches (after it runs through lightningcss).
By replacing this with the more optimal output we achieve a few things:
1. This better reflects reality since we will be using `lightningcss`.
2. This gets rid of unnecessary css.
3. Removed code!
* Run test suite against both engines
* make eslint happy
* only run `stable` tests on Node 12
* use normal expectation instead of snapshot file
When we run the tests only against `stable` (for node 12), then the
snapshots exists for the `Oxide` build. They are marked as `obsolete`
and will cause the `npm run test` script to fail. Sadly.
Inlined them for now, but ideally we make those tests more blackbox-y so
that we test that we get source maps and that we can map the sourcemap
back to the input files (without looking at the actual annotations).
* properly indent inline css
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
This will reduce the amount of different test "implementations" and
should further unify/normalise the tests. Some tests are very large and
can be split up more but this is a start in the right direction.
One of the biggest benefits is that changes in the tests file re-trigger
a jest run in watch mode. A change in the HTML/CSS file won't.
* Handle duplicate atrules without children
We assumed that all At Rule nodes had children. Including ones that do not and should not — for example `@import url(…);`. Since this is not the case we’ll skip adding children for nodes that don’t have any.
* Update changelog
Co-authored-by: Jordi Marimon Palarea <jordimarimon7@gmail.com>
* move `./tests/jit` to `./tests`
* make tests consistent
Abstracted a `run` function and some syntax highlighting helpers for
`html`, `css` and `javascript`.
