Skip to content

Releases: tailwindlabs/tailwindcss

v0.6.1

22 Jun 11:54
Compare
Choose a tag to compare
  • Fix incorrect box-shadow syntax for the .shadow-outline utility 🤦‍♂️ : #503

    If you generated a config file using v0.6.0, you'll want to make this same change in your own config file.

v0.6.0

21 Jun 16:05
Compare
Choose a tag to compare

New Features

Added border collapse utilities for styling tables (#489)

Tailwind now includes .border-collapse and .border-separate utilities for controlling the border-collapse property.

By default we don't generate any variants for these utilities (not even responsive variants) but you can change this through the borderCollapse module your Tailwind configuration file.

We've also updated Preflight to set border-collapse: collapse by default on all tables.

Added more axis-specific overflow utilities (#445)

In addition to .overflow-hidden and .overflow-visible, Tailwind now includes .overflow-x-hidden, .overflow-y-hidden, .overflow-x-visible and .overflow-y-visible for controlling overflow along a specific axis.

Added .outline-none utility for suppressing focus styles (#491)

Tailwind now includes a .outline-none utility for setting outline: 0 on an element to prevent the default browser focus ring.

By default, we also generate a focus variant (focus:outline-none) but no responsive variants.

Added .shadow-outline utility as an alternative to default browser focus styles (#491)

Outlines don't follow an element's border radius in most browsers, so a common practice is disable the browser's default focus outline and use a colored box-shadow to highlight focused elements.

Tailwind now includes a blue .shadow-outline utility that can be used for this purpose.

We've also enabled focus variants for box shadows by default, so you can add an outline shadow on focus by doing something like this:

<button class="focus:outline-none focus:shadow-outline ..."></button>

Extended default padding, margin, negative margin, width, and height scales (#499)

Tailwind's default configuration now includes more padding, margin, and negative margin sizes:

  padding/margin/negativeMargin: {
    'px': '1px',
    '0': '0',
    '1': '0.25rem',
    '2': '0.5rem',
    '3': '0.75rem',
    '4': '1rem',
+   '5': '1.25rem',
    '6': '1.5rem',
    '8': '2rem',
+   '10': '2.5rem',
+   '12': '3rem',
+   '16': '4rem',
+   '20': '5rem',
+   '24': '6rem',
+   '32': '8rem',
  }

We've also added 5 to the height and width scales to avoid any holes when compared with the spacing scales:

  width/height: {
    'auto': 'auto',
    'px': '1px',
    '1': '0.25rem',
    '2': '0.5rem',
    '3': '0.75rem',
    '4': '1rem',
+   '5': '1.25rem',
    '6': '1.5rem',
    '8': '2rem',
    '10': '2.5rem',
    '12': '3rem',
    '16': '4rem',
    '24': '6rem',
    '32': '8rem',
    '48': '12rem',
    '64': '16rem',
    // ...
  }

Enable focus and hover variants for more modules by default (#498)

Tailwind now includes focus and hover variants for more utilities out of the box.

We've added:

  • Focus variants for background colors
  • Focus variants for border colors
  • Focus variants for font weight
  • Hover and focus variants for box shadows
  • Focus variants for text colors
  • Focus variants for text style (underline, capitalization, etc.)

That means you do things like style an input differently based on whether it currently has focus:

<input class="border border-transparent bg-grey-lighter focus:bg-white focus:border-blue-light">

This was always possible if you had focus variants enabled in your own configuration, but Tailwind 0.6.0 sets these up for you out of the box so you don't need to make this common configuration change yourself. It also makes our CDN builds a little more powerful.

Changes

Removed default outline: none !important styles from focusable but keyboard-inaccessible elements (#491)

Impact: Low, Effort: Low

Prior to 0.6.0, our Preflight base styles included this rule (borrowed from suitcss/base):

/**
 * Suppress the focus outline on elements that cannot be accessed via keyboard.
 * This prevents an unwanted focus outline from appearing around elements that
 * might still respond to pointer events.
 */

[tabindex="-1"]:focus {
  outline: none !important;
}

This is a useful default for many projects, but in the odd case that it's problematic for you it is really annoying to work around.

With the addition of the .outline-none helper, we think it makes sense to remove this default style and encourage people to simply add focus:outline-none to any focusable but keyboard-inaccessible elements:

- <div tabindex="-1" class="...">...</div>
+ <div tabindex="-1" class="focus:outline-none ...">...</div>

Of course, you can also reintroduce this rule into your own base styles after Preflight:

  @tailwind preflight;
  
+ [tabindex="-1"]:focus {
+   outline: none !important;
+ }
  
  @tailwind components;
  
  @tailwind utilities;

Moved screen prefix for responsive group-hover variants (#497)

Impact: Low, Effort: Medium

Prior to 0.6.0, if you had responsive and group-hover variants enabled for a module, the resulting CSS rule for a responsive group-hover variant would look something like this:

.sm\:group .group-hover\:bg-red { ... }

This was just a consequence of the responsive variants implementation and wasn't something we intentionally designed. It allowed you to do stuff like this:

<!-- Parent only behaves like a group on large screens and up, so the child -->
<!-- remains blue on small screens even when the parent is hovered. -->
<div class="lg:group">
  <div class="bg-blue group-hover:bg-red">...</div>
</div>

This is not very useful in practice, and actually prevented you from changing how an element itself responded to group-hover on different screen sizes:

<div class="group">
  <!-- Element was always red, even on small screens and up -->
  <div class="group-hover:bg-red sm:group-hover:bg-blue">...</div>
</div>

In 0.6.0, the group-hover part of the selector adopts the screen prefix instead of the group part, so the code snippet from above will now work.

I would bet $100 that zero Tailwind users were depending on the pre-0.6.0 behavior, but if you were, the best solution is to write your own CSS for those parts of your project.

Default config file changes

Impact: Low, Effort: Low

The default config file now includes more padding, margin, negative margin, height, and width sizes; a new borderCollapse entry in the modules section; and enables more variants for more modules by default.

All the changes are purely additive, so you don't actually have to change any existing config files — all of your existing projects will work the same in 0.6.0 aside from the two breaking changes mentioned earlier in this changelog.

If you'd like to upgrade your config file to match the current default config file, you can view a diff of the changes here.

v0.5.3

07 May 18:38
Compare
Choose a tag to compare
  • Improve sourcemaps for replaced styles like preflight
  • Fix bug where informational messages were being logged to stdout during build, preventing the ability to use Tailwind's output in Unix pipelines

v0.5.2

29 Mar 16:12
Compare
Choose a tag to compare
  • Fixes an issue with a dependency that had a security vulnerability: #438

v0.5.1

13 Mar 21:13
Compare
Choose a tag to compare
  • Reverts a change that renamed the .roman class to .not-italic due to the fact that it breaks compatibility with cssnext: csstools/postcss-selector-not#10

    We'll stick with .roman for now with a plan to switch to .not-italic in another breaking version should that issue get resolved in postcss-selector-not.

v0.5.0

13 Mar 20:23
Compare
Choose a tag to compare

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...

Read more

v0.4.3

13 Mar 18:55
Compare
Choose a tag to compare
  • Use global.Object to avoid issues with polyfills when importing the Tailwind config into other JS (#402)

v0.4.2

01 Mar 13:52
Compare
Choose a tag to compare
  • Fix an issue where borders couldn't be applied to img tags without specifying a border style (#362, #363)
  • Add support for using a function to define class prefixes in addition to a simple string (#367)
  • Improve the performance of @apply by using a lookup table instead of searching (#401)

v0.4.1

22 Jan 15:16
Compare
Choose a tag to compare
  • Make default sans-serif font stack more future proof and safe to use with CSS font shorthand (#353)
  • Replace stylefmt with Perfectionist to avoid weird stylelint conflicts (#358, #322)

v0.4.0

15 Dec 15:54
Compare
Choose a tag to compare

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