don't use hardcoded values for separator styles

[aristath]

Description

Avoid using hardcoded styles for separators.
This is a part of #16782, I'll try to push separate PRs per block so they can be examined and discussed separately.

Types of changes

• Changed hardcoded font-size value from px to em
• Changed $dark-gray-100 color to currentColor with an opacity of .4 which is pretty close on white backgrounds.

The above changes make things work properly regardless of font-size used on the site, and regardless of whether the site uses a light or dark background color.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[draganescu]

Tested this small update and it works all right but it does change the look of the separator to be lighter (in TwentyTwenty at least). Adding NeedsDesignFeedback.

Before:

After:

[ZebulanStanphill]

The WordPress Coding Standards say to use a leading zero in decimal numbers. Also, do we even need this opacity adjustment?

[richtabor]

We discussed this in today's design meeting (Slack). While we could remove the hard coded value for opacity as well, it's not super necessary.

If we do remove the opacity value, I personally think an opacity control is not necessary. I'm for removing the hard opacity (or leaving it as is without an additional control).

[ZebulanStanphill]

If we do remove the opacity value, I personally think an opacity control is not necessary. I'm for removing the hard opacity (or leaving it as is without an additional control).

What opacity control are you talking about? I think you (or I) may have misunderstood something somewhere?

[richtabor]

If we do remove the opacity value, I personally think an opacity control is not necessary. I'm for removing the hard opacity (or leaving it as is without an additional control).

What opacity control are you talking about? I think you (or I) may have misunderstood something somewhere?

In the meeting we discussed possibly considering an opacity control (if we are to remove all hardcoded opacity value as well).

[ZebulanStanphill]

Ah, okay. Well, adding an opacity control seems over-the-top to me. I would think that the theme should be in charge of most of the separator styling. (Actually, I'm not sure why we even have multiple style variations included in core.)

[richtabor]

Ah, okay. Well, adding an opacity control seems over-the-top to me. I would think that the theme should be in charge of most of the separator styling. (Actually, I'm not sure why we even have multiple style variations included in core.)

So do you think we should remove the current opacity: .4; CSS value?

[ZebulanStanphill]

I'm ambivalent about it, since it's in a theme.scss file, which is for opt-in opinionated styles, if I recall correctly. It having an opacity value set is irrelevant to whether or not there should be an opacity control.

[richtabor]

Im fine either way, although I thought the goal was to remove overly specific styles?

[ZebulanStanphill]

I think the goal of this PR was to make the block styles (both default and opt-in) work better with themes, by using values that adapt better (e.g. em units instead of px units and currentColor + opacity instead of always a dark gray that may not match the text color of some themes).

[aristath]

Yeah, the default styles for separators were to use a color $dark-gray-100.
Assumng a white background and black text, that corresponds to a currentColor and an opacity of 0.4.
The opacity is not really necessary and can definitely be removed, I was simply trying to keep the styles as close to the original ones as possible (hence I added an opacity).
As long as the color changes to currentColor instead of the dark-gray the rest is not that important. Without this change, themes that respect the user's color-scheme preferences (or even just dark themes) need to override the default styles and write their own.

[ZebulanStanphill]

Yeah, the opacity shouldn't really be a blocker for this PR. Just add a leading zero to the number, rebase the PR to get tests working, and let's ship it. A follow-up PR can remove the opacity if desired.

[aristath]

Unfortunately I can't push code to this PR any longer... The source fork no longer exists and it can't be changed in the PR's reference.
I created a new one instead on #24366, and pushed the requested changes there.

I'll go ahead and close this PR in favor of the newer one since we can push any requested updates there. 👍