Here we are again. Now it’s my turn to create a simpler way to define crop variants (and later image renderings) for #typo3

To add crop variants, create a class that implements an interface and return a definition defined in PHP objects.

TCA will be created based on the existence of these classes, implementing a special interface. no other config required, dependency injection auto wiring for the win.

Anybody did something like that before?
If not, anybody interested in this?

(more to come)

And of course, defining crop variants is only half of the fun.
Here is an example of what I have working now, from defining crop variants in the same place as defining image variants to render responsive images from crop variants but also with different sizes

https://gist.github.com/helhum/58cc80edac277ae9819a26ef7aaaacd0

This strategy enables full flexibility with manageable overhead. Knowledge of “srcset”, “sizes” and “sources” in “picture” tag is currently mandatory to understand what is going on.

#typo3

Responsive image backend definition and frontend rendering with helhum/typo3-top-image

Responsive image backend definition and frontend rendering with helhum/typo3-top-image - ANewsImageVariantExample.php

Gist
@helhum Looks good so far. However, I think that an ImageVariant should be valid without appliesTo to be able to define a full responsive image configuration (be+fe) and apply it to multiple database fields afterwards.

@s2b I kind of disagree. At least for the use cases I have in mind.

CropVariants are scoped to a specific content type. Once you start using art direction for some picture sources and want to use crop variants for that, this source at least is bound to a content type as well.

@helhum My use case would be a generic TeaserCard component in the frontend that can be used by multiple content types to display a teaser grid. In this example, you would like to specify crop variants as well as the image rendering (art direction etc) once and re-use it in news, products, pages…

Another topic we should probably discuss is context, for example if an element is inside a grid component. This could influence sizes as well as media queries.

@s2b got it.
Nevertheless, once you want to use crop variants for art direction, you must connect a source to a crop variant.

how to declare that and make it possible to validate configuration to avoid mistakes.

e.g. if the image variant source only references the crop variant id, how can we ensure the image reference from a content type actually has s crop variant with that id defined and that it is a crop variant in a form that is expected in the image variant source?

@s2b by connecting image variant to crop variants in a content definition, I can ensure that.

But "appliesTo" could be an array of content types. Would that fulfil your requirements?

@s2b the context thing is tricky. Conceptually a different context means it is a different image variant. Because in a different context, the required image sizes and the required art direction can be entirely different for a "generic card component" arbitrary image variants can be defined, so this is covered. question is, if there is a reasonable simplification option when defining those, or whether de- duplication is onto users. (it's php code after all)
@helhum This may be true for media queries, but for sizes it "should" be doable automatically, since you can re-calculate everything based on the column width. I think that this is something that has been done in the bootstrap_package, might be worth a look.
@s2b Well, then how deal with definitions that have media queries? My point is, if such image variants can't be migrated automatically, then the concept must either abstain from art direction with media queries or automatic recalculation. Since I want and need art direction, I did not put any effort into automatic recalculation for different (size) contexts. I might be missing sth though.
@s2b BS Package (version I tested) uses art direction exclusively, with a min-width media query. Maybe the min-width is then auto adjusted when used in a column, have not tested that. It's a clean and working concept. I does not meet my requirements though, because editorial work for images is a pain in the butt, as cropping must be applied 6 times (times every translation), even when all breakpoints should have the same cropping area.