The position of the Navigation block item appender obstructs the view

[javierarce]

Description

The appender inside the Navigation block sits on top of the last inserted element, making it difficult, for example, to read the text of a link.

This problem also happens with vertical menus:

The solution would be to add some spacing to the left (or top) side of the appender:

Step-by-step reproduction instructions

1. Create a navigation menu that is right-aligned
2. Add two or three links inside

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 6.0, Gutenberg 13.5.1
Tested in Chrome, Firefox, and Safari for mac

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[talldan]

I wasn't involved in the change, but I think it was done this way so that when the navigation block is selected it doesn't become wider and potentially cause a layout shift in the site editor.

[javierarce]

That makes sense, but we should try to solve the problem. Links with long texts can be edited, but links with short ones (like "Help" for example, or text written using ideograms like in Chinese or Japanese) are quite difficult to select.

Maybe we could try something like this for example:

[getdave]

Related #40382

[javierarce]

Circling back to this issue, I discovered that removing the position: absolute from the .block-editor-block-list__block .block-list-appender solved the problem, and the appender position was more consistent with the default case (where it appears right after the last item)

Here's a video that shows the default behavior and the result of removing the absolute position:

Screen.Recording.2022-08-23.at.11.47.03.mov

I haven't done an exhaustive testing, so maybe I'm missing other problems that this fix could cause, but perhaps there's something here we could explore.

[javierarce]

I haven't done an exhaustive testing, so maybe I'm missing other problems that this fix could cause, but perhaps there's something here we could explore.

Oh, well, I imagine this could be one of the reasons (pointed out by @talldan above)

Screen.Recording.2022-08-23.at.11.58.43.mov

[getdave]

I think a PR to test would be great if you have time/inclination 🙇‍♂️

[javierarce]

I think a PR to test would be great if you have time/inclination 🙇‍♂️

Of course, here is the PR

[mrfoxtalbot]

Thank you, @javierarce! I am seeing that your PR #43530 is blocked. Features for 6.1 are frozen at this point, but I wanted to know what is blocking this and ask you if this is on your roadmap for the next release. Thank you!

[annezazu]

Wanted to provide additional and recent context around how this is a pain point for folks with a great example from @kathrynwp. To set the stage, she tried to use the / inserter to add a new menu item, resulting in a / listed as the menu text:

I tried to add a menu item for Home, but wasn’t sure how to do it. I typed / in the link area, but then ended up with / in the menu text itself.

From there, this bug obstructed the view in order to edit it further and fix it. Eventually, she did the following:

What I had to actually do as a workaround is change the order of menu items to move / to the left, so it’s no longer covered by the block inserter. I was then able to edit the text.

When thinking about user expectations, trying to use the / inserter alone is an interesting call out (I wonder how often that happens). Separately though, it underscores how painful this current bug is to do very basic things, name and rename menu items, resulting in a level of fragility in the experience.

Currently, this is listed as normal priority in the tracking issue ahead of 6.2: #38275 but I'd be keen to see this iterated upon, especially since Javier did the work to find a possible solution cc @getdave for consideration.

[getdave]

I agree. This is another candidate for the Quick wins category on the Tracking Issue which I suggested elsewhere.

but I'd be keen to see this iterated upon, especially since Javier did the work to find a possible solution cc @getdave for consideration.

Also agree. See #43530 (comment) as I also noticed this hadn't been reviewed. Apologies to @javierarce for that oversight. It's been...busy 😄. We will get to it.

[getdave]

This one was fixed in #42010