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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: akasunil <sunil25393@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: stokesman <presstoke@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: hanneslsm <hanneslsm@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Hi @Mamaduka, need your help with PR review here.

Hi, @sunil25393

It's been a while since I worked on the Cover block, and I might miss some of the pre-requestions needed for this change. I would recommend contacting folks who worked on the overlay feature "recently". cc @t-hamano, @stokesman

P.S. Removing the has-background-dim-{unit} class can be considered a breaking change, though I don't have any data about their usage in real-world sites.

Removing the has-background-dim-{unit} class can be considered a breaking change,

I have kept the css for backward compatibility. We can deprecate it in future version of gutenberg i guess.

I have kept the css for backward compatibility.

Yes but George was referring to its corresponding class in the markup. There could be instances of CSS written using it in their selectors. Here’s what can be found in themes from wpdirectory. Most of the usage seems odd to me and I'd like to think we can not worry about breakage but I think that’d be against policy.

Otherwise, I gave this a test drive and it worked well. I only tested a basic Cover block created from trunk before switching to this branch and the block updates successfully. I'm not sure how else these types of changes need to be tested.

There could be instances of CSS written using it in their selectors.

Thank you for your reply. I see it now. However, if we leave the class selectors, opacity will be applied twice. There is no significance to it. Is there a workaround for this? We can always update the changelog, though.

I took a closer look at the selectors used in the themes from that search and all of them that I saw are written for older cover block versions which had the has-background-dim-{unit} class directly on the block’s root element. So those styles wouldn’t be applying to more recent cover block versions anyway. I.e. this change won’t break those styles.

Yet I didn’t examine all the results because they are many (though it appears they are all repetitions of what I did examine). I wanted to try a more exacting regex to find results that aren’t paired up with wp-cover-block classes but didn’t see a way to do it that’s supported by WP Directory’s regex interpreter.

I've also ran the search on plugins. There are some results though it appears that they are for custom blocks that adopted the use of the class and so should be unaffected by this change. For example, I tested the most installed plugin in the results (WooCommerce) and the class is used on their Featured Product block that has nothing to do with Cover.

My feeling is that this should be safe to ship as is but I don’t know the level of caution others might think is warranted.

Thank you for investing @stokesman, @t-hamano can we get your view on this ?