[wp-trac] [WordPress Trac] #62731: Inline CSS inserted by wp_print_auto_sizes_contain_css_fix too high in HTML

WordPress Trac noreply at wordpress.org
Wed Jun 11 00:27:38 UTC 2025


#62731: Inline CSS inserted by wp_print_auto_sizes_contain_css_fix too high in HTML
---------------------------------------------------+---------------------
 Reporter:  superpoincare                          |       Owner:  (none)
     Type:  enhancement                            |      Status:  new
 Priority:  normal                                 |   Milestone:  6.9
Component:  Media                                  |     Version:  6.7.1
 Severity:  minor                                  |  Resolution:
 Keywords:  has-patch needs-testing has-test-info  |     Focuses:
---------------------------------------------------+---------------------

Comment (by westonruter):

 Replying to [comment:6 SirLouen]:
 > Doesn't make sense to me, deprecating such nouveau function
 `wp_print_auto_sizes_contain_css_fix`. I understand this the backwards
 compatibility policy, but we can be pretty confident noone is using this
 (and if they were using it, they might have reported this).
 [https://wpdirectory.net/search/01JXE4QAMTK4XGK3MZVYMW9A1D So just wipe
 it].

 Unfortunately, WPdirectory is not up to date. As can be seen from
 [https://wpdirectory.net/search/01JXE5N3F699MWWZF1082Z0QHN searching for
 GUTENBERG_VERSION], the last WPdirectory was updated was around the
 Gutenberg v18.2.0 release, which was around April 24, 2024. The function
 in question here was introduced in WP v6.7.1 which was released
 ''afterward'' on November 21, 2024. Therefore, it is entirely expected
 that `wp_print_auto_sizes_contain_css_fix()` would not be found by
 searching WPdirectory.

 It's safer, although noisier, to
 [https://github.com/search?q=%2F%28has_action%7Cremove_action%29%5C%28%5Cs*%5B%27%22%5Dwp_head%5B%27%22%5D%2C%5Cs*%5B%27%22%5Dwp_print_auto_sizes_contain_css_fix%2F&type=code
 search GitHub]. For complete backwards-compatibility, we'd leave the
 action on `wp_head` and in the enqueueing function check to see if
 `has_action( 'wp_head', 'wp_print_auto_sizes_contain_css_fix' )` and only
 proceed with enqueueing the style if that is the case. This is what we did
 with the emoji styles.

 > Replying to [comment:3 sabernhardt]:
 > > If the //title// should be earlier, block themes probably could add
 'title-tag' support now instead of using the
 `_block_template_render_title_tag` function. (@westonruter proposed the
 [https://github.com/WordPress/gutenberg/pull/17626/files#r329165034
 separate function], in the context of the Gutenberg plugin, and #53176
 carried it over with a new name.)
 >
 > Doesn't this seem to be a separate topic for a ticket?

 It's an alternative approach, to change the placement of the `TITLE`
 rather than the placement of the `STYLE`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62731#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list