New block: Post navigation #57664
New block: Post navigation #57664
Conversation
carolinan
added
New Block
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ lib/blocks.php |
|
Size Change: +403 B (+0.02%) Total Size: 1.83 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in bc66ed4. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/9867942148
|
carolinan
requested review from
spacedmonkey,
ajitbohra,
ryanwelcher,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Hey @carolinan 👋 Would it be possible to have this be a pattern that consists of a row block with the tag name set to I'm not sure a custom block is the right answer for the valid issue you point out :) |
|
The reason for that is in the linked issue. |
|
I would still prefer for this to be a block, but how does one even add a new core pattern? Are they added by issues and PR's to the pattern directory repository? |
carolinan
added
the
[Focus] Accessibility (a11y)
There are a mixture of ways at the moment. There are some in the They're registered here: The majority are registered from the pattern directory, those that are 'featured' or have the 'core' keyword: These patterns are only loaded when I'm not sure what the preference is for adding new bundled patterns. This one seems more like a useful utility pattern rather than the more stylistic patterns in the directory, so maybe the first way? edit: also just to mentioned that if you wanted to experiment with adding the pattern in the gutenberg plugin to start with, it should be possible to add code similar to how those core patterns are loaded in a |
|
Adding the nav element to the group does not remove the need for this block. |
That would help but still:
I would argue this is not in line with what WordPress always aimed to to. Historically, WordPress always aimed to output valid, semantic, and accessible HTML on the front end. The classic template functions for things like posts navigation etc. take care to output a |
|
Another suggestion is to create variations of the Group block. Codewp.blocks.registerBlockVariation( 'core/group', {
name: 'group-navigation',
title: 'Post navigation',
category: 'theme',
icon: () => {
return wp.element.createElement(
wp.primitives.SVG,
{ xmlns: 'http://www.w3.org/2000/svg', viewBox: '0 0 24 24' },
wp.element.createElement( wp.primitives.Path, {
d: 'M21 17.5L21 6L13 6L13 17.5L21 17.5ZM10 14.5L3 14.5L3 16L10 16L10 14.5ZM3 11L10 11L10 12.5L3 12.5L3 11ZM10 7.5L3 7.5L3 9L10 9L10 7.5Z',
} )
);
},
attributes: {
metadata: {
name: 'Post navigation',
},
tagName: 'nav',
ariaLabel: 'Posts',
layout: {
type: 'flex',
justifyContent: 'space-between',
},
},
allowedBlocks: [ 'core/post-navigation-link' ],
innerBlocks: [
[ 'core/post-navigation-link', { type: 'previous' } ],
[ 'core/post-navigation-link' ],
],
} );
Additionally, provides a UI for editing the ariaLabel attribute (See this comment). The reason I'm cautious about adding new blocks is that once a block is shipped into core, we need to continue maintaining it in a backwards-compatible manner for as long as the block is available: we can deprecate it, but we can't remove the code. So I'm wondering if there's a way to solve this without adding a new block. |
|
@t-hamano Great thinking. I like the variation approach. The other thing I wanted to mention, is that we can potentially add some smart detection on how people are using the different tag names and if we can detect mis-use show nudges like we do for color contrast. |
|
I am very surprised by the reluctance to solve this the same way the existing paginations have been solved, I am sensing that this has become about the argument rather than the solution and I don't appreciate it. |
|
This block does absolutely not create a larger maintenance burden than any of the other proposed blocks. |
|
And as far as I know, you can not style those kind of variations site wide. Just like you can't style stack and row separately from the group. |
|
Styling block variations would be good to have, but there is no ETA on resolving it: I don't think that solving known accessibility issues should be blocked by possible future changes, unless that future change is on the immediate roadmap and there is progress. |
|
On the other hand, I wish we had planned for having a single pagination block from the beginning, where the query pagination, comment pagination, next/previous could have been variations or where the pagination type would have been detected automatically depending on the context. |
To play devil's advocate here, is the ability to style the proposed variation via Global Styles a true blocker for that approach? |
|
Yes because it is a subpar experience compared to editing and styling the other pagination blocks, and creates another inconsistency between them. |
|
There was a comment that this block is only used in templates. Without statistics, we can't know if that is accurate, in the support requests I have received, the user have tried to add it to the post content in the block editor when using Twenty Twenty-Three because that theme does not include this navigation by default. |
|
@WordPress/gutenberg-core How can we move this forward? I see other new blocks getting merged after two weeks without discussion, I still don't think that the arguments against this block are valid. |
|
There is a lot of drift in terms of container block style support. For example I think it’s super weird that you can set background images on some, but not others (like the Pagination block, incidentally). This forces theme devs to utilise inefficient workarounds such as wrapping blocks like Pagination in a Group just to get access to certain style options. The knock-on effect is a more convoluted block tree that is harder for end users to navigate. The more 'containers' are added, the worse these inconsistencies seem to get. For that reason I prefer the variation suggestion. It ensures this ‘block’ always matches the Group block in terms of style options, and as already mentioned; reduces the maintenance burden. I should say that this is all assuming there aren't any styling options that this block needs that are not already present on Group. |
|
The problem is still that
|
|
I understand that the background image was a single example, but I still feel strongly that not having a background image option is preferable over not being able to add default styles at all. |
|
If you wanted to make a particular style/layout reusable would it not be more appropriate in this case to create a template part or synced pattern? It doesn't seem like a block that will be used very often outside of specific templates? |
|
I have already responded to that multiple times in this discussion, but to add to that:
|
Since this is a block targeted more towards theme devs that seems like a reasonable assumption?
Is this a block we expect people to use inside the Content block? It feels more like a template block to me. These are just my opinions. I don't want to block the effort, but there doesn't seem to be clear consensus either way on this one. |
|
I do understand all the different reasoning on this issue but, to me, the most important point is addressing the underlying usability issue. As mentioned in my previous comment, the current flow to add a fully working post navigation is unnecessarily complex, time consuming, and unintuitive. I would argue that what users need in most of the cases, whether they are theme authors, devs, or content authors, is to be able to just add a fully working Post navigation with just one click. The block should allow to remove nested blocks if users want to, for example, remove the previous link. Not the other way around. |
|
I disagree with the notion and practice that if a block is used in the Site Editor it is acceptable for that block to be more difficult to use and for it to not be accessible. That is not how you empower people to create better websites. That is not how you help users learn. |
It looks like @t-hamano's example block variation does that. |
|
I am not going to spend more time on this. I am expecting to see the following merged:
|
|
I think the fact that the only way to fully solve accessibility issues is to add a new block means that the editor itself may lack a UI to assist users in creating fully accessible pages. The Post Navigation Link block isn't the only thing that is expected to be wrapped in a nav element -- for example, a user may insert link buttons or link lists that have navigational implications. With that in mind, I think the following approach might be effective in the long term:
Either way, I'd love to hear from anyone who has other ideas or approaches to finding the ideal solution. |
|
The nav element is not the only issue that needs to be solved. Again, if a theme developer wants to style the query pagination and the next and previous post links the same way, and then design it differently in a style variation, they can't do that. |
What?
Closes #55157
The purpose of adding this new block is to:
Why?
<nav>element.How?
Adds a new block called Post Navigation.
The block adds a
<nav>element and inserts two post navigation link blocks as inner blocks.One of the inner blocks is of the "previous" block variation.
The block supports adding an aria label. The user can add a "navigation name" in the Advanced panel.
The block also supports color and typography options.
Note on accessibility
While using a nav element is an improvement, this block is still not as accessible as the post navigation function that is available for classic themes, because it does not have a visually hidden heading inside the nav element, above the links.
the_post_navigation
get_the_post_navigation
navigation markup
Testing Instructions
Activate a block theme.
The post navigation block can be tested using a single post, or the single post template.
Add the block.
Confirm that:
Testing Instructions for Screen readers
Activate a block theme.
The post navigation block can be tested using a single post, or the single post template.
Add the block.
Save and go to the front of the website.
Navigate to where you placed the block.
Confirm that the first of the two links are announced as part of a navigation, and that the aria label is announced.
If you did not change the aria label in the blocks Advanced panel, the default label is "Posts".
Screenshots or screencast