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 |
|
@WordPress/gutenberg-core How can we arrive at a final decision about whether this block should be added or not? |
|
I think we should not make this block. While it makes sense, after all there is for instance a media+text block which could just as well be a pattern (although its a relic of earlier iteration), it seems the wrong tool for the problem at hand:
This shows that we have some limitations in how we express structure semantically. I can even say it could be better to allow nav for group than to add this block just for this reason. Other than this it doesn't add too much, because unlike media+text this is a template block, not used in posts, so the frequency of every having to build row+next+prev is quite low. |
|
I would challenge you to watch a user add these blocks. The accessibility is what is most important for me, but users are also struggling with needing to insert two copies and positioning them. Adding the nav to the group still requires that the user knows it needs to change the elements, and that they need to use more than one block type. |
|
I would also challenge the assumption that users don't add this block: Are there statistics for this? |
|
I am asking for more valid arguments against than "I don't want another block" "I am not found of adding another block". |
There was a problem hiding this comment.
I would also challenge the assumption that users don't add this block: Are there statistics for this?
@carolinan I am not saying people don't add it or will not add it. They will definitely use it. What I am saying is that compared to the other block that is just a combo of blocks (media+text) this is not a content block, so it will be less frequently used to warrant the shortcut.
However, my main argument is not against the block: it is to signal that the main benefit of this block is that it solves the lack of semantics in wrapper blocks. And that should not be solved via a new block, but by solving the lack of semantics in wrapper blocks.
users are also struggling with needing to insert two copies and positioning them.
This too points to a problem that should not be solved the wrong way: why do the users struggle? I think users would struggle because building layout is not the simplest thing. All tools have certain complexity levels where the UI itself can't convey everything.
I am asking for more valid arguments against
For any new block the arguments for it should be compelling not so much against it. To me the best argument for this block is that we have plenty of shortcut (macro) blocks:
- gallery, even though we have image and columns and rows
- media text, even thgouh we have columns image and paragraph
- buttons, even though we have row and button
- author name even though we have author which also includes the name
- query pagination
Separately, one problem @carolinan is that this block is inherently more restrictive b/c of allowed blocks. The row block allows for separators and decoration between the links.
Edit: just for reference there is a proposal for a dialog block of which I am not convinced either #61297 - so it's gonna be a perpetual issue. And I don't decide anything :)
|
I will leave the decision on whether to use a new block or provide another mechanism to contributors more familiar than me with this kind of decisions. I'd be more interested in solving the underlying usability and accessibility issues. Quoting from the original description:
As a user, why on earth I have to add two separate blocks (Previous and Next) and then wrap them in a parent block? That is an unnecessarily complex, unintuitive, and time-consuming flow. In most of the cases, users would want to just add a previous/next navigation with just one click.
|
|
Maybe I'm missing something, but why can't we just add a
In my opinion, these existing elements are just as important as the |
|
@t-hamano 's question is very pertinent |
|
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:
|
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