List View and Block List: Update hover, focus, highlight, select borders #29636
Conversation
Copons
added
[Type] Enhancement
|
Size Change: +260 B (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
|
This is awesome to see :) Before getting in to the style of everything (which will certainly need some extra thought and refinement) I noticed one small issue: If you select a block on the canvas then open list view, focus transfers to the list view as expected 👍 If you then close list view using the keyboard shortcut focus seems to vanish. Should it return to the selected block on the canvas? Video: focus.mp4 |
|
Another small issue that I suspect is related – if you select a text-based block from list view, focus transfers to the canvas as expected, but for some reason I do not see the text cursor, and if I start typing characters appear at the beginning of the value: text.mp4 |
Yeah, there are a couple of minor things in the current code, but most importantly, I literally typed random block list classnames until they worked well enough.
Blurgh.
I think the cursor at the beginning is unrelated to the Persistent List View, and it's just how the The missing cursor might be hidden under one of the three outlines of the selected/focused block. |
|
Here is an overview: List-view-FSE.mp4I really like what I see. It gives a nice overview. |
|
@jameskoster I... I really can't see the difference with d772416, but I'm happy it saves a few characters! 😅 Anyway, I think the changes introduced in this PR make things 100% clearer, at least in relation to the Persistent List View. We'd be pushing major visual changes to the block editor itself though, so I'd expect more discussions from designers before committing to an approach. Otherwise, I could limit the outline changes to only the Persistent version of the List View and only the Site Editor's canvas (so, basically, limiting all the changes to the Site Editor). |
|
Exploring ways to eliminate the double-border on the canvas which looks kind of ugly. Perhaps when a block is selected + focussed we only show the focus treatment? I believe this still satisfies the accessibility requirements as the border width and position both change. single-border.mp4 |
|
Having got some feedback from the design team, I think what we're doing in this PR may be overkill :) I think the chief concern for now should be addressing the issue in the following screenshot:
Focus is in list view, but since blocks on the canvas with the The remedy for this seems fairly straight-forward – reserve the blue treatment for focus, and use another color (likely $gray-900) for hover and highlight states. The only drawback I can see to this is that template parts will then receive the same treatment (when a child is selected), as when they are hovered. So we may need to adjust that style as well. I'll push some changes for us to test soon. |
|
Pushed the changes suggested in my last comment. Here's a video demo: focus.mp4I suspect the dotted outline on the template part will be the most controversial change. There are perhaps other options to explore there, light setting an opacity instead of the different border-style. |
|
I haven't fully tested this PR, as I'm in the middle of a separate one, but thank for all the work!
I'm generally skeptical of dotted and dashed lines, as they tend to add noise. However with borders and boundaries and hover states in the site editor still in need of a fair bit of holistic thinking and love, if we are to try a dotted line, this is as good a time as any. If it doesn't work, we can explore a semi-transparent border instead. |
|
@jameskoster your latest changes help a lot with the list/canvas focus confusion! I don't have a strong opinion about the dotted template part border. I've noticed two unrelated issues that become more obvious with the Persistent List View.
|
|
Let me clean up the code a little before merging 🙂 |
|
Just FYI in 3f7b4eb I've:
Later I'll update the PR description and proceed with the merge. :) |
|
I don't think this one is ready. Here's before:
Here's after:
Thank you for all the work, but I would not make any changes to how hover and focus works inside the list view, I'd keep the changes solely to inside the canvas. |
|
Two more very small details to address @Copons (sorry).
|
|
@jameskoster @jasmussen If it's all right with you, I think it's probably easier to move the Block List changes into a different PR, merge that one, then rebase this and keep discussing/playing around with the List View style. I'm totally cool with opening it first thing tomorrow, or @jameskoster could do it if you want to keep full authorship of your changes. 🙂 |
|
@Copons I think we can continue, this is close :D
I'll revert this and we can potentially revisit in the future.
We spoke about this on Slack and found some consensus based on the fact that the white halo effect is used on a few other situations like selected + focussed Icon Buttons:
I think this is particularly useful in this list view. In heavily nested blocks, when you scroll so that the parent is hidden (and indentation consequently becomes less intuitive), it helps to understand where the container ends.
We could perhaps restrict this to list view only? I believe this is the final sticking point. |
I think so too. I think the hover change is the one that needs further thought, as the additional borders feel like they detract from focus:
Changing that back to a gray background hover addresses the biggest point. The rest we can look at. |
Hovered and highlighted blocks on the canvas now received a 1px dark grey outline rather than a 1.5px blue one. Blue is reserved for focus. When a child is selected, the associated template part now receives a dotted border to differentiate from its hover and highlighted states.
Also adjusts the background color on children of the selected parent
Copons
force-pushed
the
try/hover-focus-select
branch
from
75e251f
to
3b8ee4a
Compare
Copons
removed
Needs Accessibility Feedback
There was a problem hiding this comment.
Testing
Requirements
- In canvas, the Template Part block's outline becomes dotted when one of its children is selected.
- In the List View, focused items gain a white halo inside their blue outline.
- In canvas, the primary selection (selected, hovered, highlighted) outline changed to gray
@Copons I had a question about the canvas primary selection selected outline. I might be missing something, but could you elaborate on how to arrive in the selected state? I'm clicking on canvas blocks, and the outlines still appear to be blue?
Browsers
- Firefox
- Edge
- Safari
- Chrome
-
IE11
Note:
- Didn't test IE11 (see here). It looks like a fix is currently in the works, so hopefully (or maybe not so hopefully? 😅) we can test it again soon.
- There seems to be a noticeable delay when editing canvas text content with the persistent list view open. (Open the list view, click on a paragraph block, and start typing). Wondering if anyone else can reproduce this as well.
- I saw some general navigation block select state weirdness in Safari, but I could replicate it on the master branch as well. It appears unrelated to the changes made here. I'll look for an existing issue and file one if it doesn't already exist first thing tomorrow morning.
Selecting and unselecting nav links unexpectedly modifies link opacity
@jeyip The blue outline is because the block is
Note that not all blocks work in the same way. Sometimes the blue outline show up when you start editing their text content. Sometimes they never have a blue outline somehow (the Navigation block, for example, has the blue outline, but the Navigation Link blocks inside it don't). I'm not sure about the root of these inconsistencies, or if there's an intentional rule behind them. cc @jameskoster in case there's more to this. 🙂 |
Seing this as well. 🤔
Yeah apparently there are several issues related to blocks states in Safari, as if a block state "sticks around" after the state changed. |
|
Oh I see! There's a difference between select and focus, and the focus border styles will override the select border styles. Gotcha 👍 @jameskoster Out of curiosity, has there been a discussion about the difference between select and focus states in Gutenberg outlined anywhere? Is it similar to what this external article describes?
Thanks @jasmussen 🙏
Is it worthwhile to make an issue for the background for children, or will we revisit it naturally in the course of developing the full site editor? |
|
@jeyip good question! Not that I am aware of. The descriptions you shared seem quite closely aligned with what we have in the block editor though. Clicking an object (an on-canvas block in this case) will select and focus it. A selected and focussed block can be directly manipulated, IE when you click a paragraph block you can begin typing immediately. The focus state can move independently of the select state to a variety of different elements such as the block toolbar, the list view, or the inspector. In all of these cases the on-canvas block remains selected (and we need to indicate this visually) so that users are able to comprehend that it is the target of operations contained within the aforementioned elements – so things like grouping, transforms, text formatting, layout adjustments, and so on. I know y'all know this. But it can be easy to forget if you aren't performing these actions keyboard-only on a day to day basis 😅 |
There was a problem hiding this comment.
This is a very nice improvement overall! 🚀
I noticed two issues while testing, but both of them seem to be edge cases that can be addressed later in my opinion.
Mar-16-2021.20-04-51.mp4
-
After opening the navigator with keyboard shortcuts and pressing tab a few times the footer TP is selected, but its contents are not rendered properly and gray background is shown instead.
-
After selecting the header for example and using down arrow to focus other top level groups, the focused item is not scrolled into view and goes outside of the viewable area.
@vindl The
That's because list scroll and canvas scroll are not "in sync". It's something that bugs me as well, to be honest, and I've raised it in the past. |
I tested the arrow navigation and tried this after - with the current state/styles it appears as though it's working with tab too, even though under the hood it's focusing things in the canvas, so I got confused by it. :)
Thanks for clarifying, makes sense now. |
Description
Fixes #29467
The initial implementation of the Persistent List View had a pretty big usability issue caused by the fact that the component wasn't designed to stick around after an item was selected.
The persistence required a visual clue to indicate that, on item selection, the focus shifted from the list to the block.
This PR subtly updates the outlines of both the List View items, and the blocks in the canvas, to make their relationship clearer.
2px --wp-admin-theme-color(typically blue) to1px $gray-900.dottedwhen one of its children is selected.This PR also highlight the entire children branch of a selected item.
This required the introduction of some additional logic in the
BlockNavigationcomponent.To avoid regressions and incompatibilities, like the other Persistent List View-only features, this too is gated behind the
__experimentalPersistentListViewFeaturesflag.How has this been tested?
Screenshots
Grey outline of a hovered block:
Dotted outline of a template part with a child selected:
List View item's focus halo:
List View's selected branch:
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: