Separator Block HTML is completely different in the editor and in the frontend

[markhowellsmead]

The HTML on the frontend of the website is a simple hr with appropriate CSS class names. If the element is set to alignwide then the appropriate class name is directly on the hr. This is expected behaviour and allows me to adjust the styling appropriately.

In the editor, the hr stands alone if it is not set to alignwide or alignfull. If it is set to alignwide or alignfull, it is then wrapped with a div featuring a data-align attribute. The class names alignwide and alignfull aren't used anywhere.

Because the wrapper isn't specific to the separator block (<div class="wp-block" data-align="wide">), it cannot be targeted with appropriate CSS styling rules.

[markhowellsmead]

I have added my own block using apiVersion 2 to output just an hr and the same problem applies. The editor wraps the hr with a div and the alignwide or alignfull class name isn't applied, in favour of the data attribute on the wrapping div.

[Sandstromer]

This is how I target the separator block.

Editor
.wp-block[data-align="wide"] > .wp-block-separator
.wp-block[data-align="full"] > .wp-block-separator

Frontend
.wp-block-separator.alignwide
.wp-block-separator.alignfull

Hope this helps.

[markhowellsmead]

Thanks @Sandstromer, but I need to target the wrapper in the editor, not the hr.

[Sandstromer]

The wrapper exists only to define the alignment, so you do your wide or full stuff on the wrapper, then the styling on the hr separator.

I'm struggling to think of a use case for targeting a wide/full block where it is only wrapping the separator.

[markhowellsmead]

@Sandstromer All child elements of the block wrapper in the frontend have margin-left: 0. This is defined using .c-blocks > * {margin-left: 0}. Separators which are aligned wide have margin-left: auto, which is defined with .c-blocks > .wp-block-separator.alignwide {margin-left: auto}. This works fine.

However, this rule can't be applied in the block editor, because the target separator wrapper element .wp-block[data-align="wide"] is generic. It's currently not possible to write code for this element without some nasty JavaScript. Using JavaScript to force stuff in the editor always breaks in subsequent updates, which is impossible to maintain over a moderate range of projects.

I'm not looking for a CSS hack or workaround, but advising of logic problems because the HTML generated for the editor and the frontend are completely different.

The same issue applies to every block, so if it's not addressed, it means that many layouts are simply not possible to achieve in Gutenberg. This issue happens multiple times in every project we develop.

[Sandstromer]

I agree there is a disconnect between the addition of the .wp-block wrapper in the editor, which is not there on the frontend.

I can only say what helped me when I started messing around with the block editor and then going into FSE themes, was to develop first for the editor, then the frontend.
I found it much easier than writing for the frontend and then trying to match it in the editor, which is what I was doing to start with.

[markhowellsmead]

Thanks @Sandstromer: that's why I have created this issue. It was much easier to code CSS at the beginning of 2019, as the HTML in the editor was much closer to the HTML in the frontend. This is no longer the case, as each new version of WordPress Core introduces more and more problems due to an increasing disparity between the two sets of HTML. If this continues, the amount of extra work required by coding everything twice will mean we'll have to stop using Core and switch back to ACF, as we did until 2018.

[markhowellsmead]

An alternative to using the descendant selector method .c-blocks > * {…} would be to use .wp-block as the selector. This would be my preference. The problem there is that not all core blocks have the wp-block class: for example core/heading. Hence the need for the descendant selector method.

[talldan]

I believe this is the same for almost any block that has alignment of wide or full (the exception being image, which is implemented differently)

There's an issue here that's relevant and discusses improving things- #20650

I'd recommend adding feedback to that issue. I'll mark this as a duplicate