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

Latest Comments: Add border block support #66020

Open
wants to merge 9 commits into
base: trunk
Choose a base branch
from

Conversation

karthick-murugan
Copy link
Contributor

@karthick-murugan karthick-murugan commented Oct 10, 2024

What?

Add border block support to the Latest Comments block.

Part of #43247

Why?

Latest Comments block is missing border support.

How?

Adds the border block support in block.json

Testing Instructions

  • Go to Global Styles setting ( under appearance > editor > styles > edit styles > blocks )
  • Make sure that Latest Comments block's border is configurable via Global Styles
  • Verify that Global Styles are applied correctly in the editor and frontend
  • Edit template/page, Add Latest Comments block and Apply the border styles
  • Verify that block styles take precedence over global styles
  • Verify that block borders display correctly in both the editor and frontend
  • Since padding style has been moved from style.scss to editor.scss, please activate TT1 theme and check any padding are applied to the latest comments block.

Testing Instructions for Keyboard

Screenshots or screencast

In Frontend:
frontend

In Backend:
backend1

Copy link

github-actions bot commented Oct 10, 2024

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: karthick-murugan <[email protected]>
Co-authored-by: akasunil <[email protected]>
Co-authored-by: aaronrobertshaw <[email protected]>
Co-authored-by: carolinan <[email protected]>
Co-authored-by: jasmussen <[email protected]>

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

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

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @karthick-murugan! 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.

@akasunil akasunil added [Type] Enhancement A suggestion for improvement. [Block] Latest Comments Affects the Latest Comments Block [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi labels Oct 10, 2024
Copy link
Member

@akasunil akasunil 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 your contribution @karthick-murugan

✅ Global Styles apply correctly
✅ Block styles override Global Styles
✅ Styling is consistent between editor and front-end
✅ Box sizing allows parent container to enforce accurate width
✅ Border support is default, consistent with spacing support

Single-Posts-.-Template-.-gutenberg-.-Editor-.-WordPress.webm

LGTM 🎉

@akasunil
Copy link
Member

@aaronrobertshaw I could appreciate a second opinion to make sure I haven't overlooked anything.

@karthick-murugan
Copy link
Contributor Author

@aaronrobertshaw I could appreciate a second opinion to make sure I haven't overlooked anything.

@aaronrobertshaw - If you have some time, can you please review this PR. Thank you very much in advance. 🙇

Copy link
Contributor

@aaronrobertshaw aaronrobertshaw 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 your patience @karthick-murugan this one 👍

This PR is nearly there.

✅ Global styles apply
✅ Block instance styles override global styles
✅ Border controls are displayed by default to match spacing controls
✅ Box sizing allow parent block to enforce width

There are a couple of things that need to be fixed before merging though. I've left comments inline below. They aren't major so shouldn't take too much to get this ready to land.

Comment on lines 39 to 41
// The following styles are to prevent duplicate border for the latest comments.
border: none;
border-radius: inherit;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm assuming the intent of these is to prevent duplicate border due to the server side rendering in the editor?

  • The inline comment should probably explain why/how there could be duplicate borders
  • These are editor only styles, placing them here sends them incorrectly to the frontend too

The padding-left style above doesn't prevent the duplicate spacing in the editor either. So while you're moving the border resets to an editor.scss file, padding needs adding there too.

On that padding note, I'm not sure if the padding-left rule needs to be on the frontend or not. It might be that the selector here needs lowering in specificity so that global styles can apply correctly.

For this PR, I'd definitely sort out fixing the server-side rendering duplicate styles for padding and border. It's not much extra in terms of scope but if you really want to push the padding-left thing to a follow-up that's neither here nor there 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you very much for the review, @aaronrobertshaw. I’ve implemented all your feedback and pushed the changes.

The padding-left has been moved to the editor.scss file as it’s not needed on the frontend. Since this resolves the issue, I believe a separate PR for padding-left adjustments won’t be necessary.

Let me know if you have any further suggestions!

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the iteration @karthick-murugan but my feedback included fixing the duplicate padding caused by the server-side rendering. This isn't addressed by only moving the padding-left rule.

When fixing this, could you also update the PR test instructions to cover this? Also, how does the relocation of the padding-left rule affect the issue the PR that introduced the style aimed to solve? Does moving this style cause a regression in older themes e.g. TT1 or TT1 blocks?

In making changes to existing code or styles it's really helpful to keep Chesterton's Fence in mind. The TL;DR on that principle is we need to understand why something is in place before we change or move it to avoid unintended side effects.

On top of that, each time I update a PR, I personally re-run through the test instructions and ask myself questions about what has changed. This helps make sure the PR is easy for others to review and helps reduce the feedback cycle duration, increasing velocity.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you, @aaronrobertshaw, for your detailed feedback and for emphasizing the importance of addressing the root cause and avoiding unintended regressions.

  1. I have activated the TT1 theme and verified the Latest Comments block. The style .wp-block-latest-comments .wp-block-latest-comments { padding-left: 0; } is not applied on the frontend. This confirms that moving the padding-left rule to the editor.scss file does not introduce any regressions for older themes, including TT1 and TT1 Blocks.
REC-20241126132321.1.mp4
  1. After moving the padding-left rule to editor.scss, the original intent of removing unnecessary left padding in the editor, customizer, and widgets remains intact. I have recorded a video demonstrating this behavior.

  2. Additionally, I have tested the block borders in various scenarios following the recent changes. The video included in the PR reflects the current state, ensuring that the duplicate border issue is resolved without affecting other styles.

REC-20241126131024.mp4
  1. I have also updated the PR test instructions to explicitly cover these scenarios, helping reviewers validate the changes effectively.

Please let me know if there’s anything else you’d like me to revisit or clarify. I appreciate your guidance and the opportunity to iterate on this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the iteration @karthick-murugan but my feedback included fixing the duplicate padding caused by the server-side rendering. This isn't addressed by only moving the padding-left rule.

This still hasn't been addressed.

Steps to replicate:

  1. Add latest comments block
  2. Navigate to Styles > Blocks > Latest Comments
  3. Add padding
  4. Note duplicate padding except on the left (because only padding-left: 0 is in the reset styles.
Screen.Recording.2024-11-27.at.11.06.59.am.mp4

In addition to the padding, the margin on the inner server-side rendered block also needs resetting.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for your feedback, @aaronrobertshaw. I believe I have addressed the padding and margin issues as part of the recent iteration. To ensure clarity, I’ve recorded a video demonstrating the changes and verifying the behaviour.

REC-20241127124310.mp4

If I’ve misunderstood or overlooked anything, please feel free to correct me. I appreciate your guidance and am happy to make further adjustments as needed. 😊

Copy link
Contributor

@aaronrobertshaw aaronrobertshaw left a comment

Choose a reason for hiding this comment

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

Appreciate the patience and continued iteration here @karthick-murugan 👍

I've taken this PR for another spin. There are still some easy to encounter issues that need ironing out. They probably also speak to gaps in the test instructions as well.

Margins between the editor and frontend don't match:

Editor Frontend
Screenshot 2024-11-28 at 12 20 57 pm Screenshot 2024-11-28 at 12 21 01 pm

In the above screenshots, I have a Group block, containing 2 paragraphs with the Latest Comments block in between them. The Latest Comments block has a margin applied and it appears as though they are reset correctly in the editor for the server side render, the final margins on the frontend don't match.

Padding doesn't match on frontend

The user agent list styles are present on the frontend but are reset in the editor.

Editor Frontend
Screenshot 2024-11-28 at 12 14 06 pm Screenshot 2024-11-28 at 12 14 11 pm

I've left some comments inline with some extra thoughts.

// This block has customizable border, border-box makes that more predictable.
box-sizing: border-box;
}

// Lower specificity - target list element.
ol.wp-block-latest-comments {
// Removes left spacing in Customizer Widgets screen.
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this style still be in the frontend styles?

Its specificity is also higher than the style produced by global styles. (0-1-0). The only reason the global styles margins in the editor work is because the block is server-side rendered and the block's outer wrapper receiving the margins is then a div.

In other words, when you moved the margin-left: 0 style to the editor styles. Did you consider removing this? Better yet, did you test removing it at all, especially in the Customizer?

.wp-block-latest-comments .wp-block-latest-comments {
// Remove spacing. Higher specificity required to
// override default wp-block layout styles in the Post/Site editor.
padding: 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

There's a difference between the editor and frontend still when it comes to padding.

If no padding is specified in the editor, the frontend still uses the padding-left from the browser's user agent list styles.

We probably need to make that consistent. For backwards compatibility though, I don't think we can just remove the user agent padding. Some themes might be relying on that padding.

I'm not sure if it is possible to make the editor display the user agent list padding-left, without perhaps changing the server side render's outer wrapper to be an ol instead of a div. That would then require massaging all those list styles on the outer wrapper again.

If there's no good option there, perhaps we'll need to get design feedback on whether the user agent styles for the comments block could be safely reset on the frontend.

Copy link
Contributor

@carolinan carolinan Dec 4, 2024

Choose a reason for hiding this comment

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

I would prefer applying the padding: 0 on the front over changing the wrapper, because it is a smaller change.
And the markup in the editor is already pretty complex.

Copy link
Contributor

Choose a reason for hiding this comment

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

For clarity, my suggestion was only to swap the wrapper from this block's server-side rendering to a list element instead of a div. Then apply any necessary reset styles. I don't think that makes the markup in the editor more complex.

The main goal for me is visual consistency for the user between the editor and frontend. I ultimately don't have a strong opinion on whether that's done by tweaking the block's editor rendering or the additional padding reset on the frontend. I am a bit wary of anything that could be a breaking change for frontend styles though.

As you note it is a small change so perhaps it is something that could be merged early in the release cycle and called out?

@carolinan
Copy link
Contributor

The missing padding: 0 on the front end has been reported to be a bug, and I agree.
While this block is technically a list, it is not displayed as one, I mean, it doesn't have the bullet points etc and it does not need to be indented: if the padding is not reset, the block is miss-aligned compared to other blocks in the post and page content.

Here are the issues:
#66043
https://core.trac.wordpress.org/ticket/62615

@aaronrobertshaw
Copy link
Contributor

While this block is technically a list, it is not displayed as one, I mean, it doesn't have the bullet points etc and it does not need to be indented: if the padding is not reset, the block is miss-aligned compared to other blocks in the post and page content.

I think this is a strong argument for adding the padding reset on the frontend. Bonus points for linking the recent issues highlighting this expectation @carolinan 👍

@jasmussen or @jameskoster if you have a second, would you be against resetting the user agent's padding-left for the Latest Comments block by default on the frontend? The padding would still be overridable and the main benefit is providing visual consistency between the editor and frontend.

@jasmussen
Copy link
Contributor

would you be against resetting the user agent's padding-left for the Latest Comments block by default on the frontend? The padding would still be overridable and the main benefit is providing visual consistency between the editor and frontend.

Assuming you can use low specificity, this seems fine to do. There is an expectation that the frontend matches the backend, so it's an important one to address.

Copy link
Contributor

@aaronrobertshaw aaronrobertshaw 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 sanity check @jasmussen 🙇

@karthick-murugan, we should be able to add this padding reset using :where to keep the specificity to a bare minimum:

:where(.wp-block-latest-comments) {
	padding: 0;
}

In addition to that, I think it would pay to look through styles.scss and editor.scss to see what duplicate styles have been created by the proposed changes. For example, the new box-sizing rule appears to double up on the one defined below.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Latest Comments Affects the Latest Comments Block [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants