How best to deal with content managed markup? #2298
Replies: 2 comments
-
'Pre-creating' classes isn't a bad thing, they're called components in Tailwind. Sometimes you just have to add your styling to a global stylesheet like that when dealing with dynamic content. So for your Alternatively you can have a list of whitelisted classes you approve for your editors and whitelist them from the purger. You agree before hand what classes they can use and no other will work. A more complicated approach would be to let the purger scan a text file or a dump of your CMS markup for classes and then re-compile the stylesheet but that's not really great either. |
Beta Was this translation helpful? Give feedback.
-
@paulpopus Yes, the more I think about it, the more I think it makes sense. The fact Tailwind even documents components seems that this is the best solution, so thanks for pointing that out My only concern is that it does seem to make Tailwind a bit redundant - other then the developer experience, why use Tailwind over Sass? I think that is something for me to consider personally though, I don't want to take away how great Tailwind has been for the project I've implemented it on, and so if this is the middle ground needed I will implement in the future |
Beta Was this translation helpful? Give feedback.
-
Hi all
I'm coming here off the back of this issue, and basically want to see if there is a general best practice for dealing with classes that come from a CMS?
To give some context, I have a site that has been built with Vue Storefront. This includes server side rendering so that pages are pre-compiled for performance etc. We also use Magentos pages and blocks to generate content, so that the client can build their own pages, customise call to actions and so on. The framework also uses data prefetching to make sure that the content is called and compiled into the source code.
However, it appears that there is a discrepancy between this way of working and how the purging of Tailwind classes occurs. Tailwind purges classes when compiling the page, which is completely logical, however if someone adds Tailwind classes into a CMS block, these classes aren't excluded from the purge and so remain unstyled, or fall back to the elements default styling.
I fail to believe that I am the first person to have used Tailwind in a CMS scenario, and so I am looking for guidance as to what people think the best practice would be.
Currently, I will create an element in the CMS like this:
However, unless any of those classes are already in as part of the template, they won't display. A workaround I have adopted is to basically create my own classes and exclude these from the purge, using
@apply
to style them, so the above becomes something like this:However with this we lose the flexibility, which is essentially the primary reason I wanted to use Tailwind for this project - the way I see it, doing it this way I might as well not use Tailwind at all.
So, I was wondering if there was any guidelines or best practices for how to deal with content management along with Tailwind. From a clients point of view, I can understand how confusing a classlist (
bg-primary-500 text-white rounded-full shadow-lg hover:bg-primary-100
) can be to style, but also like I say, pre-creating classes may seem to make Tailwind a bit redundant.Or is that what the solution is? Keep Tailwind classes purely for the template markup, and create CSS classes based on these purely for content management, and have these excluded from the purge?
Thanks all, I am grateful for any input anyone has
Beta Was this translation helpful? Give feedback.
All reactions