CSS

What Can You Do with Tailwind 2?

Published Nov 24, 2020

Updated Feb 14, 2023

7 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

What Can You Do with Tailwind 2?

Tailwind CSS finally announced it's new 2.0 version on November 18th, 2020.

If you've been around the industry lately, you've probably heard of Tailwind CSS, because they seem to be everywhere! But maybe you haven't, and in that case, it's time for a short introduction. If you have, skip to 2.0 Features

Intro to Tailwind CSS

Something that started out as some handcrafted CSS used personally by Adam Wathan became an extremely popular, productivity-boosting CSS framework used by millions over the last three years. The core mindset behind Tailwind is that CSS should be composed of small single-purpose utility classes which pull from a standard set of values.

At first you may think, "This seems like inline styles, why would I want to bloat my markup and aren't those bad anyway?", and while your statement about inline styles is correct, Tailwind's utility classes aren't that at all. Here's why:

By sticking with only classes, styles all stay at the same specificity.
By using classes instead of inline styles, we encourage reuse and ensure that we're sticking to a standard set of values.
While our markup may be larger than those who use other CSS methodologies, we always know exactly what styles are coming from our classes because there is a 1-to-1 mapping.
The breadth of utility classes allows us to write 95-100% of our CSS using just utilities. This encourages a small footprint and very little maintenance overhead.

There are other benefits like increased authoring speed and others that I'd like to cover in a more thorough post later.

In case you're wondering, what does this look like? Here's an example component from Tailwind's homepage:

Now that you've gotten a short introduction, let's get back to why we're here.

2.0 Features

Since this is a major version, it needed a major launch which included not only a teaser and trailer, but also a whole new website and docs! If this isn't maximalist launching, I don't know what is! Let's see the most exciting changes with a few examples that you couldn't make without customizing version 1.

Theming and Design

I don't think it would be a major version launch if Tailwind didn't touch these two topics because they are the main pillars of why we use Tailwind in the first place. They didn't just touch these though, they brought big changes.

Colors

With regards to theming and design, the biggest of change is colors. The Tailwind team created an all new color palette which includes 17 colors and 5 grays.

This is a huge jump in expressiveness for designs, especially with alternate grays because the old gray was on the cool side. The new sets add two cooler grays and two warmer grays so you can have something that jives better with your design's palette.

Color docs

Dark Mode

Another big change is the new support for dark mode. Tailwind doesn't force one color to another for dark mode, but instead let's you control which colors get applied through the new modifier dark:. This will apply whatever style follows whenever a .dark class is above it.

Dark Mode docs

New Breakpoint and Extended Scales

In an effort to support even more refined designs, the team has added support for a larger breakpoint 2xl which now allows more specification for larger layouts. I often added this as a custom breakpoint. Breakpoint docs

They also added extended scales for spacing, typography, and opacity. For spacing, a few half values were added near the bottom for nudging smaller spacing layouts. For typography, a few values were added to the top end for larger hero text. Opacity had the largest set of adds with steps every 10, and a few half steps at the ends. Spacing, typography, and opacity docs.

A Practical Look at New Theming Changes

I've put together a small demo of landing page hero to show off the new changes. Try toggling the dark class to see dark mode:

New and Extended Utilities

It wouldn't be Tailwind without utilities, and in a major launch, we're going to see some new ones. I think both the new forms plugin and ring utilities are big wins for accessibility because they encourage good practice. The new colors are sure to help us get good contrast!

Forms

Forms have always been a struggle to style. We often resort to hacks and custom implementations with Javascript to be able to make them look good and match our designs. The Tailwind team has worked hard to make standard HTML form inputs able to be styled without custom elements or hacks. There are some limitations here, but I think the result looks great.

Forms plugin docs

Ring

Another issue that we often encounter when auditing the accessibility of our apps is showing clear focus indicators. The default web version of this is accomplished through the outline property. Unfortunately, outline ignores border-radius and isn't quite as customizable as something like box-shadow. The new ring utility will use box-shadow and that will work alongside the standard shadow utilities in Tailwind without overriding them. Our focus indicators can now look as good as the rest of our UI! 💅

Ring docs

Text Overflow

A small change, but still helpful: you can now specify overflow-ellipsis and overflow-clip to control text overflow in a multi-line scenario. Text-overflow docs

Default Line-heights

Something that I feel I'm always tweaking is line-height. I think good line-heights can make or break type styles. In an effort to help improve the quality of typography in Tailwind, the team has shipped default line-heights for each text size, and like always, you can change that with the leading utility. Font-size docs

Practical Example of New Utilities

I've put together a small form component to show off the new utilities:

Internal Mechanics Changes

Quite a few internal changes have taken place, one major one being that Tailwind dropped support for IE11 in 2.0. Given that IE11 has very little representation globally and is officially unsupported by Microsoft, I think this was a good move, especially because it allows them to do even more with the framework.

In addition, @apply can now work with all variants which is a huge boost to anyone who heavily used it. Previously, you were required to implement those variants as you would normal CSS, but no longer!

Two things changed with config. You can easily extend variant's by adding an extend property to your variants config object. This allows you to just add new variants without having to list out all of the default variants which is just a lot nicer.

The other new thing in config is that we can now set default transition timings and easing functions. This allows us to no longer need to specify a duration or easing function if we're just fine with the default, which is probably 80% of the time for me personally.

@apply, variant, and transition docs

The Road to 2.0

Whether you already use Tailwind or you just got converted above, there's a lot to be excited about with version 2.0. A ton of work went into it and it shows in the quality of what was launched.

Creating and maintaining Tailwind quickly became the work of a small company, unfortunately Adam is only so powerful 🤣. He and Steve Schoger needed extra help which they found this year using funds made from their launch of TailwindUI and RefactoringUI. They hired Brad Cornes, Robin Malfait, and Simon Vrachliotis to assist with developing the entire ecosystem that surrounds Tailwind and to push out this new version.

The team's desires for the new version were deliberated at length over many of Adam's tweets, Github issues/discussions, and even podcast episodes from Adam's very own Full Stack Radio. Something especially important to point out is the team's desire to stick to semantic versioning. Creating a new version opens up a lot of doors for change which is great, but that door also closes at the same time. Now the Tailwind team has to wait until 3.0 to make changes that will break, but I think they made good calls on what to include in this version.

What's Next?

If you're as excited as I am, you can head straight to this upgrade guide to dig through what changes you might need to make in your current Tailwind codebase. If you'd like to hear more straight from the creators themselves head on over to their announcement blog post to get an in-depth look at each change.

For some of us, it might not be time to change and that's ok. The current version is still a serious piece of craftsmanship with all the same well-thought features. Version 1.9 will be the last update in version one and will retain support for IE11.

I think Tailwind has proved to be more future-thinking than most frameworks to date including frameworks in other languages. Their attention to detail and quest for excellence shows up in the quality of their work. As a company, they're just getting started. Hopefully the future holds even more new innovations in this lovely little CSS framework, and beyond!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Hunter Miller
@hmillerdev @arthyn

How to Truncate Strings Easily with CSS

You'll often need to truncate text when working with user interfaces, especially when displaying content within a limited space. CSS provides a straightforward way to handle this scenario, ensuring that long text strings are cut off gracefully without affecting the overall layout. CSS Truncation Techniques Single-Line Truncation If you want to truncate a single line of text, CSS provides a simple solution. The key properties to use here are overflow, white-space, and text-overflow. ` Explanation of properties: * white-space: nowrap: This ensures the text stays on a single line, preventing wrapping. * overflow: hidden: This hides any content that overflows the container. * text-overflow: ellipsis: This adds the ellipsis (…) at the end of the truncated text. Multi-Line Truncation While truncating a single line of text is common, sometimes you may want to display multiple lines but still cut off the text when it exceeds a certain number of lines. You can use a combination of CSS properties such as -webkit-line-clamp along with the display and overflow properties. ` Live example: Explanation of properties: * display: -webkit-box: This is a legacy flexbox-like display property that works with the -webkit-line-clamp property. * -webkit-line-clamp: Specifies the number of lines to show before truncating. * -webkit-box-orient: vertical: Ensures the box is laid out vertically for proper multi-line truncation. * overflow: hidden: Prevents content overflow. * text-overflow: ellipsis: Adds an ellipsis after the truncated content. Why Use CSS for Text Truncation Over JavaScript Techniques? While it’s possible to truncate text using JavaScript, CSS is often a better choice for this task for several reasons. Let's explore why CSS-based truncation techniques are generally preferred over JavaScript. Performance Efficiency CSS operates directly within the browser's layout engine, meaning it doesn’t require additional processing or event handling as JavaScript does. When using JavaScript to truncate text, the script needs to run on page load (or after DOM manipulation), and sometimes, it needs to listen for events such as window resizing to adjust truncation. This can introduce unnecessary overhead, especially in complex or resource-constrained environments like mobile devices. CSS, on the other hand, is declarative. Once applied, it allows the browser to handle text rendering without any further execution or processing. This leads to faster load times and a smoother user experience. Simplicity and Maintainability CSS solutions are much simpler to implement and maintain than their JavaScript counterparts. All it takes is a few lines of CSS to implement truncation. In contrast, a JavaScript solution would require you to write and maintain a function that manually trims strings, inserts ellipses, and re-adjusts the text whenever the window is resized. Here's the JavaScript Truncation Example to compare the complexity: JavaScript Truncation Example: ` At the example above, we truncated the text to 50 characters which may be 1 line on large screens and 6 lines on mobile and in that case we will need to add more code to truncate it responsively. As you can see, the CSS solution we used earlier is more concise and readable, whereas the JavaScript version is more verbose and requires managing the string length manually. Responsiveness Without Extra Code With CSS, truncation can adapt automatically to different screen sizes and layouts. You can use relative units (like percentages or vw/vh), media queries, or flexbox/grid properties to ensure the text truncates appropriately in various contexts. If you were using JavaScript, you’d need to write additional logic to detect changes in the viewport size and update the truncation manually. This would likely involve adding event listeners for window resize events, which can degrade performance and lead to more complex code. CSS Example for Responsive Truncation: ` To achieve this in JavaScript, you’d need to add more code to handle the width adjustments dynamically, making it more complex to maintain and troubleshoot. Separation of Concerns CSS handles the presentation layer of your website, while JavaScript should focus on dynamic functionality or data manipulation. By keeping truncation logic within your CSS, you're adhering to the principle of separation of concerns, where each layer of your web application has a clear, well-defined role. Using JavaScript for visual tasks like truncation mixes these concerns, making your codebase harder to maintain, debug, and scale. CSS is purpose-built for layout and visual control, and truncation is naturally a part of that domain. Browser Support and Cross-Browser Consistency Modern CSS properties like text-overflow and -webkit-line-clamp are widely supported across all major browsers. This means that CSS solutions for truncation are generally consistent and reliable. JavaScript solutions, on the other hand, may behave differently depending on the browser environment and require additional testing and handling for cross-browser compatibility. While older browsers may not support specific CSS truncation techniques (e.g., multi-line truncation), fallback options (like single-line truncation) can be easily managed through CSS alone. With JavaScript, more complex logic might be required to handle such situations. Reduced Risk of Layout Shifting JavaScript-based text truncation risks causing layout shifting, especially during initial page loads or window resizes. The browser may need to recalculate the layout multiple times, leading to content flashing or jumpy behavior as text truncation is applied. CSS-based truncation is applied as part of the browser’s natural rendering flow, eliminating this risk and ensuring a smoother experience for the user. Conclusion CSS is the optimal solution for truncating text in most cases due to its simplicity, efficiency, and responsiveness. It leverages the power of the browser’s rendering engine, avoids the overhead of JavaScript, and keeps your code clean and maintainable. While JavaScript truncation has its use cases, CSS should always be your go-to solution for truncating strings, especially in static or predictable layouts. If you like this post, check out the other CSS posts on our blog!...

Sep 13, 2024

4 mins

CSS

The Evolution of CSS: From Early Days to Flexbox & Grid with Kevin Powell

In this episode of the Modern Web Podcast, CSS expert Kevin Powell discusses the evolution of CSS, from the early days of CSS3 to the rapid advancements with Flexbox, Grid, and the latest innovations. Kevin explains how CSS is making strides to integrate features that previously required JavaScript, like scroll-driven animations and popovers, simplifying development and improving performance. He also touches on the importance of understanding the fundamentals of CSS, debugging techniques, and the future of tools like Tailwind and Sass. Chapters Here are the timestamped chapters for the episode: - 00:00 - Introduction and Technical Setup Issues - 01:05 - Guest Introduction: Kevin Powell - 02:00 - Kevin's Journey into CSS and Content Creation - 03:21 - Evolution of CSS: From CSS3 to Modern Features - 05:46 - The Role of JavaScript in CSS and New Features - 08:08 - Popovers, Anchor Positioning, and Progressive Enhancement in CSS - 10:26 - Discussion on SAS, Tailwind, and CSS Tools - 12:35 - Challenges with Tailwind and Over-Componentization - 14:57 - The Importance of Learning Core CSS Principles - 16:56 - The "CSS is Hard" Memes and Overcoming CSS Frustration - 19:12 - Formatting Contexts and Advanced CSS Concepts - 21:31 - Opportunities for Junior Developers to Master CSS - 23:54 - Browser Discrepancies and the Future of Web Standards - 26:14 - Refactoring CSS for Performance and Best Practices - 27:50 - Favorite CSS Resources and Conferences - 28:26 - Imposter Syndrome and Kevin's Speaking Journey - 29:55 - Closing Remarks and Where to Find Kevin Powell Online Follow Kevin Powell on Social Media Twitter: https://x.com/KevinJPowell Github: https://github.com/kevin-powell YouTube: https://www.youtube.com/kevinpowell Sponsored by This Dot....

Sep 24, 2024

2 mins

CSSJavaScript

Why You Should Use React Query or SWR

Why You Should Use React Query or SWR for External Data Most of us out here in React-land are out building our apps with the shiny new Hooks API and slinging requests to external APIs like nobody's business. Those of us new to hooks may have started creating hooks that look like this simplified example: ` The Problem However, each time a hook is called, that instance is unique to the component it was called in, so there's a few issues we'll run into: 1. Updating the above query in one instance won't update it for the other instances. 2. If we have three components using a hook that makes an API request, we will get at least one request per component. 3. If we have multiple requests in the air, and we try to store them in a global store or have the hook hold the state, we will end up with state out of sync or subsequent requests overwriting each other. One way to solve this is to leave the request out of hooks and only call it on mount in a component you can guarantee will be singular (aka a singleton component, like a page/route perhaps). Depending on how that data is used, this can sometimes be very tricky to do. Potential Solutions So what can we do? There are a few options: 1. Make sure the data returned from the API goes in context or some kind of global state management, accepting the multiple requests (potentially overexerting our server's API) 2. Doing the above + use a library like react-singleton-hook, ensure there's only a single component with the useEffect doing the API call, or similar to prevent multiple requests. 3. Implement some kind of way to cache the data (while still being able to invalidate that as necessary) so that we pull from the cache first 4. Use React Query or SWR The Real Solution The real solution here is to use option 4. Both libraries have done really sophisticated work to solve these problems to prevent you from having to do it yourself. Caching is extremely tricky to get right and can have pretty dire consequences if done poorly, leading to your app partially or completely breaking. Other Problems They Solve Here are a few examples of other problems these libraries can solve with code examples for each. _Code examples are using React Query but are nearly the same with SWR._ Window Focus Refetching One big issue that we encounter with Javascript heavy sites and apps is that a user may be on one tab/window messing with data and then switch to another of the same app. The problem here is that if we aren't keeping our data fresh, these can fall out of sync. Both libraries solve this by refetching data once the window has focus again. If you don't need that or can't have that behavior, you can simply disable as an option. ` Request Retry, Revalidation and Polling Sometimes requests error temporarily, it happens. Both libraries answer this problem by allowing configured automatic retries, so anytime they encounter an error, it will retry the specified amount of times until finally throwing an error. Additionally, you can use either to poll an endpoint constantly by just setting their refetch/refresh interval to a number in milliseconds. Retry Example ` Polling Example ` Mutation with Optimistic Updates Let's say you have a list of users and you want to update the information of one of those users, a pretty standard operation. Most people are pretty content with seeing a loader to indicate the server is working to update that user, and waiting for it to finish before seeing the updated list of users. However, if we know what the updated list of users will look like locally (because the user just made the update themselves), do we really even need to show a loader? No, both libraries allow you to do mutations on your cached data that will update locally immediately and start the update to the server in the background. They will also make sure that data gets refetched/validated to be the same once it returns from the server, and if not, the returned data will fall into place. Imagine we have a page where the user gets to edit their information. First, we need to fetch that information from the backend. ` Next we need to setup a function to allow us to update the user's data once they submit the form. ` If we want to have our local data update the UI optimistically, we have to add some options to the mutation. The onMutate here will shove the data locally into the cache firing before the actual update so our UI won't show a loader. The return value is used in case of an error, and we need to reset to our previous state. ` If we're updating optimistically, we need to be able to handle errors and also make sure that the server returns the same data. So we add two more hooks into our mutation's options. onError will use the data returned from onMutate so that we can reset to the previous state. onSettled makes sure we refetch the same data from the server so that we don't end up out of sync. ` Prefetching and Background Fetching If you have an idea about some data that the user is about to need, you can use these libraries to prefetch that data. By the time the user gets to it, the data is already loaded making the transition instant. This can really make your apps feel snappier. ` On a similar note, if the user already has received some data, but it's time to refresh, the libraries will fetch new data behind the scenes and replace the old data if and only if that data is different. This prevents showing the user a loading indicator, only notifying them if there's something new which is a much better user experience. Imagine we have a Twitter-style feed component that constantly is refetching for new posts ` We can notify users that the data is upgrading in the background by listening for isFetching to be true which will fire even if cache data is present. ` If we have no data in the cache at all and the query is fetching data, we can listen for isLoading to be true and show some kind of loading indicator. Finally, if isSuccess is true and we received data, we can display the posts themselves. ` Feature Comparison React Query's creator did a great job building out a feature table comparison for React Query, SWR, and Apollo for you to see what features are available. One big feature that I'd like to call out that React Query has over SWR is it's own set of dev tools which are really helpful for debugging misbehaving queries. Conclusion Over my time as a developer, I've tried to solve these problems myself, and had I had a library like React Query or SWR, I would have saved a ton of time. These problems can be really tricky to solve and the solutions can inject subtle bugs into your app that are difficult or time-consuming to debug. Luckily, we have open source and these people were generous to offer their own robust solutions for us to use. If you'd like to see more about the problems these libraries solve and the efforts needed to solve them, Tanner Linsley did a great walkthrough of what he was experiencing and how he solved it. You can watch that walkthrough here: Overall I think these libraries are great additions to the ecosystem and will help us all write better software. I'd like to see other frameworks come out with similar libraries, because the concepts here are pretty universal. I hope you found this helpful and let us know any unique strategies you have when using these libraries! PS. What about GraphQL? 😂 Well, a lot of the GraphQL libraries out there actually built in a lot of these concepts from the get go, so if you're using something like Apollo or Urql, you probably are already getting these benefits. However, both libraries are compatible with anything that returns a promise, so if your particular favorite GQL library doesn't have these features, try putting React Query or SWR in front of it. 😁...

Sep 25, 2020

6 mins

JavaScriptReact

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

In this episode of Leadership Exchange, host Rob Ocel chats with Jerry Reghunadh, Senior Director of Enterprise Architecture at Data Nimbus, about leadership, AI adoption, and data-driven decision-making. Jerry shares his career journey, insights on leveraging tools like ChatGPT and Copilot, and strategies for building effective data pipelines. They explore how companies can avoid "analysis paralysis," adopt AI strategically, and evaluate new technologies to solve real-world problems. Tune in for practical advice on aligning innovation with business goals and staying competitive in a rapidly evolving tech landscape. Chapters 00:00 – Introduction 00:31 – Jerry’s Leadership Journey 02:01 – Discussing AI in Leadership 03:59 – Experimenting with AI Tools 06:24 – Overcoming Analysis Paralysis 09:18 – Importance of Early AI Adoption 13:12 – AI’s Impact on Efficiency 14:30 – Sponsor Message 16:26 – Setting Realistic Goals for AI 19:41 – Data Management and AI 23:09 – Is AI Just a Fad? 27:22 – Testing New Technologies 29:56 – Final Thoughts on AI 30:25 – Connect with Jerry 30:44 – Closing Remarks 31:20 – Outro Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/ Sponsored by This Dot: thisdot.co...

Nov 18, 2024

1 min

AIEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

What Can You Do with Tailwind 2?

What Can You Do with Tailwind 2?

Intro to Tailwind CSS

2.0 Features

Theming and Design

Colors

Dark Mode

New Breakpoint and Extended Scales

A Practical Look at New Theming Changes

New and Extended Utilities

Forms

Ring

Text Overflow

Default Line-heights

Practical Example of New Utilities

Internal Mechanics Changes

The Road to 2.0

What's Next?

Hunter Miller

You might also like

How to Truncate Strings Easily with CSS

The Evolution of CSS: From Early Days to Flexbox & Grid with Kevin Powell

Why You Should Use React Query or SWR

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

You might also like

How to Truncate Strings Easily with CSS

The Evolution of CSS: From Early Days to Flexbox & Grid with Kevin Powell

Why You Should Use React Query or SWR

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh