Reduce the number of display modes available on embedded images

To remove these, it's a case of simply deleting the option from the yaml file filter.format.content_format.yml in the content type base recipe.

Now that we have restricted the content width to narrow, 'large' image widths render close to the size of 'medium' image widths. I suggest that we remove 'large' options.

I'm trying to think of what might not make sense and it could be 'Small, 'Medium' and 'Large' labels, we could add view modes named 'Small (uncropped)' and 'Medium (uncropped)' instead of using view modes that give us labels 'Small' and 'Medium' (we shouldn't simply rename those, because video uses them too and can't be cropped).

For deciding which aspect ratios we may want to remove, these are options offered from the discovery and proposal and we already removed 2:3 and 3:2. The UI here is not ideal and we have to find a balance between the length of this list with the frustration editors might feel when they can't present images as they would like.

@tonypaulbarker yes, sorry I started to actually do this and then got distracted. I initially wasn't clear on what small/medium/large did but then figured out they are the original image just resized which is quite useful.

I also noticed that medium and large are more similar now, but not sure about removing large as this would be the only way to get an image that is full width, right?

One option could be to make medium a little larger and then we could get rid of 30% of the options in this list. We don’t need to make wholesale changes to achieve that because we can leave large in place but not turn it on for ckeditor.

Look forward to your thoughts.

If these are responsive, does there actually need to be a large/medium/small? I would think the responsive image styles would handle that, and only the aspect ratio would be necessary to provide as an option then.

Yes, when embedding images it is common to want to choose the size. You may want the image to fill the content area (large) or you may want it to be centred with space on either side (medium) or you may want it to float left or right around the content (small). Although these distinctions only apply to larger screens, it's a definite need that responsive image styles don't help with.

One option could be to make medium a little larger and then we could get rid of 30% of the options in this list.

Good idea @tonypaulbarker! Let's wait until the width fix is committed, there are so many related things in progress right now, it's starting to confuse me...

I'm assuming by "the width fix", you mean 📌 Implement full node content widths to match designs Active , which I just committed. So I'm thinking this is unblocked?

How about using styles on drupal-media?

In this issue, there's a post on how to add a style dropdown for embedded media items, which seems like a solution to the issue:
https://www.drupal.org/project/drupal/issues/3117172#comment-15720466 ✨ [upstream] Allow CKEditor styles for Postponed

Instead of having one select with a bunch of view modes that represent a combination of things like aspect ratio and size, we could have different options to select them individually.

Yes #9 is more the sort of thing I'd expect - e.g. it's more about the context of the embed itself than the actual rendering of the media entity. Unless they're also intended for use outside ckeditor5 but @pameela's comment suggests not.

@mortona2k @catch I agree #9 sounds well worth exploring to improve this particular situation. CKEditor is not the only context we need to consider but it’s an important one, particularly in version 1.

A possible drawback I can see is that it could make it more difficult for non-technical users to customise the options but on the other hand, it could make the out of the box experience better.

Could these requirements be met?

A dropdown lists the aspect ratio options
A separate dropdown lists the size options
These two selections in combination map to the view modes.
The editor sees live feedback in CKEditor on changing the selection.

Adding two select lists works fine in the yaml file currently.

I think the linked issue would make the options editable in the UI.

I have been thinking about variations of embeds that people typically want.

Core has Image and Remote video.

For images, we often want to scale the size of an image, but could also use crop or focal point so the final image might be a different resolution.

These options could selected in different places, on media upload, or on display in ckeditor.

We also could have responsive images defined, which might conflict with these dropdowns. We'd want some kind of smart configuration that selects the appropriate responsive image for the settings chosen on the embed.

Remote video is oembed, so dimensions can come from the max height/width in the display formatter, or defined by the provider.

In some cases when embedding a video, we want to preserve the aspect ratio when it scales.

Other times, we may want to display it less than full width. Or want to expand to an area and use letterboxing if the ratio is off.

It would be great to have a proof of concept of the 'styles' approach and I will update the roadmap to look at it.

Since we can make a quick improvement to reduce the list for the current implementation I am looking at #7.

I looked to see if there's an exiting contrib module, couldn't find one, but did find this issue which suggests the functionality is maybe supported (if not necessarily with the desired UX) already? #2911527: Allow dashes in Styles dropdown's element names →

#7 is ready for review on the MR

A big caveat to what I said in #12.

The idea to use a styles dropdown instead of view modes doesn't make sense for images, since we want to use different image styles configured in the view modes.

The style dropdown could make sense for embedded media that is rendered in an iframe. Setting height/width as attributes, or aspect ratio, will work at different resolutions, but with images we'd just be changing css and not the actual size of the loaded image.

The idea to use a styles dropdown instead of view modes doesn't make sense for images, since we want to use different image styles configured in the view modes.

@mortona2k I was assuming both. The style would set alignment and max-width in CSS. Then the image style sets the aspect ratio.

Browsers should pick the correct responsive image style based on the width of the container based on the sizes attribute and source size values. We should double check that the responsive image setup actually works for that case (and not just at unconstrained width), but if it doesn't that's fixable in either the recipe or core's responsive image support (or a bit of both).

Marking as Needs Work based on the comments in #18

As stated in #17, resizing in CSS doesn't impact the image files that we load. We do want to have better tools at our disposal but I would like to conclude that discussion on this thread given that at the current time we don't have a workable option for those enhancements in scope of this particular issue.

Please review and test the code for #7 on the MR, which is ready to ship or adjust if we like the direction of those changes and should be a tangible improvement for editors in the earliest versions of Drupal CMS.

Sending back to 'Needs review'.

This unfortunately missed the feature freeze deadline (Friday, Jan. 10) so I don't know if it can be in the 1.0.0 release. Let's ask the product owner. :)

It can definitely be in the 1.1.0 release, though, which is currently lined up for February.

I'm OK with this change if you are @phenaproxima, I don't think I can argue that is a bug specifically, but it's certainly a minor UX improvement and reducing the available options does not seem like a feature.

Added an 'After' screenshot to the IS so the change is clear.

It's your call ultimately, but ideally we'd stick the current freeze since we're trying to lock down stability in the final couple of days before we launch.

I have no particular objection to landing it in our first patch release (1.0.1), though.

Totally fine with me.

Opened 📌 Reponsive images should use sizes attribute Active

Merged into 1.x and cherry-picked to 1.0.x as a minor quality of life improvement that we were aiming for in 1.0.0 anyway, but it missed the deadline by a few hours. We won't make too many exceptions like this, but I think in these circumstances it's probably fine.

This MR changes a lot of image style config entities. I think we should set precedent to document these changes with a Change record.

That's a great idea. Setting back to NW for that.