RFC: Picture Tag - CldSource

[colbyfayock]

The HTML picture tag gives developers more control over how their images display, including art direction and using media queries to define different versions of images like light mode and dark mode.

This contrasts to the image tag's sizes and srcet, which allow you to specify different sizes of a single image.

Part of Cloudinary's toolset is being able to transform images on-the-fly, where coupled with the picture tag, can result in an easy way to provide different versions of images based on a single source.

Related Issue: #42

Proposal

The picture tag composition is defined by three separate tags: picture, source, and img.

<picture> wraps a series of <source> tags and a single <img> tag to allow configuration of what image you want to display and when.

In creating a solution, we want to maintain the flexibility and patterns of the native picture tag while exposing the advanced capabilities in an intuitive way, leaving the option of replicating the existing composition the ideal solution.

Basic Usage

 <picture>
    <CldSource
        src="<Lg Public ID>"
        width
        height
        media="(min-width: <Lg Size>)"
    />
    <CldSource
        src="<Md Public ID>"
        width
        height
        media="(min-width: <Md Size>)"
    />
    <CldImage
        src="<Default Public ID>"
        width
        height
        alt=""
    />
</picture>

The CldSource components would use the Next.js getImageProps function to assists with srcset generation.

The CldSource component would be the addition, where given the <picture> tag wouldn't have any function, at this time, it might not make sense to expose a CldPicture tag.

Alternative Options

With a little exploration on potential options for supporting this...

Unpic handles this with Source components, but not a Picture component: https://unpic.pics/blog/introducing-unpic-picture-tags/

While it feels slightly odd to not have a <CldPicture> component, given it wouldn't have any function, it doesn't make sense to create it.

Nuxt has a NuxtPicture, but my understanding is it's really meant for formats, and the syntax is encapsulated into the main component, not sources like Unpic: https://image.nuxt.com/usage/nuxt-picture

Astro similarly does what NuxtPicture does, really relying on it only for formats: https://docs.astro.build/en/guides/images/#picture-

Next.js relies on getImageProps, which isn't really first class picture support: https://nextjs.org/docs/app/api-reference/components/image#getimageprops

While there is some merit to potentially having a <CldPicture tag with an array of options as a sources prop for instance, I think following along with the native <picture> composition will be the most intuitive and practical from an education perspective and "embracing the web".

[Baroshem]

Hey there, great RFC!

I have some comments for it. Also related issue in Nuxt Cloudinary repo nuxt-modules/cloudinary#160

I would go with the solution you mentioned at the end - a native picture tag. And (my honest opinion) same for the native source component. Having a component that's only responsibility is to be a wrapper around a native HTML tag seems like an overkill to me.

In Nuxt Image example, Image component is mostly used in comparison to Picture. The Picture seems like a legacy feature that needs to be mainatined because everyone seems to be using image.

Maybe a better solution would be a docs FAQ / Guide about using Picture and Source tags (native solutions) to achieve this? This is what I am using in Nuxt Security for example -> https://nuxt-security.vercel.app/documentation/advanced/strict-csp

As my friend used to say -> the best code is the one that you have not writted (you don't need to maintain it, it does not have bugs, etc :D )

So in summary, my recommendation would be to write a docs section for each of the supported frameworks by CLD (Next, Nuxt, Astro, Svelte) about using native picture and source tags alongside CldImage component to achieve images in correct format, mode, size, etc.

WDYT? :)

[colbyfayock]

the issue with this logic though is CldSource is not just a wrapper around source. it would be:

• generating a src based on public ID, same API as CldImage
• thus allowing the same API that CldImage exposes, primarily transformations
• generating a srcset

<CldSource src= media=

feels better than

<picture src={getCldImageUrl(...)} srcset={exposedGenerateSrcSetFunction(...)) media=

particularly when considering the additional transformation complexity

for example:

 <picture>
    <CldSource
        src="<Lg Public ID>"
        width="800"  //different size
        height="600"  //different size
        crop="fil"
        media="(min-width: <Lg Size>)"
    />
    <CldSource
        src="<Md Public ID>"
        width="1200" //different size
        height="500" //different size
        crop="fil"
        media="(min-width: <Md Size>)"
    />
    <CldImage
        src="<Default Public ID>"
        width="400
        height="400
        crop="fill"
        alt=""
    />
</picture>

[Baroshem]

I see, then it makes total sense. Thanks for clarification :)

Should I start implementing it in the Nuxt CLD or would you like to wait for additional input from Ghost?

[Baroshem]

@colbyfayock

Maybe an implementation from Astro could be helpful here as well :)

https://x.com/astrodotbuild/status/1838495967252775291

[colbyfayock]

yeah! saw that one. it looks specifically geared towards variations resolutions however as opposed to being able to support the full capabilities of the native elements