Remove the leading module name from all block plugin IDs.
→ Code and CSS classes should rely on $plugin->getProvider().
Remove the trailing "_block" suffix from all block plugin IDs.
→ Needless duplication, both in plugin IDs as well as generated CSS classes.
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
Remove the "block-$module" CSS class.
→ Rare use-case. If necessary, this can be achieved with a CSS3 [class*='block-module-'] selector.
.
.
.
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.
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 → .
$plugin based naming convention for HTML IDs on blocksNone that I am aware of.
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).
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?
Postponed: needs info
9.5
Issue related to Drupal on mobile devices.
Implements and supports the use of HTML5.
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Been 9 years since this moved to PNMI. Should it be reopened or closed?
Since there hasn't been a reason to re-open since 2014, going to close out. If still a valid task in D11 lets re-open updating the summary please.
Thanks all!