Demo Site: Add createImageSizes helper

[stekalt]

Description

The function createImageSizes is implemented to generate the sizes attribute string for Next.js images based on the breakpoints in the project. The sizes attribute is used by the browser to decide which image from the srcset to load depending on the viewport width. If not set, it defaults to 100vw.

Acceptance criteria

• I have verified if my change requires an example
• I have verified if my change requires a changeset
• I have verified if my change requires screenshots/screencasts

Screenshots/screencasts

Bildschirmaufnahme.2025-04-24.um.15.25.08.mov

Further information

• Task: https://vivid-planet.atlassian.net/browse/COM-1715
• https://nextjs.org/docs/pages/api-reference/components/image#sizes

[nsams]

@johnnyomair
I'm not sure a "fake" xs breakpoint (that is not a breakpoint) is a good idea. Why not how it was originally implemented, using a second argument?

[johnnyomair]

My rationale for this was that the size for the mobile viewport is more visible. I think this

<DamImageBlock sizes={createImageSizes({ xs: "100vw", md: "50vw" }) />

is more understandable than

<DamImageBlock sizes={createImageSizes({ md: "50vw" }, "100vw") />

or even

<DamImageBlock sizes={createImageSizes({ md: "50vw" }) />

(default 100vw).

I'm fine with changing it back though. I'd drop the default value because devs then need to think about the size for mobile (might not be 100vw all the time).

[nsams]

yes, the default value can cause issues, and un-named arguments are hard to read.

Other alternatives:

simply rename xs to default (because that's what it is):
<DamImageBlock sizes={createImageSizes({ default: "100vw", md: "50vw" }) />

or, move the arguments into an options object:
<DamImageBlock sizes={createImageSizes({ default: "100vw", breakpoints: { md: "50vw" } }) />

[johnnyomair]

Both alternatives are okay for me. @stekalt what do you think? Which one would you prefer to use on a day-to-day basis?

[stekalt]

I liked the approach using xs – for me, it made it clear that the breakpoints follow the min-width principle (even if xs is just a placeholder for the default case).

Out of the alternatives I think the options object provides a clearer separation between the default value and the breakpoints, but in working with it I would prefer the first alternative, as it is simply shorter to write:

<DamImageBlock sizes={createImageSizes({ default: "100vw", md: "50vw" }) />

[nsams]

it made it clear that the breakpoints follow the min-width principle

strictly speaking, this xs is not a breakpoint and does not have a min-width.

Like in the normal styling, you write mobile-first (=default) styles and on top of that min-width breakpoints.

You should even remove the (min-width: 0px), according to mdn:

1. A media condition This must be omitted for the last item in the list.

[johnnyomair]

strictly speaking, this xs is not a breakpoint and does not have a min-width.

UX calls mobile XS and uses this in their Figma designs though.

We could change the argument to viewportWidths, then xs would be valid.

[stekalt]

Like in the normal styling, you write mobile-first (=default) styles and on top of that min-width breakpoints.

Yes we do, but most sizes-examples (also on mdn) are using the max-width approach. This is why I pointed out the min-width principle in the argumentation of my opinion.

You should even remove the (min-width: 0px), according to mdn:

I removed the (min-width: 0px) from the default item.

[nsams]

If you think xs makes more sense than default, it should be fine for me 👍

[johnnyomair]

@stekalt please use the naming you prefer – both @nsams and I won't use it in projects very often, if ever 😁