![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Initial Version and Version 1 of Ticket #53494, comment 8
- Timestamp:
- 06/25/2021 12:46:44 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #53494, comment 8
initial v1 10 10 The options I see forward: 11 11 12 - I'm a bit out of my expertise here, but wanted to share for others to weigh in: can we make it so that the `post_content` is pre-rendered for classic themes that have `should_load_separate_core_block_assets` enabled so we can enqueue the block styles in the {{{<head>}}}? This is: can we not have 1.2?12 - I'm a bit out of my expertise here, but wanted to share for others to weigh in: can we make it so that the `post_content` is pre-rendered for classic themes that have `should_load_separate_core_block_assets` enabled so we can enqueue the block styles in the {{{<head>}}}? This is: can we make it so that 1.2 doesn't happen? 13 13 14 14 - Alternatively, we can enqueue global styles in the "footer" in 1.2, following what block styles do. My concern with this approach is the same I shared [https://github.com/WordPress/gutenberg/pull/31309#issuecomment-829154451 before]: that by changing the place block styles are enqueued to, we may run into other conflicts with plugins and theme styles. In other words, third parties need to be aware of this logic as well. If they want to override block & global styles they can only do it by enqueuing to the footer with higher priority than the default.
