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 @wordpress/eslint-plugin module and switched over to Prettier for all JavaScript.
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.
Motivated by a core proposal to change WordPress’s JavaScript coding standards to ones that would support Prettier, I went ahead and made that change within _tw itself. I was disappointed when the proposal was rejected at the time, and this is my opportunity to live my best coding standards life for my client work (while also keeping error messages out of npm install output).
Tailwind 3.3
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.)
Documentation overhaul
The documentation section of this website is now divided into three sections:
- Fundamentals
- In Depth
- Extras
I’ve also finished populated each of those three sections with all of the content I had originally planned.
Automatic versioning
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.
Tailwind Typography
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 body_class function.
In order to use the classes in the block editor, I’ve added a new JavaScript file at ./javascript/block-editor.css. This file provides a ready-made location for block-editor specific code (to register a block style, for example). It also includes code supporting Tailwind Typography for the block editor: This code first watches for the creation of the .wp-block-post-title and .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.
What’s next?
While adding the new documentation pages, I decided there’s one more I’d like to write, with a current working title of, “Styling Output from WordPress Core, WordPress Plugins and JavaScript Libraries.” (I’m open to feedback on the content of that page, and to requests for more documentation as well!)
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!