Responsive Image Styles should not depend on a theme for its breakpoints

For context, this arose from 📌 Implementation of the initial Media Management Proposal Active .

For now, we decided to enable Olivero and rely on its breakpoints. We could still do that as an official decision but it might not be viable for the long term.

I looked at core's Breakpoint module and it's ironclad in its insistence that only modules and themes can define breakpoint files.

So I think that, to do this, we'll need to be able to define custom breakpoints stored in configuration.

I can think of two ways to do it:

1. We could create a new module (or find one) that lets you define custom breakpoints and have the recipe depend on and use that.
2. Maybe we could do the same thing with ECA, if ECA supports defining breakpoints. Since breakpoint definitions do have an alter hook, this should work in theory as long as ECA is able to intercept that hook.

TLDR: yes, a glue module or recipe to provide common aspect ratios and breakpoint combinations with generated responsive image styles not connected to any theme would be good

Fuller info:
I tried to think of this holistically for many possible site use cases, so I asked a designer who understands a bit about performance with images to look at a spin up of Drupal CMS responsive images for feedback:

- They liked the list of aspect ratios but would include 21:9 as a target
- Based on naming, they'd expect an XL size as they target 1980px for HD displays when they reuse content on full screen news and events walls and they often spot check key graphics at 4-5 sizes (supports sizes not being tied to a theme)
- Asked if all images got generated for all these styles as that freaked their design side out

After mentioning you can place a focal point on an image to influence resizing they breathed easier, but had a good side question as to whether you can tag an image as to what aspect ratios it can be recut. Different issue for later...

Then I showed them the default (blank) page for Responsive Image Styles on a new core site. First question "where's the list of aspect ratios to choose from?"

I asked a bit more and their expectations were to see a list of aspect ratios to select as allowable, as many of the graphical brochure sites often have a very much reduced set of art production targets -- 3:2 for call out boxes, 16:9 or 21:9 for heroes, square in stories. And they would want no others allowed to reduce issues that editors could cause in their design. They'd prefer a 'use this set of aspect ratios' then generate just those, but having a full set and removing those you don't want used was fine if it meant they didn't have to go create any themselves.

References for breakpoints is compiled elsewhere for us at https://blog.logrocket.com/css-breakpoints-responsive-design/ but for this, having a choice between bootstrap/tailwind/whatever vs just a xs sm md lg xl xxl whatever set makes sense -- making it a chose your own system widths could be nice and in which case an ECA setup for choosing or defining a set to generate against could be nice, but for expediency a set and go seems prudent for now

Searched around more, and maybe gluing a list and https://www.drupal.org/project/easy_responsive_images → together might help reduce work

I thought of a way to do this. It's slightly nuts.

We do need to provide some glue code, but why not package it up in the recipe itself, and use the Composer scaffolding plugin to move it to the right place where it will be discoverable?

In other words, we should have the following files:

recipes/drupal_cms_image/assets/drupal_cms_image.info.yml
recipes/drupal_cms_image/assets/drupal_cms_image.breakpoint.yml

Those two files comprise a tiny, minimalistic, yet complete theme, called drupal_cms_image.

Meanwhile, drupal_cms_image's composer.json tells the core scaffold plugin to move those files into themes/drupal_cms_image. The top-level composer.json is changed to allow drupal_cms_image to scaffold files. Then the recipe enables the (tiny, minimal!) theme, and all the image styles depend it, and...voilà. No more dependency on drupal_cms_olivero.

Responsive image styles provides its own 'Responsive image style' breakpoint set which has no breakpoints - so if the images in Drupal CMS could use sizes only, and not the picture element, that would be doable. See also 📌 Reponsive images should use sizes attribute Active .

@catch mostly that would work but we do have some art direction so it would not get us out of the dependency issue unless we make changes and if we did it would lock us out of being able to use the features.

#6 seems like a solid suggestion to me.

Thinking forward we could install contrib components to this type of theme so that any theme could include them from there or override them from their custom theme, so it's not the only use case for an installed but inactive theme.

drupal_cms_image theme might be useful as a self-contained thing or it could be drupal_cms_appropriately_named_middle_theme for other things (given that to provide the breakpoint no dependency on the image recipe is required).

@catch mostly that would work but we do have some art direction

How much is it possible for the art direction to actually work across arbitrary different themes though? This isn't a rhetorical question, I don't know how much it work work vs. not.

Those two files comprise a tiny, minimalistic, yet complete, theme called drupal_cms_image. It could maybe even be hidden (assuming the themes page supports that), so that it can't be inadvertently uninstalled.

Could this be an actual contrib module that themes can depend on?

Could this be an actual contrib module that themes can depend on?

We could do that, but I'm not sure the use case would justify the added overhead and infrastructure. Since the theme would contain zero runtime code, and would be updatable (via the scaffold plugin), I'm not entirely certain what the benefit of spinning up a module would be.

Wouldn't it be more robust to just use a theme project?

It would leave a little bit less to chance, but it's more stuff we have to maintain separately, for a very limited/specific use case. And it means that drupal_cms_image is a recipe that requires separate glue code, which isn't ideal. Keeping it all in one place is preferable.

Actually, I have an idea that might make us all happy: why don't we postpone this until Mediacurrent delivers the Drupal CMS design system which we're going to build our site templates on? As far as I know, the design system will be packaged as a theme, and we could either add the breakpoints to that, or adapt drupal_cms_image to use the breakpoints it defines (if any). Then we don't have to depend on Olivero, but we can instead depend on a theme that is squarely in our ecosystem, and we don't have to do Composer shenanigans.

How much is it possible for the art direction to actually work across arbitrary different themes though?

All of these image styles are opinionated and based on Olivero container sizes so the answer is that the art direction images will work as well as the others - with mixed results.

Why don't we postpone this until Mediacurrent delivers the Drupal CMS design system

We will have a different flavour of the same problem we have now: If you want to use some other theme then you're stuck.

I am hopeful that we can make some radical advances with the media system so I see this as a ring fenced problem for anyone using today's Drupal CMS.

Implemented #6 in an MR, but now that I think about it, I'm not entirely sure we want to do it this way, precisely because it requires changes in the top-level composer.json. That means the drupal_cms_image recipe, which is a foundational recipe, is no longer compatible with anything except drupal/cms projects, or projects that have specially been configured to handle it.

So that brings yet another idea to mind: what if we made the recipe depend on drupal_cms_olivero, and moved the breakpoints into that?

I understand that this doesn't seem to solve the problem on its face, but hear me out. Drupal CMS Olivero, thus far, only exists as a shim until we have Experience Builder and site templates. We don't intend to support it forever...at least, not in its current form.

But what if we moved the breakpoints into that, and made drupal_cms_image depend on it...and then, rather than completely drop Drupal CMS Olivero when we have XB, we instead just made a 2.x branch of it that only contains the breakpoints? The tricky thing here is that it would retain the name "olivero", but if it's a minimal, hidden theme that only contains breakpoints, is that really a big problem?

This is effectively the same solution as moving the breakpoints into their own actual contrib project, except we'd just reuse an existing contrib project that Drupal CMS projects are already using, which saves us some overhead (at the cost of a confusing legacy naming scheme, but maybe there are ways to work around that too).

Thoughts?

@tonypaulbarker

All of these image styles are opinionated and based on Olivero container sizes so the answer is that the art direction images will work as well as the others - with mixed results.

That makes me think it would be worth trying less opinionated image styles that rely on sizes - so that they work better across different themes, even if they're less customized for drupal_cms_olivero.

But what if we moved the breakpoints into that, and made drupal_cms_image depend on it...and then, rather than completely drop Drupal CMS Olivero when we have XB, we instead just made a 2.x branch of it that only contains the breakpoints?

I don't see how this would help because the new themes based on Experience Builder won't have the same breakpoints as Olivero.

Note that there is ✨ Add automated image optimization to image component Active , which I have no idea whether it's an XB blocker and it doesn't have a working MR yet, but the current vague state of that MR would only use sizes and not picture. e.g. #3515646-22: Add automated image optimization → but it's not clear whether that's by design or an oversight yet.

That makes me think it would be worth trying less opinionated image styles that rely on sizes - so that they work better across different themes, even if they're less customized for drupal_cms_olivero.

Using sizes over breakpoints doesn't provide the missing key piece of information required to perform optimised calculations: the container sizes in the theme CSS are unknown.