Tailwind 3.3, better documentation, automatic versioning and a new approach to Typography theme-wide
I have lots to cover, and that’s not even getting into everyone’s favourite commit message: “Improve comments”! I continue to be surprised by how many things I find to rewrite each time I read through the comments that I wrote six months earlier.
But, since I didn’t write release notes after the changes I made in January, let’s start with those.
January’s linting changes
In January, I removed the
First flagged in this issue, the official WordPress ESLint plugin has fallen behind updates to Node.js, and it seems unlikely to catch up in the short term given that Gutenberg’s own development remains locked to older versions of Node.js.
npm install output).
There’s not much to say here: I updated all dependencies to support Tailwind 3.3, and I removed the first-party line clamp plugin since it’s now part of Tailwind itself.
(Tailwind 3.3 itself looks great! I’m most excited about the new line-height shorthand, but there’s lots to like.)
The documentation section of this website is now divided into three sections:
- In Depth
I’ve also finished populated each of those three sections with all of the content I had originally planned.
Following _s’s leading, _tw has always used the version number stored in the
_TW_VERSION constant to populate the
$ver parameter when enqueuing styles and scripts.
In the zip file generated by
npm run bundle, that version number is now automatically replaced with a timestamp, converted to base 36.
This marks my second consecutive set of release notes with “a new approach to Typography theme-wide” as one of the major changes. I am very much not aiming for a three-peat, and I’m happy with where things have landed.
Last time, I needed to disable my approach to element modifiers as I had encountered issues with them, but I hadn’t found solutions I felt comfortable deploying. Previously, _tw would add the
prose class via
@apply and conditionally alter the parent class name for the block editor. Upon detailed examination of the generated CSS, though, I found minor but still meaningful discrepancies in the output from Tailwind. (I also found an upstream issue in Tailwind Typography that has since been fixed—so it was time well spent reading through the raw CSS output line-by-line!)
My goals for a new approach to Tailwind Typography were as follows:
- The front-end CSS should use the standard
.prosemodifier and corresponding add-on modifier classes.
- CSS for the administration area shouldn’t break the block editor in any way.
- All Tailwind Typography modifiers should only need to be edited in one place.
By using a single constant—
_TW_TYPOGRAPHY_CLASSES at the top of
./theme/functions.php—and by populating it with the Tailwind Typography modifiers to be used site-wide, I was able to achieve each of those goals.
The modifiers from the above constant are added to all front-end wrapper elements via a new function,
_tw_content_class, inspired by WordPress core’s
.wp-block-post-content elements; once they’ve been added, the appropriate classes are appended to each wrapper, and mutation observers are created to ensure that those new class names are added again should the React component be updated, removing them in the process.
The appropriate classes are also added to TinyMCE’s body class for classic editor and ACF support.
After that, I would like to record some screencasts and redesign the _tw website using newer Tailwind UI components.
And then I may start working on some of the other open-source projects I have planned, as my to-do list for _tw is finally starting to feel under control. Details to follow!