Try moving block margins to each block

[jasmussen]

This is a followup PR to discussion in #8283 (comment).

The chief purpose is to remove all margins on blocks, and let each and every block add these margins back themselves. The purpose of this is to more closely mimic how a WordPress theme is built — a paragraph might have one margin, a heading another, a list yet another. By not blanket applying a margin to every child, but letting each define their own, we're essentially building a vanilla editor stylesheet.

This is a try branch, and very much a work in progress. It is being pushed now to convey the purpose and to discuss whether/how this should be tackled. For example right now the beginnings of this vanila stylesheet lives in the main.scss file, but we might want to put these into the style.scss for every block individually.

Please marinate on this and lay your thoughts on me.

[jasmussen]

When you hover or select a block, we paint the outline outside the footprint of the block.

This means that if a block has no margin, these outlines will overlap. This variable is designed in a way so as to prevent this overlap from happening.

[jasmussen]

Should these rules be duplicated across each and every block in the style.scss file for each, or is it fine to keep these in a global vanilla theme like these?

[jasmussen]

This is not a complete list. Pushing the work in progress to decide if this approach is worth it at all.

[jasmussen]

This is where we, currently in master, apply margins in a blanket statement to all blocks.

Why should we not do this?

Because some blocks might want their own margins, or no margins, and shouldn't have to override. Besides, the theme might not have any margins registered, and by registering them on a per-block basis, the theme will get these margins. This forces us to decide on a per block basis what, if any, margin is needed.

[aduth]

This forces us to decide on a per block basis what, if any, margin is needed.

But we apply a blanket rule to [ class*="wp-block-" ] { to apply those margins? Is that not contradicting?

[jasmussen]

Yes, that's definitely contradicting.

The thing is, I think of the Gutenberg editor style as a vanilla stylesheet. Same as if you create a stock HTML page with no CSS styles, you get the default browser stylesheet, with Times New Roman, etc.

Only, for margins, we currently set those on .editor-block-list__block-edit, as opposed to on the contents of the block itself. For example instead of setting a margin on a p tag, we set the margin on the .editor-block-list__block-edit container of the Paragraph block.

Why does this matter? Only one reason — if you mean to style the editor itself to match the theme, it makes more sense to write:

body.gutenberg-editor-page p,
body.gutenberg-editor-page ul,
body.gutenberg-editor-page ol,
... {
    margin: 1em 0;
}

... than it does to write:

body.gutenberg-editor-page .editor-block-list__block-edit {
    margin: 1em 0;
}

Sure, it would be nicer even if themers could write, simply:

p,
ul,
ol,
... {
    margin: 1em 0;
}

But unless Shadow DOM support drastically improves or we can put the editing canvas in an iframe, I doubt we can enable that. So by moving the margins to the block contents itself, at least we're taking a half-step to make styling the editor simpler, even if it's still the same margin.

What do you think?

[aduth]

I can support the goal, but as implemented, [ class*="wp-block-" ] { would still match exactly what we're targeting today with .editor-block-list__block-edit.

Sure, it would be nicer even if themers could write, simply:

In some side-chatting with @mtias and @youknowriad some ideas have been bounced around here with how we might be able to achieve effectively this by either rewriting the CSS to prepend necessary prefixing, or iterate them automatically when rendered in the DOM via document.styleSheets. Not sure if it'll be a foolproof solution, but worth exploring. I think @youknowriad said he might look into it?

[youknowriad]

I did say, and I'll give it a try, no updates at the moment though :(

[chrisvanpatten]

For what it's worth, you can never count on dynamic/SSR blocks to match a [class*="wp-block-"] selector. (Data point: none of our custom SSR blocks use wp-block- classes.)

[jasmussen]

I can support the goal, but as implemented, [ class*="wp-block-" ] { would still match exactly what we're targeting today with .editor-block-list__block-edit.

While I agree that selector is not ideal or probably even feasible, it doesn't exactly target the same. I'm not trying to split hairs here, but look at the markup:

• .editor-block-list__block is the parent wrapper of it all
• .editor-block-list__block-edit is a direct descendant of that
• .wp-block-quote is a direct descendant of .editor-block-list__block-edit

Only the third item is the same on the front-end and the back-end.

I realize that having the markup be the same in the frontend and the backend is likely not feasible in the near future, without Shadow DOM or things like that, but it is a baby step towrads at least styling the same bits of markup in the editor and the frontend. The margin is the same, sure, but the selector is different.

This all speaks to a larger issue that came up recently when @iseulde rewrote the table to use nested blocks. Essentially I wasn't able to write CSS that would make our nested blocks editor markup behave and look like the table on the front-end. Not easily at least.

I'm not sure what the best approach is — possibly this branch isn't it. But to your point about making a build process that matches front-end selectors to backend elements, this would not address the challenge for a table with nested blocks, where the sequence of parent-to-child elements in the markup is important (at least pending display: contents).

[youknowriad]

Here you go #9008

[ellatrix]

For what it's worth, you can never count on dynamic/SSR blocks to match a [class*="wp-block-"] selector. (Data point: none of our custom SSR blocks use wp-block- classes.)

@chrisvanpatten What class do those blocks have then? How would it be possible to style them?

[chrisvanpatten]

Musings incoming… 😄

I think this makes sense but to be honest the way a block is constructed in the editor is kind of hard to understand, with all the pseudo-elements, negative margins, and various other hacks used to float the controls outside the block's footprint. It isn't necessarily in the scope of this ticket, but it might be nice to have some kind of documentation page, with visuals, sort of explaining the DOM structure, how things are positioned, etc. I think it makes sense but can't really say for sure because I feel like my grasp on the editor markup structure is tenuous, at best.

One practical issue is that if the responsibility will fall to individual blocks to configure their own margins, the $default-block-margin variable should be somehow made available to block implementors. No idea how that would work (scss dependencies in an npm package somehow?), but it's worth noting.

[ZebulanStanphill]

I think this is a very good move. Gutenberg should strive to look as much like the front-end as possible (except for the currently selected block), and removing automatic margins is a good step in that direction. This move also makes it more important to ensure that the controls surrounding a block do not overlap the content of the block. I think this is probably a good thing, since even with automatic margins, some custom blocks would have ended up disabling them (I actually did for a custom block I made once), and the block UI needs to work with something that has no margins or padding.

On a related note, the various situations with nested blocks have shown that making the block outlines larger than the actual block does not solve the hard-to-select-parent-block issue on desktop. I am starting to think that maybe the block outline should switch back to being the actual size of the block, both to improve accuracy of the UI (the visible border matches the actual border of the block), and to get rid of the overlapping border issues that exist right now with things like the Columns block.

Notably, the area between the block content and the visible border is used as a drag handle, but if #6224 is implemented, then that drag area can be removed for selected blocks. Additionally, #7114 could also solve the problem for hovered blocks, if #6224 does not already solve it. (It may be decided that no controls should be shown on hover due to overlapping toolbar issues, in which case using the hover label as the drag handle for hovered blocks makes sense.) The drag areas on the side of the block are invisible and confusing, in my opinion, and getting rid of them is almost definitely a good move since, combined with removing the auto margins, brings the editor even closer to the front-end.

[jasmussen]

the way a block is constructed in the editor is kind of hard to understand, with all the pseudo-elements, negative margins, and various other hacks used to float the controls outside the block's footprint. It isn't necessarily in the scope of this ticket, but it might be nice to have some kind of documentation page, with visuals, sort of explaining the DOM structure, how things are positioned, etc.

I think that makes total sense, and I don't necessarily think it's out of scope to do this. If we agree this is the right approach, it will be valuable to have.

One practical issue is that if the responsibility will fall to individual blocks to configure their own margins, the $default-block-margin variable should be somehow made available to block implementors. No idea how that would work (scss dependencies in an npm package somehow?), but it's worth noting.

I'm not sure, and this definitely needs hashing out. Right now we have up to three SCSS files for each block:

• editor.scss — loads only in the editor
• style.scss — loads both in the editor and the theme
• theme.scss — loads both in the editor and the theme, but only if the theme has opted in using add_theme_support( 'wp-block-styles' );

If we are mindful about how we implement this, we might build things in such a way as to be mostly transparent to the theme.

For example, p, ul, ol, blockquote margins might live in theme.scss, and assume that the theme handles these on its own.

Cover Image, Archives, Latest Comments, Image, Gallery, Embed (and so on), might have these margins live in style.scss? — We'd want to include the rules there in a way so as to be easy to override for the theme.

But this could be a balance we'd want to tread. What do you think?

I am starting to think that maybe the block outline should switch back to being the actual size of the block, both to improve accuracy of the UI (the visible border matches the actual border of the block), and to get rid of the overlapping border issues that exist right now with things like the Columns block.

This is sort of the "Plan B", which might make sense. I don't know if we're too late in the process to do this for V1, but it's definitely an option on the table for V2. If you look at notion.so, they do this, but they use a background color instead of an outline:

[jasmussen]

Pushed a small experiment (819e251) to use a different selector to target all blocks:

[class*="wp-block-"] {
  border: 10px solid coral;
}

Codepen: https://codepen.io/joen/pen/djeobN

I know this puts us back to square one — but figured I'd push it as an experiment to see if it inspires ideas.

[aduth]

Minor: We should use parentheses so the future maintainer doesn't need to recall their order of operations 😄

[jasmussen]

From #9229, noting that we need to account for that with the sibling inserter positioning and height. I have some ideas, including simply having a smaller minimum height of the hoverable area, but this is something to think about. The code in question is this:

[ZebulanStanphill]

Is there no way of having the hoverable area not prevent you from clicking any content that may be in that region of the block? I notice the side controls have rather large hover areas that do not seem to interfere with clicking within the block.

[ZebulanStanphill]

Inevitably, blocks with custom margins/padding will have their content overlapped by the sibling inserter. If Gutenberg wants to be as WYSIWYG as possible, it needs to account for this somehow and prevent the sibling inserter from permanently overlapping content as it would now.

As far as I can tell, the only way to solve this problem is to move the sibling inserter outside of the borders of the block. The toolbar and up/down movers are both located outside of the block borders, so why not the sibling inserter?

Of course, just shifting the current inserter upwards to be above the top border of the block would feel weird and unintuitive, as well as inconsistent with mobile, where the sibling inserter appears below blocks. Therefore, the sibling inserter should also be moved to show below blocks, and therefore below the bottom border of the block.

Of course, the current round design of the sibling inserter still looks kind of weird (and a bit large) below the bottom of a block, so I would suggest changing it to be smaller. I would think it makes sense to reuse the style of the up/down movers here.

So I would imagine a sibling inserter with reduced overlap issues could look like this:

See #9202 for more mockups and info.

[jasmussen]

@youknowriad I was going to close this PR as something that doesn't sufficiently improve things for the editor yet. But then I realized that you've merged in new editor styles recently — does that potentially make this PR relevant again?

Idea being, there's already a rule for p { ... } in that default editor stylesheet. Should that rule not include margins? How about all the other blocks?

Let me know your thoughts and based on that I'll either revise or close this PR.

[youknowriad]

Maybe we can add a margin to the p element in the editor styles instead of the block's wrapper, this means we need to check all the other blocks and whether they need margins as well. I think it's worth a try (only margin top and bottom right?) but I'm not certain yet if it's feasable or not, only exploration can tell.

[jasmussen]

I'm going to close this PR for now. At this point it hasn't received a lot of endorsements, and it is very easy to revisit in the future if the need for this becomes pressing.