WIP Give themes control of visual styles for core blocks

[brandonpayton]

Description

This is a PR to:

• Separate core block visual styles from structural styles.
• Give themes the ability opt-into visual styles provided with core blocks.
• Make it easy for themes to augment core block styles.

Contributes to #5360.

How has this been tested?

This has been tested manually with a parent theme. It needs to be tested with a child theme where both parent and child specify styles for the same block types. It would also be good to add unit tests.

Types of changes

• Split visual styles into a theme.css for each core block.
• Update the build to produce an aggregate build/theme.css file.
• Enqueue build/theme.css when themes enable support for wp_block_styles.
• Support themes augmenting block styles by creating a blocks/ directory and a CSS file per block styled by the theme. Example: <theme-dir>/blocks/core.quote.css.
• Read augmented block styles from both child and parent theme. If both specify augmented styles for a given block type, use the styles provided by the child theme.
• Documentation
• Unit tests
• Take steps to reduce surprise and interruption when developers and users discover visual block styles are no longer added by default.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[brandonpayton]

Questions for review:

• What would be a PHP/WP-idiomatic way of unit testing something like this?
• Any suggestions on how we can reduce the developer and tester impact of landing this?
• It seems like it would be clearer to split out theme styles for core blocks under a follow-up PR. Does that sound reasonable?
• Right now, this PR will enqueue each <theme>/blocks/<block-name>.css file found for registered and core blocks. I believe this will lead to too many resource requests on the front end. Should we read the files and add them inline instead?
• You mentioned SCSS files in your description of this feature. Is that something we should be supporting here? I don't think so but want to be sure.

[mtias]

"Default block styles"

[mtias]

type "will"

[mtias]

todo, fix version number

[brandonpayton]

Thanks for your review, @mtias. I pushed fixes to address your comments.

[rchipka]

Related to #6651

The addition of configurable CSS attributes should be standardized as a special prop on each component so that Gutenberg can take care of injecting the styles/classes in an automated, consistent, and maintainable way.

Also see the notes about how we should be doing class names and class injection to properly support extensibility.

[brandonpayton]

Closing this in favor of a simpler PR for block style separation (#6947) and likely another in support of theme overrides for specific block types.