Add a mention of Twind in the _tw documentation
Closed this issue · 7 comments
I think it would be nice to add mention of Twind in the _tw documentation. Something like a warning about the Tailwind purge process and suggesting Twind as a workaround.
Twind shim is a great solution for example if you want to add some custom tailwind classes in the Gutenberg editor or if you want to let the user customize the appearance (e.g. choose the margin size).
This would also avoid some issues like #3 or #11 and few more...
PS: What are the disadvantages of tw-in-js that you don't use it?
I'm working on a rewrite of the documentation now, and I can definitely see where you're coming from with this. I haven't started rewriting the documentation covering block editor styles, but I'll keep this in mind when I do.
Your question has made me consider whether I need a more explicit set of project goals as part of the documentation. I fundamentally want the project to be as focused on performance as Tailwind itself, and compiling all of the CSS into a single file prior to deployment is fundamental to that.
I also want _tw to treat websites with no JavaScript as first-class use cases, so I want to start from a point of effectively no JavaScript whatsoever.
I'm fairly liberal about adding developer dependencies to a project—hence the multiple approaches to linting in _tw—but conservative about any dependency that gets served to users or executed on a server.
More specifically with something like Twind, I don't want to choose between accepting flashes of unstyled content or worrying that the attribute I added to avoid the FOUC never gets removed should JavaScript fail for one reason or another, leaving part or all of a page blank. Using Twind in a single-page app makes more sense to me because if JavaScript fails, you've got bigger problems than your CSS; in this use case, it's possible for front-end compilation of CSS to be the only JavaScript in a project, and therefore a new point of failure where one wouldn't have existed before.
All of this said, I'd love to hear the other side of any of the arguments above, and I do agree that it makes sense to mention approaches like Twind for people with use cases that require it. I've never encountered one of those cases in my client work, but I know lots of developers have, and I want to acknowledge their requirements.
I agree with your arguments. I know that using a purged Tailwind CSS file is always preferable in terms of speed, caching and reliability, but Twind is still good enough for smaller production sites.
I just noted that several issues arose from the barrier posed by Tailiwnd's purging of classes and Twind is a "low-cost" solution to these problems.
Many WordPress developers use visual builders. Sometimes clients demand it (even if it's not the right way). Then the ability to use any class anywhere is very useful and comfy.
It's enough to point out to developers that there is a possibility. Currently, your answer is "if you'd like to be able to use arbitrary Tailwind classes in the block editor without limits, the only option would be not to use purging, which would result in a very large CSS file", which is not the full truth. (quote from #3)
PS: The probability that js won't work is very low, and even if it does, on the same principle we shouldn't add any js elements like sliders, modals, etc....
I may not have done a great job breaking down my previous response into two parts:
- Feedback on mentioning Twind in the upcoming documentation rewrite
- My response to your question, "What are the disadvantages of tw-in-js that you don't use it?"
I'm convinced that adding a mention of Twind to the documentation makes sense. I will likely mention other potential approaches and outline the different possibilities, as I understand that other people may need to use these even if I never have.
I will also admit that I wasn't familiar with Twind last June, and I should have made clearer that I meant my response to assume no added dependencies. There are certainly other ways to make arbitrary classes work in production—see the Tailpress plugin, for example.
The probability of JavaScript not working (or being disabled) varies so widely depending on a website's audience that I'm not comfortable making that assumption on a project meant to be broadly applicable. I'd also argue that, ideally, things like sliders and modals should themselves be built with progressive enhancement so that they continue to work when JavaScript doesn't load or is disabled.
(Right now, even the _tw generator's advanced settings form doesn't live up to this ideal, but I have a to-do item to change that.)
I'm in the process of expanding _tw's documentation, and I added the following:
https://underscoretw.com/docs/wordpress-tailwind/#arbitrary-classes
Do you have any suggestions for additional context you think I could add, or does that look good to you?
Thanks again!
I think it's ok, although it might better cover the issue in the header (?). E.g:
Why are my Tailwind classes not working?
This is likely due to you can't add arbitrary Tailwind classes in the block editor. It's because when you add Tailwind classes directly to your theme...
What would you think about keeping it the way it is on the page I linked above, but adding a Troubleshooting page with that header and explanation as one of the options?
That would allow me to expand the explanation to cover other possibilities (like issues with npm, etc.).
I've added a version of this to the new Troubleshooting page! I'm going to close out this issue, but I'm still open to feedback, so please let me know what you think.