October 2022

Tailwind 3.2, Tailwind Typography in comments, and a new approach to Typography theme-wide

I started preparing October’s changes around a week ago, knowing a Tailwind update was coming, and not expecting to add anything significant outside of that. My to-do list was simply:

• Update to Tailwind 3.2 and test those changes
• Begin using Tailwind Typography in comments

The update to Tailwind 3.2 went smoothly, and I didn’t encounter any issues during testing. Then I got to work trying to have Tailwind Typography apply to comments by default.

My initial thought was that if you’re going to apply the prose class to comments, maybe a smaller type scale should be applied by default, so I started testing that. (I quickly talked myself out of this approach, as it would include all of the classes for the smaller type scale even for users who don’t need comments and who may not notice the single prose-sm class in the wp_list_comments callback function.)

Many rabbit holes later, I emerged with a rethought approach to supporting Tailwind Typography in _tw (and an open issue in the Tailwind Typography repository that hopefully doesn’t turn out to be me seeing issues where there are none).

But the easy part first!

Tailwind 3.2

I suspect opinions vary widely about which parts of Tailwind 3.2 are and aren’t essential, but I’m very excited about dynamic breakpoints in particular. I expect to be littering my HTML markup with things like this:

<div class="min-[712px]:max-[877px]:right-16 ...">
	<!-- ... -->
</div>Code language: HTML, XML (xml)

But maybe, as the release notes suggest, your priority is to “…style the sibling of a checkbox when the checkbox’s parent is the third child in a list without leaving your HTML.” Who am I to judge?

Comment styling

It’s pretty rare for me to build a client site that uses comments, so when I was told that maybe it would be a good idea to have Tailwind Typography styles applied to the comment body, I strongly agreed. I also learned that I have a blindspot for the styling of WordPress comments, as this hadn’t come up in my work even once since I added Tailwind Typography support to _tw.

In order to add a single class to the comment body, I needed to create a callback function for wp_list_comments. I think this ends up being a positive change for the usability of _tw in general, as the process for customizing WordPress’s comment markup is under-documented, and it’s easy to begin thinking you need to do something drastic like add a custom walker class to your theme. And for those not using comments, the code will never run and can safely be ignored.

So, my apologies to those of you who have been using _tw on sites with comments. I’m very open to feedback on this and everything else comment-related—please let me know if there’s anything I’ve missed!

Tailwind Typography revisited

I really enjoy creating a new theme and having Tailwind Typography as my starting point, reflected both on the front end of the site and in the WordPress editor. I think it’s absolutely critical that there be a single place to write the foundational styles used to customize Tailwind Typography so that they apply in both locations.

My solution to this had been to create a prefixed version of the prose class and to use @apply to add element modifiers as appropriate. In a newly generated theme, you would find this:

$(prose-selector) {
	@apply prose prose-neutral max-w-none prose-a:text-primary;
}Code language: CSS (css)

And that approach worked really well! Almost flawlessly, even. I used it on a number of client sites, I’ve reviewed them recently, and they don’t need to be updated.

However, I’ve come to realize a few things about this approach:

• Adding element modifiers with @apply is fragile
  Now that Tailwind Typography uses the :where pseudo-class function, I would need to begin replacing the prose class with _tw’s custom prose selector within those pseudo-class functions, and running a regular expression on Tailwind’s output seems like a dicey proposition.
• Doing all of your styling with element modifiers can get out of hand
  A real-world example I’ve since replaced with CSS-in-JS syntax ran more than 700 characters.
• Element modifiers used outside of @apply don’t work as expected
  If we’re creating a base style to be used across multiple files in multiple contexts, element modifiers are great if there need to be slight variations between contexts, or if a different type scale is needed for a different screen size. The @apply method makes this harder to do well.

My initial understanding of element modifiers set them up in my mind as appropriate for quickly customizing the plugin’s output to match a client’s brand. I’ve come to realize that for client-supplied designs that require more than basic overrides, it makes far more sense to go with CSS-in-JS, and then to use element modifiers to override those site-wide defaults in specific locations (like for media queries).

This new approach means that all of the previously prefixed [slug]-prose classes are now simply prose. So if you want to make comments small, you would go to the comments callback function and add prose-sm, and it would work as expected.

To customize Typography’s output, use the included tailwind-typography.config.js file. It removes the max-width value by default, as I’ve yet to find a client site where I could use it. It also includes a color theme based on the neutral gray scale that Typography includes by default, pulling the primary color from your theme.json file for links. With that in place, you can trivially swap in other theme colors for things like bullets and counters, and you could quickly replace all of the included grays with a single body color if you needed to do so.

Coming soon

I’ll be completing a WooCommerce project in the next 3–4 weeks, so I’m hoping to have some recommendations there shortly. Work continues on documentation and screencasts, after which the _tw WP-CLI package no one has asked for and that I can’t be talked out of completing will finally launch.