Flaky tests detected in d552d79.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4053536069
📝 Reported issues:

• [Flaky Test] should display (capture the) text from the currently active link even if there is a rich text selection #36495 in specs/editor/various/links.test.js
• [Flaky Test] shouldn't conflict with server-side autosave #35176 in specs/editor/various/autosave.test.js

This tested well for me. The only thing I noticed is that with using wp_add_inline_style within wp_enqueue_scripts instead of echoing the style in wp_head it places the styles higher up in the header than the default customizer output which is towards the very end of the header. I think there would only be a very minimal risk of this causing any specificity issues with any existing hybrid themes with customizer custom CSS set so don't think it is too critical, what do you think?

A comment was also made here about trying to keep the custom CSS loading in the same location as the customizer CSS - I don't have a strong opinion one way or the other on how critical this is - use of the wp_head and manually echoing out the <style> element seems like the only way to do this, and this seems to be a little hacky.

Using wp_head with high priority doesn't guarantee that Global Styles's custom CSS will be loaded last or even after global-styles.

Let's keep using wp_add_inline_style for now. Then, we can change the callback hook and printing method based on feedback. What do you think?

cc @aristath

Let's keep using wp_add_inline_style for now. Then, we can change the callback hook and printing method based on feedback. What do you think?

Sounds good to me 👍