* improve collapsing of duplicate properties
In theory, we don't have to do anything because the browser is smart
enough to figure everything out. However, leaving in duplicate
properties is not that ideal for file size.
Our previous method was pretty simple: if you see a declaration you
already saw in this rule, delete the previous one and keep the current
one.
This works pretty well, but this gets rid of **all** the declarations
with the same property. This is not great for overrides for older
browsers.
In a perfect world, we can handle this based on your target browser but
this is a lot of unnecessary complexity and will slow things down
performance wise.
Alternative, we improved the solution by being a bit smarter:
1. Delete duplicate declarations that have the same property and value
(this will get rid of **exact** duplications).
2. Delete declarations with the same property and the same **unit**.
This means that we will reduce this:
```css
.example {
height: 50%;
height: 100px;
height: 20vh;
height: 30%;
height: 50px;
height: 30vh;
transform: var(--value);
transform: var(--value);
}
```
To:
```diff-css
.example {
- height: 50%; /* Another height exists later with a `%` unit */
- height: 100px; /* Another height exists later with a `px` unit */
- height: 20vh; /* Another height exists later with a `vh` unit */
height: 30%;
height: 50px;
height: 30vh;
- transform: var(--value); /* Value is too complex, but is **exactly** the same as the one below */
transform: var(--value);
}
```
This will reduce the values that we are 100% sure that can be safely
removed. This will still result in some overrides but the browser can
handle those for you.
Fixes: #6844
* update changelog
* ensure apply of rule inside atrule works
If that atrule happens to contain another rule that is technically
unrelated.
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* update changelog
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* ensure that strangely used jsx with interpolation gets detected
Co-authored-by: Luke Warlow <projects@warlow.dev>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* update changelog
Co-authored-by: Luke Warlow <projects@warlow.dev>
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* only generate variants for non-user layers
If you have the following css:
```css
@tailwind utilities;
.foo {
color: red;
}
```
And you HTML looks like this:
```html
<div class="hover:foo"></div>
```
Then the output should _not_ generate a `.hover\:foo {}` class.
* ensure that you can apply user csss (without variants)
* update changelog
* remove early return so that all plugins are handled
We had an early return so that once a plugin was matched, that we could
stop running the code through the other plugins. However, in this case
we have an issue that user defined css is technically also a plugin.
This means that:
- `bg-green-light`
Would check for:
- `bg-green-light` (no hit, continue)
- `bg-green` (Hit! Don't execute next plugins)
- `bg` (This is the one that would have generated `bg-green-light`)
We tested this change and it doesn't seem to have an impact functionally
and also not really performance wise.
* update changelog
* insert in correct spot
We were injecting the always on `@tailwind defaults` layer at the beginning of
the file. However, if a `@tailwind base` layer is available, then that
will now be injected _after_ the defaults layer. The base layer does
contain some reset that are now overriding the defaults we set.
So now we will:
- Insert the `@tailwind defaults` layer at the beginning of the file
_if_ there is no `@tailwind base`
- Insert the `@tailwind defaults` layer after the `@tailwind base` layer
if it exists.
* update changelog
