Block Validation: Ignore markup changes for the style attribute.

[youknowriad]

In https://github.com/WordPress/gutenberg/discussions/37495 we're discussing how to bring more coherence and consistency to the styles resulting from block customizations.

One of the "conclusions" of that discussion is that we should probably not consider a block that have differences in the wrapper level style attribute as invalid block.

So basically if the markup of the block is

<div style="something">content</div>

and the expected result is

<div style="something else">content</div>

The block should still be considered valid.

I'm creating this issue so we can track that and start exploring that change to the validation algorithm.

cc @andrewserong @aaronrobertshaw @mcsf @mtias

Related #21703

[ramonjd]

@youknowriad do you think this is still a requirement? Cheers.

[youknowriad]

I used to think it might be useful if we decide to drop the old style attribute like "backgroundColor", "gradient"... to consolidate in the "style" block attribute. I don't know what are your thoughts and current situation there. It might not be needed to change the validation behavior to achieve that.

[ramonjd]

I used to think it might be useful if we decide to drop the old style attribute like "backgroundColor", "gradient"... to consolidate in the "style" block attribute. I don't know what are your thoughts and current situation there. It might not be needed to change the validation behavior to achieve that.

Thanks for the quick reply.

I don't have much to say aside from that I haven't noticed any need for it so far.

Maybe we can close this issue and come back to it if a use case arises. What do you reckon?

[andrewserong]

I don't have much to say aside from that I haven't noticed any need for it so far.

Me either. I think it'll be a useful feature for if and when we ever want to switch over inline styles to be run in server-rendering instead of being stored in post content (e.g. like we now do for fluid typography output, or sort of similar to how we handle the layout support).

I still think it'd be pretty neat if we could have the style output be server-rendered, so that eventually we could give themes a bit more global control over block-level style output without having to go and update old block markup, but I can't think of an immediate need for it.

If we close out this issue, perhaps we can revisit it if and when we have a solid case for how we'd like to handle the server-rendering?

[youknowriad]

I still think it'd be pretty neat if we could have the style output be server-rendered, so that eventually we could give themes a bit more global control over block-level style output without having to go and update old block markup, but I can't think of an immediate need for it.

Agreed.

Let's close for now.

[giannis-koulouris-bb]

One reason I see this could be useful is to have the ability to filter core blocks without breaking them if you decide to make changes in the future. There are some websites I developed in the past where we didn't have ability to add margins/paddings so I filtered the core blocks and added settings for custom paddings/margins that they get added inline. How is it possible to switch to the core margin/padding settings without triggering invalidation errors?