Put Styles In Main CSS#
Write shared frontend and editor styles in resources/css/main.css:
body { font-family: Inter, sans-serif; color: #111;}h1 { font-size: 3rem; line-height: 1;}h2 { font-size: 2rem;}p { line-height: 1.7;}TemplateX mirrors this CSS into Gutenberg block previews and renders TemplateX blocks through their compiled PHP preview.
When a dynamic block preview includes server-rendered runtime content, such as a query loop, TemplateX inserts that server preview at the authored position in the markup. If a paginated query renders cards inside a grid and the pagination after that grid, TemplateX uses separate preview sections so the cards stay inside the grid and the pagination stays outside it. TemplateX also flattens WordPress's editor-only preview wrappers, including the temporary wrapper Gutenberg uses while refreshing a server preview, so rendered nodes still participate in authored flex and grid layouts.
Gutenberg previews focus on the server-rendered first markup and the CSS that styles it.
When a block uses browser interactivity, TemplateX loads the generated interactive module inside Gutenberg's editor canvas and mounts it after the server-rendered preview HTML arrives. The module is loaded separately from the parent admin page so frontend behavior can run in the iframe document that actually contains the preview markup.
Link The CSS From Your Layout#
Use the same file on the frontend:
<head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="main.css"></head>That keeps the frontend and editor preview using the same source styles.
In production builds, TemplateX reads the Vite manifest for the CSS emitted from resources/css/main.css. If Vite stores that CSS on the generated templatex:bundle entry, Gutenberg still receives the built stylesheet.
TemplateX also includes CSS emitted for local scripts referenced by your views. This matters when a view uses a selector-gated script such as syntax highlighting:
<script type="module" src="highlight.js" data-load-when="pre code"></script>The public site still lazy-loads that script only when matching markup exists. The editor preview can still use the script's emitted CSS so block previews do not lose their styling.
Use Content Wrappers#
If your frontend content lives inside a wrapper, put the class around {{ content }}:
<article class="prose"> <h1>{{ title }}</h1> {{ content }}</article>Then style the wrapper in CSS:
.prose h2 { font-size: 2rem;}.prose p { margin-bottom: 1rem;}TemplateX mirrors the nearest static content-wrapper classes into Gutenberg, so blocks inside the editor can inherit the same typography context.
Core WordPress blocks also use that inferred wrapper width. If your content wrapper is full width, such as class="container-grid fullscreen", normal Image blocks can fill that editor canvas instead of being forced into WordPress's default 650px content column. When TemplateX cannot infer a content wrapper, the editor falls back to WordPress-style normal, wide, and full block widths.
Those classes are applied to the root editor content canvas only. Outer page scaffold classes, such as section spacing around the article, are not flattened onto the content root. Nested Gutenberg layout blocks, such as Quote or Group, do not receive the page scaffold classes again.
Style Blocks Like Frontend Markup#
Block markup can use normal classes:
title: Herocategory: Sections---<section class="hero"> <h2>Build faster</h2> <p>Create pages from clean theme markup.</p></section>.hero { padding: 4rem 0;}.hero h2 { font-size: 3rem;}TemplateX scopes those styles for the editor preview while keeping the frontend HTML theme-owned. The generated editor CSS keeps the frontend rule order and wraps editor-only prefixes in :where(), so your theme selectors keep their normal specificity inside Gutenberg.
TemplateX writes the scoped preview CSS to a cached stylesheet in uploads and enqueues that file in the block editor. The cached stylesheet URL follows the admin URL scheme, so HTTPS editors load the preview CSS over HTTPS even if the uploads base URL is stored as HTTP. That keeps repeat editor loads lighter than pasting the full generated CSS into every admin page response. If the cache cannot be written, TemplateX falls back to inline preview styles so the editor still works.