CSS changes to RichText broke core and custom blocks layout

[afercia]

Splitting this out from #14366

9b84916 removed the top margin reset from the RichText editable area.

The removal of the margin is a breaking change for custom blocks that reuse RichText within a block. Example:

Before:

After:

It's also breaking the core reusable blocks > edit mode:

Before:

After:

I suspect there are also other cases.

I'm not sure this kind of changes can be made so lightly. Even if this is "just" CSS, it can break things because it's changing the expected rendering.

There has been a recent discussion on Slack about what can be considered a breaking change and what the level of backwards compatibility should be. There's a tendency to consider CSS changes as something that doesn't need backwards compatibility because not part of a "formalized API". Honestly, I really don't mind when discussions like that are made in a so abstract way without considering the real consequences for the developers ecosystem out there.

Trying to keep up with these changes is exhausting and not sustainable, especially when they're not communicated well in advance and with great relevance.

That said, this is breaking also the core blocks thus it's an issue that should be addressed in some way.

[m-e-h]

@afercia I'm trying to reproduce this.

I thing you're referring to removing the .editor-rich-text__editable { margin: 0 } which was discussed some here #14407 (comment)
I do know @jasmussen pinged several people more than once about that particular change.

When I add the 0 margin back it does remove the browser default or in this case common.css's 1em top margin on the p tag.

It's my understanding that one of the goals of the commit this is about and the one I linked above is to let the intended styles of the content shine through.

If your theme either adds a margin or doesn't remove the browser margin on p tags then I think it could be argued that your "after" screenshot is the way it should look and the "before" is actually a bug.
I see now that there's a 14px space above the rich-text area being created by edit-panels negative margin. So this looks like extra space above the text and .editor-rich-text__editable { margin: 0 } was added to make sure the text didn't add margin to that pretend space.
There's got to be a better way to handle this than to mess with styles on user entered content though, doesn't there?

I'm just talking about the reusable paragraph block though. It's hard to tell what's going on with the custom block. Is that a li or is it a p element as well?

Even if this is "just" CSS, it can break things

The fact that CSS has been an afterthought for much of this editor's development isn't lost on me.

[m-e-h]

Gallery-item captions are also showing issues with the recent figcaption changes.
The .editor-rich-text__editable { margin: 0 } would fix these in the editor but the front-end is also effected.

Both the front-end and the editor need the margin-bottom removed.

I'll can try to put together a PR in the next day or two.

[afercia]

@m-e-h thanks for looking into this. I see you've clarified (by striking-through the related sentence) this has nothing to do with a theme. Actually, I'm testing with Twenty Nineteen. Regardless, this happens with all themes.

• Whatever we put it, this is a breaking change simply because "it breaks things".
• Besides custom blocks, so far we've identified two cases where this change breaks core blocks too: I suspect there are more. For example, I'd be curious to see what happens with nested blocks.

Seen from a plugins developer perspective, having to keep up with this kind of changes is not sustainable. I'd strongly recommend to consider that, at this point of the project, also some important CSS changes should be communicated well in advance as potential breaking changes.

[youknowriad]

This is more a communication issue and I think we've been doing better at communicating how our CSS changes can affect plugin authors and third party blocks. We can always do better though.