We use it in Tailwind CSS v4 for pill-shaped borders:

  .rounded-full {
    border-radius: calc(1px * infinity);
  }

...as opposed to what everyone has done historically, which is pick some arbitrary huge value like:

  .rounded-full {
    border-radius: 9999px;
  }

No real practical benefit, just satisfyingly more "correct".

Normally 50% is used as each corner is a quarter of the box. Any reason for not simply using that?

Thanks! It's a paid feature because we just spent around $250,000 developing the library. Couldn't have built it if we were just going to give it away and maintain it forever for free, our engineers are talented people and deservingly well-paid.

We are still healthy and profitable but revenue is down about 60% from peak, and continuing to trend down (I think mostly due to AI and open-source alternatives to the things we've historically charged for.)

So things are fine but we do need to reverse the trend which is why we are pretty focused on the commercial side of things right now.

We started a corporate sponsors/partner program recently, and I'm hoping that will earn us enough funding to focus more on the free/open-source stuff, since that's where we create the most value for the world anyways. Fingers crossed!

Adam, the Tailwind corporate sponsorship program is a great example of how to do it. I hope other notable open source projects learn from you.

Tailwind Labs (https://tailwindcss.com/) | Remote (Americas/Europe) | Full-time

We’re hiring a Design Engineer and Staff Software Engineer to work on Tailwind CSS, Headless UI, and related projects full-time.

- Design Engineer ($275k/yr): https://tailwindcss.com/careers/design-engineer

- Staff Software Engineer ($275k/yr): https://tailwindcss.com/careers/staff-software-engineer

We're small, independent, and profitable, with a team of just 6 people doing millions in revenue, and growing sustainably every year. You'd work directly with the founders on open-source software used by millions of people.

If you like the idea of working on a small team that cares about craft and isn't trying to achieve VC scale, I think this is a pretty awesome place to do your best work.

Love Tailwind and this is definitely a great opportunity. I just wish we figure out remote worldwide sometime in future.

I really like your culture and I'm considering applying, even though I'm in Romania, which is CET+2, and my profile might not fit all your requirements. I like the breadth of the tasks the Staff Software Engineer works on.

How does tailwind make money? I can't find any licensing or paid support options.

They sell a nice and polished collection of components and templates: https://tailwindui.com/all-access

That’s really cool.

The job postings say European time zones only, but this says Americas as well, can you clarify?

Hey! The job postings say Eastern (UTC-5) to Central European (UTC+1) — Eastern is the American east coast. Most important thing is overlap from around 9am – 12pm Eastern, so open to other US timezones as well if someone can sustainably be available during those hours.

We have a pretty collaborative/sync culture here. Everyone on the team really enjoys pair programming together or working through designs live in Figma, and wouldn't want to build the team in a way where there are people who can never work together because of timezones.

do you pay equity or just the cash?

The listing says you'll be "self-employed". I doubt that contractors get equity.

Can’t wait for that Tailwind IPO! /s

We considered it but it felt too magical to make any CSS variable under `:root` automatically drive the existence of utility classes. Putting things under a custom at-rule like `@theme` makes that opt-in, because we know anything you put there is actually intended to drive your utility classes.

Makes sense! Thanks for the reply, Adam.

Best of luck and thanks for driving progress forward with the project still.

It'll likely embed Node I'm afraid — the vast majority of Tailwind is written in JS so we'd have to rewrite all of that in Rust just for the standalone CLI, and migrating the entire project to Rust is impractical because we'd have no JS plugin story like we do now.

The current standalone tailwind CLI does not support external plugins like DaisyUI. It would be great if external plugins could be supported in the next CLI version, it will reduce the need to use npm for some projects.

This is handy for that specific need: https://github.com/dobicinaitis/tailwind-cli-extra

But I strongly agree.

Thanks, that looks like what I was looking for, did not find that when I looked few months back. I tried it now and had some issues with SIP check on macOS, started a discussion in the repo.

The way I was thinking this would work is that the standalone CLI could be configured to pick up plugins from a specified location. That way as long as the plugins are setup locally in the required format, the standalone CLI would be able to load them. The setup process need not require npm.

There is a sibling comment which mentioned a project which is trying to bundle DaisyUI specifically with the standalone CLI. That would solve my use case but will not be a generic solution for other plugins.

Bummer, but thanks for resetting my expectations :)

I'm feeling a similar disappointment here, although I'm sure this was carefully considered by the Tailwind team.

I've been working with a fully Rust-based web stack, and it's been such a joy. Tailwind compilation causes me to still deal with Node. I'd love to see that go away.

You can’t do things like hover styles, media queries, etc. with `style=`.

Re: separating presentation from page structure, Tailwind is designed around the opinion that that whole idea was mostly wrong, similar to how frameworks like React brought back the `onClick=` attribute when everyone was saying “unobtrusive JavaScript” was the best practice

Wrote about this in depth a few years ago shortly before releasing Tailwind, can read here:

https://adamwathan.me/css-utility-classes-and-separation-of-...

One thing worth noting is that & substitutes for `:is(...)` in spirit under the hood, which means there are some significant behavior differences between native CSS nesting and Sass.

Here's one:

  .foo .bar {
    .baz & {
      color: red;
    }
  }

In Sass, that would compile to:

  .baz .foo .bar {
    color: red;
  }

With native nesting, it effectively compiles to:

  .baz :is(.foo .bar) {
    color: red;
  }

The Sass version matches this DOM structure:

  <div class="baz">
    <div class="foo">
      <div class="bar">
        ...

But the native version matches all of these structures:

  <div class="baz">
    <div class="foo">
      <div class="bar">
        ...
  
  <div class="foo">
    <div class="baz">
      <div class="bar">
        ...

  <div class="foo baz">
    <div class="bar">
      ...

Not a criticism at all (the `:is(...)` behavior is a very useful and welcome enhancement to CSS) but a notable difference worth understanding coming from Sass.

I’ll criticize it.

I recognize this is a preview and I desperately hope this implementation isn’t kept around and treated as a quirk.

This implementation is extremely unintuitive given their explanation of the expected behavior of CSS Nesting and the & symbol.

To quote:

    The & signals to the browser “this is where I want the selector from outside this nest to go”.

Their explanation and the actual implementation result in a majorly different CSS selector.

The implemented functionality, however useful, makes no sense as a default if one can explicitly use :is to achieve this behavior like below.

    .foo .bar {
        .baz :is(&) {
        }
    }

The default should behave like they claim it does; simply replace & with the “outside” selector.

With this hidden :is behavior, migrating to native CSS nesting from SASS will be extremely difficult.

Notably, this is identical to the behavior you get from @scope's nesting, and from passing a complex selector to an `el.querySelector()`.

(We discussed adopting Sass's behavior in <https://github.com/w3c/csswg-drafts/issues/8310#issuecomment...> but ultimately dropped it.)

Agree important to note the difference but I personally prefer the nested CSS behavior. Much more sensible to use `&` as a logical operator

The stylesheets for CSS Zen Garden examples are more tightly coupled to the HTML than any other CSS I've ever seen in my life. They literally have no use against any other block of HTML than that one page.

hmmmm. u right

Well still I shouldn't have to decorate my html for css to something I feel is pretty reasonable to expect it to support

I've been following Jarred's progress on this on Twitter for the last several months and the various performance benchmarks he's shared are really impressive:

https://twitter.com/jarredsumner/status/1542824445810642946

Easy to dismiss this as "another JS build tool thing why do we need more of this eye roll" but I think this is worth a proper look — really interesting to follow how much effort has gone into the performance.

Agreed, I've also been following his work for a while now. Jarred is pulling off something very impressive here :) Congratulations on the public beta!

big agree!