Enhancement Proposal: podcast:images

[nathangathright]

While the current podcast:images spec has few supporters and several detractors, its fundamental problem is that it’ll never serve its intended purpose without a critical mass of adoption. Thus, there is a chicken and egg problem: what’s the point of generating multiple image sources if apps won’t display them, and what’s the point if only a handful of podcasts generate them?

Well-written tags should provide marginal utility even without widespread adoption, and in fact, that’s their only chance of finding any traction in an open ecosystem. Instead of deprecating it, a few tweaks could deprioritize the bandwidth-saving benefit of the tag and open up a path to make this tag viable for new use cases.

Count: Multiple

Like the podcast:transcript tag, feeds should have the option to provide multiple image formats per item, and apps could select the best available one that suits their needs. For instance, if a show has animated video artwork, apps could prioritize that and, if absent, fall back to a static asset.

Attributes

• alt (optional): A clear and concise text replacement for the image’s content.
• aspect-ratio (optional): A ratio value such as 1/1, 16/9, 4/1 following the equivalent CSS syntax. This allows podcasters to provide multiple art directions for the same media.
• purpose (optional): An unordered set of case-insensative, space-separated tokens following the equivalent W3C syntax. This value should not exceed 128 characters. This allows podcasters to indicate the suggested uses of this media.
• src (required): The URL to the media you want to embed.
• srcset (optional): One or more strings separated by commas, containing URLs to media and their intrinsic width in pixels, following the equivalent HTML syntax. This allows podcasters to provide multiple resolutions of the same media.
• type (optional): Mime type of the media such as image/jpeg or video/mp4.

Purpose Tokens

The purpose attribute gives podcasters the flexibility to indicate how specific images should be used by podcast apps and other platforms. This attribute accepts a space-separated list of tokens, where each token corresponds to a potential use case or context. While podcast apps may choose whether to honor these tokens, they allow podcasters to signal intent for how their images should be utilized across different platforms and contexts.

Anyone may define a token and its requirements. For instance, an app might define a token like truefans/hero to specify an image that fits their hero banner layout, providing guidelines for aspect ratios, resolution, safe areas, or text presence. A podcaster following these guidelines would include the truefans/hero token in the purpose attribute for any media following those guidelines. Here are some suggestions for generic tokens that multiple apps might adopt:

Token	Guidelines	Prior Art
artwork	Recommended for representing the show/episode. Should contain your show name and key art.	Apple’s show artwork
social	Recommended for social preview images. Should contain a landscape version of your artwork.	Meta’s OG:image
canvas	Recommended for immersive Now Playing screens. Should contain your artwork and expect to be overlaid with UI elements.	Apple’s Full Page Show Art Spotify’s Canvas
cover	Recommended for hero to complement your artwork	YouTube’s channel banner
publisher	Recommended for publisher logos. Should be legible at small sizes.	Apple’s Channel Icon

Examples

Using alt to describe the image

<podcast:images
  alt="An antenna emanating signal waves"
  src="https://example.com/images/ep1/pci_square-massive.jpg"
/>

Using type to provide multiple file types of a single asset

<podcast:images
  type="image/jpeg"
  src="https://example.com/images/ep1/pci_square-massive.jpg"
/>
<podcast:images
  type="video/mp4"
  src="https://example.com/images/ep1/pci_square-massive.mp4"
/>

Using aspect-ratio

<podcast:images
  aspect-ratio="1/1"
  src="https://example.com/images/ep1/pci_square.jpg"
/>
<podcast:images
  aspect-ratio="16/9"
  src="https://example.com/images/ep1/pci_landscape.jpg"
/>
<podcast:images
  aspect-ratio="9/16"
  src="https://example.com/images/ep1/pci_portrait.mp4"
/>

Using purpose

<podcast:images
  purpose="artwork"
  src="https://example.com/images/today_explained.jpg"
/>
<podcast:images
  purpose="publisher"
  src="https://example.com/images/vox_media.jpg"
/>

Using srcsetto provide multiple sizes of a single asset

The syntax is borrowed from the HTML5 srcset syntax. It allows for describing multiple image sources with width and pixel hints directly in the attribute. Although the HTML5 srcset attribute allows relative urls, absolute urls are required in this tag.

<podcast:images
  src="https://example.com/images/ep1/pci_square-massive.jpg"
  srcset="https://example.com/images/ep1/pci_avatar-massive.jpg 1500w,
          https://example.com/images/ep1/pci_avatar-middle.jpg 600w,
          https://example.com/images/ep1/pci_avatar-small.jpg 300w,
          https://example.com/images/ep1/pci_avatar-tiny.jpg 150w"
/>

Using aspect-ratio and purpose to provide multiple art directions

Multiple image tags in the feed allow apps to select from multiple aspect ratios and media formats to display.

<podcast:images
  purpose="artwork"
  aspect-ratio="1/1"
  src="https://example.com/images/ep1/pci_square-massive.jpg"
/>
<podcast:images
  purpose="artwork social"
  aspect-ratio="16/9"
  src="https://example.com/images/ep1/pci_landscape-massive.jpg"
/>

Using all the attributes

<podcast:images
  alt="An antenna emanating signal waves"
  purpose="artwork"
  type="image/jpeg"
  aspect-ratio="1/1"
  src="https://example.com/images/ep1/pci_square-massive.jpg"
  srcset="https://example.com/images/ep1/pci_square-massive.jpg 1500w,
          https://example.com/images/ep1/pci_square-middle.jpg 600w,
          https://example.com/images/ep1/pci_square-small.jpg 300w,
          https://example.com/images/ep1/pci_square-tiny.jpg 150w"
/>
<podcast:images
  alt="An antenna emanating signal waves"
  purpose="artwork social"
  type="image/jpeg"
  aspect-ratio="16/9"
  src="https://example.com/images/ep1/pci_landscape-massive.jpg"
  srcset="https://example.com/images/ep1/pci_landscape-massive.jpg 1500w,
          https://example.com/images/ep1/pci_landscape-middle.jpg 600w,
          https://example.com/images/ep1/pci_landscape-small.jpg 300w,
          https://example.com/images/ep1/pci_landscape-tiny.jpg 150w"
/>
<podcast:images
  alt="An antenna emanating signal waves"
  purpose="artwork canvas"
  type="image/jpeg"
  aspect-ratio="9/16"
  src="https://example.com/images/ep1/pci_portrait-massive.jpg"
  srcset="https://example.com/images/ep1/pci_portrait-massive.jpg 1500w,
          https://example.com/images/ep1/pci_portrait-middle.jpg 600w,
          https://example.com/images/ep1/pci_portrait-small.jpg 300w,
          https://example.com/images/ep1/pci_portrait-tiny.jpg 150w"
/>
<podcast:images
  alt="An antenna emanating signal waves"
  purpose="artwork"
  type="video/mp4"
  aspect-ratio="1/1"
  src="https://example.com/images/ep1/pci_square-massive.mp4"
  srcset="https://example.com/images/ep1/pci_landscape-massive.mp4 1500w,
          https://example.com/images/ep1/pci_landscape-middle.mp4 600w,
          https://example.com/images/ep1/pci_landscape-small.mp4 300w,
          https://example.com/images/ep1/pci_landscape-tiny.mp4 150w"
/>
<podcast:images
  alt="An antenna emanating signal waves"
  purpose="artwork social"
  type="video/mp4"
  aspect-ratio="16/9"
  src="https://example.com/images/ep1/pci_landscape-massive.mp4"
  srcset="https://example.com/images/ep1/pci_landscape-massive.mp4 1500w,
          https://example.com/images/ep1/pci_landscape-middle.mp4 600w,
          https://example.com/images/ep1/pci_landscape-small.mp4 300w,
          https://example.com/images/ep1/pci_landscape-tiny.mp4 150w"
/>
<podcast:images
  alt="An antenna emanating signal waves"
  purpose="artwork canvas"
  type="video/mp4"
  aspect-ratio="9/16"
  src="https://example.com/images/ep1/pci_portrait-massive.mp4"
  srcset="https://example.com/images/ep1/pci_portrait-massive.mp4 1500w,
          https://example.com/images/ep1/pci_portrait-middle.mp4 600w,
          https://example.com/images/ep1/pci_portrait-small.mp4 300w,
          https://example.com/images/ep1/pci_portrait-tiny.mp4 150w"
/>

[jamescridland]

The media:thumbnail tag is used by YouTube, one of the largest RSS ingestion services in podcasting. This is a working example that is used by the service.

<media:thumbnail url="https://i.podnews.network/r/v/1280/podnews240620.jpeg" width="1280" height="720" />

What would be the advantages of an additional tag for podcast hosting companies to support? Is the main difference a file-type?

[nathangathright]

I’m in complete agreement that hosts shouldn’t support any version of the podcast:images tag until apps make that effort worthwhile. In my mind, this proposal merely provides a framework for apps to build upon. Like all namespace proposals, this shouldn’t be formalized without the support of apps that want to bring it to life.

Apps would need to create the incentive for the adoption of any particular combination of format + aspect ratio. Maybe an app wants to progressively enhance its Now Playing screen with muted, looping video (à la Spotify Canvas); or just static promotional artwork across the app (à la Apple Podcasts).

[jamescridland]

@nathangathright Not my question. I was wondering what this tag offers that the existing standard does not?

[nathangathright]

I’m not familiar with any other uses of the <media:thumbnail> tag beyond YouTube thumbnails. Reading the spec, it doesn’t seem intended for show-level imagery, which feels like a notable distinction to me, but maybe I’m mistaken. The thumbnail spec also mentions handling multiple images by “order of importance.” So, I’m not clear how multiple thumbnails with different aspect ratios and/or media formats would be handled by YouTube or others. If none of that’s relevant, then sure, this is just a new way to do an existing thing with more file types.

[thebells1111]

@jamescridland To answer your question, what this tag allows that media:thumbnail doesn't is the ability to limit the ratios to a few defined ones in the specs. Since we don't have control of the specs in the media namespace, using the media:thumbnail tag opens up an almost unlimited number of aspect ratios. By creating or modifying our own tag, we can decide how the spec is written, and we can narrow it down to a handful of aspect ratios the apps have to account for.

[samsethi]

I like this idea. I could see an app showing a video on the cover art or a gif. TrueFans already support the current <image tag>. We also support GIF on cover, episode and chapter art. I know several other Podcasting 2.0 apps also support GIF.

As much I would support this extension I can't see any hosts allowing podcasters to upload video, however small. TrueFans will extend our support for this image tag proposal so that we can be a reference app if any host wants to support this update and test.

TrueFans is in the process of adding support for video upload on our platform. So podcasters can upload video to the alternate enclosure and we will host it. This means a user can switch between audio and video.

However video uploaded to TrueFans will only work on TrueFans for now. If/when other hosts support the Alternate Enclosure and support video in the alternate enclosure then we can play it from there. Captivate are the only host I know of that currently supports the Alternate Enclosure. Blubrry, Hubhopper and RSS.com have said they will but that is not the case right now.

But if we are adding support for video then adding additional video support for this tag is trivial. Podnews Daily used to support the image tag and had multiple img sizes. That is no longer the case but many other podcasters still have multiple image sizes in their feed.

[daveajones]

Since this is a non-breaking change I’m in favor of it.

[thebells1111]

@daveajones

I suspect changing the count from Single to Multiple may be a breaking change. I think several parsers convert it to a single object instead of an array of objects, so any app (if there's any) supporting it may not be prepared to handle an array of objects instead of a single object. Either way, I'm moving forward with implementing these changes into Sovereign Feeds, but I worry that Adam's feeds may cause some of the parsers to hiccup.

[nathangathright]

I’m also recommending that srcset switch from required to optional in favor of src.

[redimongo]

It looks good, can I play devil advocate for a second (and this will sound hypocritical).

Do we risk confusing people who don't read docs by saying <podcast:images> but it now allows videos. While I think its a massive improvement, one could say it goes out of scope of its original function which it serves really well.

Maybe a rename of images to something else, so that its clear to everyone that this now supports everything from images to video and in any aspect ratio?

[daveajones]

It’s understandable, but I don’t think the names matter much. Devs should RTFM since our docs are so plain English and easy to follow already. After all, the HTML “a” tag is mostly meaningless semantically, but we all know what it does.

[redimongo]

While I get where you're coming from it's like in HTML we know img only handles images.

For those who just don't think they may get confused because they programmed their website to look at podcast:images while running a img script for their site.

When I went and did my diploma in website development, I was told use the "Keep it simple" method a developer should be able to look at the tag name and know clearly what it does & is used for, I am defiantly not against the improvements just goes against everything W3C would say and if we want this to become a standard that everyone from any background can understand wouldn't it be clearer if we made it say podcast:mediafiles this way for example it makes it clear that if you are looking for additional media files like images, video or banners it would be in that section. could even label it alternateMediaFiles to follow the tag <podcast:alternateEnclosure>

[nathangathright]

FYI, Safari has supported MP4 in img tags since 2017.

[Marzal]

Any thoughts about adding a new optional attribute alt?. So it has another use case (accesibility), making the tag even more useful.

As podcast:transcripts has a lot of supporters in the "deaf" community, An alt in the image tag could be the reason some apps adopt it for the blind community.

[daveajones]

Good thought.

[nathangathright]

@Marzal Given the intended use of these images is likely decorative, wouldn’t devs mark these as role="presentation" anyway, thus skipped by screen readers?

[Marzal]

I wouldn't mark the images with that role, if the podcaster thinks that it's decorative can leave the alt empty o better, with a empty space.
But If the podcaster wants to give the blind user a sense of what that image represents, then will put some description on the alt attribute.

Some use cases that I see:

• Artwork for the show: Useful for a blind person to know.
• Banner image: Probably not. I would leave it empty
• Episode artwork: Useful if they are personalized.

So I think it's best to leave the HTML <img> with the alt attribute as the indicator that if is meant to be decorative (" ") or with a description to screen reader.

Podpage for example (with could benefit a lot from this tag), has no role="presentation" in any img, and has an alt for the nav image that just says the show's name, with this proposal it could be improved.

So it would be no change if the podcasters don't bother putting the text, but it would allow "clients" (players and webs) to be more accessible if they want to put the little extra work of using the attribute that others podcasters fill in.

Another example:

• https://kdeexpress.gitlab.io/ uses images to indicate the kind of episode, so it has alt text on them
  https://kdeexpress.gitlab.io/feed has 4 podcast:images with alt text, happy to test it with screen reader users if someone wants to try to implement it.
• https://accesibilidadtl.gitlab.io/ uses just the show's artwork, so empty alt="" for the episode images.

[nathangathright]

I’ve revised the proposal to include alt and purpose attributes. I’m trying to balance suggesting potential uses and leaving it free-form. I want developers to be free to innovate new ways to use media assets without requiring them to build consensus to update the spec every time. I’d appreciate any feedback.

[Marzal]

I think that making all the new improvements as optional is a good compromise. And this tag could use a refresh to gain some adoption.

And it would help podcasters and hosting to keep track of the purpose adoption, if players would document someplace in this repo what they are supporting/implementing.

[thebells1111]

Totally, and in newpodcastapps.com, an app should be more specific about that elements of images they're supporting. images/hero is very different than images/video-preview.

[Marzal]

I think that this proposal have the opportunity to fix the lack of usage of podcast:image with the improvements and also bring the banner capability if desired. Of course you never know if (or how many) devs are going to really implement, but right now podcast:image has no real use in the wild and I would prefer to improve this tag rather than kill it and create a new one for banners. Even if one-use-case-tag are easy to implement, I agree with no "tangling" too much the spec with new tags (if there is room to just fix something that already exits and is retro-compatible), all new attributes are optional so devs can choose to implement as far as they want.

I for example would implement right away the alt attribute (given is a easy one for webs and a11y friendly)

[theDanielJLewis]

Another option to consider: a circle-crop-friendly option.

[Marzal]

For the record, or to help keep track. This #694 proposal probably super-seeds the enhancement proposal.