Page List Block: Add block.json color supports

[jeyip]

Description

Fixes #36537

There are no block-level color customizations available in the block settings menu. This PR exposes those options in the sidebar.

How has this been tested?

1. Navigate to the post editor (Posts > Add new button)
2. Insert a page list block
3. Open the block settings sidebar
4. Modify text, link, and background colors.
5. Verify that the changes persists in the editor and frontend.
6. Enable full site editing by activating an full site editing theme (Ex. Quadrat)
7. Navigate to the site editor
8. Repeat steps 2-5

Screenshots

Before

After

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[zaguiini]

🚢

[tellthemachines]

Could you share more about use cases for this @jeyip ? Page List is not like the List block in that its contents are dynamically generated, much like the Archives and Categories blocks, which don't have colour settings.

Another thing that should be taken into account is that Page List is most often used inside the Navigation block, though it can also work as a standalone. When inside Navigation, it should not have any colour controls, because it needs to inherit any colour settings from its parent block. So if we really want to do this, we have to find a way to only show those controls conditionally when Page List is not inside a Navigation block.

[tellthemachines]

Page list only ever has links (plus bullet points) so making "link" option available means we can end up with a different colour for the bullet points and for the links:

Which, granted, someone might want to do, but is likely only going to cause confusion. Having only background and text color settings should be enough.

[jeyip]

Which, granted, someone might want to do, but is likely only going to cause confusion

Agreed -- this is a good point 👍

Having only background and text color settings should be enough.

Do you happen to mean background + link color settings? I imagine the user would be more worried about changing the color of the text than the bullet point.

[tellthemachines]

The text color setting will change both links and bullets; the link color will only change the links. If I were setting a color on the block, I would expect it to change everything; not sure there's a use case for changing just the links.

[jeyip]

Thanks for the context @tellthemachines!

Could you share more about use cases for this @jeyip ?

This issue was brought about more as a question of why we were restricting the page list block customization at all, rather than with a specific use case in mind. Hearing about the archives block and categories block as precedents makes sense.

This, however, still makes me wonder why we don't allow color customization on those blocks as well 🤔

Do you happen to know? I might be missing something, but I'm not sure why dynamic vs. static content should determine if a block has customizable colors.

Another thing that should be taken into account is that Page List is most often used inside the Navigation block, though it can also work as a standalone. When inside Navigation, it should not have any colour controls, because it needs to inherit any colour settings from its parent block.

From what I can tell, only the background color of the page list block is customizable. The link color is not, even when inside the navigation block. Is that a bug?

When inside Navigation, it should not have any colour controls, because it needs to inherit any colour settings from its parent block.

I might also be missing something here as well, but after some testing, enabling color controls doesn't affect color inheritance unless a color on the page list block is already set. I could definitely see a point being made about extra color settings being a confusing user experience though.

[Addison-Stavlo]

Page List is most often used inside the Navigation block, though it can also work as a standalone. When inside Navigation, it should not have any colour controls, because it needs to inherit any colour settings from its parent block.

Im not sure I follow here @tellthemachines . Shouldn't any block inherit styles from its parent until it has its own customizations set? How is that a conflict here?

Think of a paragraph block in a group block. They both have individual color settings. The paragraph block takes on the background and text styles of its parent group block when they are set. Once you set styles on the paragraph block itself, it uses those instead of inheritance. There is no conflict in that situation, and we don't need to hide the paragraph block's own styles in that case. Why should we have to do so with navigation and links? Shouldn't they behave the same? Isn't consistent behavior important for all blocks?

[jeyip]

@tellthemachines friendly ping to follow up on this PR now that WordPress 5.9 has been released.

[tellthemachines]

This, however, still makes me wonder why we don't allow color customization on those blocks as well

That is a very good question and one I don't know the answer to 😄 It might be good to get feedback from some of the design folks on this. I'm guessing it might have to do with the fact that these blocks essentially implement core widgets as blocks, and those traditionally don't have many customisation options.

Shouldn't any block inherit styles from its parent until it has its own customizations set? How is that a conflict here?

It's not a conflict, but a way of ensuring styling isn't accidentally messed up by being set on the wrong block 😅

It would still be useful to know what prompts the need for this change. We could in theory add color controls to every single block, but that would likely do the user experience more harm than good.

[jasmussen]

Hey, took this for a spin, and notably I rebased it first to see if the new ItemGroup based colors were used. Yes, they were! Shown here, a Page List, a Navigation with a Page List inside, and a regular Navigation block:

It all seems to work reasonably well. But at the end of the GIF you'll see that the color-customized Page List colors are overridden by the colors set by the containing Navigation block, which doesn't feel the most intuitive. That seems like an argument to disallow Page List colors when it's used inside Navigation, though — perhaps it's indeed an argument to disallow it altogether? You can, after all, always wrap the Page List in a group, and assign colors there. This is not a strong opinion.

However it would be very good to consider this PR in light of #39087 by @talldan which may convert this from a static to a dynamic block. #39205 could also be relevant.

[talldan]

I don't have strong opinions about this. As of yet, I haven't been hugely involved in work with the design tools, so I don't know if there's a strategy for when a block should receive color options. I'll ask around a bit.

Also not sure what direction #39087 will go in, but it's likely that the links will inherit color from their nearest parent, just like in the nav block.

In terms of the Navigation Block, I think it makes sense that Page List has the same kind of options as other Navigation Links, because it is just a convenient way to insert links. Right now, links don't seem to have any options.

But Page List is curious in that it can be used outside the nav block, so as others have already mentioned it should also be considered alongside its relatives like Archives.

I realise this comment doesn't add much, but I've typed it out now so I might as well click the Comment button.