More <podcast:image> purpose token ideas

[theDanielJLewis]

Dave Jackson and I recorded an episode of The Future of Podcasting tonight and talked about the new image tag. During our discussion, I thought of some additional purpose tokens we could discuss and potentially add to the predefined list.

1. icon—An "image" that shows only an icon but no text. For example, look at the thumbnail images in the episode listing on https://theaudacitytopodcast.com.
2. icon/dark-mode—The inverse of icon/light-mode:A light-colored transparent icon intended to overlay a dark background and thus be dark-mode-optimized.
3. icon/light-mode—The inverse of icon/dark-mode: a dark-colored transparent icon intended to overlay a light background and thus be light-mode-optimized.
4. frame/3/4, frame/16/9, etc.—An image designed to be a frame around a transparent middle. For example, a 1/1 aspect-ratio image with frame/16/9 would be a square image with a transparent 16:9 area in the middle for framing 16:9 video for a square format (like Instagram). Or consider a 9:16 image with a 3:4 ratio area in the middle to be for "shorts" style videos.
5. no-text—Any image for any purpose but with no text in the image.

The above demonstrate another idea: the idea of mixable secondary purpose tokens, like the aspect ratio, light versus dark mode, text or no text. For example, artwork/dark-mode would be artwork that looks best in a dark-mode UI, but artwork/light-mode (assumed default) would look best in a light-mode UI.

What do you think of these ideas, and what other potential purpose tokens should we consider?

[theDanielJLewis]

Or maybe light vs. dark, text or no-text, and such should be separate attributes?

[jamescridland]

I would suggest that these are driven by podcast apps and directories, rather than podcast creators.

This makes this feature a unique one - we need to convince an app developer (or more than one!) to want to use them, and ask them for the specification that they want.

Podpage is one of those types of app developers that might usefully want to use these. I could see there being a benefit in a favicon-type icon (SVG format makes the most sense) for Podpage, as one example - they could instantly use it for their product. It’s a thing we might wish to convince them of. (If only we had a contact…)

[nathangathright]

Yes, driven by real-world usage is key. I don’t think I made this clear in my original proposal, but I named the attribute purpose to intentionally draw parallels to the txt tag. Here’s the relevant bits:

It's meant to allow for usages that might be niche or otherwise not rise to the level of needing a dedicated tag. Just like TXT records in DNS allowed for new things like SPF to evolve, this tag can allow novel techniques to be created and sandboxed without a formalization process.

The need for the verify token pre-dates the txt tag. While hosts may choose to present their users with a "Verification Code" input box, the txt tag serves as a catch-all space for apps and directories to ask feeds to provide any information. And when new use cases emerge, apps and hosts just need to agree on a new token, not formalize a new tag.

[nathangathright]

I’m looking forward to listening to the episode once it’s released. However, I’m more inclined towards removing all suggested purpose tokens from the spec than expanding or revising them over time.

Listing specific tokens in the namespace can give the impression they have broad consensus or endorsement, even if they’re not widely adopted by feeds or apps. This can create pressure for developers to lobby for their own tokens to be added, as a way to gain visibility or legitimacy, turning the namespace into a kind of gatekeeper. To avoid that, I think it’s healthier for the ecosystem if the spec stays vague about specific use cases, and lets real-world adoption shape best practices.

Separately, I think every token or tag proposal should be grounded in a clear understanding of progressive enhancement. For any new tag to gain traction, apps need to be able to support it in a way that still works well for the vast majority of feeds that haven’t adopted it. If an app can’t offer a reasonable fallback experience, it simply won’t implement the feature, no matter how useful it might be in the ideal case. That’s a key reason why I think caution and minimalism in the spec are more valuable than creating tokens for hypothetical use cases.

I understand we might not see this the same way, and that’s totally fine. I just wanted to clearly explain where I’m coming from.

[theDanielJLewis]

But if the spec is too open or vague, then you'll end up with multiple tokens for the same purpose, or a total lack of support for certain uses.

Take circular for example. If it wasn't defined, apps might ask for circular, round, circle, circle-crop, rounded, and anything else. Then for the podcaster to support that, they have to redundantly include those versions of the same thing. The publishing-tool developers would also have to make their interfaces handle all these versions of the same thing, potentially causing confusion for the user.

Case in point: look at the nearly dead and under-supported socialInteract tag for comments. It could be the feature with the greatest appeal for podcasters and audiences, but its ambiguity has led to a messed up ecosystem.

So my point in this thread is to start the conversation, and perhaps developers and podcasters can come to enough consensus that some other official tokens can be added.

Let's just not repeat the --moz-border-radius … mess of early CSS3!

[jamescridland]

This is why it's up to you to convince app developers to start supporting these (when, I believe, we start adding them to the spec documents).

I agree with Nathan that we shouldn't have any, yet, in the spec (other than a few examples of how it might be done).

We have learnings from the images tag, and also learnings from the socialInteract tag here - that filling a spec with random "would be nice" features without support from app developers is a mistake. Support from app developers is the starting point.