-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Full Site Editing: Block selection #27239
Comments
Thanks for sharing this exploration!
In the context of the post/page editor, the outlines really got in the way of writing. But you're right that they may make more sense here since the site editor is distinctly more of a "building" environment. There are borders available in the post editor today if you switch to "Select" mode. Maybe this is just that, but on by default in the Site editor? cc @jasmussen since I know you have a lot of knowledge and thoughts on this topic. |
... and ...
Good thoughts, both. The instinct to resurface some block boundary indications, especially in context of the site editor, is a good one. But I don't think we should mess with the tool defaults, the two editors are close enough in appearance that the change will likely just confuse. But thank you for bringing it up, because there's an important aspect about focus and "block selected" to keep in mind. Specifically, the blue thicker border means focus, and it often also (but not always) means selected, implying you can press the Delete key to remove the block. That overlap is the cause of the the intentional overlap with the select tool where a block with a blue border is both selected, and has focus. This ticket seems focused on the hover effect, and is limited to the site editor which is in beta. That seems fine to me as a way to test this out, see how/if it helps. But testing out the prototype opens a couple of questions: Why is the border orange here? I see there's an orange "symbol" icon in the toolbar, and being a Figma fan myself, I sense that it has to do with template parts. But the problem with adding color here is that those colors are neither theme background aware, nor wp admin theme aware. I would avoid adding any new colors other than the spot color (blue by default). When I select the group, there's a blue 2px border around the box. When I select a group in the block editor, there is a 1.5px focus rectangle around the block, with a 2px border radius, and this focus rectangle disappears when focus lands elsehwere. I assume the difference here is primarily due to this being a prototype, but I wanted to explicitly note it. Revisiting borders is fine, but we should take very careful and minimal steps, one at a time. Therefore, just to set out some boundaries for these explorations:
In that vein, a 1px border for hover seems a good thing to experiment with. I've tinkered myself with showing a 1px border around the immediate parent block, to indicate its boundaries, and to look for ways to improve selecting the parent. |
On the subject of color, your sense is correct, it is used here to highlight template parts. I've used orange in the prototype (red in the PR) just as an example, the final choice should of course be color-scheme-aware, etc. Exploring that here is perhaps taking the issue a step too far, but I wanted to get an idea of what that felt like in something beyond the static prototype. There is a separate issue here to discuss further. |
For the sake of shipping this as a cool improvement, probably best to keep the color stuff as a separate exploration. (Which by the way I agree should happen, it would be helpful to show different colors in a multi user editing environment, for example.) |
Anyone who has spent some time playing with the Site Editor – and Template Parts in particular – will likely empathise with the struggles one can face when interacting with these container blocks and their children.
I frequently feel a distinct lack of confidence in any attempt I make to select a template part via click. More often than not I inadvertently select a child block, and from there I have to decide whether to:
It probably shouldn't be this difficult to simply select a container block like a template part of a group.
Since the template editing experience in the Site Editor will largely revolve around interactions with container blocks like Template Parts, Queries, and Groups, I'm wondering if that environment might be a good space to explore solutions to this problem.
Doing so should also address the final high priority item in part 2 of the Site Editing Infrastructure and UI milestone.
A prototype
To tackle this head-on I put a rough prototype together which addresses the aforementioned issues via a combination of UI adjustments.
Take it for a spin yourself.
The prototype includes regular blocks, two separate template parts, and a group block as examples.
I appreciate we've had borders outline blocks similar to this in the past, and moved away from that pattern. But in the context of editing templates with lots of nested elements I find the indications to be very helpful and intuitive. I'm sure there is a lot of refinement still to do, particular around the visuals (border widths, color treatments, etc), but this feels like a decent starting point to me.
cc @jasmussen @shaunandrews @kjellr
The text was updated successfully, but these errors were encountered: