Navigation: Next steps for supporting non-links in Navigation block and screen

[noisysocks]

A complementary feature to Full Site Editing is that we want to allow users to add blocks to their navigation menus and widget areas even if they are not using a block-based theme. Exploration of how to support non-link blocks in a navigation menu began in #22656 and was further discussed in #22096 and #23915.

In this issue, I'll attempt to provide a complete overview of this feature and go over the next steps for building it. This supersedes the above linked issues.

Overview

Navigation block

The Navigation block allows non-link blocks to be added alongside Link blocks. To begin, we can support useful blocks like Search, Social Icons, Image, Separator and Spacer. In the medium term, we can look at supporting nearly all non-layout blocks as well as blocks for building complex mega menus such as Pages (#23689) and Submenu (#23745 (comment)).

It is a "tailored group" block (#23207 (comment)). Unlike Group, it allows the user to customise whether to show these blocks horizontally, vertically, spaced evenly, etc. Also, unlike Group, it uses (<nav> and <ul>) markup to denote the special semantic meaning of its content.

Navigation is a static block. Features such as background colour, foreground colour, and whether or not to display submenu indicators should be implemented using cascading CSS or block context. The Link block should be mostly static but with dynamic PHP code that adds the current-menu-item class when the user is currently on the page represented by that link.

Children of the Navigation block are automatically wrapped in a <li> element using the API described in #23915 (comment). In the medium term, a more flexible API (#23915 (comment)) should be used. This more flexible API would allow us to support blocks like Pages and Submenu inside Navigation while still retaining semantic list markup.

Navigation screen

The Navigation screen displays a single Navigation block. Each item in the Navigation is saved to the database as a menu item CPT. By default, only Link blocks may be added to the Navigation block inside the Navigation screen. This ensures that wp_nav_menu() works as it always has done and that existing themes do not need to be changed. It also means that plugins which use menu items for their functionality will continue to work.

Themes may opt in to allowing more blocks to be inserted the Navigation screen by declaring add_theme_support( 'block-navigation' ).

Non-link blocks that the user adds to the Navigation screen are then saved to the database as a menu item with type set to 'html'. Alternatively, the type can be 'blocks' which mirrors how block widgets are stored per #24267.

Opting in causes wp_nav_menu() to output a complete Navigation block using render_block() instead of Nav_Menu_Walker. This significantly changes the outputted markup. By declaring add_theme_support( 'block-navigation' ), a theme author is indicating that they have tested their theme with the Navigation block markup. Customisations such as mega menus will work as they do when using the Navigation block in a block-based theme. Note that, in a typical case, opting in allows a theme author to delete CSS because wp-block-library already contains Navigation block styling.

If a user switches from a theme that supports block navigation to one that doesn't, non-link blocks will no longer render on the frontend. This prevents the site's navigation from appearing visually broken as it is not common that a theme's existing styling will correctly style block markup. Existing non-link blocks in the Navigation screen will continue to display but are marked as invalid so that the user is able to replace them with Link blocks.

If a user disables the block-based Navigation screen using a plugin, non-link blocks will, no longer render on the frontend. Again, this prevents a site's navigation from appearing visually broken. Existing non-link blocks in the Navigation screen will display in nav-menus.php as a HTML menu item so that the user is able to replace them with a menu item.

Next steps

I'll be working through the list below in the coming weeks. Ping me if you'd like to help out with any of the items!

• Make Navigation wrap its children with <li> using the API proposed in Navigation: Non-link blocks should be wrapped in a <li> #23915 (comment). InnerBlocks: introduce prop to specify render callback for each block. #24232
• Make Navigation block static. Navigation: Make Navigation a static block #24371
• Make Link block mostly static. Navigation: Make Navigation a static block #24371
• Update styling of Navigation block so that it is a flexbox container that supports non-link children. Navigation: Try adding Links block #24644 Navigation: Make Search block look nice when added to a Navigation #24643
• Make wp_nav_menu() render entire Navigation block using render_block() when theme opts in to block navigation. This gist demonstrates the approach. Navigation screen: Add opt-in Navigation block rendering #24503
• Make Navigation screen hide non-link blocks when theme has not opted in to block navigation. Navigation screen: Add opt-in Navigation block rendering #24503
• Hide non-link blocks from frontend when theme has not opted in to block navigation. Navigation screen: Add opt-in Navigation block rendering #24503
• Mark non-link blocks in the Navigations screen as invalid when theme has not opted in to block navigation. Navigation: Improve how invalid non-link blocks appear in Navigation screen #24640
• Make HTML menu items display the HTML when displayed in nav-menus.php. Navigation screen: Add opt-in Navigation block rendering #24503

[afercia]

Having read this issue and previous discussions on #22656, #22096, and #23915 I still fail to understand why a navigation menu should contain extraneous content like a Search form and potentially any other type of non-link blocks.

The Navigation block allows non-link blocks to be added alongside Link blocks. To begin, we can support useful blocks like Search, Social Icons, Image, Separator and Spacer. In the medium term, we can look at supporting nearly all non-layout blocks as well as blocks for building complex mega menus

I can understand additional text (e.g. a paragraph) meant to be used as description of a menu item. That would need to be correctly associated with the link but I guess it can work.

Other extraneous elements are arguably appropriate for a navigation menu.

HTML 5.2 specification:
https://www.w3.org/TR/html52/sections.html#the-nav-element

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

Please also read the notes there and see the examples. If an unordered list is used for the menu items, the list is supposed to exclusively contain links. A search form would break the expected semantics for all software that read the page (Google included) and break the users expectation.

An "All Pages" block would make sense as it's a set of links, as long as the HTML is valid and semantic. Other blocks seem completely inappropriate for a navigation menu and I'd tend to think the list of allowed blocks should be very limited.

Will propose the accessibility team to discuss this issue in the next meeting.

Other useful references:

Landmarks usage:
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/

Native HTML sectioning elements that define ARIA landmarks by default:
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html

Search landmark usage:
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/search.html

[noisysocks]

Hey @afercia! I want to get this right, so thanks for the feedback and for the resources. Please do bring this up at the next accessibility meeting as I'd love to get the team's perspective on best practices here. In particular, what markup would you expect to have for a navigation menu like this?

[talldan]

There was a pretty lengthy discussion about this issue on slack (https://wordpress.slack.com/archives/C02RQBWTW/p1596613710043800).

In particular the idea of wrapping all inner blocks in li elements.

I have some concerns here because it's not really the idiomatic way to build navigation based on what's out there on the web. Most sites seem to use a ul just to represent a list of links, and put other content either at the root of the nav or outside of a nav element.

Though I do realise at the same time there's a great deal of inconsistency.

You've got sites that tend to put all kinds of elements inside nav:

• https://www.w3.org/WAI/ (this seems closest to what you're proposing @noisysocks, as they put everything, including a search form inside of list items within a nav).
• https://www.theguardian.com/

And sites that just use navigation for links and put other elements outside the nav:

• https://www.bbc.com/
• https://developer.mozilla.org/

Some that don't even use an ul:

• https://github.com/

Beyond that W3 site I haven't been able to find many others that wrap everything in li.

[enriquesanchez]

It's worth noting that a navigation block does not necessarily need to translate 1:1 to the HTML nav element. Navigation links can just be a part of the whole.

That said, the nav element does allow for flow content, according to the WHATWG HTML spec. This can be seen in the W3C's example, where a search form is nested inside a list in a nav element.

<nav class="metanav" aria-label="Meta &amp; Search" lang="en">
    <ul>
      <li><a href="/WAI/about/participating/">Get Involved</a></li>
      <li><a href="/WAI/about/">About W3C WAI</a></li>
      <li>
        <form action="/WAI/search/" role="search">
          <div>
            <label for="header-search">
              <span class="visuallyhidden">Search:</span>
              <input id="header-search" type="search" name="q" placeholder="Search" aria-label="Search">
            </label>
            <button class="button button-icon button-nobg button-noborder"><span><svg focusable="false" aria-label="Submit Search" class="icon-search "><use xlink:href="/WAI/assets/images/icons.svg#icon-search"></use></svg></span></button>
          </div>
        </form>
      </li>
    </ul>
</nav>