Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preformatted block: Add support for font sizes #27584

Open
wants to merge 3 commits into
base: master
from

Conversation

@mendezcode
Copy link

@mendezcode mendezcode commented Dec 8, 2020

Description

Adds support for font sizes to the preformatted code block. It also changes the CSS for this block to use the global styles variable, setting a fallback font size.

How has this been tested?

Tested with a block based and non block based version of twentytwentyone.

Screenshots

Screen Shot 2020-12-08 at 12 59 17 PM

Types of changes

New feature (non-breaking change which adds functionality).

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.
  • I've updated all React Native files affected by any refactorings/renamings in this PR.
@@ -0,0 +1,4 @@
.wp-block-preformatted {
overflow-x: auto;

This comment has been minimized.

@jasmussen

jasmussen Dec 9, 2020
Contributor

The style.scss file always gets loaded into the editor, so if a rule exists in that file, it does not need to be replicated in editor.scss.

This comment has been minimized.

@mendezcode

mendezcode Dec 9, 2020
Author

Oh, yes, true that. I'll fix accordingly.

@@ -0,0 +1,4 @@
.wp-block-preformatted {
overflow-x: auto;
white-space: pre !important;

This comment has been minimized.

@jasmussen

jasmussen Dec 9, 2020
Contributor

Since this rule also exists in style.scss, we are so close to not needing any editor style at all for this block. And we should be avoiding !important anyway, if at all possible. I dug in to see why the !important was necessary, and it appears that white-space: pre-wrap; is applied as an inline style on the preformatted block:

Screenshot 2020-12-09 at 08 20 30

Why does that exist? I'm not sure, but from digging at the code, it looks to be related to this PR: #18656. Or possibly #17779. Specifically there's some commentary in https://github.com/WordPress/gutenberg/pull/17779/files#diff-7df6f5253ccec2f2e6d1bb22e81f87a4b6bccd2604463eeecded163aa27fd333R70 which seems relevant.

It seems we need to figure out why that output

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Dec 9, 2020

Thanks so much for this PR! Here's the editor, before:

editor before

Frontend, before:

front before

Here's the editor, after:

editor after

Here's the frontend, after:

front after

The font size control is also added:

Screenshot 2020-12-09 at 08 26 23

That font size stuff all seems fine. It also adds a white-space: nowrap; property with a horizontal scrollbar. While it's good that this makes the frontend and editor sync up, this is the part of the PR we need to tread carefully with:

  1. It changes the default appearance of the block which is already in wide usage. While I generally think it's an okay change, it is nevertheless a change, which means we need to tread carefully.
  2. As I also left some comments about, it changes the intrinsic pre-wrap property to wrap, which based on commentary in the code by @ellatrix might go against initial intentions.

It seems the safest way forward, which still puts the frontend in sync with the editor, is to go in the opposite direction.

Instead of:

.wp-block-preformatted {
	font-size: var(--wp--preset--font-size--extra-small, 1em);
	overflow-x: auto;
	white-space: pre;
}

you output

.wp-block-preformatted {
	font-size: var(--wp--preset--font-size--extra-small, 1em);
	white-space: pre-wrap;
}

That way you can also remove the editor style you added again, and we sync up the frontend.

I'd also argue that this serves as a good bugfix for the lacklustre overflow handling.

What do you think?

This is a more elegant solution compared to the previous one, which relied on overflow.
@mendezcode
Copy link
Author

@mendezcode mendezcode commented Dec 9, 2020

It changes the default appearance of the block which is already in wide usage. While I generally think it's an okay change, it is nevertheless a change, which means we need to tread carefully.

@jasmussen What I think would make sense here is to do the following:

Set the default font size to match the existing size in Gutenberg. Right now it is --wp--preset--font-size--extra-small, and it definitely looks different compared to the size before. It may need to be set to the current value it has at the moment. I haven't looked, but there may be a bigger font size that matches the current size of the editor.

My thinking here is that this needs to be done as progressive enhancement instead of doing it like I did initially. It must have backwards compatibility with the existing preformatted block, which means it would be totally better for it to have the same size it had.

I'll work on the backwards compatibility fix for the font size and will keep you posted.

What do you think?

Makes absolute sense, I pushed a commit to address the pre-wrap change. Thanks!

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Dec 9, 2020

Set the default font size to match the existing size in Gutenberg. Right now it is --wp--preset--font-size--extra-small, and it definitely looks different compared to the size before. It may need to be set to the current value it has at the moment. I haven't looked, but there may be a bigger font size that matches the current size of the editor.

The size looks the same to me in my testing of TT1🔳s, but definitely worth testing the before and after in a few themes to be sure.

My thinking here is that this needs to be done as progressive enhancement instead of doing it like I did initially. It must have backwards compatibility with the existing preformatted block, which means it would be totally better for it to have the same size it had.

I think that's generally the safe mindset, but it doesn't have to be the case always. If the existing block has a bug or something in that category, it's fine to fix it. So the fact that it goes out to every user, is arguably a key benefit. So this isn't a fundamental issue, so much as us being careful that we do this deliberately and thinking through any potential side effects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.