Allow option for Post title to specify tag, or none for no extra markup

[mkaz]

I would like to use the query block to create something close to the following markup:

<ul>
    <li><a href="{LINK}">{POST TITLE}</a></li>
    <li> ... </li>
</ul>

The issue is not necessarily the query block but the Post Title block renders as a header tag based on the level, or a p tag if the level=0. I would prefer just the title and not the additional markup.

A solution could be to specify the tagname for the Post Title block, passing a level and tagname=h can be the default behavior and it works the same, but an empty tagname could just return the title fragment with no markup.

[ntsekouras]

Hey 👋 - so your use case would be to have a Query block with just Post Title or is it just a quick example written here?

Because if that's the case it could be something related to Navigation block and Page List, no?

[mkaz]

My goal is to create an index page with the above markup based on categories:

The result would be something like this:

I added additional CSS to style the H5 from the Post Title block to look like that, but ideally if it was just plain text inside a link, it wouldn't need any additional CSS.

[skorasaurus]

Running into this issue right now:

I'm making a page right now where, semantically, the most appropriate tag to be used for the post title is strictly an <li> (in a list of recent posts for example, where I am only displaying and hyperlinking the post title as @mkaz does in his example..

I'm totally open to hear other opportunities to do this besides just offering an extra option to do to select the wrapping tag in the sidebar; maybe filters (possibly like #14009 )?

Another example of where this be useful is when you'd want to display your posts as an inline list, as requested at #25505

(I ended up making a custom block for my use case; available at https://gitlab.com/cpl/post-title-list-block

[carolinan]

I don't think having no tag would be possible, where would the block's attributes be added?
I think it makes sense to allow it to use a P tag just like the site title.

[alexstine]

In the above PR, using the p tag I think is a tricky situation.

• This fixes the problem mentioned in this issue, 100%.
• It creates an issue where post titles could now be rendered as p elements. This would break accessibility if a user changed this because of logical heading structure. Site title, then post title or post title, then sub-headings for the post.

I do not trust users enough. Here are my ideas.

• Add this feature to another block that does not currently rely on headings.
• Create a new block that makes it clear to users how it should be used.
• Create a way to warn users when converting to p element in certain contexts could be harmful to accessibility. This would be my personal favorite, but probably decent amount of tech work.

If we introduce this, I almost guarantee we will see long-term broken accessibility just from the simple mistake of selecting a p element. Even if the user made a mistake and selected the heading 5, at least it still follows some heading order. A p element would be invisible as a title identifier.

Just trying to think about the time down the road from now. I would rather get this perfect now then to revisit later and have an even bigger challenge to solve.

[paaljoachim]

This PR by @carolinan
Add a tag selection component to replace HeadinglevelDropdown
#46003
Can use some feedback from anyone who has commented in this issue.

[t-hamano]

I think this problem could be solved by simply using a Latest Posts block. The post title would be displayed as a list item, with a link. You can filter by category and change the number of items as well.

The only thing missing might be that the post type cannot be changed.

[mrwweb]

Here's another request for this feature from @cdils and I'd like to see it too.

I completely understand the accessibility concerns around allowing this and I tend to fall in the camp of highly valuing accessibility defaults.

Until WordPress 6.3 it was possible to specify the level attribute of the Post Title block to be 0 which output a paragraph (see #53594). I'm curious for those who want the ability to use a paragraph wrapper here, would being able to edit the attribute or make a Block Pattern or Block Variation with this output be sufficient? @alexstine Would you still have the same concerns, or would that put the feature into a place where it can only be used by "people who know what they're doing" (air quotes around that last part).

[alexstine]

I did not know there was a setting that would allow post titles to become paragraphs, that's likely going to haunt us later. If we were to add this, it should be thrown under the Advanced section of the block sidebar. Isn't the title field considered a block now so it has the Block tab?

[t-hamano]

Up until WordPress 6.2, the paragraph (i.e. level zero) was supported as attributes internally, even though you couldn't select them in the block toolbar dropdown, so if you update the value of the attribute to zero via the code editor, was being rendered as a p tag.

WordPress 6.3 and the Gutenberg trunk no longer consider level zero, so it outputs an incorrect tag of h0.

My understanding is that there are three choices:

• Do not allow the p tag. In other words, migrate blocks with level zero set to h2 and so on.
• As in WordPress 6.2 and earlier, support the p tag internally.
• Provide a UI to convert to the p tag in one of the Advanced sections or other places.

[alexstine]

The 4th option.

Convert <h0> to <p> and add a warning that this may be an accessibility violation. It does have practical use-case but we should ensure users understand the risk.

[t-hamano]

I'm thinking that if there is an accessibility issue, it might be better to just not allow the p tag itself.

I would love to know if anyone has a specific use case where the post title must appear as a p tag. I believe that if we only address the issues raised by this issue, as I have commented here, we can solve the problem by substituting the Latest Posts block.

[alexstine]

Since there is a work-around with the other block, it is likely okay to remove the "0" option.

[mrwweb]

I would love to know if anyone has a specific use case where the post title must appear as a p tag.

@t-hamano My need for it was on a home page template where the Site Name was the h1 (in the page template) but we used the Post Title as a tagline of sorts. In other situations, we want the Post Title to be an h1 in the same position as styles, so it made sense to use the Post Title block in both cases, style it the same way, but change the element.

I know that I learned about this from other chatter with people and was definitely not the only person using the level: 0 workaround.

[cdils]

we can solve the problem by substituting the Latest Posts block.

Since there is a work-around with the other block, it is likely okay to remove the "0" option.

@t-hamano @alexstine The Latest Post block does not accommodate custom post types, so any use case involving CPTs would rely on the Query Loop block.

I would love to know if anyone has a specific use case where the post title must appear as a p tag.

Using a heading for the post title is not always semantically correct. It depends on the usage context, but this has come up for me in multiple scenarios. For instance, simply creating something akin to the Latest Posts block but with a CPT.

My workaround has been registering a block variation using level: 0

    wp.blocks.registerBlockVariation(
        'core/post-title',
        {
            name: 'post-title-p',
            title: 'Post Title (<p>)',
            attributes: {
                level: 0,
                isLink: true
            }
        }
    );

[alexstine]

Still interested in what the use-case looks like. I am just having a hard time understanding where and when you would not want the post title to be a heading X. Maybe in some type of list output presentation? Related posts type of thing?

[cdils]

Related posts type of thing?

@alexstine That's a great example.

[alexstine]

Okay, so maybe this moves forward by defaulting to level 1 for heading 1 and users can select level 0 if they choose? I still think adding a warning would be a good step for this just to alert users that it might not be a good idea but possibly okay for their use-case. My main concern, links with just <p> tags for post titles offers no real HTML structure that screen readers can read. If it was presented in the proper list format, <ul> <li>, it would be a little different. Visual lists do not count. There is a big difference between visual presentation and presentation for non-sighted users. Maybe level 0 should become this instead?

<ul>
<li><a href="/example">Example Post 1</a></li>
<li><a href="/example">Example Post 2</a></li>
</ul>

Thoughts?

[skorasaurus]

Still interested in what the use-case looks like. I am just having a hard time understanding where and when you would not want the post title to be a heading X. Maybe in some type of list output presentation?
@alexstine

Yep; I made a plugin that for a few sites that I admin that contains a list (using the (ul elment) of most recently published posts' titles. A similar issue would be if someone would want the most recently published posts inline also related types of posts as requested at #25505

[alexstine]

@skorasaurus If that refers to display: inline;, that is a common accessibility annoyance when used with links. About the only time I recommend this type of rule for links is with breadcrumbs so they follow left to right. It would not be ideal to use this with post links. The reason being, Windows screen reader users cannot reliably use down arrow to access each link one by one. It becomes a horizontal navigation challenge and that is one I like to not implement for links that users will likely need to select. You probably won't find any accessibility violation out there as far as rules go, but this is a good example of how the rules don't always catch up with modern development.

You probably would not notice this issue at all with Voiceover on Mac due to how flat the navigation method is.

[mrwweb]

@alexstine I haven't thought a ton about this yet, but I wonder whether a warning like that should either match the heading warnings in the Document outline or intentionally exceed them. Since this is a heading-related concern, it seems like it would be good to consider it in a full context. It also bring up the fact that the document heading outline doesn't actually include all the headings #5037.

[alexstine]

Full context would be really nice. Flagging errors for the whole page/post.

[cdils]

I'm circling back around as I'd still like an option to display the Post Title Block as a <p> instead of a heading. I'd even settle for a <span> or no wrapper at all. :)

In a current use case, I'd like to display some latest posts, with each post including a featured image, the post categories, and the post title.

The Latest Posts block would be perfect as it outputs the post title in a list (no paragraph or heading needed). The limitation of this block is its inability to display post categories.

Moving on to the Query Loop block as an alternative solution to get my desired display, this only lets me display the post title as a heading, which is semantically unnecessary.

This is the output:

<div class="wp-block-query is-layout-flow wp-block-query-is-layout-flow">
  <ul class="columns-3 wp-block-post-template is-layout-grid wp-container-core-post-template-layout-1 wp-block-post-template-is-layout-grid">
    <li class="wp-block-post">
      <figure class="wp-block-post-featured-image"></figure>
      <div class="taxonomy-category wp-block-post-terms">
        <a href="#" rel="tag">Post Category</a>
      </div>
      <h2 class="wp-block-post-title">This post title isn't a heading</h2>
    </li>
    <li class="wp-block-post">
      <figure class="wp-block-post-featured-image"></figure>
      <div class="taxonomy-category wp-block-post-terms">
        <a href="#" rel="tag">Another Post Category</a>
      </div>
      <h2 class="wp-block-post-title">This post title would happily take any non-heading tag</h2>
    </li>    
    <li class="wp-block-post">
      <figure class="wp-block-post-featured-image"></figure>
      <div class="taxonomy-category wp-block-post-terms">
        <a href="#" rel="tag">Post Category</a>
      </div>
      <h2 class="wp-block-post-title">Post title</h2>
    </li> 
  </ul>
</div>

Possible solutions could include:

• Extend the Latest Posts block to support the display of post categories
• Extend the Post Title block to support <p>

For the latter option, I'd support a dev-only option so that use of <p> instead of a heading tag is only done with specific intention.

[mrwweb]

It's very clear that this is a need, and I wonder if this issue should really get folded / referenced in two others:

• Consolidating the Query Loop block, Latest Posts block and Post Lists block  #32332
• Block Bindings API iteration for 6.5 #54536 and Displaying Dynamic text #58626

#32332 makes explicit with @cdils is calling out. The Latest Posts block strangely offers certain features that a lot of us want from the Query Block and the blocks that can go in it like the Post Title block, and yet it feels very "Block Editor 1.0". The Query Block feels like the future, and so it would make sense to deprecate Latest Posts for Query Loop, but only once there is feature parity.

#54536 and #58626 talk about ways to get dynamic data in blocks. If we could insert some kind of {post_title} token-like thing into a paragraph block, that would be a great way to resolve this issue (and then maybe we could rename "Post Title" to "Post Title Heading" for clarity.

If these other tickets have real forward momentum, then I can see it making sense to not add this to the Post Title block. However, the merging of Latest Posts and Query Loop doesn't seem to have much momentum, so that may be an argument to do this.