Tailwind CSS heeft de front-end wereld stormenderhand veroverd. De utility-first aanpak maakt het mogelijk om razendsnel consistente designs te bouwen, zonder eindeloze CSS-bestanden of ongewenste style-leaks.
Maar wat als je in de WordPress-wereld werkt – en je klant wil per se Full Site Editing (FSE) met Gutenberg-blokken? Dan kom je erachter dat Tailwind en FSE niet bepaald de beste vrienden zijn.
In dit artikel leg ik uit waarom Tailwind fantastisch is voor developers, maar botst met de verwachtingen van klanten die FSE willen gebruiken – en wat je als front-ender kunt doen.
Waarom we als developers van Tailwind houden
✅ Utility-first CSS → geen context switching, gewoon flex gap-4 bg-neutral-900 text-white in je HTML.
✅ Design tokens centraal in tailwind.config.js → kleuren, spacing, fonts en breakpoints allemaal op één plek.
✅ Purge/Content scanning → alleen gebruikte classes in productie.
✅ Consistente UI-componenten → Figma → Tailwind = bijna 1-op-1 match.
Met Tailwind heb jij als developer volledige controle over je HTML + styling. Ideaal voor custom projecten of headless setups.
Waarom klanten juist FSE willen
Maar… jouw klant denkt niet in utility classes. Die denkt:
✅ “Ik wil makkelijk pagina’s opbouwen met blokken.”
✅ “Ik wil kleuren, spacing en typografie direct in de WordPress-editor kunnen aanpassen.”
✅ “Ik wil geen developer nodig hebben voor elke kleine wijziging.”
Daarom is Full Site Editing (FSE) bedacht:
- Via theme.json definieer je globale stijlen (kleuren, fonts, spacing).
- In Gutenberg kun je blokken visueel bewerken, met een editor die lijkt op een page builder.
- Geen extra frameworks nodig, alles zit in WordPress core.
Voor klanten dus super gebruiksvriendelijk.
Waar Tailwind en FSE botsen
En hier komt het pijnlijke punt. Tailwind en Gutenberg FSE werken conceptueel tegengesteld.
1. Dynamic classes vs. Tailwind purge
Tailwind verwijdert onnodige CSS via purge. Maar Gutenberg genereert dynamische HTML (met onvoorspelbare classnames en inline styles). Resultaat:
- Styling die soms verdwijnt in productie.
- Moeilijk te voorspellen welke classes je moet “safen” in je Tailwind config.
2. theme.json vs. tailwind.config.js
- FSE wil dat je kleuren, fonts en spacing definieert in theme.json.
- Tailwind wil dat je dit in tailwind.config.js doet.
➡️ Twee bronnen van waarheid, dus dubbele maintenance.
3. Editor UI vs. utility-first mindset
Gutenberg laat editors visueel blokken aanpassen. Tailwind verwacht dat je styling in code beheert.
- Je kunt Tailwind classes niet zomaar inline toevoegen in de editor.
- Editor-opties (zoals “kleurenpalet” of “spacing controls”) overrulen jouw Tailwind-styling.
4. Gutenberg CSS specificity & inline styles
Veel Gutenberg-blokken injecteren inline styles of hoge specificity selectors. Wil je daar met Tailwind overheen? Dan krijg je:
!importanthell- Custom block filters
- Extra PostCSS-hacks