Always output core block global styles after base global styles.

[tellthemachines]

Trac ticket: https://core.trac.wordpress.org/ticket/60280

Alternative to #5892.

Given that it's undesirable to have base global styles load before block-library styles, this PR changes just the block global styles so they load after the base global styles.

The order of loading should now be:

• Block library styles
• Base global styles (element styles, etc)
• Block-specific global styles

This order should be the same regardless of whether should_load_separate_core_block_assets is true or false.

This addresses part of @oandregal's feedback here. It doesn't touch on custom CSS yet. To fix the existing bug and keep this change small, I'll address the custom CSS separately (it's not really the same issue, because the order of custom CSS is fine, the problem is that it's always loading whether the target blocks are on the page or not)

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core SVN

Core Committers: Use this line as a base for the props when committing in SVN:

Props isabel_brison, oandregal.

GitHub Merge commits

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: oandregal <oandregal@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[oandregal]

OK, I had to jump through some hoops but I finally created a test case for this, was able to reproduce it, and this works nicely. Thanks for keep trying!

This is how I reproduce:

• Using the TwentyTwentyFour theme, with default configuration.
• Created two posts. One with the quote block and one without. Publish them.
• Verify that:
  • the post with the quote has the quote styles as part of the global-styles-inline-css stylesheet while the other doesn't.
  • the wp-block-quote-inline-css stylesheet doesn't have the block-level styles that are now part of global-styles-inline-css.

• Go to the functions.php file of the theme and add the following:

add_filter( 'should_load_separate_core_block_assets', '__return_false', 11 );

• Reload the two posts and verify that
  • both posts have the quote styles as part of the global-styles-inline-css stylesheet.
  • the wp-block-quote-inline-css stylesheet doesn't have the block-level styles that are now part of global-styles-inline-css.

[oandregal]

This is great work, thank you!

[tellthemachines]

Thanks for reviewing @oandregal ! Committed in r57546.