Over the past couple of months we’ve been working away at a new SaaS marketing site template for Tailwind UI. It’s called Radiant, and you can start using it today.

We just wrapped up work on a beautiful new SaaS marketing site template called Radiant, and it’s available now as part of Tailwind UI.

It’s built with Next.js, Framer Motion, and Tailwind CSS, with a blog powered by Sanity.

It’s been a while since we built a SaaS marketing template like this, and in that time we’ve learned a lot about what makes a template like this useful and easy to work with. We’ve tried to incorporate all of those learnings into Radiant.

Check out the live preview as always for the full experience — there are tons of cool details in this one that you have to see in the browser to really appreciate.

​Tastefully interactive

It’s super easy to overdo animation on a site like this. We’ve all seen sites where you can’t even scroll a few pixels without a bunch of different elements animating in to place. Even worse is how slow things feel when you have to wait for the content to appear before you can read it.

Radiant is loaded with delightful animations, but they are all layered on to existing content and triggered by user interaction so the site still feels fast. In most cases, we went for animations that loop to make elements feel “alive” while you’re interacting with them.

We used Framer Motion for almost all of the animations. It’s declarative, making it easy to create our own APIs for complex animations that other people can customize without much effort.

It does have some drawbacks to work around though. For example, when you have multiple elements animating independently it’s annoying to pass a hover state down to each child. We ended up leveraging Framer’s variant propagation to make this work — a hover event triggers a variant change in the parent that propagates down to the children because they share the same variant keys.

export function BentoCard() {
  return (
    <motion.div
      initial="idle"
      whileHover="active"
      variants={{ idle: {}, active: {} }}
      data-dark={dark ? 'true' : undefined}
    >
      /* ... */
    </motion.div>
  )
}

There is no difference between the variants in the parent so it doesn’t actually change but the children still get a signal to change variants on hover, even if they are deeply nested.

function Marker({
  src,
  top,
  offset,
  delay,
}: {
  src: string
  top: number
  offset: number
  delay: number
}) {
  return (
    <motion.div
      variants={{
        idle: { scale: 0, opacity: 0, rotateX: 0, rotate: 0, y: 0 },
        active: { y: [-20, 0, 4, 0], scale: [0.75, 1], opacity: [0, 1] },
      }}
      transition={{ duration: 0.25, delay, ease: 'easeOut' }}
      style={{ '--offset': `${offset}px`, top } as React.CSSProperties}
      className="absolute left-[calc(50%+var(--offset))] size-[38px] drop-shadow-[0_3px_1px_rgba(0,0,0,.15)]"
    >
      /* ... */
    </motion.div>
  )
}

/* ... */

The logo timeline animation is a bit different, because we wanted the logos to pause in their current position when you stop hovering, rather than return to their original position. This doesn’t play very well with Framer’s approach of specifying start and end states, so it was actually easier to build this in CSS.

It exploits the fact that you can set a negative animation-delay value to offset the start position of the element. That way all the logos share the same animation keyframes but they can start at different positions and have different durations.

function Logo({
  label,
  src,
  className,
}: {
  label: string
  src: string
  className: string
}) {
  return (
    <div
      className={clsx(
        className,
        'absolute top-2 grid grid-cols-[1rem,1fr] items-center gap-2 whitespace-nowrap px-3 py-1',
        'rounded-full bg-gradient-to-t from-gray-800 from-50% to-gray-700 ring-1 ring-inset ring-white/10',
        '[--move-x-from:-100%] [--move-x-to:calc(100%+100cqw)] [animation-iteration-count:infinite] [animation-name:move-x] [animation-play-state:paused] [animation-timing-function:linear] group-hover:[animation-play-state:running]',
      )}
    >
      <img alt="" src={src} className="size-4" />
      <span className="text-sm/6 font-medium text-white">{label}</span>
    </div>
  )
}

export function LogoTimeline() {
  return (
    /* ... */
    <Row>
      <Logo
        label="Loom"
        src="./logo-timeline/loom.svg"
        className="[animation-delay:-26s] [animation-duration:30s]"
      />
      <Logo
        label="Gmail"
        src="./logo-timeline/gmail.svg"
        className="[animation-delay:-8s] [animation-duration:30s]"
      />
    </Row>
    /* ... */

This approach means we don’t need to track the play state in JavaScript, we can just use a group-hover:[animation-play-state:running] class to start the animation when the parent is hovered.

As you’ve maybe noticed, we’re using a bunch of arbitrary properties for individual animation properties in this component, since these utilities don’t exist in Tailwind today. This is what’s great about building these templates — it helps us find blind spots in Tailwind CSS. Who knows, maybe we’ll see these utilities added for v4.0!

​Deliberately reusable

The trickiest part of designing a SaaS template like this, is coming up with interactive elements that people can apply to their own product without too much effort. There’s nothing worse than buying a template and realizing that it’s so specific to the example content that you can’t actually use it for your own project.

We came up with some core graphical elements that most SaaS products might have. A map with pins, a logo cluster, a keyboard — things that could be applied to a bunch of different features. Because we wanted them to be easy to repurpose for your own product, we built a lot of them in code and designed nice APIs for them.

The logo cluster, for example, has a simple API that lets you pass in your own logos, tweak their position and hover animation to match.

<Logo
  src="./logo-cluster/dribbble.svg"
  left={285}
  top={20}
  hover={{ x: 4, y: -5, rotate: 6, delay: 0.3 }}
/>

The keyboard shortcuts section is another good example. Adding your own shortcuts is as simple as passing an array of key names to the Keyboard component and because each key is a component, you can easily add custom keys or change the layout.

<Keyboard highlighted={['F', 'M', 'L']} />

It turns out it’s actually quite a lot of work to build a keyboard in code, but at least now you’ll never have to find that out for yourself.

Of course, we also left spots for you to drop in screenshots of your own product. Here’s what this section looks like customized to suit our friends at SavvyCal, using the same interactive components.

​Powered by a CMS

Usually we just use MDX when adding a blog to a template, but this time we thought it would be fun to play with a headless CMS for a chance instead. We decided to give Sanity a go for this one after polling our audience and hearing a lot of good things.

Instead of creating files, making commits, and managing images and stuff by hand, a CMS lets you handle everything from their UI, so even non-developers can easily contribute.

One cool thing about headless CMSes like Sanity is you get your content back in a structured format, so similar to MDX you can map elements to your own custom components to handle all of your typography styles.

<PortableText
  value={post.body}
  components={{
    block: {
      normal: ({ children }) => (
        <p className="my-10 text-base/8 first:mt-0 last:mb-0">
          {children}
        </p>
      ),
      h2: ({ children }) => (
        <h2 className="mb-10 mt-12 text-2xl/8 font-medium tracking-tight text-gray-950 first:mt-0 last:mb-0">
          {children}
        </h2>
      ),
      h3: ({ children }) => (
        <h3 className="mb-10 mt-12 text-xl/8 font-medium tracking-tight text-gray-950 first:mt-0 last:mb-0">
          {children}
        </h3>
      ),
      blockquote: ({ children }) => (
        <blockquote className="my-10 border-l-2 border-l-gray-300 pl-6 text-base/8 text-gray-950 first:mt-0 last:mb-0">
          {children}
        </blockquote>
      ),
    },
    types: {
      image: ({ value }) => (
        <img
          className="w-full rounded-2xl"
          src={image(value).width(2000).url()}
          alt={value.alt || ''}
        />
      ),
    },
    /* ... */
  }}
/>

Working with a CMS also means all of your assets like images are hosted for you, and you can control the size, quality, and format of the image on the fly.

<div className="text-sm/5 max-sm:text-gray-700 sm:font-medium">
  {dayjs(post.publishedAt).format('dddd, MMMM D, YYYY')}
</div>
{post.author && (
  <div className="mt-2.5 flex items-center gap-3">
    {post.author.image && (
      <img
       className="aspect-square size-6 rounded-full object-cover"
       src={image(post.author.image).width(64).height(64).url()}
       alt=""
      />
    )}
    <div className="text-sm/5 text-gray-700">
      {post.author.name}
    </div>
  </div>
)}

Like you might do with front matter in Markdown, you can also enrich content with custom fields. For example, we added a featured boolean field to the blog post schema so you can highlight some posts in a special section on the blog.

Sanity in particular is a paid product, but they have a pretty generous free tier which is more than enough to play around. And if you wanted to try out a different headless CMS, I think the Sanity integration we’ve put together here will still serve as a great informative example of how you might approach wiring things up with another tool.

And that’s Radiant! Have a look under the hood, kick the tires, and let us know what you think.

Like all of our templates, it’s included with a one-time purchase Tailwind UI all-access license, which is the best way to support our work on Tailwind CSS and make it possible for us to keep building awesome stuff for you for years to come.

(The post Radiant: A beautiful new marketing site template appeared first on Tailwind CSS Blog.)

We just released Headless UI v2.1 for React, which dramatically simplifies our transition APIs and adds support for rendering multiple dialogs as siblings.

We just released Headless UI v2.1 for React, which dramatically simplifies our transition APIs and adds support for rendering multiple dialogs as siblings.

​Simplified transition API

We’ve made transitions way easier in v2.1 by adding a new transition prop to all of the built-in components you might want to transition, and adding data attributes for each transition stage so you can add transition styles by just throwing some classes on the target element:

import { Menu, MenuButton, MenuItem, MenuItems } from '@headlessui/react'

function Example() {
  return (
    <Menu>
      <MenuButton>My account</MenuButton>
      <MenuItems
        transition
        className={`
          transition ease-out
          data-[closed]:scale-95 data-[closed]:opacity-0
          data-[enter]:duration-200 data-[leave]:duration-300
        `}
      >
        {/* Menu items… */}
      </MenuItems>
    </Menu>
  )
}

There are four data attributes you can use to target the different stages of your transitions:

• data-closed: The styles the element should transition from when entering and to when leaving.
• data-enter: Styles to apply while the element is entering, like a duration or easing curve.
• data-leave: Styles to apply while the element is leaving, like a duration or easing curve.
• data-transition: Styles to apply while the element is entering or leaving, useful for sharing values between both stages.

You can even stack these attributes to use different closed styles for entering and leaving. For example this dialog slides in from the left, but slides out to the right:

import { Dialog } from '@headlessui/react'
import { useState } from 'react'

function Example() {
  let [isOpen, setIsOpen] = useState(false)

  return (
    <>
      <button onClick={() => setIsOpen(true)}>Open dialog</button>
      <Dialog
        open={isOpen}
        onClose={() => setIsOpen(false)}
        transition
        className={`
          transition ease-out duration-300
          data-[closed]:opacity-0
          data-[closed]:data-[enter]:-translate-x-8
          data-[closed]:data-[leave]:translate-x-8
        `}
      >
        {/* Dialog content… */}
      </Dialog>
    </>
  )
}

And for transitioning regular HTML elements or other components, you can still use the <Transition> component but with the new data attribute APIs:

import { Transition } from '@headlessui/react'
import { useState } from 'react'

function Example() {
  const [isShowing, setIsShowing] = useState(false)

  return (
    <>
      <button onClick={() => setIsShowing((isShowing) => !isShowing)}>Toggle</button>
      <Transition show={isShowing}>
        <div className="transition duration-300 data-[closed]:opacity-0">
          I will fade in and out
        </div>
      </Transition>
    </>
  )
}

We’ve already updated all of Tailwind UI to use this new transition API and the code is a lot simpler and lighter. Take a look at the Modal Dialog, Dropdown, Slide-over, Flyout Menu, or Select Menu components for more examples.

All of the existing APIs continue to work for backwards compatibility, but this new approach is what we’re going to recommend going forward.

Check out the updated Transition component documentation to learn more.

​Rendering multiple dialogs as siblings

In Headless UI v2.1 you can finally render multiple dialogs at the same time without nesting one inside the other.

This can be really helpful when two unrelated parts of your application need to show a dialog at the same time — for example maybe you already have some sort of confirmation dialog open but another part of your app detects that you’ve lost network connectivity or your session has timed-out and needs to throw up a new dialog on top.

Here’s what something like that might look like with Catalyst, the application UI kit we’ve been working on recently:

We keep track of the order in which each dialog is opened, and whichever one was opened last is the one that will close when you press escape or click outside the dialog.

To start using this stuff today, just install the latest version of Headless UI:

$ npm i @headlessui/react@latest

If you run into any issues, let us know on GitHub!

(The post Headless UI v2.1: Simplified transition API and improved multi-dialog support appeared first on Tailwind CSS Blog.)

We just released a new version of prettier-plugin-tailwindcss which adds support for removing unnecessary whitespace and duplicate classes when sorting.

We just released a new version of prettier-plugin-tailwindcss which adds support for removing unnecessary whitespace and duplicate classes when sorting.

​Cleaning up unnecessary whitespace

When you’re copying around class names or deleting a class name from the middle of a list, it’s easy to end up with some extra whitespace that needs to be cleaned up.

Now our Prettier plugin will handle this for you automatically, so you don’t need to clean it up yourself.

function MyComponent({ children }) {
  return (
    <div className=" mx-auto  max-w-7xl px-6 lg:px-8 ">
      {children}
    </div>
  )
}

​Removing duplicate classes

Our VS Code extension has warned you about duplicate class names for a long time, but now our Prettier plugin can remove those duplicate classes for you automatically.

function MyComponent({ children }) {
  return (
    <div className="flex bg-zinc-100 bg-zinc-100 px-4">
      {children}
    </div>
  )
}

To start playing with these improvements in your own projects, just install the latest version:

$ npm i prettier-plugin-tailwindcss@latest

If you run into any issues, let us know on GitHub!

(The post Automatically clean up whitespace and duplicate class names appeared first on Tailwind CSS Blog.)

We just published the first major update to Catalyst since releasing the development preview, with two new application layouts, navbar and sidebar components, description lists, and more.

We just published the first major update to Catalyst since releasing the development preview, with two new application layouts, navbar and sidebar components, description lists, and more.

We’re also pumped to share that with the release of Headless UI v2.0 for React, Catalyst is no longer in development preview — it’s officially stable and you can start using it in production today without worrying about breaking changes in the underlying dependencies.

Check out our brand new live demo site to see what a full Catalyst project looks and feels like after these updates for yourself.

​New application layout components

One of the hardest things about trying to get started on a new project idea is getting past the blank canvas so you can actually start building something.

In this update we’ve added two new application layout components to make it easy to give your project a shape and structure so you have something you can start building with.

The first layout is a classic sidebar layout, that moves the sidebar into a collapsible mobile menu on smaller screens:

import { SidebarLayout } from '@/components/sidebar-layout'
import { Navbar } from '@/components/navbar'
import { Sidebar } from '@/components/sidebar'

function Example({ children }) {
  return (
    <SidebarLayout
      sidebar={<Sidebar>{/* Sidebar menu */}</Sidebar>}
      navbar={<Navbar>{/* Navbar for mobile screens */}</Navbar>}
    >
      {/* Your page content */}
    </SidebarLayout>
  )
}

The second is a simpler stacked layout with a horizontal navigation menu, which is often a great fit for apps with fewer pages:

import { StackedLayout } from '@/components/stacked-layout'
import { Navbar } from '@/components/navbar'
import { Sidebar } from '@/components/sidebar'

function Example({ children }) {
  return (
    <StackedLayout
      navbar={<Navbar>{/* Top navigation menu */}</Navbar>}
      sidebar={<Sidebar>{/* Sidebar content for mobile menu */}</Sidebar>}
    >
      {/* Your page content */}
    </StackedLayout>
  )
}

And they both support dark mode too, of course:

We worked really hard to get the APIs for all of these components right, making it easy to position things where you need them to be, optionally include icons, incorporate dropdown menus, and more.

The final result turned out feeling really simple which is exactly what we were going for, and I think you’ll find they are a real delight to build with.

Check out the Sidebar layout documentation and Stacked layout documentation to get started, then dig into the Navbar and Sidebar components to learn how to structure all of the navigation items.

​Description lists

When we were working on the application layouts we realized we didn’t have any great content to demo them with, so we cooked up a DescriptionList component to fill in that big empty space.

import { DescriptionDetails, DescriptionList, DescriptionTerm } from '@/components/description-list'

function Example() {
  return (
    <DescriptionList>
      <DescriptionTerm>Customer</DescriptionTerm>
      <DescriptionDetails>Michael Foster</DescriptionDetails>

      <DescriptionTerm>Event</DescriptionTerm>
      <DescriptionDetails>Bear Hug: Live in Concert</DescriptionDetails>

       {/* ... */}
    </DescriptionList>
  )
}

It’s a really simple API that works just like the HTML <dl> element, but is nicely styled, responsive, and with dark mode support of course.

Check out the Description list documentation for more details.

​Page headings

More components we needed to make the demo look good! We’ve added Heading and Subheading components you can use to quickly and consistently title things in your UI.

import { Heading, Subheading } from '@/components/heading'

function Example() {
  return (
    <div>
      <Heading>Heading</Heading>
      <Subheading>Subheading</Subheading>
    </div>
  )
}

You can control which HTML heading element is rendered using the level prop, and like everything else, they’re responsive with built-in dark mode support.

See the Heading documentation for more examples.

​Dividers

Saved the best for last — Catalyst now includes a gray line you can put in between things.

import { Divider } from '@/components/divider'

function Example() {
  return <Divider />
}

We worked tirelessly on this one, and are so proud to make this part of your application development process easier.

Check out the Divider documentation — it does have one prop at least.

Catalyst is included with your Tailwind UI all-access license at no additional cost, so if you’ve got a license, log in and download the latest version to start building.

Looking forward to seeing what you do with it!

(The post Catalyst: Application layouts, navigation menus, description lists, and more appeared first on Tailwind CSS Blog.)

Nothing beats actually building something real with your own tools when it comes to finding ways to make things better. As we’ve been working on Catalyst these last several months, we’ve been making dozens of improvements to Headless UI that let you write even less code, and make the developer experience even better.

Nothing beats actually building something real with your own tools when it comes to finding ways to make things better.

As we’ve been working on Catalyst these last several months, we’ve been making dozens of improvements to Headless UI that let you write even less code, and make the developer experience even better.

We just released Headless UI v2.0 for React, which is the culmination of all this work.

Here’s all the best new stuff:

• Built-in anchor positioning
• New checkbox component
• HTML form components
• Improved hover, focus and active state detection
• Combobox list virtualization
• New website and improved docs

Add it to your project by installing the latest version of @headlessui/react from npm:

npm install @headlessui/react@latest

If you’re upgrading from v1.x, check out the upgrade guide to learn more about what’s changed.

​Built-in anchor positioning

We’ve integrated Floating UI directly into Headless UI, so you never have to worry about dropdowns going out of view or being obscured by other elements on the screen.

Use the new anchor prop on the Menu, Popover, Combobox, and Listbox components to specify the anchor positioning, then fine-tune the placement with CSS variables like --anchor-gap and --anchor-padding:

import { Menu, MenuButton, MenuItem, MenuItems } from '@headlessui/react'

function Example() {
  return (
      <Menu>
        <MenuButton>Options</MenuButton>
        <MenuItems
          anchor="bottom start"
          className="[--anchor-gap:8px] [--anchor-padding:8px]"
        >
          <MenuItem>
            <button>Edit</button>
          </MenuItem>
          <MenuItem>
            <button>Duplicate</button>
          </MenuItem>
          <hr />
          <MenuItem>
            <button>Archive</button>
          </MenuItem>
          <MenuItem>
            <button>Delete</button>
          </MenuItem>
        </MenuItems>
      </Menu>
  )
}

What makes this API really nice is that you can tweak the styles at different breakpoints by changing the CSS variables using utility classes like sm:[--anchor-gap:4px].

Check out the anchor positioning documentation for each component for all of the details.

​New checkbox component

We’ve added a new headless Checkbox component to complement our existing RadioGroup component, making it easy to build totally custom checkbox controls:

import { Checkbox, Description, Field, Label } from '@headlessui/react'
import { CheckmarkIcon } from './icons/checkmark'
import clsx from 'clsx'

function Example() {
  return (
    <Field>
      <Checkbox
        defaultChecked
        className={clsx(
          'size-4 rounded border bg-white dark:bg-white/5',
          'data-[checked]:border-transparent data-[checked]:bg-blue-500',
          'focus:outline-none data-[focus]:outline-2 data-[focus]:outline-offset-2 data-[focus]:outline-blue-500',
        )}
      >
        <CheckmarkIcon className="stroke-white opacity-0 group-data-[checked]:opacity-100" />
      </Checkbox>
      <div>
        <Label>Enable beta features</Label>
        <Description>
          This will give you early access to any awesome new features we're developing.
        </Description>
      </div>
    </Field>
  )
}

Checkboxes can be controlled or uncontrolled, and can automatically sync their state with a hidden input to play nicely with HTML forms.

Take a look at the Checkbox documentation to learn more.

​HTML form components

We’ve added a whole new set of components that just wrap native form controls, but do all of the tedious work of wiring up IDs and aria-* attributes for you automatically.

Here’s what it looked like to build a simple <input> field with a properly associated <label> and description before:

<div>
  <label id="name-label" for="name-input">Name</label>
  <input
    id="name-input"
    aria-labelledby="name-label"
    aria-describedby="name-description"
  />
  <p id="name-description">Use your real name so people will recognize you.</p>
</div>

And here’s what it looks like with these new components in Headless UI v2.0:

import { Description, Field, Input, Label } from '@headlessui/react'

function Example() {
  return (
    <Field>
      <Label>Name</Label>
      <Input name="your_name" />
      <Description>Use your real name so people will recognize you.</Description>
    </Field>
  )
}

The new Field and Fieldset components also cascade disabled states like the native <fieldset> element, so you can easily disable an entire group of controls at once:

import { Button, Description, Field, Fieldset, Input, Label, Legend, Select } from '@headlessui/react'
import { regions } from './countries'

export function Example() {
  const [country, setCountry] = useState(null)

  return (
    <form action="/shipping">
      <Fieldset>
        <Legend>Shipping details</Legend>
        <Field>
          <Label>Street address</Label>
          <Input name="address" />
        </Field>
        <Field>
          <Label>Country</Label>
          <Description>We currently only ship to North America.</Description>
          <Select
            name="country"
            value={country}
            onChange={(event) => setCountry(event.target.value)}
          >
            <option></option>
            <option>Canada</option>
            <option>Mexico</option>
            <option>United States</option>
          </Select>
        </Field>
        <Field disabled={!country}>
          <Label className="data-[disabled]:opacity-40">State/province</Label>
          <Select name="region" className="data-[disabled]:opacity-50">
            <option></option>
            {country && regions[country].map((region) => <option>{region}</option>)}
          </Select>
        </Field>
        <Button>Submit</Button>
      </Fieldset>
    </form>
  )
}

We expose the disabled state using a data-disabled attribute in the rendered HTML. This lets us expose it even on elements that don’t support the native disabled attribute like the associated <label> element, making it really easy to fine-tune the disabled styles for each element.

All in all we’ve added 8 new components here — Fieldset, Legend, Field, Label, Description, Input, Select, and Textarea.

For more details, start with the Fieldset documentation and work your way through the rest.

​Improved hover, focus and active state detection

Using hooks from the awesome React Aria library under the hood, Headless UI now adds smarter data-* state attributes to your controls that behave more consistently across different devices than the native CSS pseudo-classes:

• data-active — like :active, but is removed when dragging off of the element.
• data-hover — like :hover, but is ignored on touch devices to avoid sticky hover states.
• data-focus — like :focus-visible, without false positives from imperative focusing.

<!-- Rendered `Button` -->
<button data-active data-hover data-focus class="bg-indigo-600 data-[active]:bg-indigo-700 data-[hover]:bg-indigo-500 data-[focus]:outline ...">
  Submit
</button>

To learn more about why applying these styles using JavaScript is important, I highly recommend reading through Devon Govett’s excellent blog series on this topic:

• Building a Button Part 1: Press Events
• Building a Button Part 2: Hover Interactions
• Building a Button Part 3: Keyboard Focus Behavior

The web never ceases to surprise me with the amount of effort it takes to actually make nice things.

​Combobox list virtualization

We’ve integrated TanStack Virtual into Headless UI to support list virtualization when you need to put a hundred thousand items in your combobox because, hey, that’s what the boss told you to do.

Use the new virtual prop to pass in all of your items, and use the ComboboxOptions render prop to provide the template for an individual option:

import { Combobox, ComboboxButton, ComboboxInput, ComboboxOption, ComboboxOptions } from '@headlessui/react'
import { ChevronDownIcon } from '@heroicons/react/20/solid'
import { useState } from 'react'

const people = [
  { id: 1, name: 'Rossie Abernathy' },
  { id: 2, name: 'Juana Abshire' },
  { id: 3, name: 'Leonel Abshire' },
  { id: 4, name: 'Llewellyn Abshire' },
  { id: 5, name: 'Ramon Abshire' },
  // ...up to 1000 people
]

function Example() {
  const [query, setQuery] = useState('')
  const [selected, setSelected] = useState(people[0])

  const filteredPeople =
    query === ''
      ? people
      : people.filter((person) => {
          return person.name.toLowerCase().includes(query.toLowerCase())
        })

  return (
    <Combobox
      value={selected}
      virtual={{ options: filteredPeople }}
      onChange={(value) => setSelected(value)}
      onClose={() => setQuery('')}
    >
      <div>
        <ComboboxInput
          displayValue={(person) => person?.name}
          onChange={(event) => setQuery(event.target.value)}
        />
        <ComboboxButton>
          <ChevronDownIcon />
        </ComboboxButton>
      </div>
      <ComboboxOptions>
        {({ option: person }) => (
          <ComboboxOption key={person.id} value={person}>
            {person.name}
          </ComboboxOption>
        )}
      </ComboboxOptions>
    </Combobox>
  )
}

Check out the new virtual scrolling documentation to learn more.

​New website and improved docs

To go along with this major release, we’ve also significantly revamped the documentation and given the website a fresh coat of paint:

Head over to the new headlessui.com to check it out!

(The post Headless UI v2.0 for React appeared first on Tailwind CSS Blog.)

We’re hiring a Design Engineer and Staff Software Engineer to work on some ambitious new projects with us. Both roles are fully remote, with a salary of $275,000 USD.

We’re hiring a Design Engineer and Staff Software Engineer to work on some ambitious new projects with us.

We’re small on purpose, and we take a lot of pride in punching above our weight. We’re six people, but Tailwind CSS is installed over 30 million times per month, and is used by the world’s biggest companies to build the world’s best websites.

We’re independent and profitable, and we do this because it’s fun. We’re in this to enjoy the actual work we do every day, not to grind it out in hopes of a big exit in the future.

If this sounds like the sort of place you’d like to work, we’d love to hear from you.

​Design Engineer

We’re hiring a Design Engineer to build ambitious interfaces, prototype new ideas, and push the boundaries of what’s possible with Tailwind CSS.

You’d be responsible for things like:

• Design and build ambitious marketing websites for our open-source projects, commercial products, and events like Tailwind Connect.
• Design and prototype new features for Tailwind CSS to make sure we’re always using the full potential of the platform.
• Create new components and templates for Tailwind UI, taking them all the way from initial concept to shipped.
• Enhance our documentation with visual demos to make it easy for people to understand and apply complex CSS features in their work.
• Teach and inspire our audience by breaking down interesting things you design and build as articles and social media posts.

Here are some real examples of projects you would have worked on in the last few months:

• Design and build the Tailwind Connect microsite — including coming up with a unique Markdown-driven badge design experience.
• Craft the first components for Catalyst — our first fully-componentized React UI kit.
• Build a tool for capturing videos for our Showcase site — to automate creating preview videos that feel like a real person scrolling through a site.
• Build interactive demos to explain dynamic viewport units — to include in the documentation along with the release of Tailwind CSS v3.4.

After you start, you’d work on upcoming projects like:

• Design and build an interactive microsite for the Tailwind CSS v4.0 release with thoughtfully crafted demos that communicate the most important improvements in a visual way.
• Prototype APIs for scroll-driven animations in Tailwind CSS, finding the right balance between simplicity and flexibility, and making our users feel like they have superpowers.
• Explore new color palettes with automatic dark mode support, carefully figuring out the right abstractions for different levels of hierarchy that apply universally to different projects.
• Research and design text-shadow support for Tailwind CSS, finally.

This is a fully remote position with a salary of $275,000 USD, open to candidates in the Eastern (UTC-5) to Central European (UTC+1) timezones.

Learn more about this role and apply →

​Staff Software Engineer

We’re hiring a Staff Software Engineer to work on Tailwind CSS, Headless UI, and our supporting ecosystem of tools like the Tailwind CSS IntelliSense extension for VS Code.

You’d have a wide range of responsibilities, including:

• Build and document new features for projects like Tailwind CSS and Headless UI.
• Contribute improvements to upstream projects like Lightning CSS, Next.js, and Vite.
• Maintain CI workflows and automations for running tests and building releases.
• Manage issues and contributions from the community to our open-source repositories.
• Define and uphold engineering standards with a focus on code quality, performance, and documentation, to make sure we’re always shipping work we can be proud of.
• Manage project priorities and adjust scope to meet project deadlines without sacrifing on top-level goals.

Here are some real examples of projects you would have worked on in the last few months:

• Create a Rust library for extracting utility class names — a tool that can scan an entire directory of template files as fast as possible and extract potential class names in parallel.
• Write a fast CSS parser in TypeScript — to parse only the exact amount of detail needed by Tailwind’s internals, looking for domain-specific shortcuts to make it significantly faster than existing libraries for our needs.
• Fix an issue with scroll-locking in Headless UI — to make sure scrollable elements in dialogs can still be scrolled on iOS.
• Campaign for new APIs we need in Vite — prepare a compelling argument for improvements we need to support Tailwind CSS and collaborate with the Vite core team to prototype a solution.

After you start, you’d work on upcoming projects like:

• Develop a Tailwind CSS bundler plugin for Next.js — to generate your CSS using the module graph instead of scanning the file system, working with our contacts at Vercel to get it right.
• Design a set of IDE integration APIs for Tailwind CSS — first-class, stable, documented APIs that editor teams like JetBrains can rely on to add things like completions, lint warnings, class sorting, and more to their tools.
• Design, build, and document a Tooltip component for Headless UI — making sure it’s fully accessible, with a flexible but delightful API.
• Build a backwards compatibility layer for Tailwind CSS v4.0 — re-introduce support for JavaScript configuration files, explore codemod tooling, and make sure existing community plugins are as compatible as possible with the new engine.

This is a fully remote position with a salary of $275,000 USD, open to candidates in the Eastern (UTC-5) to Central European (UTC+1) timezones.

Learn more about this role and apply →

(The post We're hiring a Design Engineer + Staff Engineer appeared first on Tailwind CSS Blog.)

Last summer at Tailwind Connect I shared a preview of Oxide — a new high-performance engine for Tailwind CSS that we’ve been working on, designed to simplify the developer experience and take advantage of how the web platform has evolved since Tailwind was first released.

Last summer at Tailwind Connect I shared a preview of Oxide — a new high-performance engine for Tailwind CSS that we’ve been working on, designed to simplify the developer experience and take advantage of how the web platform has evolved in recent years.

The new engine was originally going to ship as a v3.x release, but even though we’re committed to backwards compatibility, this feels so clearly like a new generation of the framework that it deserves to be v4.0.

It’s still early and we’ve got a lot of work to do, but today we’re open-sourcing our progress and tagging the first public v4.0.0-alpha so you can start experimenting with it and help us get to a stable release later this year.

I’ll try keep it brief to save some of the excitement for the stable release, but if you like to play with very early and experimental stuff, there should be plenty of information here to get you going.

​A new engine, built for speed

The new engine is a ground-up rewrite, using everything we know about the framework now to better model the problem space, making things faster with a lot less code.

• Up to 10x faster — we can do a full build of the Tailwind CSS website in 105ms instead of 960ms, or our Catalyst UI kit in 55ms instead of 341ms.
• Smaller footprint — the new engine is over 35% smaller installed, even with the heavier native packages we ship like the parts we’ve rewritten in Rust and Lightning CSS.
• Rust where it counts — we’ve migrated some of the most expensive and parallelizable parts of the framework to Rust, while keeping the core of the framework in TypeScript for extensibility.
• One dependency — the only thing the new engine depends on is Lightning CSS.
• Custom parser — we wrote our own CSS parser and designed our own data structures tailored to our needs, making parsing over 2x as fast for us as it was with PostCSS.

​Unified toolchain

Tailwind CSS v4 isn’t just a plugin anymore — it’s an all-in-one tool for processing your CSS. We’ve integrated Lightning CSS directly into the framework so you don’t have to configure anything about your CSS pipeline.

• Built-in @import handling — no need to setup and configure a tool like postcss-import.
• Built-in vendor prefixing — you don’t have to add autoprefixer to your projects anymore.
• Built-in nesting support — no plugins needed to flatten nested CSS, it works out of the box.
• Syntax transforms — modern CSS features like oklch() colors and media query ranges are transpiled to syntax with better browser support.

We’re still shipping a PostCSS plugin, but we’re also exploring first-party bundler plugins, and we’re shipping an official Vite plugin with this first alpha release that you can try out today.

​Designed for the modern web

We’re looking into the future with Tailwind CSS v4 and trying to build a framework that’s going to feel cutting edge for years to come.

• Native cascade layers — we’re using real @layer rules now, which solves a ton of specificity problems we’ve wrestled with in the past.
• Explicitly defined custom properties — we use @property to define our internal custom properties with proper types and constraints, making it possible to do things like transition background gradients.
• Using color-mix for opacity modifiers — making it easier than ever to use our opacity modifier syntax when using CSS variables for colors, or even adjusting the opacity of currentColor.
• Container queries in core — we’ve added support for container queries directly to core, with new @min-* and @max-* variants to support container query ranges.

We’re also working on refreshing our color palette with wide gamut colors, and introducing support for other modern CSS features like @starting-style, anchor positioning, and more.

​Composable variants

The new architecture makes it possible to compose together variants that act on other selectors, like group-*, peer-*, has-*, and a new not-* variant we’re introducing for v4.

In earlier releases, variants like group-has-* were explicitly defined in the framework, but now group-* can compose with the existing has-* variant, which can compose with other variants like focus:

<div class="group">
  <div class="group-has-[&:focus]:opacity-100">
  <div class="group-has-focus:opacity-100">
    <!-- ... -->
  </div>
</div>

There’s no limits to this composability, and you can even write stuff like group-not-has-peer-not-data-active:underline if for some horrible reason that’s what you need to do.

​Zero-configuration content detection

You’ll notice that at least in these early alpha releases, it’s not even possible to configure your content paths. For most projects, you’re never going to need to do this ever again — Tailwind just finds your template files for you.

We do this using one of two ways depending on how you’ve integrated Tailwind into your project:

• Using the PostCSS plugin or the CLI, Tailwind will crawl your entire project looking for template files, using a bunch of heuristics we’ve built in to keep things fast, like not crawling directories that are in your .gitignore file, and ignoring binary file formats.

• Using the Vite plugin, we rely on the module graph. This is amazing because we know exactly what files you’re actually using, so it’s maximally performant, and with no false positives or negatives. We’re hoping to expand this approach outside of the Vite ecosystem with other bundler plugins in the future.

We’ll introduce a way to configure content paths explicitly in the future for sure, but we’re curious to see how well this automatic approach works for everyone — it’s working awesome in our own projects.

​CSS-first configuration

A major goal of Tailwind CSS v4.0 is making the framework feel CSS-native, and less like a JavaScript library.

Once you’ve installed it, you add it to your project with a regular CSS @import statement:

@import "tailwindcss";

And instead of setting up all of your customizations in a JavaScript configuration file, you just use CSS variables:

@import "tailwindcss";

@theme {
  --font-family-display: "Satoshi", "sans-serif";

  --breakpoint-3xl: 1920px;

  --color-neon-pink: oklch(71.7% 0.25 360);
  --color-neon-lime: oklch(91.5% 0.258 129);
  --color-neon-cyan: oklch(91.3% 0.139 195.8);
}

The special @theme directive tells Tailwind to make new utilities and variants available based on those variables, letting you use classes like 3xl:text-neon-lime in your markup:

<div class="max-w-lg 3xl:max-w-xl">
  <h1 class="font-display text-4xl">
    Data to <span class="text-neon-cyan">enrich</span> your online business
  </h1>
</div>

Adding new CSS variables behaves like extend did in earlier versions of the framework, but you can override a whole set of variables by clearing the namespace with syntax like --color-*: initial before defining all of your custom values:

@import "tailwindcss";

@theme {
  --color-*: initial;

  --color-gray-50: #f8fafc;
  --color-gray-100: #f1f5f9;
  --color-gray-200: #e2e8f0;
  /* ... */
  --color-green-800: #3f6212;
  --color-green-900: #365314;
  --color-green-950: #1a2e05;
}

We’re still fine-tuning some of the naming conventions, but you can explore the default theme on GitHub to see what’s available to customize.

If you don’t want to explicitly clear the default theme and would rather start from scratch, you can import "tailwindcss/preflight" and "tailwindcss/utilities" directly to skip importing the default theme:

@import "tailwindcss";
@import "tailwindcss/preflight" layer(base);
@import "tailwindcss/utilities" layer(utilities);

@theme {
  --color-*: initial;
  --color-gray-50: #f8fafc;
  --color-gray-100: #f1f5f9;
  --color-gray-200: #e2e8f0;
  /* ... */
  --color-green-800: #3f6212;
  --color-green-900: #365314;
  --color-green-950: #1a2e05;
}

We also make all of your theme values available as native CSS variables in your custom CSS:

:root {
  --color-gray-50: #f8fafc;
  --color-gray-100: #f1f5f9;
  --color-gray-200: #e2e8f0;
  /* ... */
  --color-green-800: #3f6212;
  --color-green-900: #365314;
  --color-green-950: #1a2e05;
}

This makes it easy to reference any of your theme values in arbitrary values without needing the theme() function:

<div class="p-[calc(var(--spacing-6)-1px)]">
  <!-- ... -->
</div>

It also makes it possible to use your theme values when working with UI libraries like Framer Motion, without having to use the resolveConfig() function:

import { motion } from "framer-motion"

export const MyComponent = () => (
  <motion.div
    initial={{ y: 'var(--spacing-8)' }}
    animate={{ y: 0 }}
    exit={{ y: 'var(--spacing-8)' }}
  >
    {children}
  </motion.div>
)

​What’s changed

We don’t take breaking changes lightly, but there are a few things we’re doing differently in v4 so far that are worth sharing:

• Removed deprecated utilities — we’ve removed utilities we stopped documenting a long time ago like text-opacity-*, flex-grow-*, and decoration-slice in favor of their modern replacements like text-{color}/*, grow-*, and box-decoration-slice.
• PostCSS plugin and CLI are separate packages — the main tailwindcss package doesn’t include these anymore since not everyone needs them, instead they should be installed separately using @tailwindcss/postcss and @tailwindcss/cli.
• No default border color — the border utility used to default to gray-200, but now it defaults to currentColor like the browser does. We made this change to make it harder to accidentally introduce a wrong gray into your project if you’re using zinc or slate or something else as your main gray.
• Rings are 1px by default — the ring utility used to be a 3px blue ring by default, now it’s a 1px ring using currentColor. We find ourselves using the ring-* utilities as an alternative to borders in our projects, and using outline-* for focus rings, so we think making things consistent here is a helpful change.

There are a handful of other really low-level implementation detail changes that might surface in some way in your projects, but nothing deliberate like these changes. If you bump into anything surprising, let us know.

​Roadmap to v4.0

This new engine is a ground-up rewrite, and up until now we’ve been focused entirely on this reimagined developer experience using the new configuration approach.

We put an enormous amount of value in backwards compatibility, and that’s where the bulk of the work lies before we can tag a stable v4.0 release later this year.

• Support for JavaScript configuration files — reintroducing compatibility with the classic tailwind.config.js file to make migrating to v4 easy.
• Explicit content path configuration — making it possible to tell Tailwind exactly where your templates are when automatic content detection isn’t good enough for your setup.
• Support for other dark modes — right now we only support dark mode using media queries, and still need to reimplement the selector and variant strategies.
• Plugins and custom utilities — we don’t have support for plugins, or for writing custom utilities that automatically work with variants yet. Obviously we will make this work before a stable release.
• Prefix support — there’s no way to configure a prefix for your classes yet, but we’ll bring it back for sure.
• Safelists and blocklists — can’t force Tailwind to generate certain classes or prevent it from generating other classes yet.
• Support for important configuration — there’s no way to make utilities all generate with !important right now, but we plan to implement it.
• Support for the theme() function — this isn’t needed for new projects because you can use var() now, but we’ll implement it for backwards compatibility.
• Standalone CLI — we haven’t worked on a standalone CLI for the new engine yet, but will absolutely have it before the v4.0 release.

Aside from that, I’m sure we’ll find a lot of bugs to fix, some exciting new CSS features to sneak in, and refine some of these new APIs that need some more polish before a proper release.

I don’t want to make promises on a specific release timeline, but I’d personally love to mark v4.0 as stable before the summer holiday season kicks in.

​Try out the alpha

We’ve tagged a couple alpha releases already, and you can start playing with it in your projects today.

If you’re using the Tailwind CSS IntelliSense extension for VS Code, make sure you switch to the prerelease version from the extension page, and if you’re using our Prettier plugin, make sure you install the latest version.

If you find an issue, please let us know on GitHub. We really want this thing to be bullet-proof before we tag a stable release and reporting any problems you find will help us a lot.

​Using Vite

Install the Tailwind CSS v4 alpha and our new Vite plugin:

$ npm install tailwindcss@next @tailwindcss/vite@next

Then add our plugin to your vite.config.ts file:

import tailwindcss from '@tailwindcss/vite'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [tailwindcss()],
})

Finally, import Tailwind in your main CSS file:

@import "tailwindcss";

​Using PostCSS

Install the Tailwind CSS v4 alpha and the separate PostCSS plugin package:

$ npm install tailwindcss@next @tailwindcss/postcss@next

Then add our plugin to your postcss.config.js file:

module.exports = {
  plugins: {
    '@tailwindcss/postcss': {}
  }
}

Finally, import Tailwind in your main CSS file:

@import "tailwindcss";

​Using the CLI

Install the Tailwind CSS v4 alpha and the separate CLI package:

$ npm install tailwindcss@next @tailwindcss/cli@next

Next, import Tailwind in your main CSS file:

@import "tailwindcss";

Finally, compile your CSS using the CLI tool:

$ npx @tailwindcss/cli@next -i app.css -o dist/app.css

(The post Open-sourcing our progress on Tailwind CSS v4.0 appeared first on Tailwind CSS Blog.)

Today’s the day — we just published the first development preview of Catalyst, our first fully-componentized, batteries-included application UI kit for React, just in time for your holiday hacking sessions.

Today’s the day — we just published the first development preview of Catalyst, just in time for your holiday hacking sessions.

Catalyst is our first fully-componentized, batteries-included application UI kit — real React components with thoughtfully designed APIs that build on each other to create a real component architecture, the same way we’d do it in a real application.

Check out the live demo, read the documentation, and if you’re a Tailwind UI All-Access customer, download it and try it out in a new project today.

Catalyst is currently in development preview and there’s a lot more to come, but we’re releasing it today so you can play with it right away as we continue to build new components and find ways to make it an even better experience.

​Your components, not ours

With Catalyst, we set out to build a UI kit that tomorrow’s Stripe or Linear would feel good about using to build their products — design-obsessed teams who want to own their UI components, and would never choose an off-the-shelf library.

So it’s not a dependency you install, instead you download the source and copy the components into your own project where they become the starting point for your own component system:

Want to change the border radius on your buttons? Just open button.tsx and change some classes. You don’t need to open a GitHub issue and try to convince us to expose a new configuration option.

Catalyst is a “disappearing UI kit” — six months after you’ve installed it, you should almost forget it wasn’t you who built the original components.

​Design is in the details

Getting the visual style right on a project like this is hard. We went into it with a few goals:

• Be competitive — we wanted to design something that could hold its own next to some of the nicest interfaces on the web today.
• Be timeless — we didn’t want to design something that would look dated in 6 months because it leaned too hard into specific trends.
• Be productive — whatever we designed needed to feel fast and efficient to real users, not just look great in a Dribbble shot.

It took a lot of work and there were a lot of trade-offs to balance, but I’m really in love with where we ended up:

To be competitive, we invested in lots of details like subtle backdrop blurs on dropdown menus, perfecting the way shadows and borders blend with each other on form controls, and thoughtful use of animation in things like dialogs and toggle switches.

To be timeless, we tried to strike the right balance between flat and skeuomorphic design, with just enough depth cues that our components will look great even if the trends change a bit in either direction.

We also took inspiration from the browser, and used unopinionated blue focus rings to avoid picking a treatment that might soon look out of fashion.

To be productive, we worked carefully to make sure there was still plenty of whitespace, but that the UI was still dense enough to fit plenty of information on the screen.

We also limited our use of transitions and animations only to places where it felt important, and even then tried to keep them fast so it never feels like you’re waiting on the UI.

Catalyst also ships with full dark mode support, and anything you build with Catalyst components automatically adapts between light and dark modes.

It’s not obvious, but there are a ton of little details we had to change to make things look their best in dark mode, like adjusting shadows, changing outer rings to inner rings to mimic the change in lighting, and more.

​Modeled after HTML

We spent a lot of time working on the component APIs, trying very hard to make things really easy to drop in and use right away, without compromising on flexibility.

It’s common for UI libraries to use APIs like this:

function Example() {
  return (
    <TextField
      name="product_name"
      label="Product name"
      description="Use the name you'd like people to see in their cart."
    />
  )
}

But with all the props living on the same component, it starts to get difficult to do things like add a class just to the <input> element itself.

Ultimately that led us to APIs that closely mirrored HTML, where it’s rare that a single component renders more than one element.

Creating a text field with Catalyst looks like this for example:

import { Description, Field, Label } from '@/components/fieldset'
import { Input } from '@/components/input'

function Example() {
  return (
    <Field>
      <Label>Product name</Label>
      <Description>Use the name you'd like people to see in their cart.</Description>
      <Input name="product_name" />
    </Field>
  )
}

By keeping things composable like this, it makes it really easy to do things like constrain the width of the input, without constraining the width of any of the other elements:

import { Description, Field, Label } from '@/components/fieldset'
import { Input } from '@/components/input'

function Example() {
  return (
    <Field>
      <Label>Product name</Label>
      <Description>Use the name you'd like people to see in their cart.</Description>
      <Input name="product_name" />
      <Input name="product_name" className="max-w-sm" />
    </Field>
  )
}

It also makes it easy to move the description below the input, instead of above:

import { Description, Field, Label } from '@/components/fieldset'
import { Input } from '@/components/input'

function Example() {
  return (
    <Field>
      <Label>Product name</Label>
      <Description>Use the name you'd like people to see in their cart.</Description>
      <Input name="product_name" className="max-w-sm" />
      <Description>Use the name you'd like people to see in their cart.</Description>
    </Field>
  )
}

It took a lot of experimenting to figure out the right way to make these APIs work, especially around details like adding layout styles to the right children, but the payoff was worth it, and these components are really a delight to use.

​Powered by the next generation of Headless UI

We released the first version of Headless UI back in the summer of 2020, but it’s been just over a year now since the last significant feature release because of all the work we’ve been focused on with Tailwind CSS itself.

Catalyst was the perfect excuse to get our hands dirty with Headless UI again, and we quickly found lots of ways to improve the project to simplify the code in Catalyst itself.

We just published Headless UI v2.0.0-alpha.1, which includes a ton of new stuff:

• Built-in anchor positioning — using Floating UI, components like Menu, Listbox, and more can now automatically position their popovers to be anchored to their trigger, adapting as needed to changes in the viewport.
• Headless checkbox component — we’ve added a headless Checkbox component to complement our existing RadioGroup component, making it easy to build totally custom checkbox controls.
• HTML form components — we’ve added Input, Select, Textarea, Label, Description, Fieldset, and Legend components that handle all of the ID generation and aria-* attribute mapping you need to do to connect form fields together.
• Improved hover and focus-visible detection — using hooks from the awesome React Aria library under the hood, Headless UI now adds smarter data-hover and data-focus attributes to your controls that behave more consistently across different devices than the native pseudo-classes.
• Combobox list virtualization — the next version of Headless UI can now handle giant lists of combobox options with no performance issues.

…with plenty of other improvements to come, including a date picker, tooltips, and more.

These improvements are React-only for now during this early alpha period, but we plan to bring all of these improvements to Vue as well before tagging v2.0.

We’ll have documentation published for this stuff really soon, but couldn’t resist getting Catalyst out before the holidays, even if it meant publishing the Headless UI docs a few days later.

​Try it out

Catalyst is a free update for all Tailwind UI All-Access customers, and you can download it and start playing with this first release today.

More work went into getting everything we’re releasing today just right than you could ever imagine, but we’re eager for feedback and ways it could be improved, so build some stuff with it and let us know what you think.

We’re going to take a couple weeks to recharge over the holidays, but we’ll be right back into Catalyst in the new year, working on new components like application layouts, comboboxes, command palettes, tooltips, and more.

(The post Introducing Catalyst: A modern UI kit for React appeared first on Tailwind CSS Blog.)

There’s nothing like building a major new product for finding all the features you wish you had in your own tools, so we capitalized on some of that inspiration and turned it into this — Tailwind CSS v3.4.

There’s nothing like building a major new product for finding all the features you wish you had in your own tools, so we capitalized on some of that inspiration and turned it into this — Tailwind CSS v3.4.

As always the improvements range from things you’ve been angry about for years, to supporting CSS features you’ve never even heard of and probably can’t even use at work.

• Dynamic viewport units: Full-height elements that actually work on mobile.
• New :has() variant: Style parent elements based on their children.
• Style children with the * variant: We’ll probably regret giving you this one.
• New size-* utilities: Set width and height at the same time, finally.
• Balanced headlines with text-wrap utilities: No more max-width tweaking or responsive line breaks.
• Subgrid support: That grid feature you struggle to understand, finally in Tailwind CSS.
• Extended min-width, max-width, and min-height scales: Now min-w-12 is a real class.
• Extended opacity scale: For those moments when neither 60% or 70% were quite right.
• Extended grid-rows-* scale: Might as well make it match the column scale.
• New forced-colors variant: Easily fine-tune your site for forced colors mode.
• New forced-color-adjust utilities: For even more forced colors fine-tuning.

All the good stuff is in that list, but check out the release notes for a couple more details that weren’t exciting enough to earn a spot in this post.

Upgrade your projects by installing the latest version of tailwindcss from npm:

$ npm install tailwindcss@latest

Or try out all of the new features on Tailwind Play, right in your browser.

​Dynamic viewport units

When the vh unit was added to browsers we all got so excited — finally a way to build full-height application layouts and stuff without drilling height: 100% through 17 layers of DOM! But mobile devices and their damn disappearing menu bars spoiled all the fun, effectively making the vh unit just a cruel reminder of a future that could’ve been so great.

Well we’ve got a new future now — dvh, lvh, and svh are designed to accommodate that disappearing browser chrome and Tailwind CSS v3.4 supports them out of the box:

<div class="h-dvh">
  <!-- ... -->
</div>

We’ve added the following new classes by default:

If you need other values, you can always use arbitrary values too like min-h-[75dvh].

Browser support is pretty great for these nowadays, so unless you need to support Safari 14 you can start using these right away.

​New :has() variant

The :has() pseudo-class is the most powerful thing that’s been added to CSS since flexbox. For the first time ever, you can style an element based on its children, not just based on its parents. It even makes it possible to style based on subsequent siblings.

Here’s an example where the parent gets a colored ring if the radio button inside of it is checked:

<label class="has-[:checked]:ring-indigo-500 has-[:checked]:text-indigo-900 has-[:checked]:bg-indigo-50 ..">
  <svg fill="currentColor">
    <!-- ... -->
  </svg>
  Google Pay
  <input type="radio" class="accent-indigo-500 ..." />
</label>

I feel like I’ve found a new use-case for :has() every week while working on this new UI kit we’ve been building for the last few months, and it’s replaced a crazy amount of JavaScript in our code.

For example, our text inputs are pretty complicated design-wise and require a little wrapper element to build. Without :has(), we had no way of styling the wrapper based on things like the :disabled state of the input, but now we can:

export function Input({ ... }) {
  return (
    <span className="has-[:disabled]:opacity-50 ...">
      <input ... />
    </span>
  )
}

This one is pretty bleeding edge but as of literally today it’s now supported in the latest version of all major browsers. Give it a few weeks for any Firefox users to install today’s update and we should be able to go wild with it.

​Style children with the * variant

Here’s one people have wanted for literally ever — a way to style children from the parent using utility classes.

We’ve added a new * variant that targets direct children, letting you do stuff like this:

<div>
  <h2>Categories:<h2>
  <ul class="*:rounded-full *:border *:border-sky-100 *:bg-sky-50 *:px-2 *:py-0.5 dark:text-sky-300 dark:*:border-sky-500/15 dark:*:bg-sky-500/10 ...">
    <li>Sales</li>
    <li>Marketing</li>
    <li>SEO</li>
    <!-- ... -->
  </ul>
</div>

Generally I’d recommend just styling the children directly, but this can be useful when you don’t control those elements or need to make a conditional tweak because of the context the element is used in.

It can be composed with other variants too, for instance hover:*:underline will style any child when the child is hovered.

Here’s a cool way we’re using that to conditionally add layout styles to different child elements in the new UI kit we’re working on:

function Field({ children }) {
  return (
    <div className="data-[slot=description]:*:mt-4 ...">
      {children}
    </div>
  )
}

function Description({ children }) {
  return (
    <p data-slot="description" ...>{children}</p>
  )
}

function Example() {
  return (
    <Field>
      <Label>First name</Label>
      <Input />
      <Description>Please tell me you know your own name.</Description>
    </Field>
  )
}

See that crazy data-[slot=description]:*:mt-4 class? It first targets all direct children (that’s the *: part), then filters them down to just items with a data-slot="description" attribute using data-[slot=description].

This makes it easy to target only specific children, without having to drop all the way down to a raw arbitrary variant.

Looking forward to seeing all the horrible stuff everyone does to make me regret adding this feature.

​New size-* utilities

You’re sick of typing h-5 w-5 every time you need to size an avatar, you know it and I know it.

In Tailwind CSS v3.4 we’ve finally added a new size-* utility that sets width and height at the same time:

<div>
  <img class="h-10 w-10" ...>
  <img class="h-12 w-12" ...>
  <img class="h-14 w-14" ...>
  <img class="size-10" ...>
  <img class="size-12" ...>
  <img class="size-14" ...>
</div>

We’ve wanted to add this forever but have always been hung up on the exact name — size-* felt like so much to type compared to w-* or h-* and s-* felt way too cryptic.

After using it for a few weeks though I can say decisively that even with the longer name, it’s way better than separate width and height utilities. Super convenient, especially if you’re combining it with variants or using a complex arbitrary value.

​Balanced headlines with text-wrap utilities

How much time have you spent fiddling with max-width or inserting responsive line breaks to try and make those little section headings wrap nicely on your landing pages? Well now you can spend zero time on it, because the browser can do it for you with text-wrap: balance:

<article>
  <h3 class="text-balance ...">Beloved Manhattan soup stand closes<h3>
  <p>New Yorkers are facing the winter chill...</p>
</article>

We’ve also added text-pretty which tries to avoid orphaned words at the end of paragraphs using text-wrap: pretty:

<article class="text-pretty ...">
  <h3>Beloved Manhattan soup stand closes<h3>
  <p>New Yorkers are facing the winter chill...</p>
</article>

The nice thing about these features is that even if someone visits your site with an older browser, they’ll just fallback to the regular wrapping behavior so it’s totally safe to start using these today.

​Subgrid support

Subgrid is a fairly recent CSS feature that lets an element sort of inherit the grid columns or rows from its parent, make it possible to place its child elements in the parent grid.

<div class="grid grid-cols-4 gap-4">
  <!-- ... -->
  <div class="grid grid-cols-subgrid gap-4 col-span-3">
      <div class="col-start-2">06</div>
  </div>
  <!-- ... -->
</div>

We’re using subgrid in the new UI kit we’re working on for example in dropdown menus, so that if any item has an icon, all of the other items are indented to keep the text aligned:

<div role="menu" class="grid grid-cols-[auto_1fr]">
  <a href="#" class="grid-cols-subgrid col-span-2">
    <svg class="mr-2">...</svg>
    <span class="col-start-2">Account</span>
  </a>
  <a href="#" class="grid-cols-subgrid col-span-2">
    <svg class="mr-2">...</svg>
    <span class="col-start-2">Settings</span>
  </a>
  <a href="#" class="grid-cols-subgrid col-span-2">
    <span class="col-start-2">Sign out</span>
  </a>
</div>

When none of the items have an icon, the first column shrinks to 0px and the text is aligned all the way to left.

Check out the MDN documentation on subgrid for a full primer — it’s a bit of a tricky feature to wrap your head around at first, but once it clicks it’s a game-changer.

​Extended min-width, max-width, and min-height scales

We’ve finally extended the min-width, max-width, and min-height scales to include the full spacing scale, so classes like min-w-12 are actually a real thing now:

<div class="min-w-12">
  <!-- ... -->
</div>

We should’ve just done this for v3.0 but never really got around to it — I’m sorry and you’re welcome.

​Extended opacity scale

We’ve also extended the opacity scale to include every step of 5 out of the box:

<div class="opacity-35">
  <!-- ... -->
</div>

Hopefully that means a few less arbitrary values in your markup. I’m coming for you next 2.5%.

​Extended grid-rows-* scale

We’ve also bumped the baked-in number of grid rows from 6 to 12 because why not:

<div class="grid grid-rows-9">
  <!-- ... -->
</div>

Maybe we’ll get even crazier and bump it to 16 in the next release.

​New forced-colors variant

Ever heard of forced colors mode? Your site probably looks pretty bad in it.

Well now you can’t blame us at least, because Tailwind CSS v3.4 includes a forced-colors variant for adjusting styles for forced colors mode:

<form>
  <input type="checkbox" class="appearance-none forced-colors:appearance-auto ...">
</form>

It’s really useful for fine-tuning totally custom controls, especially combined with arbitrary values and a working knowledge of CSS system colors.

​New forced-color-adjust utilities

We’ve also added new forced-color-adjust-auto and forces-color-adjust-none utilities to control how forced colors mode affects your design:

<fieldset>
  <legend>Choose a color</legend>
  <div class="forced-color-adjust-none ...">
    <label>
      <input class="sr-only" type="radio" name="color-choice" value="white" />
      <span class="sr-only">White</span>
      <span class="size-6 rounded-full bg-white"></span>
    </label>
    <label>
      <input class="sr-only" type="radio" name="color-choice" value="gray" />
      <span class="sr-only">Gray</span>
      <span class="size-6 rounded-full bg-gray-300"></span>
    </label>
    <!-- ... -->
  </div>
</fieldset>

These should be used pretty sparingly, but they can be useful when it’s critical that something is rendered in a specific color no matter what, like choosing the color of something someone is buying in an online store.

To learn more about all this forced colors stuff, I recommend reading “Forced colors explained: A practical guide” on the Polypane blog — by far the most useful post I’ve found on this topic.

If you’ve been paying close attention, you might be wondering about Oxide, the engine improvements we previewed at Tailwind Connect this summer.

We’d originally slated those improvements for v3.4, but we have a few things still to iron out and so many of these other improvements had been piling up that we felt it made sense to get it all out the door instead of holding it back. The Oxide stuff is still coming, and will be the headlining improvement for the next Tailwind CSS release in the new year.

In the mean time, dig in to Tailwind CSS v3.4 by updating to the latest version with npm:

$ npm install tailwindcss@latest

With :has() and the new * variant, your HTML is about to get more out of control than ever.

(The post Tailwind CSS v3.4: Dynamic viewport units, :has() support, balanced headlines, subgrid, and more appeared first on Tailwind CSS Blog.)

We just released Heroicons v2.1 which includes a brand new micro style — a full set of almost three hundred 16×16 icons designed for tighter, higher density UIs.

We’ve wanted to do a set this size for a long time, but it wasn’t until we started working on a new React UI kit project earlier this year that we finally needed them badly enough to bite the bullet and design them.

In Catalyst (our new UI kit), we’ve tried to really thread the needle in terms of giving things enough room to breathe but also keeping things dense enough that the applications you build with it actually feel productive to use.

We’re using lots of 14px text which looks great in the UI, but when we tried to incorporate our existing 20×20 icons, they felt just a tiny bit too big and unbalanced.

Most people would have probably just scaled the icons down and moved on, but we’re not most people, for better or for worse.

Icons always turn out a lot sharper when you design them for the exact size they’re going to be used, so we began the process of redrawing every icon from scratch, carefully trimming down the amount of detail on an icon-by-icon basis to make sure they render nice and crisp at their intended size.

About a month later we had a brand new set of 288 icons, meticulously crafted for higher density interfaces like what we’ve been working on with Catalyst.

You can check out all of the new icons on the Heroicons website, start designing with them using our official Heroicons Figma library, and add them to your projects with our React and Vue libraries.

(The post Heroicons Micro: What are these, icons for ants? appeared first on Tailwind CSS Blog.)

We just released Studio — a beautiful new agency website template we’ve been working on for the last couple of months for Tailwind UI.

We just released Studio — a beautiful new agency website template we’ve been working on for the last couple of months for Tailwind UI.

We built it with Next.js, MDX, and of course Tailwind CSS, and it’s the first template we’ve published using the new Next.js App Router.

Designing an agency template is an interesting project, because creative agencies commonly use their own website to show off some really flashy, bespoke ideas, and using a template just kind of feels strange when the goal is to show what your own company is capable of.

So we tried to approach this one with two goals in mind to actually make it useful to people:

1. Teach people how to do some of the cool stuff you see on flash agency sites — I’ve always believed our templates are just as (if not more) valuable as an educational resource than as simply templates, so we wanted to use this template as an opportunity to show off how we’d build a lot of the cool interactive and animated details you see on these sorts of sites.
2. Design it for agencies that don’t sell design — there are a lot of agencies out there who just focus on engineering work, and a lot of the time those companies struggle to stand out design-wise. We tried to design this template in a way that it didn’t depend on tons of screenshots of design work and stuff to look good, so that an agency that focuses on code could use it as a starting point for their own site.

I think what we came up with nailed these two goals and I’m really proud of how it all turned out.

Check out the live preview as always for the full experience — there are tons of cool details in this one that you have to see in the browser to really appreciate.

​Delightfully animated

One of the unspoken rules of agency websites is that they’ve gotta be flashy. We didn’t go full replace-the-mouse-cursor or render-the-entire-site-with-WebGL but we did look for opportunities to tastefully introduce animations and interactivity wherever we could.

For instance, we built a light declarative component-based API around some features of Framer Motion to make it easy to do scroll-triggered entrance animations:

The authoring experience for these types of animations turned out really nice — just wrap the stuff you want to fade in with a FadeIn or FadeInStagger component and you’re in business:

function Clients() {
  return (
    <div className="mt-24 rounded-4xl bg-neutral-950 py-20 sm:mt-32 sm:py-32 lg:mt-56">
      <Container>
        <FadeIn className="flex items-center gap-x-8">
          <h2 className="text-center font-display text-sm font-semibold tracking-wider text-white sm:text-left">
            We’ve worked with hundreds of amazing people
          </h2>
          <div className="h-px flex-auto bg-neutral-800" />
        </FadeIn>
        <FadeInStagger faster>
          <ul
            role="list"
            className="mt-10 grid grid-cols-2 gap-x-8 gap-y-10 lg:grid-cols-4"
          >
            {clients.map(([client, logo]) => (
              <li key={client}>
                <FadeIn>
                  <Image src={logo} alt={client} unoptimized />
                </FadeIn>
              </li>
            ))}
          </ul>
        </FadeInStagger>
      </Container>
    </div>
  )
}

We also added this nice little animation to the logo where the mark is filled with a solid color on hover:

This little detail looks small but interestingly you can’t really do it without client-side navigation, because the animation would re-run when clicking the logo to go back to the homepage. Using a framework like Next.js, we’re able to keep the logo filled in while hovering, even across URL changes, which feels a lot nicer.

The menu drawer animation turned out really nice as well, pushing the whole page down when it opens:

If you look closely, the logo and button don’t just naively change color either — it’s actually driven precisely by the position of the sheet that’s sliding down, and the logo is actually partially white and partially black at the same time when the edge of the sheet is intersecting with it.

Another detail I really love is this interaction we came up with for the images on the case study pages:

We wanted the whole site to feel black and white, but showing black and white images all of the time didn’t feel right. So we came up with this treatment where the image starts off black and white, and the saturation animates back in as the image gets close to the center of the screen when scrolling. We also show the full color image on hover.

We were also careful to try and implement all of these animations in a way that’s mindful of people with vestibular motion disorders and are sensitive to these types of big animations. Using Framer Motion’s useReducedMotion hook and the motion-safe variant in Tailwind, we do things like conditionally disable the navigation menu animation, and limit the scroll-driven entrance animations to opacity only so things aren’t moving on the screen.

​Developer-centric case study and blog workflow

Studio includes support for both case studies and blog posts, and as you might have guessed if you’ve played with any of our other templates, we used this an excuse to integrate MDX into the project.

Here’s an example of what a basic case study looks like — authored mostly in markdown with some common metadata and support for custom components mixed in to the content:

import logo from '@/images/clients/phobia/logomark-dark.svg'
import imageHero from './hero.jpg'
import imageJennyWilson from './jenny-wilson.jpeg'

export const caseStudy = {
  client: 'Phobia',
  title: 'Overcome your fears, find your match',
  description:
    'Find love in the face of fear — Phobia is a dating app that matches users based on their mutual phobias so they can be scared together.',
  summary: [
    'Find love in the face of fear — Phobia is a dating app that matches users based on their mutual phobias so they can be scared together.',
    'We worked with Phobia to develop a new onboarding flow. A user is shown pictures of common phobias and we use the microphone to detect which ones make them scream, feeding the results into the matching algorithm.',
  ],
  logo,
  image: { src: imageHero },
  date: '2022-06',
  service: 'App development',
  testimonial: {
    author: { name: 'Jenny Wilson', role: 'CPO of Phobia' },
    content:
      'The team at Studio went above and beyond with our onboarding, even finding a way to access the user’s microphone without triggering one of those annoying permission dialogs.',
  },
}

export const metadata = {
  title: `${caseStudy.client} Case Study`,
  description: caseStudy.description,
}

## Overview

Noticing incredibly high churn, the team at Phobia came to the conclusion that, instead of having a
fundamentally flawed business idea, they needed to improve their onboarding process.

Previously users selected their phobias manually but this led to some users selecting things they
weren’t actually afraid of to increase their matches.

To combat this, we developed a system that displays a slideshow of common phobias during
onboarding. We then use malware to surreptitiously access their microphone and detect when they
have audible reactions. We measure the pitch, volume and duration of their screams and feed that
information to the matching algorithm.

The next phase is a VR version of the onboarding flow where users are subjected to a series of
scenarios that will determine their fears. We are currently developing the first scenario, working
title: “Jumping out of a plane full of spiders”.

## What we did

<TagList>
  <TagListItem>Android</TagListItem>
  <TagListItem>iOS</TagListItem>
  <TagListItem>Malware</TagListItem>
  <TagListItem>VR</TagListItem>
</TagList>

<Blockquote
  author={{ name: 'Jenny Wilson', role: 'CPO of Phobia' }}
  image={{ src: imageJennyWilson }}
>
  The team at Studio went above and beyond with our onboarding, even finding a
  way to access the user’s microphone without triggering one of those annoying
  permission dialogs.
</Blockquote>

<StatList>
  <StatListItem value="20%" label="Churn rate" />
  <StatListItem value="5x" label="Uninstalls" />
  <StatListItem value="2.3" label="App store rating" />
  <StatListItem value="8" label="Pending lawsuits" />
</StatList>

All of the typography styles for this template are totally custom and we took a bit of a different approach this time than we have in the past — instead of writing a bunch of complex CSS to avoid our typography styles clashing with any custom components in the MDX, we created a little remark plugin called remark-rehype-wrap that makes it possible to wrap chunks of Markdown content with a wrapper element.

This way, we could wrap anything that was vanilla Markdown content with a typography class, but make sure any custom components in the document were simply not wrapped, rather than try to craft the CSS in such a way that it ignores those parts of the tree.

Both approaches totally work but it’s always fun to try new ideas and see what you learn. I’m curious to see what a solution based on the new style queries feature coming to CSS might look like in the future too!

So that’s Studio! Pull it down, tear it apart, and see if you learn a couple of new tricks.

Like all of our templates, it’s included with a one-time purchase Tailwind UI all-access license, which is the best way to support our work on Tailwind CSS and make it possible for us to keep building awesome stuff for years to come.

(The post Meet Studio: Our beautiful new agency site template appeared first on Tailwind CSS Blog.)

Last month, over 200 people got together in my hometown of Cambridge, Ontario to hang out, talk shop, and get a peek behind the curtain at some of the new stuff we’ve been working on.

Tailwind Connect started out as an idea for throwing a little local meetup while the team was in town, but naturally ballooned into us renting a massive hall, hiring a crew of four videographers, and racking up a catering bill that put my own wedding to shame.

But even though we got a little carried away with the production, we really tried to make it feel more like a meetup than a full-blown conference. We ran the event in the evening and kept it to just one presentation, leaving as much time as possible for people to just hang out and connect over pizza and beer.

We originally expected it to be a “drive there after work” local-heavy event, but almost half of the people who attended traveled by plane to get here. So to help everyone make the most of their time here, we set up a Discord server for the event so people traveling in could make plans with each other, and rented out the patio at the Foundry Tavern next door to the event space for the afternoon to give people a reason to meet up early and make some new friends.

We opened up the doors for the event around 5:30pm and started the night with an hour long opening reception, where people could hang out and talk and enjoy some canapés.

One detail I thought we really nailed was the badges — when you bought a ticket we gave you a basic markdown field where you could write anything you wanted about yourself that might help people start interesting conversations with you.

I found myself looking at everyone’s badges all night and it was an awesome way to immediately break the ice and have something to talk about.