DaveJun 24

#namespace The <podcast:image> tag draft write-up:

https://github.com/Podcastindex-org/podcast-namespace/blob/image_tag/docs/tags/image.md

Included a new example (screenshot) apropos to current need.

This draft also formally deprecates the <podcast:images> tag. @theDanielJLewis I'm not sure how that would/should come across to podcasting2.org in a way that is a visible (colorful?) deprecation warning callout. I'm open to ideas on that. Just tell me what you need:

https://github.com/Podcastindex-org/podcast-namespace/blob/image_tag/docs/tags/images.md

@nathan Can you eyeball this for me and see if it works?

podcast-namespace/docs/tags/image.md at image_tag · Podcastindex-org/podcast-namespace

A wholistic rss namespace for podcasting. Contribute to Podcastindex-org/podcast-namespace development by creating an account on GitHub.

GitHub
Show threadDaveJun 24
Oops. Forgot to insert the screenshot:
Show threadDaniel J. LewisJun 24

@dave Why only a width? That tells nothing conclusive about an image. 4,320 could be landscape, square, or portrait.

Weren't we discussing an aspect ratio indicator instead of a single dimension?

Show threadDaveJun 24
@theDanielJLewis Did you read the spec?
Show threadDaniel J. LewisJun 25

@dave Spec looks good!

I noticed an unforeseen potential edge case. How should the tag be treated if it includes only href and it's pointing to a video?

It can't then be assumed to be 1:1 aspect ratio, and it probably shouldn't be assumed to be the cover art.

So maybe the solution is to say that href-only should be _only_ for 1:1 images. If the href is to _anything_ other than a 1:1 image (even if it's a 1:1 video), that it should use additional attributes.

Show threadNathan GathrightJun 25

@theDanielJLewis @dave Adding implicit default values for aspect ratio and purpose to the spec can’t hurt.

That said, I can’t imagine app developers would trust an href-only tag of *any* media type enough to display it w/o additional validation. Their default UX will presume that the vast majority of shows won’t provide any special assets, and then progressively enhance when available. If podcasters want to take advantage of that, the burden is on them to opt-in to the necessary attributes.

Show threadDaniel J. LewisJun 25

@nathan @dave They do it with <itunes:image>.

<podcast:image> could be assumed to be a drop-in replacement (like many Podcast Namespace tags are), but also with optional progressive enhancements (like many Podcast Namespace tags are).

Show threadNathan Gathright

@theDanielJLewis So? <itunes:image> has universal support, existing norms, and guardrails built into most hosts to prevent most edge cases. That makes all the difference in the world when it comes to reasonable assumptions.

Besides defining implicit default values, which I agree with, are you bringing this up to argue a new point?

Jun 25 at 7:54pmWeb
Show threadDaniel J. LewisJun 25
@nathan I'm saying the implicit default value should be that <podcast:image> works exactly the same as <itunes:image>—until you add on additional attributes.
Show threadNathan GathrightJun 25
@theDanielJLewis Agreed!