It looks like it's because only ViewGrid has the previewSize prop.

I guess something like this would work:

	const columnNumberSetting =
		'grid' === view.type ? view.layout?.previewSize || 0 : 0;

Where do these calculations come from?
What happens for grid items other than images?
Why can't we use a resize observer, and then calculate sizes from that?

Where do these calculations come from?

The image widths at each breakpoint are based on the layout grid CSS and take the UI into account as mentioned in the comments above.

What happens for grid items other than images?

Nothing 😄 this functionality only exists for img tags.

Why can't we use a resize observer, and then calculate sizes from that?

In principle I think it's better to avoid throwing a ton of JS at a problem that's been solved in native HTML already. Also, if we have to wait for the resize observer (which means waiting for layout to happen on screen) it's too late for the browser to fetch the right image at that point - either it has to load a backup image first (adding unnecessary downloads) or it'll be slow to appear on screen which is also not an optimal experience.

Thanks for looking into this.

One advantage of using this approach instead of passing the view object is that we can use information that may be private to the view to calculate the size.

One downside is that we need to figure out is how to support any kind of media field (or the most common ones). That I know of, I think we've used images and iframes as media fields. Perhaps video would be useful as well, though I'm not convinced. We'd need to understand what each of them needs, so we can support them.

To discriminate among the different types of media fields, we need to evolve the field types available. For example, introducing image, iframe, etc. field types. That could signal which props to use.

One downside is that we need to figure out is how to support any kind of media field (or the most common ones). That I know of, I think we've used images and iframes as media fields. Perhaps video would be useful as well, though I'm not convinced. We'd need to understand what each of them needs, so we can support them.

Afaik the HTML spec only provides tools for serving images responsively, so the "sizes" attribute won't be of use to other media types. I think it's fine to implement this behaviour only for images though. Other media fields can just ignore the attribute.

Perhaps video would be useful as well, though I'm not convinced. We'd need to understand what each of them needs, so we can support them.

I was thinking about this for the admin redesign, and was wondering about the possibility of a single, generic media props object. Example:

interface MediaFieldProps {
  sizes?: string; // for images
  aspectRatio?: string; // for videos, iframes
  maxWidth?: string | number; // for any media type
  maxHeight?: string | number;
  objectFit?: 'cover' | 'contain' | 'fill'; // for any media type
}

I think it'd scale better for different media types, e.g., can be expanded without breaking changes.

Then the media field render func can destructure only the props it needs.

It's also self-documenting through its TS interface

Yeah, I think the idea of making it more generic is a good one and it'll be more flexible. Maybe it could be called mediaAppearance.

I also personally prefer more specific types like VideoAppearance / ImageAppearance / BlockPreviewAppearance, as then the user can't specify an invalid combination of props, but this discussion has also come up on other PRs and there are mixed opinions about it.

Yes, that could work!

It is worth adding a comment here as an explainer? I see the other types are documented.

Perhaps video would be useful as well, though I'm not convinced. We'd need to understand what each of them needs, so we can support them.

I was thinking about this for the admin redesign, and was wondering about the possibility of a single, generic media props object. Example:

interface MediaFieldProps {
  sizes?: string; // for images
  aspectRatio?: string; // for videos, iframes
  maxWidth?: string | number; // for any media type
  maxHeight?: string | number;
  objectFit?: 'cover' | 'contain' | 'fill'; // for any media type
}

I think it'd scale better for different media types, e.g., can be expanded without breaking changes.

Then the media field render func can destructure only the props it needs.

It's also self-documenting through its TS interface

I think this is creating a regression in the default width of the images.

The default value of usedPreviewSize is undefined, but if you change it using the slider, you can't get back to the default state.

I guess it's no big deal, but it's odd not to be able to return to the original width as loaded.

Hmm yeah I'll look into it.
I guess we could try changing usedPreviewSize to work with min-widths instead of number of columns, or we could just unset the value if it equates to default.

I guess we could try changing usedPreviewSize to work with min-widths instead of number of columns

I just tried this and although it drastically simplifies the code I don't much like the experience of the un-stepped range control, because results feel a bit arbitrary. I'll play with this a bit further to see if I can keep the columns logic while using image widths in the background.

Ok this is now fixed and I've been able to retain most of the drastic simplification 😄

I believe that containerRef needs to be on this wrapper because its use is related to the scrolling behaviour of the wrapper.

The fact that this is the scrollable container for the layout is what makes it unsuitable to use with the resizeObserver, because the presence of a scrollbar will throw off the size of that actual layout. This is why I'm moving resizeObserverRef to context so it can be used directly in the grid layout.

I'm now wondering whether it's really worth switching the value of sizes for different grid sizes, because it means that changing the grid size in the UI can download a whole new set of images 😅

We could just go with a fixed maximum size of 900px here, because with grid-template-columns using auto-fill, even the biggest grid size on a really big screen won't go over that.

Good rationale 👍

As mentioned above, we need this ref here so DataViews can set the containerWidth in its context to the actual grid width, instead of the width of its wrapper that may or may not include scrollbars.

(Also I changed this to use a div instead of Grid so I could pass it the ref)

This tries to emulate the current behaviour, where setting the grid at its biggest size on a small container and resizing the window preserves the biggest size setting, even when more size options appear. This is probably not too important a point in user-facing terms though, because people don't go around resizing windows that much 😄

I haven't changed this (only moved it around in the file) but this padding logic could probably be improved to be fully independent of sidebar width (which is specific to the site editor) and gutenberg media queries breakpoints.

To be honest for me, right now, this is way too advanced/complex for a small gain. I'd rather pass the "view" object here as a "temporary API". I can't imagine this "mediaAppearance" API sticking forever either.

I would like to understand better what other kind of "rendering config" we need per field before having a more formal/complex API.

But now, that I think about itrender is also called on DataForm which doesn't have the concept of "view". So my question here, what would be the simplest common denominator thing we could pass here that allow us to achieve the use-case without complexity. For instance I want to avoid resize observers as much as possible personally, can we instead having

config={ config }

with the following type

interface config {
   size?: "small" | "medium" | "large"
}

and each view could decide to pass the right "size" as needed.

• For instance the "media" field in table would always pass "small"
• The "media" field in grid would always pass "medium"
• DataForm would probably pass "small" too

I realize this is close to what you're proposing but there are two changes:

• Simpler because there's no need for resize observers
• More generic because it's not just about "media", later we might want other kind of "rendering config" for fields.

Simpler because there's no need for resize observers

The simpler config won't fix the need for resize observer, because that's already being used to build the grid layout. I just moved it to a different element because it isn't giving accurate numbers in its current location (the layout wrapper).

I did simplify the grid logic as much as I could so it's less dependent on breakpoints, but unfortunately we do still need to know the container size in order to display the right options in the preview size picker.

interface config {
size?: "small" | "medium" | "large"
}

small, medium, large won't really work here because the responsive image logic requires actual numeric values for its sizes attribute. The layout is responsible for setting the image size, so we should get that size from it. Otherwise we're putting the burden on the consumer to figure out what those sizes mean in px and produce a suitable number themselves, which might break if we ever change the layout.

We can call the object something more generic than mediaAppearance; it could be config or something else. But we do need those numeric widths for the responsive images to work.

I've updated to a generic config with a size property that takes a string with the size in px.

Given the usage we expect for this prop, I'd probably call it config.sizes, like the img attribute name — even if for now we just want to pass the target source size.

Updated!

In the Edit function for the FeaturedImage field we could also use this technique to prevent the full image being requested for such small needs 24px (note the quick edit button for media):

Oh, I totally missed the quick edit experiment! I think I'd rather address that in a follow-up though, because it's not clear what the best approach might be.

Arguably, we could just pass in the thumbnail URL directly instead of the full image, because FeaturedImageEdit defines its own image size. Whether we do that or use srcset and sizes, there's a side-effect we need to be aware of: the image will no longer show at its true aspect ratio, but in a square crop.

An alternative that preserves the aspect ratio is to use the medium size URL if it exists and default to full if not.

I've tried this on a large screen (2560px), way past the max breakpoint (1636). With these changes, the images aren't that big and the space looks more balanced. Of course, I'm not designer, so others may have different thoughts 😅

In any case, I like that the mapping from a minimum breakpoint to a minimum image size is clearer and easier to tweak.

	Before	After
Min width (6 images before, 8 after)
Max width (3 images before, 5 after)

As a gift to our future selves, would you expand why this is the maximum width an image can achieve in the grid?

Sure!