WordPress 7.0 introduces a major leap forward for block customization: the ability to add custom CSS directly to individual block instances. This addresses a long-standing limitation that frustrated developers and site operators alike.
Until now, targeting specific block instances required a workaround. Users had to assign a custom class name and then define matching CSS rules in the Site Editor’s global Custom CSS field. This process was obscure for many and inaccessible to content editors without Site Editor permissions. Plugins emerged to fill the gap, confirming widespread demand for a simpler solution.
How Custom CSS Works in WordPress 7.0
The new feature is powered by the customCSS block support. It adds a Custom CSS input field to the Advanced panel of the block inspector. Users can write CSS declarations directly inside this field — no need to include selectors. Nested selectors can be applied using the & syntax, but HTML markup is prohibited.
Custom CSS is stored in the block’s style attribute under the css key. At render time, WordPress generates a unique class for the block instance based on a hash of its content and attributes. This class is injected into the block’s outer HTML element and accompanied by a has-custom-css marker class. The actual CSS rules are output in a scoped stylesheet that ensures the custom CSS loads after WordPress defaults and Global Styles, allowing it to override these.
Editor and Frontend Behavior
In the editor, the custom CSS is applied immediately as a scoped style override, so users can preview their changes in real-time. On the frontend, the stylesheet is registered with dependencies to ensure proper load order.
Core blocks that render raw content or lack meaningful outer elements, such as core/html and core/freeform, have opted out of this feature by default. Developers can disable customCSS support for their custom blocks by setting "customCSS": false in the block’s block.json.
What Developers and Agencies Need to Know
- No immediate action required: The feature is enabled by default for all blocks, except those opted out for technical reasons.
- Capability gating: Only users with the
edit_csscapability will see the Custom CSS panel. This aligns with permissions for the Customizer and Global Styles. - Server-side rendering: Blocks using
render_callbackorrenderinblock.jsonwill have the class injected into their first HTML element. - Opt-out availability: Developers maintaining blocks that should not support custom CSS can explicitly disable it in
block.json.
For site operators, this change simplifies customization workflows, reducing dependency on custom plugins or developer intervention. Agencies managing client sites will find it particularly useful for granular design adjustments without touching global styles.
What To Do
- Site Operators: Test the new feature in staging environments to evaluate how it can streamline your workflows. Confirm editor permissions for staff who need access to custom CSS.
- Theme Developers: Verify your blocks and themes are compatible with the new CSS field. If a block must opt out, update its
block.json. - Plugin Developers: Ensure blocks with server-side rendering correctly support the injected class.
