Block Visibility: change visibility class

[t-hamano]

Trac ticket: https://core.trac.wordpress.org/ticket/64802

Use of AI Tools

None

[github-actions]

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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props wildworks.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[ramonjd]

LGTM - manually tested and against WordPress/gutenberg#76166

[mukeshpanchal27]

Does this class conflict with any existing one themes/plugin? Have you checked that?

I do quick search https://wpdirectory.net/search/01KK0QW5ZCT6GTEZDAMAZ33HXM for themes.

[ramonjd]

That's a good question. I wouldn't be against reinstating wp as a namespace. After all it's wp that's generating it.

[t-hamano]

There are already other classes that could potentially be in conflict.

• is-position-sticky
• is-nowrap
• is-layout-constrained
• is-repeated

However, it's a good idea to avoid conflicts. For example:

• is-block-hidden-on-{viewport}
  • Search for themes: https://veloria.dev/search/1009fa0e-b751-4433-83f6-0a9397c5e689
  • Search for plugins: https://veloria.dev/search/937734d8-bff6-4799-95ad-f09b61a279a0
• wp-is-hidden-on-{viewport}
  • Search for themes: https://veloria.dev/search/7515443e-069c-48a8-91d7-103872a49e77
  • Search for plugins: https://veloria.dev/search/856b45fd-e95f-41dd-83e2-920fa8c039a8

As you can see, neither CSS class is likely to conflict with existing themes or plugins.

Personally I prefer is-block-hidden-on-{viewport}. What do you think?

[ramonjd]

If we get in first it's ours 😄

I'm ambivalent. My only 2c would be that wp indicates that this is coming from WP core.

Same as what happens for WP block classes:

wordpress-develop/src/wp-includes/blocks.php

Line 49 in 64086b2

$asset_handle = str_replace( 'core/', 'wp-block-', $block_name );

It might reduce confusion for humans (and bots) looking at the code.

[t-hamano]

I thought about it again and began to think that the current CSS class is the least likely to conflict with other themes or plugins, and there's no need to change it now 😅

For now, I'm going to close this pull request. Sorry for the confusion!