Size Change: +39 B (0%)

Total Size: 1.06 MB

_{compressed-size-action}

For context, we removed that restriction for themes at #29941

I've just checked the styles section of a couple of themes and I see that they use the following styles for which the block doesn't declare support:

TT1-blocks:

• button: font-weight (the block does support other typography properties)
• pullquote: font-size, font-weight, padding
• code: spacing, border (the block only supports font-size and it has a __experimentalSelector)

Quadrat:

• button; font-weight & line-height (the block does support other typography properties)
• code: border, spacing, typography, color. The block only supports font-size. It does have a __experimentalSelector.
• gallery: spacing.margin but the block doesn't support anything.
• pullquote: typography, spacing.padding
• separator: color, border
• quote: border, spacing, typography, citation
• navigation-link: color
• list: padding
• query-pagination: typography
• site-logo: spacing

The rationale to remove that requirement for themes was that they could experiment at a higher pace than we could add supports for the blocks. The responsibility for checking that it worked was shifted to the themes, I'm not sure it's a good thing to expose users to this burden. I'd argue the properties I've shared above should be added as block supports to the blocks at some point (even if we want to hide them by default from the user in the block sidebar).

Essentially, my concern is: if we show the panels, isn't the expectation that they work? And if they don't work, isn't this a bug?

An alternative approach is to create the panel/properties if any of this happens: the block supports the property or the theme styles the property. If the theme is styling the property, it probably works, so we could be optimistic about exposing that to users.

The responsibility for checking that it worked was shifted to the themes, I'm not sure it's a good thing to expose users to this burden. I'd argue the properties I've shared above should be added as block supports to the blocks at some point (even if we want to hide them by default from the user in the block sidebar).

I agree with this way of seeing things.

I also worry about another point:

Removes the check for "block supports" to decide whether a block supports a given panel. Rely solely on theme.json.

What if theme.json does not use some block supports at all but the block supports it? The user will not be able to use some customization ability that should be possible right?

Yeah, I see the points. I'm still uncertain as well. I think I can scale this down to this to start with:

If the block doesn't support any of the panels, its menu item is removed.

Ok, I restored the checks and only left the removal of blocks with no visible panels. This should be ready for another review.