* remove `any` data type for decoration color plugin
The main reason for the `any` type is so that we don't have to parse the
value and can assume that this plugin handles "any" value you give it.
This is useful because `decoration-[var(--something)]` would be
correctly translated to the correct decoration property. However, we
introduce another plugin with the same `decoration` prefix.
This means that now both `textDecorationColor` and
`textDecorationThickness` have the same base utility name: `decoration`.
- `textDecorationColor` had ['color', 'any']
- `textDecorationThickness` had ['length', 'percentage']
This means that `3px` fit both in the `length` data type of the
`textDecorationThickness` plugin and in the `any` data type of the
`textDecorationColor` plugin.
Removing the `any` fixes this.
TL;DR: Only have `any` when there are no conflicting utility names.
* remove utility that doesn't generate css
Having `decoration-[var(--abc)]` is ambiguous because there are multiple
plugins that have a `decoration` utility name. In order for this to work
you have to prefix it with the type: `decoration-[color:var(--abc)]`
which is already tested in this file.
* fix modifiers for arbitrary properties
The main issue was that we are splitting on the separator and popping
the last section of to know the _base_ utility. However, in this case it
would be something like `markers]` which is incorrect.
Instead we only split by the separator and ignore the separtor if it
exists between square brackets.
* add tests for modifiers + arbitrary values that contain the separator
* Basic implementation + some failing tests for edge cases
* Use asClass instead of nameClass
* Solve edge cases around content with colons
* Avoid duplicating work when parsing arbitrary properties
* Update changelog
* add ::file-selector-button reset
Otherwise you have to apply `file:border-solid` which you don't have to
do for other elements with borders.
See: https://play.tailwindcss.com/EvtdftCPt6
* update changelog
* add normalizeScreens function
This will allow us to normalize the various kinds of inputs to a stable
version that is consistent regardless of the input.
* use normalized screens
* add dedicated test for new tuple syntax
* make test consistent with other tests
While working on the normalizeScreens feature, some tests started
failing (the one with multiple screens), while looking at them I made
them consistent with the rest of the codebase.
* add test to ensure consistent order in screens output
* update changelog
* Update CHANGELOG.md
* Update CHANGELOG.md
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
Historically we've only included `fill-current` and `stroke-current` due to file size considerations, and recommended combining them with text color utilities like this:
```html
<svg class="fill-current text-blue-500">
```
With the JIT engine, there's no real reason for this anymore, so this PR enables all colors by default, allowing you to write this out of the box instead:
```html
<svg class="fill-blue-500">
```
Giddy up.
* Add new outline style, color, width and offset utilities
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Remove old `outline` property from default config
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Tweak order of outline plugins
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Revert to previous `outline-none` styles
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Drop quotes from outline property
* Add offset back to `outline-none` utility
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* call function for colors that are not in colors
* add all color related thingies
* transformThemeValue in a very verbose way
* handle functions by default
* cleanup, make sure we handle functions everywhere
* update changelog
Co-authored-by: Bill Criswell <bill_criswell@comcast.com>
