You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
At the time of writing the image component uses the focus parameter only for passing it to the Storyblok API which works well for images with dimensions that are not relative to their container.
So imagine you have lets say a stage module which is width: 100vw; and height: 80vh; and the image should fill the whole area (similar to next/images layout="fill"):
Depending on the aspect ratio of the original image the Storyblok API tries to shift image to the provided focus as good as it can, but then the Images CSS applies object-position: center center which can lead to a scenario where the focus point is not even in the visible area of the component.
Describe the solution you'd like
What would you think about passing the focus coordinates down to the CSS to make sure the focus point/area is always visible?
Two things are to be considered:
Storyblok treats focus as area described by two pairs of coordinates while object-position expects a point which would make calculating the center of the focus area necessary (e.g. by <coordinateA> + <coordinateB> / 2)
Shifting the image using object-position by a percentage value can lead to moving it too far and create undesired whitespace so the amount of translation has to be clamped:
Describe alternatives you've considered
For now we tried to patch the Image component from the outside to reflect the desired behavior, but this is not really a sustainable solution…
Thanks for the well-written issue! I think this is indeed something that this library needs, actually when implementing focus points I was considering doing it like this but didn't know clamp was a thing.
Interestingly when testing I found that the focus point that storyblok gives back is actually two pairs of coordinates that are right next to eachother (1px difference).
I'll try to implement the object-fit behaviour you described.
@BJvdA thank you for looking into this!
We discovered the same and our assumption is that with the two types of predefined image blocks led to this focus API:
"Image (old)" has an image editor with predefined aspect ratios where I'd expect focus being the selected area
"Media" interface provides only a point where the focus area is 1x1 px in size to approximate point
clamp is a rather new feature where depending on the targeted browsers a fallback using the min / max equivalent: max(MIN, min(VAL, MAX)) might extend support.
Is your feature request related to a problem? Please describe.
At the time of writing the image component uses the
focus
parameter only for passing it to the Storyblok API which works well for images with dimensions that are not relative to their container.So imagine you have lets say a stage module which is
width: 100vw;
andheight: 80vh;
and the image should fill the whole area (similar tonext/image
slayout="fill"
):Depending on the aspect ratio of the original image the Storyblok API tries to shift image to the provided focus as good as it can, but then the
Image
s CSS appliesobject-position: center center
which can lead to a scenario where the focus point is not even in the visible area of the component.Describe the solution you'd like
What would you think about passing the
focus
coordinates down to the CSS to make sure the focus point/area is always visible?Two things are to be considered:
focus
as area described by two pairs of coordinates whileobject-position
expects a point which would make calculating the center of the focus area necessary (e.g. by<coordinateA> + <coordinateB> / 2
)object-position
by a percentage value can lead to moving it too far and create undesired whitespace so the amount of translation has to be clamped:Describe alternatives you've considered
For now we tried to patch the
Image
component from the outside to reflect the desired behavior, but this is not really a sustainable solution…Let me know what you think, happy to discuss the details or helping with the implementation :)
/cc @martinjuhasz
The text was updated successfully, but these errors were encountered: