Skip to content

Conversation

@coderGtm
Copy link
Contributor

@coderGtm coderGtm commented Jun 3, 2025

What?

Closes #69668

Fixes the highlight issue for the frontend but does not seem to be working for editor.

Why?

Currently, when text within a code block is highlighted and includes extra white space, it can overflow beyond the code box, which is not ideal. While this issue is uncommon, it negatively affects the overall UI experience when it does happen.

How?

Changed the white-space property to break-spaces in the style.scss file.

Testing Instructions

  1. Create a new Post
  2. Insert a code block with extra white-spaces at the end of 1 line.
  3. Highlight the code's background from the Block Controls Toolbar.
  4. Verify that the highlight does not overflow the code block in the frontend.

Screenshots

Before After
Screenshot 2025-06-03 at 5 46 06 PM Screenshot 2025-06-03 at 5 46 16 PM

Note

While this solves the issue on the frontend, it is still not solved in the editor. Despite applying the css in style.css, it is overiden by inline styles of the Code block that adds white-space: pre-wrap; min-width: 1px; to the element:

Screenshot 2025-06-03 at 5 49 22 PM

While I am searching the source of this inline style, any guidance would be helpful.

Thanks

@github-actions github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Jun 3, 2025
@github-actions
Copy link

github-actions bot commented Jun 3, 2025

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @coderGtm! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

@coderGtm coderGtm marked this pull request as ready for review June 3, 2025 13:48
@github-actions
Copy link

github-actions bot commented Jun 3, 2025

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: coderGtm <[email protected]>
Co-authored-by: fabiankaegy <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: yyppsk <[email protected]>
Co-authored-by: jasmussen <[email protected]>
Co-authored-by: Rishit30G <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@coderGtm
Copy link
Contributor Author

coderGtm commented Jun 3, 2025

Added !important to the attribute value to fix the editor style.

Since the Code Block internally uses the RichText Component, it has stylings of RichText applied. And the RichText uses some default styles which are defined here. These styles are applied as inline styles and take precedence over the Code Block's style.scss and hence, added the !important rule to fix it.

Another option would be to change the value of whiteSpace to break-spaces here in the default styles but I don't know how other components would be affected in that case.

Before After
Screenshot 2025-06-03 at 10 40 59 PM Screenshot 2025-06-03 at 10 41 12 PM

@t-hamano t-hamano added [Block] Code Affects the Code Block [Type] Bug An existing feature does not function as intended labels Jun 5, 2025
font-family: inherit;
overflow-wrap: break-word;
white-space: pre-wrap;
white-space: break-spaces !important;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd recommend leave the pre-wrap as a fallback and move the break-spaces into an @supports query since the property is still newer.

Copy link
Member

@fabiankaegy fabiankaegy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick followup :)

After thinking about it for a bit more I have one additional request. We really should avoid using !important wherever we can. I know you explained why you had to use it here and it does make sense. But I think there is an alternative we could use here.

Let's remove the !important from the main stylesheet and then add a separate editor only stylesheet in which we can use a more specific css selector which then can override the property without the usage of !important.

This also ensures that the specificity on the frontend remains as low as possible to 3rd parties can override it easily :)

@coderGtm
Copy link
Contributor Author

coderGtm commented Jun 5, 2025

Hi. I understand your pov about avoiding !important as much as possible but even an editor style wont take precedence here as the pre-wrap style is added inline as I mentioned earlier.

Another solution I found right now, is to give Inline style to the Code Block after the initial Inline styles by Rich Text are applied. This will not require !important and also solves the issue.

@coderGtm coderGtm reopened this Jun 10, 2025
@yyppsk
Copy link

yyppsk commented Jun 14, 2025

Hi @coderGtm ,

I’ve tested this PR on the frontend and block editor and can confirm the highlight no longer overflows the code block as intended.

Environment

  • OS: macOS Air (M3)
  • Browsers: Chrome, Safari, Firefox

Steps to Reproduce

  1. Create a new post.
  2. Insert a code block and add extra whitespace at the end of one line.
  3. Apply a background highlight via the Block Controls toolbar.

Expected Result
The highlighted background should stop at the code block’s edge—even when trailing whitespace is present.

Actual Result
Frontend: No overflow—highlight respects the block boundary in all tested browsers.
Block Editor: Works perfectly fine—no overflow there either.

Screenshots

Before After
Screenshot 2025-06-14 at 9 57 55 PM Screenshot 2025-06-14 at 10 23 05 PM

Block editor

Screenshot 2025-06-14 at 10 37 26 PM

cc: @fabiankaegy

@coderGtm
Copy link
Contributor Author

Hi @fabiankaegy

Did you get a chance to review the changes? Is there anything else expected that I am missing?

Thanks

@coderGtm
Copy link
Contributor Author

coderGtm commented Jul 1, 2025

Just a ping letting reviewers know that all tests are now passing.

cc: @fabiankaegy

@coderGtm coderGtm requested a review from ellatrix as a code owner September 5, 2025 08:34
@Mamaduka Mamaduka requested a review from jasmussen September 15, 2025 11:31
@Mamaduka Mamaduka removed the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Sep 15, 2025
Copy link
Member

@Mamaduka Mamaduka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@coderGtm, I just noticed that you've pushed changes on your fork's trunk`, which makes it harder to test locally.

You should always use feature/fix branches for the PRs. Do you mind extracting this?

Comment on lines +8 to +13
const SUPPORTS_BREAK_SPACES =
typeof CSS !== 'undefined' &&
// eslint-disable-next-line no-undef
CSS.supports &&
// eslint-disable-next-line no-undef
CSS.supports( 'white-space', 'break-spaces' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can simplify this with optional chaining - !! CSS?.supports?.( 'white-space', 'break-spaces' );

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It think it is safer as the suggested expression will short-circuit and return undefined if either CSS or CSS.supports is not defined.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suggested expression will always return a Boolean, because of the !! operator.

if either CSS or CSS.supports is not defined.

Then SUPPORTS_BREAK_SPACES should be false, this is what we want, no?

Comment on lines 24 to 32
/**
* If the browser supports 'break-spaces', we can use it for better
* handling of whitespace in code blocks. Otherwise, we fall back to
* 'pre-wrap', which is more widely supported.
*
* @constant
* @type {string}
*/
const whiteSpaceStyle = SUPPORTS_BREAK_SPACES ? 'break-spaces' : 'pre-wrap';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a comment for this line? It just described what the code is doing, which is already visible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added it as a standard coding practice but yeah understandable as it's not needed really. Removed it.

@coderGtm
Copy link
Contributor Author

coderGtm commented Sep 16, 2025

@Mamaduka
Yes I know that's a big pain to test locally and a bad practice. This was my first PR in WordPress and in excitement I forgot to take it to a new branch and raised the PR. I also have a tough time managing the fork for other PRs due to it.

That is one of the reasons I want to get this PR approved and merged so I can safely update my fork's trunk 😅

I'm not sure what you mean by extracting it. Afaik once a PR is raised its branch cannot be changed, right?

@jasmussen
Copy link
Contributor

Thanks for the PR. The details of the implementation are well covered by other reviewers, so I'll mostly comment on expectations of the behavior of the codeblock, seeing as this is using an exciting and new to me feature of break-spaces.

Which is to say, the "after" image is what I would also expect as far as the default out-of-box experience, so I think the PR/approach is reasonable. Should we choose differently at some point in the future, a block support could be considered for the code block to toggle this behavior off, if you really wanted the spaces to break out.

@Mamaduka
Copy link
Member

Thanks for the input, @jasmussen! I agree, let's keep things simple for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Block] Code Affects the Code Block [Type] Bug An existing feature does not function as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Code Block: Highlighted white space overflows

6 participants