Boot: Adjust specificity of the image reset styles so components can size their own images

[juanfra]

What?

Wraps the img reset in :where() so it stops overriding components that set their own image sizes.

Why?

Found this in the font library. On "Appearance > Fonts" the cards come out at different heights creating some sort of jump when the font list is loaded, while the exact same list in the font library modal is consistent.

While trying to find why, I've found that the the reset is nested, so it compiles to .boot-layout-container .boot-layout img, one tag selector more specific than the font library's .font-library__font-card .font-library__font-variant_demo-image. height: auto wins, the previews render at their natural ratio instead of the 24px they're given (I measured images from 22 to 28px), and each row ends up as tall as its image.

The rule itself is right, an image of unknown size shouldn't blow out the layout. But the problem is that it's beating the components trying to set sizes for their images.

I can imagine this can become more evident when we start seeing more of these pages, with Dataviews (found a few places where it would happen the same).

I asked about this in the PR where the reset was added, in case the specificity was serving a specific purpose. No reply yet, so opening this in the meantime, happy to close it if it turns out to be intentional.

How?

:where() matches exactly the same images but contributes no specificity, so the reset still catches anything without a more specific rule and loses to anything with one. Removed the .boot-layout-container part since it was only there due to nesting.

Testing Instructions

1. Open Appearance > Fonts.
2. Go to "Install fonts" (authorize google if necessary)
3. Navigate the different pages, and confirm the images on .font-library__font-card .font-library__font-variant_demo-image have a computed height of 24px.

Screenshots or screencast

After the fix

boot-img-reset.mp4

Before the fix (see the jump while navigating)

boot-height-auto-before.mp4

[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.

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: juanfra <juanfra@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>
Co-authored-by: simison <simison@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]

Size Change: +4 B (0%)

Total Size: 7.76 MB

📦 View Changed

Filename	Size	Change
build/modules/boot/index.min.js	49.4 kB	+4 B (+0.01%)

_{compressed-size-action}

[aduth]

How will this be impacted or how should we think of this in relation to the SCSS modules conversion in #80359 ? (cc @simison)

[juanfra]

Thanks for checking this out, and pointing me to that PR @aduth! I had a look at it and the CSS touched here is migrated pretty much as is, so it looks like this would still be relevant there. .layout img is still more specific than the components, so it keeps applying to any image rendered inside the layout.

The class name changes with the migration though, so over there it'd be something like

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

From what I tested the class gets hashed inside :where(), and the fix still works well.

If we all agree the fix makes sense, we could either land this and carry it over, or close this one directly and address it in #80359. cc @simison

[simison]

Fine to merge this as a bug fix first; no need to wait! :-) (I'd also update the label from enhancement to bug)

Worth also including in WP 7.1?

[aduth]

This makes sense 👍 Though I do wonder if we need this rule at all, or if it's reasonable to expect that individual components are responsible for making sure that images are constrained rather than it being a page-level concern. I think the updated selector is reasonable if we want this to be page-wide, as its specificity "3-column score" would be 001 and most overrides should be at least 010 or more.

[juanfra]

Thanks! Given it's fixing a bug in the fonts page, I'd say it's worth including in 7.1.

Though I do wonder if we need this rule at all, or if it's reasonable to expect that individual components are responsible for making sure that images are constrained rather than it being a page-level concern.

I also thought about removing it completely. But then I thought the layout can also end up rendering things we don't control, plugins can register their own routes and content into these pages. Having a default there still feels useful to me and sort of a safety net for any clients using this.

[github-actions]

I just cherry-picked this PR to the wp/7.1 branch to get it included in the next release: 6a026c9