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

Nav block: handle overflowing items using wrap on Block selection #18429

Closed
wants to merge 6 commits into from

Conversation

getdave
Copy link
Contributor

@getdave getdave commented Nov 11, 2019

An alternative attempt at #18298.

See also #18336 (comment)

This approach avoids retaining the overflow scroll when the Block is in edit mode. Instead the items are allowed to wrap thereby improving the editing experience.

The major issue is that there is quite a big change in layout when the Block is selected.

How has this been tested?

Manual testing.

Screenshots

Screen Capture on 2019-11-11 at 12-04-16

Types of changes

Bug fix (non-breaking change which fixes an issue).

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR. .

Now detects hoz scroll and adds suitable class which can be used to hook CSS styles for when there is hoz scrolling.
Previously there were many issues with the editing experience and UI when allow for overflowing editing.

Experiment with allow items to wrap when the Block is selected.

See #18336 (comment)
.wp-block {
display: flex;
flex: 1; // grow to own content width only
// margin-top: $block-padding*2;
Copy link
Contributor

Choose a reason for hiding this comment

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

are we going to keep these lines here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeh these are the key to the PR 😁

Comment on lines +57 to +60
if ( scrollWidth > clientWidth ) {
setHasScrollX( true );
} else {
setHasScrollX( false );
Copy link
Contributor

Choose a reason for hiding this comment

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

minor suggestion
what do you think about

useLayoutEffect( () => setHasScrollX( scrollWidth > clientWidth ), [ clientWidth, scrollWidth ] );

Feel free to ignore it 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes that is valid.

@@ -79,6 +95,7 @@ function NavigationMenu( {
'wp-block-navigation-menu', {
'has-text-color': textColor.color,
'has-background-color': backgroundColor.color,
'has-scroll-x': hasScrollX,
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems that the has-scroll-x' is not being used in any place of the CSS. Should we remove entirely the js code which handles it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We should if we decide this wrapping approach is valid.

@jasmussen
Copy link
Contributor

I think this also touches #18337.

@jasmussen
Copy link
Contributor

Thank you for tackling this head-on. I'm seeing a few issues with scrollbars. This one probably shouldn't be present:

shift

There's also a shift.

There's also some sizing stuff going on:

typing

It is very possible and even likely that I'm missing some of the complexities of the navigation menu, but just to be absolutely sure it's not a failure of my explanation, I created #18431 as a PR that simply allows wrapping using flex-wrap: wrap;. It looks like this:

Screenshot 2019-11-11 at 14 52 46

It's simple, yes, but IMO it feels like a good and very basic baseline that unblocks us, and then we can explore separate PRs that keep all menu items on a single line and handle overflow in a dropdown menu or hamburger or something in that vein.

Did I miss anything obvious?

@draganescu
Copy link
Contributor

To second @jasmussen why would we wrap only on edit and not all the time?

@shaunandrews
Copy link
Contributor

A scrollbar seems very clunky. Perhaps we collapse overflowing menu items within a "more" button. This is a fairly common pattern across the web, and would closely match how I'd expect this to work on the frontend as well. Here's a quick GIF showing how this could look/work:

Navigation Overflow Menu

@draganescu
Copy link
Contributor

@shaunandrews that is a creative approach! I like it :) I wonder what happens next:

  • how do submenus work in that setup?
  • how does the submenu item look with the label on?

@jasmussen
Copy link
Contributor

Perhaps we collapse overflowing menu items within a "more" button. This is a fairly common pattern across the web, and would closely match how I'd expect this to work on the frontend as well.

Nice. It echoes my thoughts. But I wonder if the interface for editing the menu should just let items wrap, as this 3 line PR does: #18431. Picture this — you select the block to edit it, and items wrap. You deselect it and overflowing items are moved into a dropdown menu.

The benefit of that approach is that we can merge #18431 as is to fix #18298, and then we can followup with a PR to enhance that further.

@getdave
Copy link
Contributor Author

getdave commented Nov 14, 2019

The benefit of that approach is that we can merge #18431 as is to fix #18298, and then we can followup with a PR to enhance that further.

@jasmussen I'm confused as to how #18431 improves upon this PR? Isn't it a duplicate?

This discussion feels like we need a decision. I feel this might be best to happen on the Issue so it's more easily traceable. Do we agree?

@jasmussen
Copy link
Contributor

It is a duplicate, yes, it's a different approach to accomplish wrapping. What I'm suggesting with followup improvements, is something along the lines of what Shaun has suggested with a dropdown menu. I don't necessarily think that one blocks anything.

This discussion feels like we need a decision. I feel this might be best to happen on the Issue so it's more easily traceable. Do we agree?

Agree on keeping it on the issue, this was spread across three PRs so a bit hard to follow.

What needs deciding, though, scrollbar or wrap?

@getdave
Copy link
Contributor Author

getdave commented Nov 14, 2019

I've moved the discussion on next steps to the Issue.

@getdave
Copy link
Contributor Author

getdave commented Nov 14, 2019

Closed in favour of Wrap solution. See Closing in favour of Wrap solution. See #18298 (comment)

@getdave getdave closed this Nov 14, 2019
@aristath aristath deleted the try/nav-block-overflow-wrap branch November 10, 2020 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants