WordPress.org

Make WordPress Core

Opened 2 months ago

Last modified 5 weeks ago

#52763 new defect (bug)

Relative CSS units used in front-end, absolute in block editor

Reported by: andrejcremoznik Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.6.2
Component: Editor Keywords:
Focuses: css Cc:

Description

.has-large-font-size and .has-small-font-size are core CSS classes. On front-end, the font-size uses em-s while in the editor, the units are in px.

If the cascaded font-size is 16px, then it's not a problem but anything else obviously breaks everything if your goal is to visually match front-end and editor.

All editor's sizes should use relative units and the editor should have an option for devs to provide the base size.

There are probably other instances of this. If I find them I'll add them to the bug report.

Change History (6)

#1 @SergeyBiryukov
2 months ago

  • Focuses css added

This ticket was mentioned in Slack in #core-css by ryelle. View the logs.


5 weeks ago

#3 @ryelle
5 weeks ago

There's an issue to add custom units to the font size inputs, which would let you set those sizes in rems. You can follow that work on the issue on github: https://github.com/WordPress/gutenberg/issues/23323

What theme are you using? Your theme could provide an editor stylesheet to make sure the styling of those classes matches, and if it's a core theme, we could look at fixing that.

#4 @andrejcremoznik
5 weeks ago

I am developing themes and of course I'm providing an editor stylesheet. I had cascade/specificity issues trying to fix the problem that shouldn't even exist. This is a WordPress core issue because it ships unmatching CSS for blocks in the editor and on the front-end. Ideally, WP wouldn't hardcode any values in stylesheets. You could output some defaults in sensibly named CSS variables which could be adjusted by devs via a filter hook. All font-size and color settings for core blocks could then go there and devs would be able to change them or add their own.

Obviously I'm missing insight here as I haven't worked on core block editor, but if you use a class like has-large-font-size then its CSS value obviously should not ever be hardcoded anywhere. Either don't use a class and set the font-size in a style attribute or give developers the control over the class's value.

The mentioned Github issue isn't related to this bug.

Here's some simple instructions, how you can test this issue:

  1. on any theme find the element that wraps the output of the_content() and make sure the style font-size: 16px is set on that element.
  1. Create a new post with a Cover block, give it a background and type some text. The text by default will have the has-large-font-size class. Publish the post.
  1. Visually compare the Cover block on the front-end with the Cover block in the editor. They will be more or less identical.
  1. Now change the font-size on the element from step 1 and repeat step 4. The text will differ.

You don't need any of the official themes for this. All you need is a wrapper for the_content() and block editor support enabled. No stylesheets are needed because it's all core WP.

#5 @andrejcremoznik
5 weeks ago

Should I post this issue to Github?

#6 @ryelle
5 weeks ago

Thanks for the testing instructions! Now that I understand your problem better, I think github would be a better place for this discussion. You can open an issue here.

Note: See TracTickets for help on using tickets.