Skip to content

Releases: tailwindlabs/tailwindcss

v0.3.0

01 Dec 14:58
Compare
Choose a tag to compare

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 :feelsgood:

// ...

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:

  • responsive
  • hover
  • focus
  • group-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 modules key 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 to false.
  • The options key 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

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

Read more

v0.2.2

19 Nov 17:26
Compare
Choose a tag to compare
  • Fix issue with dist files not being published due to bug in latest npm

v0.2.1

18 Nov 15:52
Compare
Choose a tag to compare
  • Fix overly specific border-radius reset for Chrome 62 button styles: #216

v0.2.0

17 Nov 21:07
Compare
Choose a tag to compare

New Features

Add a custom prefix to all utilities

One of the most common questions we've received since releasing v0.1.0 is "can I use Tailwind with {my existing CSS|another CSS framework}?"

While there was nothing stopping you from layering Tailwind on top of existing CSS, Tailwind has a lot of class names in common with other frameworks (.container, .mb-2, etc.) so you could run into problematic naming collisions if you weren't careful.

To fix this, you can now specify a custom prefix for all of the classes Tailwind generates under the new options key in your Tailwind config file:

{
  // ...
  options: {
    prefix: 'tw-',
    // ...
  },
}

Now all of Tailwind's utilities will include that prefix:

<!-- This... -->
<div class="bg-white hover:bg-blue md:bg-red"></div>

<!-- ... becomes this: -->
<div class="tw-bg-white hover:tw-bg-blue md:tw-bg-red"></div>

To learn more, read the full documentation.

Optionally make all utilities !important

Another common obstacle when trying to use Tailwind with existing CSS is dealing with specificity.

By default, Tailwind utilities are not marked as !important, which means that if your existing CSS has high specificity selectors, trying to override what those selectors are doing with a Tailwind utility just won't work.

To fix this, we've added another option to the options section of the Tailwind config file:

{
  // ...
  options: {
    // ...
    important: true,
    // ...
  },
}

If you set important to true, all of Tailwind's declarations will get marked as !important, so they can easily be used to override existing CSS.

To learn more, read the full documentation.

Round element corners independently

Up until now, you could only apply a border radius to pairs of corners, like the top two corners, left two corners, etc.

Now you can round corners independently too:

<!-- Round the top left corner: -->
<div class="rounded-tl"></div>

<!-- Round the top right corner: -->
<div class="rounded-tr"></div>

<!-- Round the bottom right corner: -->
<div class="rounded-br"></div>

<!-- Round the bottom left corner: -->
<div class="rounded-bl"></div>

See more examples in the border radius documentation.

Cascading border colors and styles

In v0.1.x, our border width utilities used the border shorthand property, which meant that setting a border width also set a style and color:

.border-2 {
  border: 2px solid config('colors.grey-lighter');
}

This meant that if you wanted to change the border style or color of an element and then change the border width at a larger breakpoint, you'd have to re-specify the style/color:

<div class="border-2 border-red border-dashed md:border-4 md:border-red md:border-dashed"></div>

Now our border width utilities only specify the width, so any color or style modifications will properly cascade to larger breakpoints without having to be re-specified:

<div class="border-2 border-red border-dashed md:border-4"></div>

This is technically a breaking change, so check out the relevant section in the upgrade guide to understand how this might affect your site.

Upgrade Guide / Breaking Changes

auto is no longer a hard-coded margin value

Impact: Low

Instead of hard-coding mx-auto, ml-auto, etc. into Tailwind itself, we've moved those values into the customizable margin scale in the config file.

So if you're using a custom config file, add auto to your margin scale:

  {
    // ...
    margin: {
+     'auto': 'auto',
      'px': '1px',
      '0': '0',
      '1': '0.25rem',
      '2': '0.5rem',
      '3': '0.75rem',
      '4': '1rem',
      '6': '1.5rem',
      '8': '2rem',
    },
  }

The defaultConfig function is now a separate module

Impact: Low

In the generated Tailwind config file, we include a line of code showing you how to reference Tailwind's default config values in case you'd like to reference them in your own config file.

For technical reasons, the way this works has changed:

// The old way:
var defaultConfig = require('tailwindcss').defaultConfig()

// The new way:
var defaultConfig = require('tailwindcss/defaultConfig')()

The good news is that this change makes it possible for you to import your custom config file into your front-end JavaScript if you'd like; making it easy to re-use the same color palette with libraries like D3.js or Chart.js for example.

Rounded utilities now combine position and radius size

Impact: High

Previously, border radius position and radius size were specified with two utilities. Now, size and position are combined into the same utility:

<!-- The old way: -->
<div class="rounded-lg rounded-t"></div>

<!-- The new way: -->
<div class="rounded-t-lg"></div>

We made this change because it makes working with border radius generally more predictable and much more flexible.

For example, previously, if you wanted to round 3 corners of an element, you could try this, but it wouldn't work:

<!-- Doesn't work: -->
<div class="rounded-lg rounded-t rounded-l"></div>

Instead, you'd see that only the left side was rounded. This is because the previous implementation of rounded-l worked by unrounding the right-side corners.

Now you can round 3 corners of an element two ways:

<!-- Option 1: Round two sides -->
<div class="rounded-t-lg rounded-l-lg"></div>

<!-- Option 3: Round the corners separately -->
<div class="rounded-tl-lg rounded-tr-lg rounded-bl-lg"></div>

Upgrade steps

  1. If you have a custom config file, make sure your 0 value border radius utility appears first in your border radius scale:

      {
        // ...
        borderRadius: {
    +     'none': '0',
          'sm': '.125rem',
          default: '.25rem',
          'lg': '.5rem',
          'full': '9999px',
    -     'none': '0',
        },
      }

    This is important if you ever need to reset the border radius of a side at a breakpoint and add a border radius to another side that shares a corner.

  2. Look for any time you round one side of an element in your codebase and collapse the separate position and size utilities into the new corresponding compound utility:

    <!-- Change this: -->
    <div class="rounded-lg rounded-t"></div>
    
    <!-- To this: -->
    <div class="rounded-t-lg"></div>
    
    
    <!-- Change this: -->
    <div class="rounded rounded-l"></div>
    
    <!-- To this: -->
    <div class="rounded-l"></div>
  3. If you were changing which side of an element was rounded responsively, now you'll need to explicitly unround one side when you round the other:

    <!-- Change this: -->
    <div class="rounded-lg rounded-t lg:rounded-lg lg:rounded-l"></div>
    
    <!-- To this: -->
    <div class="rounded-t-lg lg:rounded-t-none lg:rounded-l-lg"></div>

Border width utilities no longer affect border color/style

Impact: Medium

Previously, applying a border width utility like .border-2 would not only set the border width; it would also override the border color and border style.

This is no longer the case, so if you were ever depending on that behavior (for example when overriding things responsively), you'll need to update your code to explicitly change the color and style:

<!-- Change this: -->
<div class="border border-dashed border-red md:border-2"></div>

<!-- To this: -->
<div class="border border-dashed border-red md:border-2 md:border-solid md:border-grey-lighter"></div>

It's very unlikely that you were depending on this behavior so chances are you won't need to make th...

Read more

v0.1.6

09 Nov 14:32
Compare
Choose a tag to compare
  • Fix CDN files not being published to npm

v0.1.5

08 Nov 13:39
Compare
Choose a tag to compare
  • Fix CLI tool not loading config files properly (#149)
  • Apply the same default placeholder styling that's applied to inputs to textareas (#119)

v0.1.4

06 Nov 16:50
Compare
Choose a tag to compare
  • If using Webpack, it will now watch your config file changes
  • Autoprefix dist assets for quick hacking and prototyping
  • Move list utilities earlier in stylesheet to allow overriding with spacing utilities (bug fix)
  • Add my-auto, mt-auto, and mb-auto margin utilities
  • Add sans-serif to end of default sans font stack
  • When running tailwind init [filename], automatically append .js to filename if not present
  • Support default fallback value in config(...) function, ie. config('colors.blue', #0000ff)
  • Don't output empty media queries if Tailwind processes a file that doesn't use Tailwind

v0.1.3

02 Nov 18:16
Compare
Choose a tag to compare
  • Add new .scrolling-touch and .scrolling-auto utilities for controlling inertial scroll behavior on WebKit touch devices
  • Generate separate dist files for preflight, utilities, and tailwind for CDN usage

v0.1.2

01 Nov 22:04
Compare
Choose a tag to compare
  • Fix issue with config option not being respected in tailwind build
  • Target Node 6.9.0 explicitly (instead of 8.6 implicitly) to support more users

v0.1.1

01 Nov 19:19
Compare
Choose a tag to compare
  • Fix tailwind build CLI command not writing output files