Convert all px values in front-facing styles to relative (em) units

[aristath]

This is the result of many smaller PRs combined.

Came up in a discussion in #24409 (comment) that it might be preferable to have all smaller PRs combined in a single one.

This one contains commits from #24433, #24432, #24404, #24413, #24407, #24405, #24322, #24323, #24330 #24409, as well as a few additional commits that take care of any remaining absolute units conversions.

[aristath]

And also, things are a little different in the recent comments block. The avatars are larger (similar to the social icons above), and the alignment of the comment itself is off on the front-end:

Tested this and it's definitely due to the theme's styles...
It overrides the default margin for excerpt & meta with the following CSS:

.has-avatars .wp-block-latest-comments__comment .wp-block-latest-comments__comment-excerpt, 
.has-avatars .wp-block-latest-comments__comment .wp-block-latest-comments__comment-meta {
    margin-left: 5.5rem;
}

The block styles on their own look like this:

The problem in the twentytwenty theme is the fact that it's basically using the rem-hack mentioned in a previous comment, and tweaking the margin of excerpts & meta but not the body of the comment 🤷

[aristath]

I did notice inconsistencies in the Social Icons block. The icons are much bigger than usual in general, and the icons are off-center in the editor:

Fixed the off-center thing in 9f7228b. But as mentioned by @jasmussen in a comment above, perhaps we should just revert all tweaks to social-icons 🤔

[ZebulanStanphill]

The Social Icons block is certainly an interesting case. I'm not really sure whether it should scale with the font size or not. I think it would be fine to leave it out of this PR; we can always change it later.

[aristath]

I agree 100% with the above assessments regarding social-icons.
Changes to them were reverted and they are no longer included in this PR. 👍

[jasmussen]

It's already a sweet PR, and nothing blocks us from a separate social icons PR ✨

Thank you.

[aristath]

What is blocking us for this one?

[jasmussen]

Just a final test/sanity check. I'm happy to take a look tomorrow and 👍 👍 this one, in the mean time if others on the thread feel confident they can approve it. At a quick glance, all looks good to me.

[ZebulanStanphill]

I've looked through every file, and it seems good enough to merge at this point. We can always polish things more in future PRs.

[ZebulanStanphill]

I'm going to go ahead and merge this now.

[mtias]

Mmm, how much testing and thought has been put into how this change might cause visual difference on people's sites depending on what themes are choosing to overwrite or the contexts in which they do so? If themes have different containers where they are already relying on ems the cascade might cause unexpected visual results.

My inclination would be to not do a change like this until it can be properly structured through the theme.json efforts, allowing themes to opt-in to a preferred unit type.

[ZebulanStanphill]

As far as I can tell, these changes would be more likely to make things work better with themes. Previously, the values were mostly hardcoded px values that would have clashed with themes with a standard font size that wasn't close to 16px. These changes would fix the styles on those themes. While there will certainly be some visual difference, I expect it to be almost entirely for the better. Surely, if a theme is using em units on a container to scale up (or down) the font size, it must expect all text inside to be larger/smaller than usual? For our blocks to not act that way would be disrespecting theme styles, wouldn't it?

It seems to me that using em units in our block styles should be far more compatible with both themes that use px styles and those that use em units.

Still, I've added a "Needs Dev Note" label, as this is something we should let people know about either way.

[mtias]

It doesn't matter if it's a better default if it can still cause regressions for people's sites that they may not know how to solve or address themselves. For better or worse, themes and users would have accommodated how block styles interact with themes so far (not to mention all the third-party blocks that might also be using pixels). I think this is something we should do more carefully, ideally pairing it with a default unit spec (connected to the unit control component as well for custom styles, which right now is gated on an add_theme_support) which is part of the global styles project. Without that it seems overall fragile as users would still be using controls that default to pixels.

[jasmussen]

I think this one is maybe something to revert. I don't 100% fully understand where those 70px come from (cc: @jorgefilipecosta perhaps?) but I think given it's part of a calc statement, it was potentially important that this remained a pixel value.

[jorgefilipecosta]

I reviewed the PR you submitted it seems we can just remove the rule 👍

[johnstonphilip]

@jasmussen @jorgefilipecosta Please see comment here:
#25103 (comment)

This is causing styling breakages on the frontend for cover blocks.

[jasmussen]

Thanks again @johnstonphilip. I believe that #26143 to fix it.