* remove unused `withRule`
* ensure all ::before and ::after elements have content
* update --tw-content for the content plugin
* simplify `before` and `after` variants
* update tests, to reflect changes
* make new `format` and `wrap` API's private for now
* allow returning a format string from `addVariant` callback
* add `content: var(--tw-content)` for before/after variants
* update tests to add `content: var(--tw-content)`
* 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
* utilities and tests in place for textDecorationColor and textDecorationOpacity
* change 'backgroundColor' to 'textDecorationColor' in corePlugin declaration for latter
* remove explicit textDecorationOpacity utility (the JIT slash syntax suffices)
Co-authored-by: Michael Warner <michaelwarner@Michaels-MacBook-Pro.local>
This adds `grow-*` and `shrink-*` utilities as aliases for `flex-grow-*` and `flex-shrink-*` since those names are unnecessarily verbose. We will stop documenting the long form ones and consider them deprecated.
```diff
- <div class="flex-grow-0 flex-shrink">
+ <div class="grow-0 shrink">
```
* 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>
* fix incorrect logic for validating content paths
* remove `includeRules` helper
* generate keyframes as part of the animate plugin
* add matchUtilities
* splitup `variantPlugins` and `corePlugins`
* Add `[open]` variant
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-Authored-By: Sean Doyle <2575027+seanpdoyle@users.noreply.github.com>
* Add new `applyStateToMarker()` function
This function replaces the existing `applyPseudoToMarker()` and `applyAttributeToMarker()` functions.
Co-Authored-By: Robin Malfait <1834413+RobinMalfait@users.noreply.github.com>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Sean Doyle <2575027+seanpdoyle@users.noreply.github.com>
Co-authored-by: Robin Malfait <1834413+RobinMalfait@users.noreply.github.com>
* use export default instead of named exports
I'm a little sad about this change, but it turns out that the order is
not guaranteed for named exports in ESM. It was the correct order in our
tests because of babel, but not in native ESM.
* update imports
* simplify `inset` plugin
* run `prettier` on stub file
* simplify `align` utility
* improve arbitrary support for outline
This will allow us to use `outline-[OUTLINE,OPTIONAL_OFFSET]`
Input:
```html
outline-[2px_solid_black]
```
Output:
```css
.outline-\[2px_solid_black\] {
outline: 2px solid black;
outline-offset: 0;
}
```
---
Input:
```html
outline-[2px_solid_black,2px]
```
Output:
```css
.outline-\[2px_solid_black\2c 2px\] {
outline: 2px solid black;
outline-offset: 2px;
}
```
* remove default `type`
* simplify createUtilityPlugin, use types directly
* find first matching type when coercing the value
* introduce css data types
Ref: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Types
These data types will be used to "guess" the type of an arbitrary value
if there is some ambiguity going on. For example:
```
bg-[#0088cc] -> This is a `color` -> `background-color`
bg-[url('...')] -> This is a `url` -> `background-image`
```
If you are using css variables, then there is no way of knowing which
type it is referring to, in that case you can be explicit:
```
bg-[color:var(--value)] -> This is a `color` -> `background-color`
bg-[url:var(--value)] -> This is a `url` -> `background-image`
```
When you explicitly pass a data type, then we bypass the type system and
assume you are right. This is nice in a way because now we don't have to
run all of the guessing type code. On the other hand, you can introduce
runtime issues that we are not able to detect:
```
:root {
--value: 12px;
}
/* Later... */
bg-[color:var(--value)] -> Assumes `color` -> *eventually* -> `background-color: 12px`
```
* add a bunch of new tests for advanced arbitrary values
* add url to resolveArbitraryValue list
* add `asURL` data type
* add `bg-[url('..')]` regex
* allow for `resolveArbitraryValue` to be an array
* prevent spaces around `-` when in a `url`
* add tests to verify `bg-[url('...')]` and `stroke-[url(...)]`
* Add variant for file-selector-button pseudo element
* Rename `file-selector-button` variant to `file`
Co-Authored-By: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Co-authored-by: Jonathan Reinink <jonathan@reinink.ca>
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
* Add `break-before` utilities
* Add `break-inside` utilities
* Add `break-after` utilities
* Add `break-before/inside/after` utilities to basic usage test
* Remove `break-before` and `break-after` utilities that have no browser support
* Rename `break-inside: avoid-column` utility to `break-inside-avoid-column`
* refactor dropShadow plugin, use `matchUtilities`
* replace `_` with ` ` for arbitrary values
* remove custom `asList` function
* do not replace escaped underscores with spaces
* Replace `culori` with simple color parser
* Use space-separated color syntax
* Update default color values to use space-separated syntax
* Update separator regex
* Fix tests
* add tests for the new `color` util
Also slightly modified the `color` util itself to take `transparent`
into account and also format every value as a string for consistency.
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
* filter out `..Variant` plugins for the core-plugin-list
* inline all corePlugins
* move preflight css to `./src/css`
* remove individual plugins
* convert export default object to named exports
Note: Normally I would use export function ..., but since we also have
some export let xx = createUtilityPlugin in this file, it means that all
the `export function` declarations would be hoisted and therefore won't
have the correct order anymore.
To fix this, I used `export let xx = () => {}` instead of the usual
`export function xx() {}`
* drop unused `variants()` function
This was required for AOT mode.
* make a few plugins shorter
* make `jit` mode the default when no mode is specified
* unify JIT and AOT codepaths
* ensure `Object.entries` on undefined doesn't break
It could be that sometimes you don't have values in your config (e.g.: `presets: []`), this in turn will break some plugins where we assume we have a value.
* drop AOT specific tests
These tests are all covered by JIT mode already and were AOT specific.
* simplify tests, and add a few
Some of the tests were written for AOT specifically, some were missing. We also updated the way we write those tests, essentially making Tailwind a blackbox, by testing against the final output.
Now that JIT mode is the default, this is super fast because we only generate what is used, instead of partially testing in a 3MB file or building it all, then purging.
* add some todo's to make sure we warn in a few cases
* make `darkMode: 'media'`, the default
This also includes moving dark mode tests to its own dedicated file.
* remove PostCSS 7 compat mode
* update CLI to be JIT-first
* fix integration tests
This is not a _real_ fix, but it does solve the broken test for now.
* warn when using @responsive or @variants
* remove the JIT preview warning
* remove AOT-only code paths
* remove all `mode: 'jit'` blocks
Also remove `variants: {}` since they are not useful in `JIT` mode
anymore.
* drop unused dependencies
* rename `purge` to `content`
* remove static CDN builds
* mark `--purge` as deprecated in the CLI
This will still work, but a warning will be printed and it won't show up
in the `--help` output.
* cleanup nesting plugin
We don't have to duplicate it anymore since there is no PostCSS 7
version anymore.
* make sure integration tests run in band
* cleanup folder structure
* make sure nesting folder is available
* simplify resolving of purge/content information
* Fix issue where disabled corePlugins can't be re-enabled
* Disable caretColor and content core plugins by default, enable in JIT
* Don't disable caretColor/content in default config stub, hard-code for AOT instead
But with ability to still opt-in through your own config. Somewhat messy, but goal is to keep the messes in the AOT path and keep the JIT path pure.
* Fix style
* Revert unnecessary changes
* Fix style
* WIP
* WIP
* Finish combining JIT and AOT plugins
Still lots of clean up that can be done in some of the more complex ones, but at least it's one file per plugin now.
* Remove unused import
* Fix AOT generation bugs
* Move corePlugins/index.js to corePlugins.js
* Convert JIT files to ESM
* Move tests
* Reorder core plugins to match JIT order
* Update AOT apply tests
* Unify utils
* Combine plugin lists to one single source of truth
* Finish resolving merge conflicts, fix tests
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
