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

Let the menu grow #8756

Merged
merged 3 commits into from
Aug 16, 2018
Merged

Let the menu grow #8756

merged 3 commits into from
Aug 16, 2018

Conversation

jasmussen
Copy link
Contributor

This PR lets the menu grow to accommodate long text. Already now in Spanish, the "Code Editor" wraps having to fit both the spanish label and keyboard shortcut. As we add more keyboard shortcuts as well as hints, we need to let the menu grow to accommodate that, up to the mobile breakpoint in width.

This PR accomplishes that using auto widths, nowrap whitespace, and a little Nacin' Spacin' thrown in for code cleanup while I was there.

Screenshots:

screen shot 2018-08-09 at 09 37 39

screen shot 2018-08-09 at 09 38 17

Affects #7433

To test, verify that there are no regressions with any menus/popover content, including the switcher and the library.

@jasmussen jasmussen added the [Type] Enhancement A suggestion for improvement. label Aug 9, 2018
@jasmussen jasmussen self-assigned this Aug 9, 2018
@jasmussen jasmussen requested a review from a team August 9, 2018 07:41
@gziolo
Copy link
Member

gziolo commented Aug 9, 2018

We introduce stylelint which enforces WordPress standards for SCSS files. You can run it with npm run lint-css to see all issues and npm run lint-css:fix to let the tool fix the following issues:

[0] [2] packages/components/src/popover/style.scss
[0] [2] 150:26 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 150:37 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 155:38 ✖ Unexpected whitespace at end of line no-eol-whitespace
[0] [2] 161:26 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 161:37 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 165:26 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 165:37 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 170:26 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 170:37 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 176:26 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 176:37 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 176:44 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 176:55 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 187:26 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 187:37 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside
[0] [2] 187:44 ✖ Unexpected whitespace after "(" selector-pseudo-class-parentheses-space-inside
[0] [2] 187:55 ✖ Unexpected whitespace before ")" selector-pseudo-class-parentheses-space-inside

@jasmussen
Copy link
Contributor Author

ORLY, and that linter doesn't allow Nacin-Spacin'? Who designed this thing?

:D

I'll fix things up. But seriously though — space after parenthesis is WordPress coding style no?

@noisysocks
Copy link
Member

But seriously though — space after parenthesis is WordPress coding style no?

https://make.wordpress.org/core/handbook/best-practices/coding-standards/css/#values

  • Do not pad parentheses with spaces

Weird, huh?

@gziolo
Copy link
Member

gziolo commented Aug 9, 2018

I'll fix things up. But seriously though — space after parenthesis is WordPress coding style no?

I have never studied them, however, @ntwb should know why it works as it works 😃

@jasmussen
Copy link
Contributor Author

jasmussen commented Aug 9, 2018

Wait what when did this happen?

Also CC: @pento I'M ESCALATING THIS ALL THE WAY 😂

Are we also writing "Wordpress" now?

@pento
Copy link
Member

pento commented Aug 9, 2018

WHO WROTE THESE CSS CODING STANDARDS

😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡

@pento
Copy link
Member

pento commented Aug 9, 2018

Are we also writing "Wordpress" now?

We definitely capital_P_dangit() wherever we find it. 😉

@ntwb
Copy link
Member

ntwb commented Aug 9, 2018

h23hmby

@jasmussen
Copy link
Contributor Author

alert( 'This is not fine!` );

@tofumatt
Copy link
Member

tofumatt commented Aug 9, 2018

As someone who advocates for coding standards that vary by language, I like the lack of spaces in our (S)CSS! 😄

Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

What happens if the menu text is too long, say in a locale with long words?

@@ -42,10 +42,14 @@
stroke: $dark-gray-900 !important;
fill: $dark-gray-900 !important;
}

// Don't wrap text.
Copy link
Member

Choose a reason for hiding this comment

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

Won't this mean it overflows if it's too long?

height: auto;
overflow-y: auto;

// Let the menu scale to fit items.
width: auto;
Copy link
Member

Choose a reason for hiding this comment

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

These are literally out of alphabetical order and I find that makes them so tough to read. Not part of the coding standards though, so I gotta just live with it I guess 🤷‍♂️

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So, what will happen if you add a really really really really long sentence, one that is larger than 360px minus the chrome, well then a horizontal scrollbar will appear in the menu. And we need the whitespace in order for the menu to grow.

From a philosophical perspective, though, I think it's okay to set "no wrapping" as a hard limit. I can't think of software where I see menu items wrapping text (* quickly flips through macos file menus to verify*). Added to that, I feel like we could also put some onus on translators to test that things look right.

That's my opinion in any case.

@tofumatt
Copy link
Member

tofumatt commented Aug 9, 2018

To be clear: I really like this and am just curious about very long names. After that's addressed I think we should 🚢

@sarahmonster
Copy link
Member

It might make sense to wrap the text for smaller screens, to avoid horizontal scrolling within the popover:

2018-08-09 11 20 10

@jasmussen
Copy link
Contributor Author

Without the whitespace rule, the menu can't grow — the menu grows by having a min width, a max width, and a width set to auto. But auto allows text wrapping, whereas if you turn off text wrapping, the menu itself expands.

If we were to want to address super long titles on mobile, we'd need to explicitly set a width. Which is definitely doable, something like on mobile, the menu is always 100% the width of the screen and text wraps, and beyond the mobile breakpoint we flip back to auto width and nowrap.

However it does feel like we're hyper optimizing for catastrophe before it's even happened. Which... I know that sounds strong and I'm REALLY not trying to dismiss any of this legitimate feedback. I'm just wondering if we should postpone fixing the theoretical issue until it's an actual issue?

@sarahmonster
Copy link
Member

Can plugins extend this area? Totally agreed that if we have control over the text here, it's unlikely to be an issue. But if plugins can extend the popover menu, we may not have a way of monitoring when it's become an issue, beyond "people start to complain and/or stop using things."

Also, if we're running on the assumption that users don't want to use WordPress via a web browser on their mobile device, this probably doesn't need to be addressed now. That may well be the case—I don't have any data here and I wouldn't be surprised if users would prefer to use the app ... but that could also be an effect of "the app is easier to use on my phone" as well, so 🙃.

@jasmussen
Copy link
Contributor Author

Yes, plugins can indeed extend this area. It's a solid point. I will try and see if I can figure something at least for the mobile breakpoints.

@jasmussen
Copy link
Contributor Author

So, I write some CSS to try and make the menu full width on mobile through classic responsive breakpoint work, but then I noticed a bunch of .is-mobile references in the CSS. I tried replicating those, but as far as I can tell, that functionality is completely broken right now.

The key seems to start here: https://github.com/WordPress/gutenberg/blob/master/packages/components/src/popover/index.js#L255

... but I'm not actually sure when this is supposed to work. Is this a prop we set on a per-component boolean? @tofumatt since you're way more skilled in this than I am, is there any chance you can take a look and see what might be up?

Here's how I imagine it should work:

@jasmussen jasmussen added this to the 3.6 milestone Aug 15, 2018
@youknowriad
Copy link
Contributor

youknowriad commented Aug 15, 2018

@jasmussen The is-mobile className is definitely a per-component controlled prop. That's how the inserter works on mobile. you need to pass expandOnMobile prop to the Popover component to trigger this behavior.

I'd be very cautious to style changes there :) it affects the inserter.

@tofumatt
Copy link
Member

Sorry, I somehow just missed that GitHub ping. 😓

@tofumatt
Copy link
Member

Like @youknowriad said: at any rate I don't think you want to use that class; I'd think you'd want to use breakpoints.

I'm unclear if this is ready for another review or not, it looks the same as it did before. Feel free to ping me if there are unanswered questions. 😄

@youknowriad
Copy link
Contributor

To clarify, this class is only added on small screens if the prop is true. So if the behavior wanted here is to make this popover fullscreen on mobile, this is the right way to do it. Use this prop.

This PR lets the menu grow to accommodate long text. Already now in Spanish, the "Code Editor" wraps having to fit both the spanish label and keyboard shortcut. As we add more keyboard shortcuts as well as hints, we need to let the menu grow to accommodate that, up to the mobile breakpoint in width.

This PR accomplishes that using auto widths, nowrap whitespace, and a little Nacin' Spacin' thrown in for code cleanup while I was there.
@jasmussen
Copy link
Contributor Author

Now there's a case for mobile, where we allow wrapping. It's not super pretty and we'll probably encourage shorter titles, but it should work:

screen shot 2018-08-16 at 09 48 24

Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

Hah, it occurs to me: why do we even show the keyboard shortcuts on mobile? We could get a lot more use out of that space by hiding them, and keyboard shortcuts on mobile aren't super useful.

Still, this is better. Let's 🚢 , but maybe we should hide those shortcuts on mobile too. I'll make a PR for it.

@@ -41,11 +41,19 @@
// !important allows icons from plugins to be overriden and given a dark-gray fill
fill: $dark-gray-900 !important;
}

// Don't wrap text.
Copy link
Member

Choose a reason for hiding this comment

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

Should this be "Don't wrap text on mobile screens."?


// Don't wrap text.
@include break-mobile() {
.components-popover:not(.is-mobile) & {
Copy link
Member

@tofumatt tofumatt Aug 16, 2018

Choose a reason for hiding this comment

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

This is a bit confusing because it's used on mobile breakpoints but when :not(.is-mobile) is true. 😕

EDIT: Nevermind, I just understood how this works and apparently @include break-mobile works unlike how I expect.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The "break-mobile" mixin is the confusing aspect. is-mobile never invokes on desktop responsive viewpoints, but the mixin does as it is just a media query. So in a way this is a responsive fix, not solely a mobile fix. And given the whole behavior of the popover changes when is-mobile is present, I'd rather not interfere here.

I will clarify the comment.

Copy link
Member

Choose a reason for hiding this comment

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

lol, paths crossed! Cheers 👍

@jasmussen
Copy link
Contributor Author

The keyboard shortcuts thought is a solid idea, and worth a separate ticket.

Note that there are some considerations for that — you might have a really thin viewport on the desktop, but still have access to the shortcuts. Would we want to show or hide them in this case?

@jasmussen jasmussen merged commit c3211fa into master Aug 16, 2018
@jasmussen jasmussen deleted the try/let-the-menu-grow branch August 16, 2018 13:25
@noisysocks
Copy link
Member

It looks like this has accidentally made DotTips appear too narrow on desktop:

localhost_8888_wp-admin_post-new php screen recording

@jasmussen
Copy link
Contributor Author

Hmm, that is unfortunate. I'll put together a PR to fix. Here's all the tips, for posterity. Although it's suboptimal, I don't feel like it's so bad we need to make a point release to fix:

tips

jasmussen added a commit that referenced this pull request Aug 17, 2018
This fixes a regression introduced as part of #8756. Basically we removed the min-width so as to let the content itself expand the popover. But alas an empty textfield, like the URL input field, did not expand the popover as it should. We could look at adding the min-width to the URL input field instead, this should expand the popover, but given the fallout this min-width removal has caused already, it's probably good to keep it in place as a baseline.
mtias pushed a commit that referenced this pull request Aug 17, 2018
This fixes a regression introduced as part of #8756. Basically we removed the min-width so as to let the content itself expand the popover. But alas an empty textfield, like the URL input field, did not expand the popover as it should. We could look at adding the min-width to the URL input field instead, this should expand the popover, but given the fallout this min-width removal has caused already, it's probably good to keep it in place as a baseline.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants