tailwindcss 0.4.0

on Node.js NPM

• New Features
  • @apply'd classes can now be made !important explicitly
• Changes
  • @apply now strips !important from any mixed in classes
  • Default color palette tweaks

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 grey closer to grey-light than 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:

See the v0.3.0 color palette