Categories: Development, WordPress Posted: February 5, 2026February 6, 2026 by Carlos Prieto The Problem The layout issue ultimately comes down to constraint styles coming from the Group block itself. I didn’t realize this at first because our theme suppresses the Group block. So when I inspected the WordPress 2024/2025 default themes, I noticed they have these classes wrapping the content in the PHP templates (content.php, content-page.php, etc.). Once I copied that approach, everything worked as expected. …or did it? Since we’re essentially wrapping all our content in the Group Block it comes with some undesirable styling. Overrides top margin to 24px on all direct children, and bottom margin to 0. It removes the top margin from the first-child The issues this causes are obvious. But the frustrating part is how the selector is set up. When it selects it through the is-layout-constrained it adds a higher specificity (0,1,0) than any of our base elements (0,0,1). The :first-child is even worse, that has a specificity of (0,2,0). Possible Solutions Option 1 We can set a default margin, like 20px for example. That will get applied to all the immediate children. Then we would have to specify margins for all our blocks that would match whether they’re inside the constrained-layout or not. Pros: Keep our ability to use margins If we use a @mixin, doesn’t add much more code Cons: Have to remember to add the specificity or use the @mixin on every stylesheet May fall into a specificity war We can streamline this by making a @mixin that wraps our styles in the specific selectors that encompasses all the options. Then we would just use that where ever it’s required. Option 2 We zero out margins entirely and rely on padding for vertical spacing. Pros: Avoids cascading specificity issues all together since it only affects margins Easier mental map (removing margins as spacing option) Cons: Depends heavily on how blocks are wrapped and structured (may have to refactor some blocks) Blocks like Columns and Heroes rely heavily on margins for vertical spacing Columns with backgrounds are especially problematic Worst of all (in my opinion), we’re eliminating margins for spacing* *Affects only immediate children in the layout but then we would have two separate rules for inside and out which sorta defeats the simplicity of the mental map Parting Thoughts I think we need to address this ASAP as it’s going to be an issue on every site going forward. Both options have the common benefit of setting a baseline spacing to all our elements, but will require refactoring code to different degrees. Ultimately, I believe option 1 with a @mixin is the better option. I think removing margins as a spacing tool is a mistake, and would require more work. Post navigation Previous: Our WordPress boilerplateNext: The power of theme.json