* add tests for spaced around operators in CSS math functions
* fix CSS math functons besides calc not getting the love they deserve
* improve comment
* update changelog
* update changelog
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* Fix typo
* Support alpha modifier for theme color values
* Eliminate redundant object creation in resolveFunctionKeys
Building an object of N keys incrementally using Object.reduce + splat results in N intermediate objects. We should just create one object and assign each key.
* Switch to inline theme values in theme fn in config
* Add test case
And fix typos that were definitely not there
* Update changelog
* WIP
* use correct separator
* run all tests
* Fix regex
* add a few more tests
* name the experimental feature flag `variantGrouping`
* update changelog
* rename test file `variant-grouping`
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
* register arbitrary variants
With the new `addVariant` API, we have a beautiful way of creating new
variants.
You can use it as:
```js
addVariant('children', '& > *')
```
Now you can use the `children:` variant. The API uses a `&` as a
reference for the candidate, which means that:
```html
children:pl-4
```
Will result in:
```css
.children\:pl-4 > * { .. }
```
Notice that the `&` was replaced by `.children\:pl-4`.
We can leverage this API to implement arbitrary variants, this means
that you can write those `&>*` (Notice that we don't have spaces) inside
a variant directly. An example of this can be:
```html
<ul class="[&>*]:underline">
<li>A</li>
<li>B</li>
<li>C</li>
</ul>
```
Which generates the following css:
```css
.\[\&\>\*\]\:underline > * {
text-decoration-line: underline;
}
```
Now all the children of the `ul` will have an `underline`. The selector
itself is a bit crazy since it contains the candidate which is the
selector itself, it is just escaped.
* add tests for arbitrary variants
This still requires some work to the `defaultExtractor` to make sure it
all works with existing code.
* update changelog
* Fix candidate detection for arbitrary variants
* Refactor
* Add support for at rules
* Add test for attribute selectors
* Fix test
* Add attribute selector support
* Split top-level comma parsing into a generalized splitting routine
We can now split on any character at the top level with any nesting. We don’t balance brackets directly here but this is probably “enough”
* Split variants by separator at the top-level only
This means that the separator has to be ouside of balanced brackets
* Fix extraction when using custom variant separators
* Support custom separators when top-level splitting variants
* Add a second multi-character separator test
* Split tests for at-rule and at-rule with selector changes
* Add nested at-rule tests
* Fix space-less at-rule parsing in addVariant
* Add test for using with `@apply`
Co-authored-by: Jordan Pittman <jordan@cryptica.me>
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
* Add failing test cases
* Flatten finalizeSelector code
* Use AST operations to format selector classes
With this change we only parse the selector once and operate on the AST until we need to turn it back into a selector. In addition this lets us solve an issue where .replace(…) did the wrong thing because it doesn’t understand that .base and .base-foo are two different classes
* Remove extraneous, non-matching selectors from utilities
* Update changelog
* ensure the `percentage` data type is validated correctly
When checking for our data types, we have to make sure that each part is
correct, this wasn't happening for the `percentage` data type, which
meant that `top_right_50%` was a valid percentage value because it ended
in `%` which is not correct.
Because of this, the generated code was non-existent because we got a
warning:
The class `bg-[top_right_50%]` is ambiguous and matches multiple utilities.
Use `bg-[length:top_right_50%]` for `background-size: top right 50%`
Use `bg-[position:top_right_50%]` for `background-position: top right 50%`
If this is content and not a class, replace it with `bg-[top_right_50%]` to silence this warning.
But this is not correct because this can never be a valid background
size due to the `top right` section.
This fixes it by validating each part individually, and now we get
generated css.
* update changelog
* Fix context reuse test
* Don't update files with at-apply when content changes
* Prevent at-apply directives from creating new contexts
* Rework apply to use local postcss root
We were storing user CSS in the context so we could use it with apply. The problem is that this CSS does not get updated on save unless it has a tailwind directive in it resulting in stale apply caches. This could result in either stale generation or errors about missing classes.
* Don’t build local cache unless `@apply` is used
* Update changelog
* Replace chalk with picocolors
Already used in latest postcss, autoprefixer and browserslist versions.
See https://github.com/alexeyraspopov/picocolors
* Update `dim` function
Co-authored-by: Brad Cornes <bradlc41@gmail.com>
* Preserve source maps for `@apply`
* Overwrite the source for all cloned descendants
* Preserve source maps when expanding defaults
* Verify that source maps are correctly generated
* Update changelog
* Add failing tests for negative utility detection
We're not generating them properly in all cases, when using at-apply we sometimes crash, and safelisting doesn't currently work as expected.
* Refactor
* Generate utilities for negatives before and after the prefix
* Properly detect negative utilities with prefixes in the safelist
* Refactor test a bit
* Add class list tests
* Update changelog
Default's declarations are now processed and merged even when there is no tailwind base directive included in the stylesheet. Without this applying tailwind utilities in css modules would break if they relied on defaults rules.
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* 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 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>
* 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>
* mark `prefix` as a function as a breaking change
* remove `prefix` as a function related code
* remove `prefix` as a function related tests
* update changelog
* fix incorrect comment
Probably messed this up in another PR, so just a bit of cleaning.
* implement a formatVariantSelector function
This will be used to eventually simplify the addVariant API.
The idea is that it can take a list of strings that define a certain
format. Then it squashes everything to a single format how you would
expect it.
E.g.:
Input:
- '&:hover'
- '&:focus'
- '.dark &'
- ':merge(.group):hover &'
- ':merge(.group):focus &'
Output:
- ':merge(.group):focus:hover .dark &:focus:hover'
The API here is:
- `&`, this means "The parent" or "The previous selector" (you can
think of it like if you are using nested selectors)
- `:merge(.group)`, this means insert a `.group` if it doesn't exist
yet, but if it does exist already, then merge the new value with the
old value. This allows us to merge group-focus, group-hover into a
single `.group:focus:hover ...`
* add new `format`, `withRule` and `wrap` API for addVariant
* implement backwards compatibility
This will ensure that the backwards compatibility for `modifySelectors`
and direct mutations to the `container` will still work.
We will try to capture the changes made to the `rule.selector`, we will
also "backup" the existing selector. This allows us to diff the old and
new selectors and determine what actually happened.
Once we know this, we can restore the selector to the "old" selector and
add the diffed string e.g.: `.foo &`, to the `collectedFormats` as if
you called `format()` directly. This is a bunch of extra work, but it
allows us to be backwards compatible.
In the future we could also warn if you are using `modifySelectors`, but
it is going to be a little bit tricky, because usually that's
implemented by plugin authors and therefore you don't have direct
control over this. Maybe we can figure out the plugin this is used in
and change the warning somehow?
* fix incorrect test
This was clearly a bug, keyframes should not include escaped variants at
all. The reason this is here in the first place is because the nodes in
a keyframe are also "rule" nodes.
* swap the order of pseudo states
The current implementation had a strange side effect, that resulted in
incorrect class definitions. When you are combining the `:hover` and
`:focus` event, then there is no difference between `:hover:focus` and
`:focus:hover`.
However, when you use `:hover::file-selector-button` or `::file-selector-button:hover`,
then there is a big difference. In the first place, you can hover over the full file input
to apply changes to the `File selector button`.
In the second scenario you have to hover over the `File selector button` itself to apply changes.
You can think of it as function calls:
- focus(hover(text-center))
What you would expect is something like this:
`.focus\:hover\:text-center:hover:focus`, where `hover` is on the
inside, and `focus` is on the outside. However in the current
implementation this is implemented as
`.focus\:hover\:text-cener:focus:hover`
* add more variant tests for the new API
* update parallel variants tests to make use of new API
* implement core variants with new API
* simplify/cleanup existing plugin utils
We can get rid of this because we drastically simplified the new
addVariant API.
* add addVariant shorthand signature
The current API looks like this:
```js
addVariant('name', ({ format, wrap }) => {
// Wrap in an atRule
wrap(postcss.atRule({ name: 'media', params: '(prefers-reduced-motion: reduce)' }))
// "Mutate" the selector, for example prepend `.dark`
format('.dark &')
})
```
It is also pretty common to have this:
```js
addVariant('name', ({ format }) => format('.dark &'))
```
So we simplified this to:
```js
addVariant('name', '.dark &')
```
It is also pretty common to have this:
```js
addVariant('name', ({ wrap }) => wrap(postcss.atRule({ name: 'media', params: '(prefers-reduced-motion: reduce)' })))
```
So we simplified this to:
```js
addVariant('name', '@media (prefers-reduced-motion: reduce)')
```
* improve fontVariantNumeric implementation
We will use `@defaults`, so that only the resets are injected for the
utilities we actually use.
* fix typo
* allow for nested addVariant shorthand
This will allow to write something like:
```js
addVariant('name', `
@supports (hover: hover) {
@media (print) {
&:hover
}
}
`)
// Or as a one-liner
addVariant('name', '@supports (hover: hover) { @media (print) { &:hover } }')
```
* update changelog
* WIP
* Add failing test for negating default values
* Add dynamic negative value opt-in (#5713)
* Add `supportsNegativeValues` plugin option
* Update `getClassList` to support dynamic negative values
* Add test for using a negative scale value with a plugin that does not support dynamic negative values
* Support dynamic negation of `DEFAULT` values (#5718)
* Add test case
Co-authored-by: Brad Cornes <bradlc41@gmail.com>
