Page List block: Editor-only div inside page links causes misalignment in Firefox

[mrleemon]

Description

In the block editor, the Page List block generates markup that includes a <div> tag nested directly inside the <a> tag for each list item. This behavior is exclusive to the editor; the frontend markup doesn't include it.

This nested structure causes a visual hiccup in Firefox, where the list bullets become misaligned with the text labels. Chrome seems to handle this layout quirk more gracefully.

Here is an example markup code:

<ul tabindex="0" draggable="true" class="block-editor-block-list__block wp-block is-selected wp-block-page-list block-editor-block-list__layout" id="block-a71820aa-1a73-4a36-a4f1-c07515d46262" role="document" aria-label="Block: Page List" data-block="a71820aa-1a73-4a36-a4f1-c07515d46262" data-type="core/page-list" data-title="Page List" style="transform-origin: center center 0px; z-index: 1;">
	<li class="wp-block-pages-list__item">
		<a class="wp-block-pages-list__item__link"><div>About Us</div></a>
	</li>
	<li class="wp-block-pages-list__item">
		<a class="wp-block-pages-list__item__link"><div>Projects</div></a>
	</li>
	<li class="wp-block-pages-list__item">
		<a class="wp-block-pages-list__item__link"><div>Services</div></a>
	</li>
	<li class="wp-block-pages-list__item">
		<a class="wp-block-pages-list__item__link"><div>Contact Us</div></a>
	</li>
</ul>

Expected behavior:

The editor markup should mirror the frontend markup as closely as possible, avoiding unnecessary block-level wrappers inside inline anchor tags:

<li><a>Link Text</a></li>

Current behavior (Editor only):

The editor wraps the link text in a <div>:

<li><a><div>Link Text</div></a></li>

Step-by-step reproduction instructions

1. Use a site running WP 6.9.1 with the Twenty Fifteen theme.
2. Open the Block Editor and add a Page List block.
3. Observe the alignment of the bullets in Firefox.
4. Inspect the code in the browser console to see the <li><a><div>Text</div></a></li> structure.

Screenshots, screen recording, code snippet

Environment info

WordPress Version: 6.9.1
Gutenberg plugin: Not active
Theme: Twenty Fifteen
Browser: Firefox

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

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[mrleemon]

This line might be the culprit:

gutenberg/packages/block-library/src/page-list-item/edit.js

Line 95 in 0180c41

<RawHTML>{ safeHTML( title ) }</RawHTML>

The RawHTML component adds a div element inside the a elements.

[mrleemon]

This might be related: #74248

[t-hamano]

Thanks for the report! I was able to reproduce the problem.

Chrome	Firefox

I believe this issue is a problem introduced by #73614. The RawHTML component injects an extra div.

As far as I know, there are two approaches:

1. Use the HtmlRenderer component. This component is used to render HTML retrieved from the server side, or icon SVGs.
2. Use dangerouslySetInnerHTML, but also use the safeHTML method. This approach is used in the Playlist block.

cc @getdave

[Mamaduka]

The button markup above also might need updating. Going with second option seems like a easier approach.

gutenberg/packages/block-library/src/page-list-item/edit.js

Lines 77 to 83 in 0180c41

	<button
	type="button"
	className="wp-block-navigation-item__content wp-block-navigation-submenu__toggle"
	aria-expanded="false"
	>
	<RawHTML>{ safeHTML( label ) }</RawHTML>
	</button>

[prasadkarmalkar]

I am able to reproduce the above issue in firefox and also tried the solution to use dangerouslySetInnerHTML instead of <RawHTML> component

				<a
					className={ clsx( 'wp-block-pages-list__item__link', {
						'wp-block-navigation-item__content': isNavigationChild,
					} ) }
					href={ link }
					dangerouslySetInnerHTML={ {
						__html: safeHTML( title ),
					} }
				/>

After the update on firefox it looks good and aligned. Raised PR for it here: #75890

Before	After