Super broad selector for images max-width on WP 5.9.1 breaks image width

[wolffe]

Description

This was reported on Trac.
Copy-pasting from https://core.trac.wordpress.org/ticket/55229
Props hvianna for the original report.

I recently updated to WP 5.9 and noticed some undesired behavior on images in my custom theme, caused by the CSS declaration below (from ./wp-includes/css/dist/block-library/style.min.css):

html :where(img) {
    height: auto;
    max-width: 100%;
}

This causes images that would previously overflow a smaller container to be "squished" inside it now. Any reason to use such a broad selector on core?

My comment:

This also broke Metafizzy's Flickity slider for me and squishing off-canvas images. It's a breaking change that will affect various image containers, such as sliders, carousels, image animations and so on.

I had to override the CSS selector with:

html :where(img) {
    max-width: fit-content;
}

This new selector broke images on 200+ websites we currently manage.

Step-by-step reproduction instructions

1. Update to WordPress 5.9.1
2. Check Flickity slider (squished images)
3. Check image blocks in footer (full width, instead of being constrained to their container)
4. Check images in galleries (full width, instead of being constrained to their container)
5. Check images in custom HTML blocks (full width, instead of being constrained to their container)

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 5.9.1 with and without Gutenberg (latest version).

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[hvianna]

Thanks @wolffe for opening the issue here.

Below are some screenshots, using Kwicks Slider:

WordPress 5.8.2:

WordPress 5.9:

[kirill-grouchnikov]

This is way too broad. max-width: 100%; is breaking custom styles that allow images to overflow the boundaries of the main column. The primary scenario is edge-to-edge (editorial style, if you will) images, embedded in an otherwise constrained primary column of text.

[Mamaduka]

Fixed via #39045 and will be backported into the next minor release.

[wolffe]

This might reduce the issues, but not fix them completely.

The selector is still there:

html :where(img[class^="wp-image-"]) {
	height: auto;
	max-width: 100%;
}

It's just the class that has been appended. In my case, I use WordPress native functions to generate the images in the carousel, so it will still be broken for me.

[hvianna]

@wolffe I use get_the_post_thumbnail() to retrieve the images and it adds the classes "attachment-medium size-medium wp-post-image" - none of which match the selector, so I think this will work!

[Mamaduka]

@wolffe, which functions are you using to get images for the carousel?

[wolffe]

I think I use the same function as @hvianna. I'll report back/again after I apply this update. Thanks!

[nasif-co]

It's just the class that has been appended. In my case, I use WordPress native functions to generate the images in the carousel, so it will still be broken for me.

The implemented fix should only affect images added through the Classic Editor with the "Add Media" option. To my knowledge, no other part of the wp core adds the class wp-image-{attachment ID}, although I might be wrong, in which case it would be great if anyone more knowledgable on the core code can verify this.

The wp_get_attachment_image() function which I believe is the most widely used way to get images ouside of the the_content() (apart from get_the_post_thumbnail()) does not use the aforementioned class and is therefore safe from the newly implemented css rule.

[wolffe]

For me, the moment it was implemented, it broke 200+ websites. It shouldn't have been added, as this is theme territory.

All my images, regardless of how they were added to the post, were working fine before this new code has been added.

[nasif-co]

For me, the moment it was implemented, it broke 200+ websites. It shouldn't have been added, as this is theme territory.

I meant that the new proposed implementation should not affect your images! Sorry for my confusing writing :)

[gbaggaley]

Had the same issue as @wolffe, broke a lot of our websites built using the classic editor as the selector is far too broad and just applied the styling to every img tag on the website. The best solution for now is just to de-enqueue the block editor styles until this is fixed.

[PorterOneDesign-Bobby]

Just throwing my hat in the ring as this affected several of our sites. This kind of broad selector should not be Wordpress includes and should be removed.

[wolffe]

They changed the selector (see above) and the fix is coming in WordPress 5.9.2. I'll close this issue.

[nathanwalasek]

It does not appear this was resolved with the 5.9.2 update - I'm still seeing this rule after updating:

html :where(img) {
    height: auto;
    max-width: 100%;
}

/wp-includes/css/dist/block-library/style.min.css?ver=5.9.2

[wolffe]

They moved it to 5.9.3 or 6.0. @audrasjb can confirm.

[jondaley]

I was surprised by this breaking code as well. Please don't make such broad changes. And if I'm understanding the where() pseudo class correctly, doing html :where(img) isn't even useful, which makes me suspicious of whoever added it. Isn't that the same thing as doing "html img" or just "img", which would then make it really obvious that they were changing every single image on the entire site?

Adding in the class selector would fix it for me, and I'll edit the core code so my site won't be broken until the next upgrade at least. But, I agree that it seems reasonable to me that even with the class would break on some sites.

[Mamaduka]

The fix will be part of 5.9.3 release.

[johnstonphilip]

I just had about 10,000+ users of an old theme (circa 2012) of mine get hit with this as well. Very full inbox for me for a very old, unrelated, intentionally opted-out-of-Block-Editor product.

[hvianna]

Version 5.9.3 works for me! 👍

[Mamaduka]

Thanks for the confirmation, @hvianna.

I'm going to close the issue.

[johnpawsonS1]

Sooooo I'm seeing this exact issue on a site running 6.0.2... was this actually fix or has the problem been reintroduced? This is the code I'm seeing:

html :where(img[class*=wp-image-]) {
height: auto;
max-width: 100%;
}

I've joined Github specifically to try and figure out what's happening here as this is doing my head in!

[wolffe]

The issue was never fixed, they just made the selector less broad. Before, it used to be html :where(img), now they are targeting wp-image-*, but I still had to override this in 2 of my themes.

[johnpawsonS1]

Yeah I still can't get my head round this. The images that are being affected at my end are being added through a module in the Elegant Themes Divi theme. So they're not being added using Gutenberg/standard WP processes. Is there a way to nullify it using CSS?

[wolffe]

The way I solved it is above. On 2 custom themes, I had to add this:

html :where(img) { max-width: fit-content; }

Also, I have other overrides for specific blocks, so it now works for me.

[johnpawsonS1]

thank you - I'll give that a crack