[meta] Update block HTML IDs now that they're plugins

Problem

1. Inconsistent block CSS class names.
2. Needlessly verbose block CSS class names - repeating "block" as suffix (originating from plugin ID).

Goal

1. Revise block CSS class names for D8.

Proposed solution

1. Remove the leading module name from all block plugin IDs.

   → Code and CSS classes should rely on $plugin->getProvider().

2. Remove the trailing "_block" suffix from all block plugin IDs.

   → Needless duplication, both in plugin IDs as well as generated CSS classes.

3. Make the primary block CSS class "block-$provider-$pluginid".

   → Clean class names that cover all use-cases.

   Note: Double-check plugin IDs of derivative plugins (e.g., menu blocks). To my knowledge, they are compatible and would work like this:

   Plugin ID:  base_plugin_id:derivative_id           →  menu:main
   CSS class:  block-$provider-$baseid:$derivativeid  →  block-menu-menu--main
   

4. Remove the "block-$module" CSS class.

   → Rare use-case. If necessary, this can be achieved with a CSS3 [class*='block-module-'] selector.

.

.

.

Problem/Motivation

The Block HTML ID naming convention has changed from block-$module-$delta to block-$instance_machine_name. Since the $instance_machine_name naming convention differs from the $module-$delta pattern, the CSS selectors in core CSS and JS files no longer correctly apply styles to blocks provided by core.

Please note that #1896098: Add a plugin class to the blocks to identify instances in css → addresses the issue of plugin-based class names on blocks. This issue's discussion and patches should be limited to the ID only of the block's HTML and associated CSS and/or JS.

Proposed resolution

To be determined, but should focus on the ID and not the class name, due to work being done in #1896098: Add a plugin class to the blocks to identify instances in css → .

Remaining tasks

• Determine $plugin based naming convention for HTML IDs on blocks
• Update CSS and JS selectors in core CSS and JS files (unsure which specific files would be affected)

User interface changes

None that I am aware of.

API changes

With an updated $plugin based naming convention for HTML IDs on blocks, CSS and JS selectors will necessarily be updated in core files. Any ID-based CSS or JS selectors targeting blocks in contrib theme or modules will need to be updated (by the contributor).

Original report by effulgentsia

In #1535868: Convert all blocks into plugins → , block HTML IDs have changed from block-$module-$delta to block-$instance_machine_name. The instance's machine name is administrator settable when initially creating the block instance (choosing "Configure" from the "Block Library"). The Standard profile includes several predefined block instances via config files in core/profiles/standard/config/plugin.core.block.*. For example, the User login block instantiated in the Bartik theme has a machine name of login, forming a config filename of plugin.core.block.bartik.login.yml.

The machine names of these Standard profile blocks differ from the $module-$delta pattern that existed prior to the conversion to plugins. For example, the User login block's machine name is login, not user-login.

But in several core CSS and JS files, we still have CSS selectors for #block-user-login and other #block-$module-$delta IDs.

At a minimum, we need to fix the CSS selectors to match the machine names, but are the machine names what we want them to be, and are we ok with them being administrator configurable?