-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[core] Fix MenuItem text clipping #2265
Conversation
Merge branch 'develop' into rv/fix-menuitem-clippingPreview: documentation | landing | table |
this causes menu items to render at 32px height by default, which is going to be very obnoxious to fix. all the padding logic assumes 16px height of icons and text. |
yeah, also breaks the grid. @reiv any thoughts on how to preserve 30px height for menu items here? |
Are menu items intended to be single-line? I'm asking because the |
yes, it's gotta be a multiple of IIRC, by default they're one-liners, but it should be able to override that behavior to get a multiline item with correct line-height |
removing |
Oh, so if there's an explicit |
I think that could work yes, it's a 2.0 thing |
Add CSS class for single-line menu itemsPreview: documentation | landing | table |
@llorca That's weird, considering the change shouldn't affect multiline menu items whatsoever (it only adds a class when |
I was just turning |
Apply line-height directly to menu item labelPreview: documentation | landing | table |
@@ -45,6 +45,15 @@ $dark-menu-item-color-active: $dark-minimal-button-background-color-active !defa | |||
color: $pt-text-color-disabled; | |||
} | |||
|
|||
&.pt-menu-item-single-line { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😢 sad we need an extra class just for that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we could define a class for multiline instead. Would that be preferable?
// to be clipped. Instead, we set the height directly to adhere to the | ||
// grid. | ||
height: $pt-grid-size * 3; | ||
line-height: normal; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
normal
makes the text misaligned, vertically not centered by 1px. unset
seems to work, although I have no idea why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see the misalignment on my end, so I'm assuming this is font-specific. Can you post a screenshot please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I thought that was due to Segoe UI's baseline. Here it is with sans-serif
(Arial):
What's odd to me is that changing it from normal
to unset
has no effect on Firefox*, but on Chrome it does actually fix the misalignment with Segoe UI.
* That is, the computed line-height changes from 20px (normal
) to 18px (unset
), but visually it's all the same for some reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to look up the difference between normal
and unset
:
normal
uses the browser default, whereas unset
inherits the nearest parent's value. In this case it would be <body>
, which gets its line-height
from here:
blueprint/packages/core/src/common/_variables.scss
Lines 30 to 31 in b4de4e6
// a little bit extra to ensure the height comes out to just over 18px (and browser rounds to 18px) | |
$pt-line-height: ($pt-grid-size * 1.8) / $pt-font-size + 0.0001 !default; |
So unset
gives us an 18px line height. Furthermore, it seems that in Chrome, odd pixel values for line-height
shift everything down by 1px, as shown here:
This affects most fonts, Arial being one of the exceptions. I'm guessing normal
ends up producing an odd pixel value (inspector doesn't show the actual value), causing the misalignment.
@reiv I assume the original clipping was due to the overflow, have we considered going for |
@llorca Yes, |
@reiv going back to the previous 18px line height try, what about:
this seems to be working solidly on my end, albeit ugly. but if that solves the clipping 🤷♂️ |
Set explicit line-height value based on font sizePreview: documentation | landing | table |
@llorca Ok, cool. 18px might not work for all zoom levels, but I get the idea. |
Add $menu-item-line-height-factor variablePreview: documentation | landing | table |
Add commentPreview: documentation | landing | table |
that looks like progress! I like the fact that we don't need an extra class a couple of issues to address:
|
@@ -61,6 +61,7 @@ Styleguide pt-menu | |||
&::before, | |||
.pt-icon { | |||
align-self: flex-start; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that flex-start works for the icon on the left side, but not for the item label on the right. can you also add flex start for .pt-menu-item-label
on line 69?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Ensure line-height is an even valuePreview: documentation | landing | table |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I think this is sane. @giladgray for final approval.
Separately, we'll have to fix large menu item style regressions (#2281)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this actually looks really good! math is frightening at first, but the change is small and end result is perfect.
one final refactor.
color: $pt-icon-color; | ||
} | ||
|
||
.pt-menu-item-label { | ||
align-self: flex-start; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems we can just change .pt-menu-item
to align-items: flex-start
now, rather than overriding with align-self
here and line 63.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually, i'm going to merge this so I can work on a fix for #2281 and i'll make the align-items
change there.
@reiv thanks for your hard work on this! end result is 💯 🔥 |
Fixes #2177
Reviewers should focus on:
Does this break anything that uses
MenuItem
?Screenshot
Edit: The font shown here, Segoe UI (Windows default), seems to have a weird baseline, causing it to appear slightly off-center compared to other fonts. This isn't fixable without replacing the font altogether.