Releases: tailwindlabs/tailwindcss
v0.5.2
v0.5.1
-
Reverts a change that renamed the
.romanclass to.not-italicdue to the fact that it breaks compatibility with cssnext: csstools/postcss-selector-not#10We'll stick with
.romanfor now with a plan to switch to.not-italicin another breaking version should that issue get resolved inpostcss-selector-not.
v0.5.0
New Features
Plugin system
Tailwind now includes a feature-rich plugin system that allows people to create reusable third-party packages that can hook into Tailwind's compilation process to add new styles.
// ...
module.exports = {
// ...
plugins: [
function({ addUtilities, addComponents, config, prefix, e }) {
addComponents(
{
['.btn-blue']: {
backgroundColor: 'blue',
},
},
{ respectPrefix: true }
)
},
],
// ...
}Documentation is coming very shortly, but in the mean time you can learn more through these two pull requests:
Update: Documentation is now available: https://tailwindcss.com/docs/plugins
Added .sticky position utility
Tailwind now includes a .sticky utility for setting an element to position: sticky. This isn't supported by IE 11, but falls back fairly gracefully with no effort so we decided to include it out of the box.
Learn more about sticky positioning at MDN
Added .cursor-wait and .cursor-move utilities
In addition to .cursor-auto, .cursor-default, .cursor-pointer, and .cursor-not-allowed, Tailwind now includes .cursor-wait to indicate when the application is busy, and .cursor-move to indicate that an element can be moved.
Added .bg-auto background size utility
To allow resetting an element's background size at other breakpoints, Tailwind now includes a .bg-auto utility:
<div class="bg-cover md:bg-auto">...</div>Background sizes are now customizable
If you'd like to customize the available background size utilities in your project, you can now do so by adding a backgroundSize key to your Tailwind config:
module.exports = {
// ...
backgroundSize: {
'auto': 'auto',
'cover': 'cover',
'contain': 'contain',
},
}Support for active variants
In addition to hover, focus, and group-hover, Tailwind now includes support for active variants of each utility:
module.exports = {
// ...
modules: {
// ...
backgroundColors: ['hover', 'active'],
// ...
}
}Better postcss-import support
If you're using postcss-import to inline your imports, you can't use @tailwind preflight or @tailwind utilities directly in a file that contains other imports, due to postcss-import staying strict to the CSS spec for import statements.
Previously, the workaround for this was to create a new file just for @tailwind preflight and another new file just for @tailwind utilities, and then @import those files into your main stylesheet.
It turns out postcss-import can import files from node_modules, so as of v0.5.0, you can now import these files directly from Tailwind itself:
@import "tailwindcss/preflight";
@import "tailwindcss/utilities";Configuration options for the .container component
Now that the .container component is provided as a built-in plugin, it exposes optional configuration for centering the container by default as well as adding default horizontal padding:
// ...
module.exports = {
// ...
plugins: [
require('tailwindcss/plugins/container')({
center: true,
padding: '2rem',
}),
],
}Containers are still not centered with no padding by default, and the configuration object is not required:
// ...
module.exports = {
// ...
plugins: [
require('tailwindcss/plugins/container')(),
],
}You can also disable the container component entirely now by removing the plugin from the plugins list:
// ...
module.exports = {
// ...
plugins: [
- require('tailwindcss/plugins/container')(),
],
}Changes
The .container component is now a built-in plugin
Impact: Large, Effort: Low
The .container component has long been a bit of an oddball in the Tailwind codebase; it's the only set of styles that can't be used with state variants and apply different styles at different breakpoints.
With the addition of the new plugin system, it made sense to move the container component out of same bucket of code that holds all of our utility classes and into its own plugin with its own options.
If you are using the container in your projects, you will need to add the following section to your existing Tailwind config file:
// ...
module.exports = {
// ...
+ plugins: [
+ require('tailwindcss/plugins/container')(),
+ ],
}You'll also need to add the new @tailwind components directive to your CSS:
@tailwind preflight;
+ @tailwind components;
@tailwind utilities;State variant precedence changes
Impact: Small, Effort: High
Prior to 0.5.0, state variants had the following precedence (lowest to highest):
- Focus
- Hover
- Group Hover
That means that if an element had both focus:bg-blue and hover:bg-green applied, when the element was both focused and hovered, the hover styles would take precedence, so the element would be green.
It also meant that if an element had group-hover:bg-blue and hover:bg-green applied, hovering the element would make it blue because the group styles would take precedence over the individual element styles.
In 0.5.0, state variants have the following precedence (lowest to highest):
- Group Hover
- Hover
- Focus
- Active
Now hover styles will defeat group-hover styles, and focus styles will defeat hover styles.
If this sounds counter-intuitive, see #417 for more information on the motivation behind this change.
It is extremely unlikely that this change affects you; the odds that you were changing the same property on both hover and focus is extremely low, and if you were, I'm willing to bet it was on an input field where the new behavior would actually feel like an improvement.
If this change does break the expected behavior in your project, the best solution is to create your own component classes for the places where you were doing complex interaction like this so you can control the precedence manually.
New config file keys
Impact: Small, Effort: Low
New plugins key
If you'd like to use the new plugin system in an existing project, you'll need to add the plugins key to your config, and include the container component plugin if you need it:
// ...
module.exports = {
// ...
+ plugins: [
+ require('tailwindcss/plugins/container')(),
+ ],
}This is optional, your project will build fine without this change and will just fall back to the plugins configuration from the default config file.
New backgroundSize key
If you'd like to customize the available background size utilities, add the backgroundSize key to your config
module.exports = {
// ...
+ backgroundSize: {
+ 'auto': 'auto',
+ 'cover': 'cover',
+ 'contain': 'contain',
+ },
}This is optional, your project will build fine without this change and will just fall back to the backgroundSize configuration from the default config file.
.overflow-x/y-scroll now set overflow: scroll instead of overflow: auto
Impact: Large, Effort: Medium
The .overflow-x-scroll and .overflow-y-scroll utilities now set overflow to scroll instead of auto.
New .overflow-x-auto and .overflow-y-auto utilities have been adde...
v0.4.3
v0.4.2
v0.4.1
v0.4.0
New Features
@apply'd classes can now be made !important explicitly
If you need to @apply a class and make it's declarations !important, you can now add !important to the @apply declaration itself. This will make the applied declarations !important even if they aren't marked as important in the class being applied:
// Input:
.bar {
@apply .foo !important;
}
.foo {
color: blue;
}
// Output:
.bar {
color: blue !important;
}
.foo {
color: blue;
}Changes
@apply now strips !important from any mixed in classes
Impact: Low
Prior to 0.4, if you had a class that contained !important declarations and you @apply'd that class to another class, the declarations would preserve their !important value:
// Input:
.bar {
@apply .foo;
}
.foo {
color: blue !important;
}
// Output:
.bar {
color: blue !important;
}
.foo {
color: blue !important;
}This turned out to be problematic if you have Tailwind configured to make utilities !important by default, and you wanted to compose components from those utilities that contained descendant selectors, for example:
// Input:
.custom-table td {
@apply .text-grey-dark;
}
// Output:
.custom-table td {
color: #8795a1 !important;
}The problem was that rules like this would have a higher specificity than the utilities themselves due to the compound selector, so you couldn't override those styles with utilities:
<table class="custom-table">
<tr>
<td class="text-red">Will still be grey</td>
</tr>
</table>In 0.4, @apply will always strip !important to avoid specificity issues like this:
// Input:
.bar {
@apply .foo;
}
.foo {
color: blue !important;
}
// Output:
.bar {
color: blue;
}
.foo {
color: blue !important;
}Odds of this affecting your existing codebase is quite low; if anything this will let you clean up code you might have had to write to work around this annoying behavior.
Default color palette tweaks
Impact: Low
Some of the values in the default color palette have been tweaked with the aim of making it more useful in more situations.
-
The dark end of the grey scale has been spread out more, making
greycloser togrey-lightthan it was previously. See the PR. -
The darker/darkest variants of most colors have been desaturated slightly so they work better as background colors. See the PR.
These changes will only affect you if you are dynamically referencing the default color palette in your own config file. If you'd like to keep using the old colors, they can be found here:
v0.3.0
New Features
Enable/disable modules and control which variants are generated for each
The Tailwind config file now contains a new modules key where you can control which modules should be responsive, or have hover or focus variants generated:
// ...
module.exports = {
// ...
modules: {
// Generate base appearance utilities + responsive versions
appearance: ['responsive'],
// Generate base, responsive, hover, and focus versions
backgroundAttachment: ['responsive', 'hover', 'focus'],
// Only generate base utilities
backgroundPosition: [],
// ...
},
// ...
}If you don't need a certain module at all, you can disable it by setting it to false:
// ...
module.exports = {
// ...
modules: {
// ...
flexbox: false,
// ...
},
// ...
}This gives you better control over the generated file size and also lets you add hover/focus variants to utilities that don't have them by default, like shadows for example.
If you're a PurgeCSS user who doesn't care about the pre-PurgeCSS file size, you can even set modules to all to generate every variant for every utility 
// ...
module.exports = {
// ...
modules: 'all',
// ...
}Learn more about in the configuration modules documentation.
Focus variants
As alluded to earlier, Tailwind now lets you generate focus: variants of each utility that are only active on focus.
Focus variants are currently not enabled on any modules by default, but you can enable them for a specific module in your own project by adding 'focus' to the variants list in the modules section of your config file:
// ...
module.exports = {
// ...
modules: {
// ...
backgroundColors: ['responsive', 'hover', 'focus'],
// ...
},
// ...
}Focus variants work just like the hover variants that you're used to:
<input class="bg-grey-light focus:bg-white border border-grey">Group hover variants
Sometimes you need to change the style of an element when some parent element is hovered rather than the element itself.
To handle these situations, Tailwind 0.3 adds a new group-hover variant.
Group hover variants are currently not enabled on any modules by default, but you can enable them for a specific module in your own project by adding 'group-hover' to the variants list in the modules section of your config file:
// ...
module.exports = {
// ...
modules: {
// ...
textColors: ['responsive', 'hover', 'group-hover'],
// ...
},
// ...
}
To use a group-hover: utility variant, you need to mark the target parent element with the .group class:
<div class="group ...">
<svg class="text-grey-light group-hover:text-grey-dark"><!-- ... --></svg>
<a class="text-blue group-hover:underline" href="#">Click me</a>
</div>Check out this CodePen to see it in action.
New @variants at-rule
To make it easy to generate hover, focus, and group-hover versions of your own utilities, Tailwind 0.3 adds a new @variants at-rule that lets you specify which variants to generate for a given list of classes:
@variants hover, focus {
.banana { color: yellow; }
.chocolate { color: brown; }
}This will generate the following CSS:
.banana { color: yellow; }
.chocolate { color: brown; }
.focus\:banana:focus { color: yellow; }
.focus\:chocolate:focus { color: brown; }
.hover\:banana:hover { color: yellow; }
.hover\:chocolate:hover { color: brown; }The @variants at-rule supports all of the values that are supported in the modules section of your config file:
responsivehoverfocusgroup-hover
Note: In previous versions, Tailwind included undocumented @hoverable and @focusable directives. These were fundamentally flawed in how they worked, and have been removed in favor of the new @variants directive.
The @responsive directive however has not been removed, and we fully intend to continue to support it as a shortcut for @variants responsive {}.
Customize the separator character
By default, Tailwind uses a colon (:) as a separator between variants and utility names:
<div class="hover:bg-blue">...</div>
Some templating languages (like Pug) don't play nicely with this, so Tailwind 0.3 adds a new configuration option that lets you change this if needed:
// ...
module.exports = {
// ...
options: {
// ...
separator: '_',
},
}Missing config keys now fallback to their default values
Prior to Tailwind 0.3, excluding a key (like backgroundColors) from your config file was undefined behavior.
To make upgrades smooth as new options are added to the config file, missing keys now fallback to their default values.
This has the added benefit of allowing you to completely omit keys from your config file if you don't intend to change the default values.
The exact behavior is as follows:
- Top level keys fallback to their default values only if missing. The contents of top level keys are not merged, except for the two cases noted below.
- The
moduleskey is merged with the default modules key. This means that if you exclude a module from your config, it will be generated using the default settings. It will not be disabled unless you include the key and set it tofalse. - The
optionskey is merged with the default options key. This means if you only want to change one option, you only need to provide that one key.
New utilities
.pin-nonehas been added to undo existing.pin-{side}utilities at different breakpoints.resize-bothhas been added to allow resizing an element both horizontally and vertically- A completely new background attachment module has been added
- A completely new background repeat module has been added
- Completely new SVG fill and SVG stroke modules have been added
Upgrade Guide / Breaking Changes
Lists now have no margins by default
Impact: Medium
Until 0.3, Tailwind's Preflight base styles left ul and ol elements generally untouched, relying on the list-reset utility to remove default browser styling if you wanted to use a list for navigation or similar.
In 0.3, Tailwind still doesn't change list-style-type or padding on lists in our base styles, but we do remove margins:
ul, ol {
margin: 0;
}
Tailwind already did this for all headings, block quotes, paragraph tags, etc., so removing margins on lists feels much more consistent.
It's unlikely this will impact your project as you were most likely overriding the browser's default margins with existing margin utilities.
If you were relying on the browser's default list margins, simply add margin utilities to your lists to make up for the now missing default margin.
.pin no longer sets width and height to 100%
Impact: Low
In an effort to make .pin{-side?} utilities easier to undo at different breakpoints, the all-sides .pin utility no longer sets width and height to 100%.
This will only affect you if you were using .pin on iframe, textarea, input, or button elements, and is easily remedied by adding the w-full and h-full utilities to those elements.
SVG fill no longer defaults to currentColor
Prior to 0.3, Tailwind's Preflight styles set all SVG fills to currentColor:
svg {
fill: currentColor;
}
This made it harder to use icon sets like Feather that are drawn entirely with strokes with Tailwind, because they'd now be filled with the current text color by default instead of having no fill.
Tailwind 0.3 removes this base style entirely, and adds the fill-current class to make up for it, allowing you to be explicit when you want an SVG element to be filled with...
v0.2.2
- Fix issue with dist files not being published due to bug in latest npm