Repository navigation
Replies: 1 comment
|
This is a common architectural limitation when building visual editors on top of Tailwind. Tailwind generates CSS from class names discovered during the build. If a user creates a completely new class at runtime, there is no guarantee that its corresponding CSS rule exists in the production stylesheet. For an editor, I would use a hybrid strategy. 1. Pre-generate a bounded set of utilities. If your editor exposes a predefined palette and spacing scale, use Tailwind v4's @import "tailwindcss";
@source inline("{hover:,}bg-red-{100,200,500}");
@source inline("{hover:,}bg-blue-{100,200,500}");2. Use CSS variables for truly dynamic values. For example: <div class="bg-[var(--editor-bg)]">
Editable content
</div>Then update 3. Separate authoring from production rendering. If users can enter arbitrary Tailwind class names, consider a server-side compilation service that generates a stylesheet for each saved document. Compile only when the document changes, cache the result, and isolate user-generated input. For a production editor, I would avoid relying on the Tailwind Play CDN as the rendering engine. A pre-generated utility subset plus runtime CSS variables is usually simpler, safer, and faster. Documentation: https://tailwindcss.com/docs/detecting-classes-in-source-files |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm building an HTML editor with Tailwind support. The editor should allow my users to add any Tailwind class at runtime. Tailwind scans the source code and generates CSS based on the classes used. In my case, the classes are used later and, therefore, are not included in the CSS file.
At the moment, I'm using an iframe and loading Tailwind through the CDN. However, this is less than optimal, and I have many problems bundling the iframe src code with vite.
Do you have any idea how to optimize this process?
All reactions