Gutenberg: [Feature Request] Add `wp-block` class to all the blocks

[srikat]

It would be handy to have wp-block class added to all the blocks in addition to block specific class.

This would be useful if we want to set say, a bottom margin to all the blocks in CSS.

Ex.:

Instead of having to write

p.wp-block-subhead,
.entry-content .wp-block-cover-image,
.wp-block-image,
.entry-content ul.wp-block-gallery,
.wp-block-text-columns,
.entry-content .wp-block-button,
blockquote.wp-block-quote,
.entry-content .wp-block-quote.is-large,
.wp-block-code,
.wp-block-audio,
.entry-content .wp-block-video,
.wp-block-preformatted,
.wp-block-verse,
.wp-block-table,
.wp-block-categories,
.entry-content .wp-block-latest-posts,
.wp-block-embed {
    margin-bottom: 60px;
}

we could simply write

.wp-block {
    margin-bottom: 60px;
}

[aduth]

While not as explicit, would the following work?

[class^="wp-block-"] {
    margin-bottom: 60px;
}

[rchipka]

:+1:

There's no reason why this shouldn't be the case and the sooner we decide on the class name the better.

This would also be useful if Gutenberg decides to take over dynamic CSS injection.

@aduth It should be its own wp-block class (in addition any to other classes) so that block developers can target their blocks using a higher-than-default (but still easily overridable) selector specificity.

[gziolo]

We offer the filter which allows to modify the default class name:
https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#blocks-getblockdefaultclassname

What about using the following instead:

function addBlockCustomClassName( className ) {
    return 'wp-block ' + className;
}

// Adding the filter
wp.hooks.addFilter(
    'blocks.getBlockDefaultClassName',
    'my-plugin/add-block-custom-class-name',
    addBlockCustomClassName
);

[mtias]

This probably needs a decision for the "try" milestone.

[mcsf]

I don't feel strongly about adding wp-block on its own, but I do think we should make sure all core blocks do respect the wp-block-foo nomenclature (for instances, Lists are an exception).

[chrisvanpatten]

One question: is the idea that .wp-block is added on all blocks, or _only_ core blocks?

I imagine only core blocks (you wouldn't really be able to enforce it on 3rd party blocks) but either way I like the idea.

[wpscholar]

At present, we are enforcing a specific class naming convention for third-party blocks unless they specifically opt out. I think it would be reasonable to enforce the .wp-block class unless the third-party has opted out and wants to use their own class names.

[noisysocks]

This came up in a weekly #core-editor chat (link). We decided to punt on this for now because:

• [class^="wp-block-"] is an OK workaround.
• Blocks don't necessarily have wrapper elements, e.g. <!-- wp:foo/bar -->hello world<!-- /wp:foo/bar --> is a valid block.
• It's easier to add a wp-block class later than it is to remove it later.

[hatsumatsu]

@noisysocks

• The suggested workaround [class^="wp-block-"] also targets inner block elements like wp-block-group__inner-container.

• Adding a custom classname via the filter blocks.getBlockDefaultClassName does not alter the class attributes of "blocks" like Heading, Paragraph and Image...

From a user perspective it's very hard to understand what prevents adding a class of wp-block to all blocks by default.

[noisysocks]

What do you think, @gziolo? It sounds like the existing solutions we have here aren't good enough.

[gziolo]

What do you think, @gziolo? It sounds like the existing solutions we have here aren't good enough.

I think there are still blocks which don't have any class name provided by design like Paragraph, Heading or List blocks (all of those with support set to false). As far as I know, it was a conscious decision to keep HTML output as clean as possible. @mtias or @youknowriad should have the best idea of whether such core change is feasible. You can always use one of the PHP filters which operates on block's content and inject such class to all blocks during render phase if necessary.