Add block classes for bundle and view mode

+++ b/core/modules/block_content/block_content.module
@@ -51,6 +51,19 @@ function block_content_theme($existing, $type, $theme, $path) {
+    $variables['attributes']['class'][] = 'block-type--' . $variables['elements']['content']['#block_content']->bundle();
+    if (isset($variables['elements']['#configuration']['view_mode'])) {
+      $variables['attributes']['class'][] = 'view-mode--' . $variables['elements']['#configuration']['view_mode'];

I'm still not convinced adding these classes across the board is the right approach.

Personally I want less Drupal noise in my templates, not more.

Should we be instead taking the approach node takes, which is to add additional theme suggestions?

i.e so block--block-content--{bundle} and block--block-content--{bundle}--{view-mode} works out of the box?

That seems to be what we're doing in ✨ Template suggestions for custom block view modes Fixed

Can see both scenarios where one may want to add css targeting a specific class without having to override the template.

I'm still not convinced adding these classes across the board is the right approach.

Personally I want less Drupal noise in my templates, not more.

Should we be instead taking the approach node takes, which is to add additional theme suggestions?

i.e so block--block-content--{bundle} and block--block-content--{bundle}--{view-mode} works out of the box?

I'm sort of leaning that way as well. It always bothers me how much markup Drupal can spew out onto the page. There's also the question of sites which may not even want to expose their internal naming to end users. It's probably not a security concern, but personally I might find it a bit annoying.

Building on that thinking, this does make me wonder if we should instead provide template suggestions for all [content] entities out of the box. This is a case of boilerplate code which at some point every entity type (core or contrib) is probably going to come up against.

Yeah, I still think ✨ Template suggestions for custom block view modes Fixed is the best approach here, @AaronMcHale seems to agree. Should we close won't fix this?

I asked in #frontend for others to chime in.

For posterity, for a very long time our frontend workflow has been to use something like BEM to bring order to class naming, preferring to override templates to use class names that are meaningful to the project.

Theming using Drupal generated classes is considered an edge-case/last resort when you can't change the markup and typically isolated in CSS files under the heading 'Fugly selectors' 😛

FYI not married to the idea here if the consensus is it’s not needed.

Adding a preprocess hook is also very simple.

When I opened this issue lo these several years ago, my concerns (see the issue summary) were two:

the lack of such classes is [1] a barrier when theming custom blocks and, [2] compared to node, detracts from parallelism between content entity types.

✨ Add block classes for bundle and view mode Closed: duplicate is a good step towards both concerns, so FWIW I agree this can be closed as a duplicate.

I'd prefer to avoid this... theme suggestions and variables sure, but classes output by default means more things I need to override and strip out.

Thanks @smustgrave @nedjo @rikki_iki