[List View]: Improve icon alignments and added scroll when blocks are deeply nested. #46990
Conversation
|
Size Change: +1.1 kB (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 6e4e7a7. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3882477240
|
MaggieCabrera
requested review from
jasmussen,
scruffian,
getdave,
ajlende and
draganescu
MaggieCabrera
added
[Type] Enhancement
MaggieCabrera
changed the title
|
Thank you for trying this based on my codepen. This is feeling better and better. Here's a GIF:
I do think if we're going with the approach outlined in the codepen, the base item can be wider initially, it seems like there's room enough for the ellipses to be vertically aligned here: The edit icon also sits a bit up high. Another detail this surfaces: Notice how the edit icon above is cropped? This is because the sidebar panel has a 16px inner padding, even on the right. We could probably do a -16px right margin on the scrollable, to claim that extra space, and have that 16px padding be internal to the scrollable instead. One last thing, I don't think this is easy and perhaps not feasible, but it might be worth looking at making the lock+edit+ellipsis be fixed position overlays on each row instead. That way they could always be vertically aligned — they'd just cover the content below. What do you think? |
|
Thanks for the comments @jasmussen !
Yes, I think this gets solved when we offset the sidebar's padding like you mentioned, have a look, tell me what you think
Mmmmh, maybe as a follow-up? I'm already a bit worried about how this affects the regular list view, I'm not sure what edge cases we might be affecting with visual changes here. Also, how would you consider the overlap in the very deeply nested cases when the arrow and text won't appear at all without scrolling? I've checked the list view and I see this weird interaction with the navigation block having a background color around it. Before we didn't allow scroll at all (even hiding the icons in the process!):
|
Yeah, or as a separate exploration, if I get some time I might take a stab. The original codepen I explored may have been misleading, and didn't fully surface the problem of icons aligning. Mainly that they get misaligned as soon as you scroll right. Edge case, but still, awkward when it happens. I wonder: can the right-most actions be position: sticky? I.e. be pushed by content on the left, but still sticky to the right edge? |
| @@ -520,4 +517,12 @@ | |||
| & > * { | |||
| visibility: visible; | |||
| } | |||
|
|
|||
| // Always enable scrollbar on Mobile devices. | |||
| @media (hover: none) { | |||
I'd have to check, but what happens in cases like this?:
This is a quick and dirty try (what happens in the overlap of the icon is a different question too):
|
|
I'm not sure if this is expected, but with these changes the List View expands if it contains a lot of items inside the navigation block. |
|
I do worry that I led you down a rabbit hole with this one, but thanks again for looking into this. What I mean is for the lock and ellipsis icons to always be locked along the right side of the edge, all of them, even if they cover content below. We could maybe add a white scrim gradient background to elide? |
I knew this one was tricky from the start, I'm not even sure this PR will be the solution for this, but we gotta explore, right? There's also this issue to consider when it comes to this whole situation, so maybe this PR is not the right way to go at all. |
|
I wonder if this situation is a good reason to argue for adding click to edit functionality rather than requiring a separate "edit" icon. I know we introduced it to avoid accidental edits when toggling nodes, but perhaps it's introduced more problems. If I could click on the node's text to edit would that help avoid this Issue? |
I think that's part of what Matias meant about how this block should work (and what I very badly tried to explain in #47506), that also meant we can probably remove the "Customize" button from the settings tab too |
|
What I'm suggesting is going back to "click to edit" rather than having to locate the pencil icon and click it. See comment here #47023 (comment) |
|
I was just about to create an issue for this when I found this pull request. Thanks for the proposed solutions, but I honestly don't think this is the way to go. Aligning some of the icons and leaving the off screen ones to the right feels like an inconsistent solution. The problem for me was that all browsers on Apple devices hide the scrollbar by default, which makes it hard to know you're able to scroll to the right. I didn't see that scrollbar until I was halfway inspecting everything in the Inspector Tools of Chrome. Maybe the way to go might be to just make the scrollbar visual as soon as there's an overflow. What do you think? Another option would be to always have the icons show up on the right, and only put an overflow and max width on the links so you only scroll through them, but that one is not my preferred solution. |
|
Page List no longer shows lock icons in the Navigation List View since #48723 merged, so I think we can close this. |
What?
This PR makes some changes on how the List View is styled to accommodate better when items are deeply nested. It also includes the CSS scrollbar already implemented in #45100 that only appears on hover when a scrollbar is needed.
Closes #46474
Why?
Having the list view show on the right sidebar (which is narrower than the list view) has uncovered some uncomfortable user experience with scrollbars showing very early and icons not being visible or aligned.
How?
This PR implements:
I'm implementing this codepen that @jasmussen worked on for this particular solution and that was discussed in #46474
Testing Instructions
We should test both the regular List View and the List View on the right sidebar for the navigation block inspector. There shouldn't be any visual regressions on the list view.
Testing Instructions for Keyboard
Everything should still be accessible via keyboard on the list view.
Screenshots or screencast
EDIT: This one is blocked for now because it needs further design direction. This approach is heavy-handed and touches on the list view too, and the results are not that much of a visual improvement, in my opinion.