dropbuttons get weird white line when font size is changed and at at various zoom settings

Patch #12, no longer applies to 10.1.x. I have re-rolled the patch. Along with that instead of margin-right I have used margin-inline-end so we don't need to write it again for RTL. Please review.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Issue version was not updated. Bot checked against wrong branch.

Able to reproduce the issue using steps in IS
Verified and tested patch #16 on Drupal 10.1.x-dev
The patch applied cleanly
The issue got resolved after applying the patch. Now, the white line doesn't appear when the font size is reduced
Refer to the attached screenshots

Before:

After:

RTBC +1

For me this is a won't fix because this is a button + dropdown. That little space provides some separation but without it the two blend together.

Will post in #frontend

Yeah, I think removing the vertical line is out of scope.

The issue summary is about removing the bottom line.

Providing the patch, Please review it.

Cannot reproduce this issue on Drupal: 10.1.x, tried it on different browsers and with different font sizes. Attaching screenshots for reference.

Build failure in #22

Addressed #21, attached interdiff with #16.

#22, introduced a new solution, that is not aligned with the earlier ones.

@Gauravvvv Thanks for the Patch. I tested Patch #27 and it is working fine. Please find the attached image for the results.

Thank You!!

Checked the patch given in #27 working fine as expected

The last submitted patch, 27: 3316627-27.patch, failed testing. View results →

I tried the various patches here and all of them had issues at certain zoom settings. MR has a solution that I believe works at all zoom settings, and a reviewer can confirm or disprove this 😎

Tested the MR3768 and did not see any issue when zooming in and out. Used chrome for testing.

Crediting @smustgrave for changing the course of the issue and @Asha Nair for the first screenshots

Manually tested this and confirmed the white box at the bottom is gone.

Crediting joachim for reporting.

Committed to 10.1.x and backported to 10.0.x and 9.5.x

Updating status

Reverting this from 9.5.x, while this cherry-picked cleanly, yarn build gives a different result:

diff --git a/core/themes/claro/css/components/dropbutton.css b/core/themes/claro/css/components/dropbutton.css
index fa35ce738f..15d9a3fba1 100644
--- a/core/themes/claro/css/components/dropbutton.css
+++ b/core/themes/claro/css/components/dropbutton.css
@@ -67,12 +67,16 @@
 }
 
 .js .dropbutton-widget {
-  border-radius: var(--button-border-radius-size);
-  background-color: var(--button-bg-color);
+  border-radius: 2px;
+  background-color: #d3d4d9;
+}
+
+[dir="ltr"] .js .dropbutton-action {
+  border-right: 1px solid white;
 }
 
-.js .dropbutton-action {
-  border-inline-end: var(--dropbutton-border-size) solid white;
+[dir="rtl"] .js .dropbutton-action {
+  border-left: 1px solid white;
 }
 
 /* Variants. */

This is presumably because we can't use CSS variables on IE11 in 9.5.x, and so PostCSS builds the resulting CSS differently.

Good catch!

Committed the new patch variant to 9.5.x

Lessons learned - 'css only changes' still need testing on lower versions before backport 😀

Thanks @longwave

Automatically closed - issue fixed for 2 weeks with no activity.

The button background introduced a problem in Gin theme
🐛 Dropbutton style issue after Claro update Fixed

Was looking at this issue and was surprised that the person who created the issue was not given issue credit... I thought we always give issue credit to the issue creator? In fact, I don't know why that wouldn't just default to being checked. Also, Deepali looks to have genuinely tested a patch that had not been tested yet didn't get credit so I'm unclear on that as well. But since this is marked closed, I don't know if it will be changed.