Skip to content

Releases: tailwindlabs/tailwindcss

v2.0.0-alpha.6

04 Nov 15:23

Choose a tag to compare

v2.0.0-alpha.6 Pre-release
Pre-release

Changed

  • Respect preserveHtmlElements option even when using custom PurgeCSS extractor (#2704)
  • Set font-family and line-height to inherit on body to behave more like v1.x (#2729)

v2.0.0-alpha.5

30 Oct 12:57

Choose a tag to compare

v2.0.0-alpha.5 Pre-release
Pre-release

Changed

v2.0.0-alpha.4

29 Oct 14:19

Choose a tag to compare

v2.0.0-alpha.4 Pre-release
Pre-release

Added

  • Support deep merging of arrays of objects under extend (#2700)

v2.0.0-alpha.3

27 Oct 15:16

Choose a tag to compare

v2.0.0-alpha.3 Pre-release
Pre-release

Added

  • Support flattening deeply nested color objects (#2148)
  • Support defining presets as functions (#2680)

Changed

  • Merge extend objects deeply by default (#2679)
  • Rename flex-no-wrap to flex-nowrap (#2676)

v2.0.0-alpha.2

25 Oct 16:49

Choose a tag to compare

v2.0.0-alpha.2 Pre-release
Pre-release

Added

  • Support extend in variants configuration (#2651)
  • Add max-w-prose class by default (#2574)

Changed

  • Revert use of logical properties for space and divide utilities (#2644)
  • space and divide utilities ignore elements with [hidden] now instead of only ignoring template elements (#2642)
  • Set default font on body, not just html (#2643)
  • Automatically prefix keyframes and animation names when a prefix is configured (#2621, #2641)
  • Rename whitespace-no-wrap to whitespace-nowrap (#2664)

v1.9.6

23 Oct 18:13

Choose a tag to compare

Changed

  • The presets feature had unexpected behavior where a preset config without its own presets key would not extend the default config. (#2662)

    If you were depending on this unexpected behavior, just add presets: [] to your own preset to exclude the default configuration.

v2.0.0-alpha.1

21 Oct 03:18

Choose a tag to compare

v2.0.0-alpha.1 Pre-release
Pre-release

Warning: This is a pre-release. I don't plan for anything to change (otherwise I would have already changed it) but things probably still will. There are probably also obviously broken embarrassing mistakes I haven't noticed because I'm so deep in the rabbit hole. Please test, help me fix them, and have some sympathy for me 😅

TL;DR:

  • Dark mode
  • New 2xl breakpoint
  • More big font sizes
  • More useful extended spacing scale (you can do top-16 and stuff by default now)
  • New sweet color palette (smaller and bigger at the same time 🤯 )
  • @apply works with everything now
  • IE11 compatibility completely dropped
  • Bunch of other small things that aren't as important

Added

  • Added dark mode support (#2279, #2631)
  • Added overflow-ellipsis and overflow-clip utilities (#1289)
  • Add transform-gpu to force hardware acceleration on transforms when beneficial (#1380)
  • Extended spacing scale (#2630)
  • Add spacing scale to inset plugin (#2630)
  • Enable useful relative sizes for more plugins (#2630)
  • Extend font size scale (#2609, #2619)
  • Support using @apply with complex classes (#2159)
  • Add new 2xl breakpoint (#2609)
  • Add default line-height values for font-size utilities (#2609)
  • Support defining theme values using arrays wherever it makes sense (box-shadow, transition-property, etc.) (e13f083c4)
  • Enable group-hover for color utilities by default (28985b6)
  • Enable focus for z-index utilities by default (ae5b3d3)

Changed

  • New @apply implementation, slight backwards incompatibilities with previous behavior (#2159)
  • Move truncate class to textOverflow core plugin (#2562)
  • Removed target feature and dropped any compatibility with IE 11 (#2571)
  • Switch normalize.css to modern-normalize (#2572)
  • Remove scrolling-touch and scrolling-auto utilities (#2573)
  • Change special use of 'default' in config to 'DEFAULT' (#2580)
  • Drop support for Node 8 and 10 (#2582)
  • Modernize default system font stacks (#1711)
  • Upgrade to PurgeCSS 3.0
  • Upgrade to PostCSS 8.0 Reverted for now
  • Use logical properties for space and divide utilities (#1883)
  • Make theme retrieve the expected resolved value when theme value is complex (e13f083c4)
  • Adjust default font-size scale to include 60px instead of 64px (#2619)
  • Update default colors in Preflight to match new color palette (#2633)

v1.9.5

19 Oct 15:51

Choose a tag to compare

Fixed

  • Fix issue where using theme with default line-heights did not resolve correctly (#2308)

v1.9.4

17 Oct 16:57

Choose a tag to compare

Fixed

  • Fix issue changing plugins defined using the withOptions API would not trigger rebuilds in watch processes

v1.9.3

16 Oct 19:02

Choose a tag to compare

  • Fix issue where tailwindcss init --full scaffolded a corrupt config file (#2556)
  • Remove console warnings about upcoming breaking changes (see note below)

I've opted to remove the console notices about upcoming breaking changes (that encouraged users to opt-in to future features using the future option in their config file.)

While I had good intentions for this approach originally, I'm realizing now that it just ends up creating more confusion and a sloppier documentation story. Any breaking changes can't really be documented easily because the documentation needs to show the stable version of any given feature, since we can't assume someone has opted in to the new stuff.

This means that when someone does opt in, they are basically opting in to being out of sync with the documentation, which is a crappy experience for them, especially if they can't upgrade to Tailwind 2.0 in the near future because they need to support IE11.

For this reason I've decided to stop warning about the upcoming breaking changes so that we don't force users to opt-in to an essentially undocumented version of the framework. Instead we will continue to maintain the "upcoming changes" page in the docs, and continue to ship new ideas behind flags for people to test but without the nudge to upgrade. Folks who are comfortable opting-in to the new stuff early can do so, and folks that aren't can comfortably keep using things the way they are (along with complete documentation) and upgrade to the next version all at once, like people have done traditionally with most dependencies.

I will always strive to make breaking changes as painless and minimal as possible, so spending an hour to do the upgrade in one sitting is never going to be too bad. I highly value backwards compatibility and will never make needlessly breaking changes. An improvement is only worth making if it improves things enough to make up for the upgrade cost, and that's usually pretty rare. For example lh-5 might be a nicer class name than leading-5 but it is absolutely not worth breaking everyone's muscle memory and forcing them to replace hundreds of instances of classes in their projects. We'll only make breaking changes if they unlock meaningful new possibilities or fix fundamental problems that are holding people back.