Support » Plugin: Gutenberg » Block Padding/Margins not WYSIWYG

  • I’m wondering if anyone can point to reasons why the Gutenberg team has opted to add padding/margin around blocks that make it not a true representation of what appears on the front end?

    There seems that at some point there was a definitive decision to not make Gutenberg a true WYSIWYG and while I can come up with some reasons why I’m curious if anyone knows of information or a conversation where and why this was decided.


Viewing 7 replies - 1 through 7 (of 7 total)
  • I think the main problem is that most themes do not have a corresponding editor style that’s loaded to make Gutenberg look like what the theme does on the front-end. In my case other things like the Headings didn’t match as well as the main font.

    In my theme’s functions.php, I added the following:

     * Enqueue block editor style
    function mytheme_block_editor_styles() {
        wp_enqueue_style( 'mytheme-block-editor-styles', get_theme_file_uri( '/blocks.css' ), false, '1.0', 'all' );
    add_action( 'enqueue_block_editor_assets', 'mytheme_block_editor_styles' );

    Then, in my theme’s directory I created a block.css file with CSS to make Gutenberg look like what my Twenty Twelve theme does on the front-end.

    Thanks for the comment. Yep, I have done similar with my themes to add Gutenberg support. Where I see the biggest issue is with the margins Gutenberg adds that are unrelated to the front end. There is padding above and below each block that is set by Gutenberg and has no effect on what block you add and no relationship with the front end of any site.

    I added an experimental css option to my plugin here that removes this extra margin and it seems to work fine. It could make the margins between two paragraph blocks easy to match that of the theme.

    So it’s led me to try and find out why the padding was added to start with along with other decisions to not make Gutenberg a true WYSIWYG.

    Moderator Marius L. J.



    You can either override the Gutenberg styles in the backend, or (ideally), you can enqueue them on the frontend as a basis to work off. Check out

    In particular, in themes, using add_theme_support( 'wp-block-styles' );

    Thanks for posting, again though that is not an answer to the question I asked, I suppose I’ll need to ask it somewhere else…

    Moderator Marius L. J.


    The padding/margin are needed to make room for the block controls, this is a necessary tradeoff from a 100% visual representation of what it will look like, but is a minor one compared to what we have today and as such shouldn’t be a large issue.

    There is also a bit added for readability sake, this is content after all, and it would look strange if content was hugging the sides of a block if you were to add a background color for example.

    As mentioned earlier though, you can get a more accurate representation by utilizing editor styles, or adding theme support for the block styles on the front end, which will help get you closer to that 1:1 representation.

    Hey, Thanks for posting.

    ok so “necessary tradeoff” to “make room for controls” is debatable certainly considering how much margin is added. But at least that is exactly what I wanted to know. Don’t care who agrees with what I just want to know from the people that made the decision why they claim it needed to be made that way. Your answer is at least gives me something to cite and reference.

    But I’m curious though if/when there ever was a discussion by the core Gutenberg team about this that is public and one that I could read and reference.

    Makes me wonder when it moves to the customizer if the site preview will then have to add in all this extra space making the customizer no longer a true WYSIWYG of if they plan to try and remove/limit the amount of space.


    Moderator Marius L. J.



    I don’t know of any tickets that cover the padding. It should be noted I’m not part of the Gutenberg team, I’m merely here trying to help people with their questions, and some of the answers I give are my understandings of how things are meant to work.

    As for your worries with the customizer, I actually do’n think we will have the same, let’s call it “limitations”, there. The customizer already has a well established workflow, and doesn’t require the same in-content manipulation that the post editor does.

    With a post editor, there is an expectancy for your content controls to be at hand, and contextually there for the block you are working with.

    In the customizer, we already have panels, because the contextual tool-area for a full site is just outside the site. This is just speculation on my part, as phase 2 hasn’t begun work yet, but it’s certainly a concern I’ll make sure is brought on to them when they do start development there just to ensure it’s at the very least getting an official response at that time.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Block Padding/Margins not WYSIWYG’ is closed to new replies.