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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jeryj <jeryj@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: MaggieCabrera <onemaggie@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: getdave <get_dave@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +673 B (+0.01%)

Total Size: 6.85 MB

_{compressed-size-action}

I like this! maybe @fcoveram has design input on the icons, but I think it's an improvement on the current experience.

Also cc @jasmussen for design feedback

Good motivation, good instincts. I'm not sure icons or colors in the list view are good here, for one the yellow doesn't meet contrast with the background. For instance we included the word (draft) in menu items for the same reason, that also mimics statuses in posts in the posts list.

The other aspect is, these issues are not unique to the navigation block. They're the same for every block: dead link in a paragraph? Maps block missing API key? Block hidden? Group has custom CSS? Color doesn't meet contrast ratios? Responsive values? So while valuable for the navigation block, it's valuable for the block editor, and in order to not make 10 different implementations of the same it may be worth it to draw a line in the sand and say: we need an editor linting tool. There's a related discussion and tentative design here.

I recognize that's probably not what you want to hear right now, given there's a PR here that works. But I do think we may have reached the point where we start work on the generic linting tool, as opposed to these block specific features. Is that fair?

This was just a prototype anyways - I can use the anchors for now so we have "invalid" and "draft" in the anchor text. I'll close this PR for now.

@jasmussen - What do you think of these prototypes (ignore that the icons are not centered in the badge 😄). The idea is to use the same general design as the anchor spot. This badge would supersede the anchor, so it wouldn't try to show both.

Icon Badge with Tooltip

Inline Badge (truncated if too long)

Thanks for sharing.

I do think there's something there, insofar as it does feel like linting indicators just like you'd see from a JS console, which as noted I think we need. In the thread I linked, I proposed putting linting messages in the Notes tray, but another option mentioned there too, is to add a linting panel or instructions into the document outline tab.

That's not going to be as discoverable as an in-canvas notes tray, but the point is mainly that this information is useful for every single block in core, and plugin blocks, so it's worth thinking about the infrastructure for how we show this information. What do you think?

I think we need a way to represent errors within the List View for Navigation, as in Content Only editing you won't have access to same on canvas information about the links. Without something in the Editable List View for navigation blocks, I worry that people will be especially confused why some links aren't showing up on the frontend of their site. I understand the need for a wider "here's all the issues on the page," but I think we'd still want to raise errors within the List View.

I also worry about waiting for a wider linting project to be available, when we could deliver a way to allow custom badges within the List View now. I could make it more generic though, and instead of allow any badge, allow for flagging error or warning + tooltip message?

Opened an alternative prototype PR for adding the badges to the right side (overriding anchor spot) on the List View: #75695

as in Content Only editing you won't have access to same on canvas information about the links

Can you expand on that? The motivation sounds extremely valid, but I'm wondering if something equally obvious could be done. E.g. if (draft) or (unlinked) don't show up in the locked pattern editing view, then perhaps we could omit those entirely? Or would that be even more confusing?

Alternately, can they just show that text, (draft) and (unlinked) even in the locked pattern editing mode?

E.g. if (draft) or (unlinked) don't show up in the locked pattern editing view, then perhaps we could omit those entirely? Or would that be even more confusing?

The reason they don't show up on the canvas is that the navigation block doesn't check its validity state until the block becomes active. I believe it was due to a performance issue - but maybe it was only a theoretical performance issue.

I think it would be more confusing to emit it, as the lack of information about the items not showing up is the reason for the confusion.

Alternately, can they just show that text, (draft) and (unlinked) even in the locked pattern editing mode?

Possibly! I'm worried about the performance of checking all of them even when the navigation isn't active, but that might be helpful. It would interfere with being able to really see your design accurately though, as the draft/inactive takes up space on the canvas.