Tailwind v3 WP Scaffold #156
Conversation
Update content to target only explicit files at root with coverage for all default WP templates (thanks Jon!). Added basic safelisting for bg and text primary, secondary, and tertiary colors. Removed additional plugins I had added previously.
- Added WP breakpoint (600px) often used in core styles - Container are now centered and have padding by default - Removed additional colors that were already being defined by theme.json Note: on the above for the colors, I’m just having the definitions come directly from theme.json, vs using the CSS variables (which are already CSS variables, or absolute values). I think its the same difference here since these are both coming from the same place anyway.
Added official plugins back to create a simpler DX and reduce friction during initial setup. Added a brief explanation for each and link to the plugin page in the Tailwind docs.
Setup separate file for tailwind helper JS Added logic for opt-in importing for color palettes in blocks (includes dedup to prevent overwrites) I tested this locally using a custom block style.
Colors are now retrieved directly from theme.json Colors with the primary, secondary, and tertiary slugs are now safelisted via regex CSS organization has been reorganized around the use of imports, vs one tailwind index file Content definitions updated with list from Jon Tested/confirmed pattern for ensuring WP class defs are not lost Plugins are included by default
Add extensions.json in .vscode config
Full coverage for Admin bar and certain gutenberg styles
Tailwind: Additional config updates
Fix arbitrary class typos for reduced motion
Add Doc Links
Update placement of purgecssWordPress safelist. Co-authored-by: Jon Christensen <[email protected]>
Tailwind Documentation
Add PurgeCSS WordPress SafeList
|
Definitely will, thanks @iansvo ! |
|
@dainemawer Super glad to see this initiative. I've dabbled with Tailwind a little and have been very impressed. The notes on where to use this version of the scaffold are great. In some ways this feels like the big transition from Classic Editor to Gutenberg. There will be growing pains but it feels worthwhile to invest the time. As has already been discussed, this may not be suitable to merge into trunk and may end up being in a separate I have a proposal to make the WP Scaffold modular here, #104 With a modular scaffold, the Tailwind flavor of WP Scaffold could become a separate composer package. And the Theme author can choose to then declare support for Tailwind with a change like, add_theme_support( 'tailwind' );Great work! |
|
@dsawardekar - great to have you weigh in here!! It's a pretty big shift, I agree. I'll definitely chime in on your PR to add my support. @Nikki-Jones @Firestorm980 @iansvo - any thoughts on Darshans proposal above? |
Feature/19138441 tailwind v3 testing
| @@ -0,0 +1,58 @@ | |||
| const themeJSON = require('../theme.json'); | |||
There was a problem hiding this comment.
Overall here, I like this feature. Just curious of a few things.
- Could we add a header comment to this file, explaining its purpose?
- Could we add JSDoc commenting to each of the functions?
- Would this ever be problematic functionality if the theme.json had certain things removed by an engineer?
There was a problem hiding this comment.
Didn't see this until now but yeah I'll see about addressing a few things like this.
@devinle Can you elaborate a bit more on number 3 for me?
The only thing I wonder about is integration with |
There was a problem hiding this comment.
I honestly don't have time to test this, but I love all the thought and work that has been put into it!
- I agree with Devin's questions
- I love Darshan's suggestion and agree maintaining a separate branch will not only be difficult, but has a high chance of losing viability (from my experience)
- If we use this, are we therefore no longer going to leverage theme.json for establishing custom properties, global element styles, typography, color pallets, spacing, etc? Either way, there will need to be documentation on how to (or not to) integrate theme.json (apologies if that is already in place). Theme.json is becoming more and more powerful... so it will be difficult if we are to bypass it long term.
- Make it as easy as possible for "non tailwind" folks to pick up - or it will be a pain point
- Is there guidance for block development? Core blocks? Custom blocks? Are we intended to use
@applyall over the place or are we using utility classes? If using@apply, how is that more efficient than a few lines of css? This will come up, so wanting to be sure this is thought through. - Please be sure TL, Nicholas and Fabian get their eyes on it when you feel it is at final review stage.
@dsawardekar any thoughts on this? |
@iansvo @Nikki-Jones @Firestorm980 - I think @joesnellpdx brings up some valid points here - how best can we tackle these in a meaningful way? @joesnellpdx some thoughts from me based on your feedback:
|
|
@joesnellpdx great points, I added some comments in this PR to address 1,3,5: #162 thanks! cc: @dainemawer @iansvo |
|
@dainemawer Since we have 2 completely different dependency trees, I think we should keep this simple to start with. Once the things that are common are well defined we can look at dependency management tools like lerna. I would keep a This is easy enough to automate with a CLI / generator. We could also do the same on composer.json side if required. |
|
What about having both themes in the theme folder? The readme can be clear that you need to choose one and delete the other. If we want to add a CLI we could then copy Next.js with their create-next-app package. https://github.com/vercel/next.js/tree/canary/packages/create-next-app
|
|
Good point, I think there is merit to @tobeycodes's suggestion. If the 2 themes are independent and do not actually share any of the baseline styles / code, then having 2 separate starter themes would be pretty clean. It will also be nicer to maintain because the pull requests won't have any merge conflicts across themes. |
Tailwind v3 doc updates
|
@dsawardekar @tobeycodes I really like the suggestion of doing something like: I'd like to outline some next steps here:
|
|
@dainemawer Toby's suggestion above still feels like a cleanest way to proceed here. Instead of having these changes inside The scaffold generation feels like a separate feature that we should brainstorm first. Right now as noted in the docs we are recommending to do a search-replace for scaffold strings like |
|
Resurrecting this thread to see if there are any clear action items that can be taken. I would like to rebuild some momentum on this initiative. |
|
Since we are not actively working on this at the moment I'm going to close the PR for now. The branch will still be there and the PR can always get revived |
Description of the Change
This PR adds Tailwind v3 support to
wp-scaffold- the team has worked hard to set up the correct implementation, considering all avenues and pitfalls regarding WordPress and Tailwind working together seamlessly.We have no intention of merging this PR into
trunk- Tailwind should be an opt-in for projects that think they can benefit from its fast prototyping and well-thought-out utility CSS.We have added plenty of documentation to this feature in order to ensure that getting up and running with the framework is as easy as possible:
Read the TAILWIND.md
Read the README.md
For more information and further help, you can reach out to the
#10up-tailwindchannel in Slack.Issue
Closes #105
How to test the Change
epic/tailwind-v3branch:wp-contentfolder with the extract filesnpm install.php,.js, file in the theme and runnpm run build- see thetemplates/page-tailwind.phpfor a working example.Changelog Entry
Credits
Props @Nikki-Jones @iansvo @Firestorm980 @dainemawer
Checklist: