Deprecate Comments Pagination block

[t-hamano]

What problem does this address?

The Comments Pagination block has the following specifications:

• Layout support
• The paginationArrow attribute for adding decorative arrows to the Comments Next Page and Comments Previous Page.
• The three blocks Comments Next Page, Comments Previous Page, and Comments Page Numbers can only be inserted within this block.

The three blocks Comments Next Page, Comments Previous Page, and Comments Page Numbers do not necessarily require wrapper blocks, and these specifications should be possible with additional implementation.

What is your proposed solution?

In order to deprecate the Comments Pagination block, I believe the following tasks are necessary:

• [ ] Allow the Comments block as a parent of the three blocks (Comments Next Page, Comments Previous Page, and Comments Page Numbers) in addition to the Comments Pagination block.
• [ ] Add the paginationArrow attribute option to the two blocks, Comments Previous Page and Comments Next Page. However, if the paginationArrow attribute is undefined and is wrapped in the Comments Pagination block, inherit the context.
• [ ] Deprecate the Comments Pagination block.

Note: These tasks will not break themes that use the Comments Pagination block. Themes that use the Comments Pagination block will continue to work as before, we will just not be able to insert the new Comments Pagination block.

I believe the advantages and disadvantages of deprecating the Comments Pagination block are as follows:

Advantages

• The three blocks Comments Next Page, Comments Previous Page, and Comments Page Numbers can be placed anywhere within a Comment block without a wrapper block.
• By wrapping them in the Group block or variations of it, we can set any gap value. The Comments Pagination block currently does not support the gap.
• Hard-coded margins will no longer be applied. (Example) This style has a CSS specificity of 0-2-0, so it cannot currently be overridden via global styles or theme.json.

Disadvantages

• Decorative arrows can no longer be set in both Comments Next Page and Comments Previous Page blocks at the same time

Known Issue

I found that we could try to insert the Comments Pagination block into the Comment Template block. However, although it shows up in the inserter, it doesn't seem to be possible to insert it:

The Comment Template block loops through the blocks inside it, so we shouldn't be able to insert the Comments Next Page, Comments Previous Page, and Comments Page Numbers blocks, let alone the Comments Pagination block.

This issue will need to be addressed separately.

cc @WordPress/block-themers

[t-hamano]

P.S. For the same reasons as the Comments Pagination block, I believe the Pagination block (core/query-pagination) can also be deprecated. If we are able to move this issue forward, I would consider deprecating this block as well.

[carolinan]

I disagree because navigations should semantically be <nav> elements to be accessible. Users should also be able to separate different nav elements from others, for example, separate comments pagination from paginated pages and the next / previous post navigation, so they need an identifier.

It is a big ask of the user to know this and to manually add a container around the navigation, and then changing the element using the code editor.

Comment pagination should use a nav and an accessible name https://github.com/WordPress/gutenberg/issues/63328

[t-hamano]

because navigations should semantically be

elements to be accessible.

Ah, I missed this important point! But do we need to force this block to be surrounded by certain elements? For example, header, footer, main elements, etc. must be explicitly specified by the user via the Group block.

Wouldn't it be possible to solve this by adding a nav to the HTML element options of the Group block and then adding an aria-label field?

[carolinan]

When i worked on the proposed update for the post navigation link (next and previous), I asked a few designers and they preferred to be able to do both: 1) Use the parent block that is just a working drop in solution 2) Place the individual blocks where they wanted

Yes, it is possible to add a group and then go into the code editor mode and manually add the block attributes for aria-label and tagName. But it is too much to ask of users that they should know how to do that, compared to inserting the single block and be done.

Nav is not selectable in the HTML element selection on the group block because if it is used incorrectly it has a negative impact on the structure of the page, making navigation more difficult. Aria label does not have a user interface because using it correctly requires advanced knowledge.

Header and footer template parts use the correct tags on creation, the user does not need to change it.

[carolinan]

So I would suggest not deprecating, but making sure the individual blocks do not require the parent? That leaves the question about the icon options (the arrows). I would support moving them to the individual block (removing it from the parent) - as long as it is consistent across all the pagination related blocks.

And by moving the icon option, it would be possible to use different icons on different "sides" if anyone would ever want that... I mean using one arrow for next and another for previous. (Like in the early design proposals I found for twenty thirteen :p )

[t-hamano]

Thanks for the feedback!

not deprecating, but making sure the individual blocks do not require the parent

I see, this seems like the best approach.