Blicks - Layout Blocks for the Block Editor

No. Blicks lives inside the native block editor and adds layout primitives — Stack, Grid, Box, Section — that you compose the same way you compose any other block. Nothing replaces your editor.

It is built for block themes and full site editing, where it reads the presets your theme.json defines and resolves its own tokens through them. It also runs on classic themes, but falls back to its own default token values, since there is no theme.json to sync with.

No. Blicks keeps its own catalogue of token slugs, and their values alias your theme's preset variables where the theme defines them. Where it defines none — a shadow scale, say — Blicks supplies its own, so a control is never empty.

Blicks enqueues one stylesheet, 13,301 bytes gzipped, on requests that render a block. There is no per-block <style> tag and no per-request CSS generation for token and utility values. Per-instance rules — pseudo-elements, container queries, keyframes — are collected and deduplicated into a single block in the footer.

Blocks save static HTML, so the markup stays in the post. The runtime stylesheet stops loading, so the styling it carries goes with it.

By default, nothing is removed — your tokens, themes, animations and settings survive a delete and reinstall. If you want Blicks to clean up after itself, set On uninstall to "Delete all Blicks data" in Blicks → Settings before deleting the plugin.

No. There is no stylesheet field, no script field and no snippet runner. Blicks never evaluates anything you type, and you cannot write a CSS rule, a selector or an at-rule anywhere in it. Two places do accept typed input. Some controls take a typed value rather than offering a picker — a length like 800px, a transform like translateX(10px), a shape like polygon(0 0, 100% 0, 100% 100%). Each of those is the value of one named property that the control itself chooses; you cannot write the property, a selector or a rule. Every value is validated whole against a closed list of permitted characters and CSS functions before it is used, so a value cannot end its own declaration or start another one. Anything that does not validate is dropped. The custom animation editor (Blicks → Design System → Animations, administrators only) works the same way. Each keyframe step is a form row: you pick a property from a fixed list of animatable properties (opacity, transform, color and similar), and type its value, which is validated exactly as above. You cannot name any other property, write a selector or add an at-rule; Blicks generates the @keyframes rule and its name itself.

Yes. Import HTML in the editor's options (⋮) menu opens a one-way importer: you paste a block of markup, Blicks maps each element to the closest Blicks block, and inserts the result into the post. It reads each element's inline style attribute only — not <style> blocks, not stylesheets, not <script>. A declaration is kept only where its property matches an existing Blicks control that takes a plain value; it then becomes an ordinary block attribute, validated exactly like any value you would have typed into that control yourself. Everything else — every property with no matching control, and every structured control that would need reshaping — is dropped, and the import report names each one so nothing is silently discarded. The pasted text itself is never stored and never rendered. No pasted CSS reaches the front end unvalidated, and pasted <script> is parsed as text, never executed.

Yes, via the media library. Background image URLs are restricted to your own site's uploads or an ordinary http(s) address; javascript: and data: URLs are rejected.

Yes. Rules that carry a keyframe animation are emitted inside @media (prefers-reduced-motion: no-preference), so a visitor who has asked for reduced motion never gets them.

The source is at github.com/blicks-dev/blicks. Issues, pull requests and translations are all welcome; translations go through translate.wordpress.org.