Tailwind

Due to an internal technical limitation, we are still running on Tailwind 3.3.2. This is because Tailwind migrated into using async APIs internally after 3.3.3 and the only way we can migrate is by using Suspense on the Tailwind component which would force everyone into using only renderAsync.

You can track our progress on this issue.

We do not yet support prose, and beyond that, we don’t yet support classes that might be resolved into selectors that are relatively complex. That is, selectors with more than a class lookup.

This is because we optimistically look into the selectors for class names and look these up later on the elements, and since prose, by using more complicated selectors, cannot be directly inlined without matching the selectors to the elements, it isn’t able to match the selectors appropriately.

This also means some other utilities do not work either, like the space-* utility.

The only exception for this inlining of styles is with media queries, as they are not inlinable. We do not do the same for hover: styles though, but since their support is not best, you probably won’t need it.

In the future, we will be inlining all the styles we can by actually matching the selectors against the elements themselves.

Currently, the component works, at a high level, going through the following steps:

1. Do a very surface-level rendering on the children to have something resembling the HTML
2. Run tailwind as a postcss plugin in the new fake rendered email template to generate a CSS stylesheet with all the styles of the template
3. Generate a map of all the class names pointing to their respective styles
4. Run recursively through all elements, and their children, by looking up class by class to add the appropriate styles to it while removing the classes

The biggest cause of limitation here is going to be 1.. Since that fake rendering process does not render the components, that means that, if a class name doesn’t appear in the resulting HTML, it won’t have its style either, so the class isn’t removed. Here’s an example:

const Component = ({ className, style }) => {
  console.log(className, style);
  return <div className={`bg-red-500`} style={style} />;
};

export default function Email() {
  return <Tailwind>
    <Component className="bg-blue-400" />
  </Tailwind>;
};

The prop for className will come in as bg-blue-400 which would seem like you can manipulate the className, but once you add it somewhere to the resulting HTML, like:

const Component = ({ className, style }) => {
  console.log(className, style);
  return <div className={`bg-red-500 ${className}`} style={style} />;
};

export default function Email() {
  return <Tailwind>
    <Component className="bg-blue-400" />
  </Tailwind>;
};

The email will render with a red background and a class="undefined" attribute as the class will have been removed. This means that manipulations are very unstable in the current version.

In a future version, the behavior is going to be of resolving the styles regardless of them appearing in the HTML, and it will not remove the classes that were inlined if they were done in a React component, so that you are able to manipulate both the className and style at the same time.

On small email templates this is most likely not going to be an issue, though.