-
Notifications
You must be signed in to change notification settings - Fork 4.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
Don't overlap canvas with inserter panel at large screens #64110
Conversation
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: +549 B (+0.03%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
@@ -1,5 +1,5 @@ | |||
$block-inserter-preview-height: 350px; | |||
$block-inserter-width: 350px; | |||
$block-quick-inserter-width: 350px; |
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.
Renaming this as I kept getting confused since this variable was only applicable to the quick inserter (the inline inserter in the canvas)
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.
Worth an inline comment as well, defining what that is (for future reference?)
@@ -299,7 +305,7 @@ $block-inserter-tabs-height: 44px; | |||
@include break-medium { | |||
border-left: $border-width solid $gray-200; | |||
padding: 0; | |||
left: 100%; | |||
left: $secondary-sidebar-width; |
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 is now a fixed number, but we need it to be to know how far to offset. The category panel content still needs to be absolutely positioned as it's within the flow of the tabs.
left: 100%; | ||
width: 300px; | ||
left: $secondary-sidebar-width; | ||
width: $sidebar-width; |
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.
@richtabor This was previously fixed at 300px and updating this to $sidebar-width makes it thinner at 280px. I think it still looks good but wanted to flag this.
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.
Yup, it's good to go.
|
||
@include break-medium() { | ||
width: 350px; | ||
} |
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 shouldn't have been fixed at 350, as it shouldn't care what the parent width is. This would need to be removed to use it within the right side setting sidebar anyways.
It should be just as fluid as the other sidebars are on the right. In this case, it's a step backwards from what's in trunk: This PR:CleanShot.2024-07-31.at.13.42.53.mp4Trunk:CleanShot.2024-07-31.at.13.45.12.mp4 |
@richtabor see if you like the latest. The pattern category opening still feels clunky but I think the rest is matched. |
@@ -1,5 +1,5 @@ | |||
$block-inserter-preview-height: 350px; | |||
$block-inserter-width: 350px; | |||
$block-quick-inserter-width: 350px; |
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.
$block-quick-inserter-width: 350px; | |
$block-quick-inserter-width: 350px; // Only used in the quick inserter. |
} } | ||
transition={ defaultTransition } | ||
> | ||
<div | ||
<motion.div |
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.
Why do we need two motion components?
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.
One sets the width of the sidebar, and one allows the content to slide in on top of it. We need the sidebar to use a width so it can push the canvas over smoothly. The X value didn't work for that. And if we only use width, then then content of the sidebar reflows instead of being a fixed width.
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.
Because the parent animation is a width, not a transform, the child doesn't move with it, as it is absolutely positioned. We did try using a transform for the parent but that broke the animations for the canvas, because the canvas resizes based on the width of the sidebar.
> | ||
{ children } | ||
<motion.div |
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.
Is it better to have the motion div inside each tab, or could we put this outside categories.map
?
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.
The tab won't mount its content until it is selected, so this is essentially one div until it mounts. It's possible it's better if we have it outside of it, but I'm concerned with that method since until we have a tabpanel selected, the semantics are off. I think this way with the motion div inside is safer semantically.
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.
The motion div only gets mounted when the category is mounted, so we don't generate loads of motion divs with this approach anyway.
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 think this is ready to go, but I'd like to get a review from @richtabor too, to check its working as expected :)
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 is an improvement from covering up the content; I like it.
One follow-up for the transition is to specify a slightly different transition when the category panel is transitioning out. Perhaps a slight delay, or a big stronger start to the transition could help the panel look like it's sliding back behind the Inserter—instead of now where it disappears.
Flaky tests detected in f764e96. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/10188244291
|
Yeah this is hard to do because the whole component gets unmounted, so it would require a lot of reworking. |
What?
At larger screen sizes, resize the canvas when the pattern category panel is open.
Fixes #63510
Why?
Allow the full canvas to be visible.
How?
When the pattern category is open, manually increase the width of the sidebar. Added a new base variable called
$secondary-sidebar-width
to use in list view and inserter sidebars and remove it from the tabbed sidebar component.Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Screen.Recording.2024-07-30.at.1.44.56.PM.mov