Mastodawn

#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

I know we discussed perhaps just reusing the <podcast:images> name for this new thing, but I can't kick the feeling that would be a bad idea. They are just so different and I'm afraid old feeds would linger forever with the conflicting format and cause edge case chaos for devs.

So, just sticking with <podcast:image> for the new thing. There are no right answers here, so it is what it is.

Todd Cochrane Jun 24

@dave Alt Images

@Todd_Blubrry Eh. Names.

Oops. Forgot to insert the screenshot:

Daniel J. Lewis Jun 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?

@theDanielJLewis Did you read the spec?

@theDanielJLewis The purpose being set to "apple/hero" tells you what the aspect ratio is (4:1 according to their docs) so including it in the tag isn't necessary. Including the width isn't necessary either, but could be useful for UI hinting.

James Cridland Jun 25

@dave @theDanielJLewis I think it's not useful to show the width in an example here - the apple/showhero (its proper name) has a set height/width, so I think we can usefully not include either in any spec examples. That'll remove questions like Daniel's.

James Cridland Jun 25

@dave @theDanielJLewis It seems Apple has now named this Showcase Hero, and I'd recommend apple/showcase-hero as the "purpose" tag.

@james @theDanielJLewis 👍

@james @dave @theDanielJLewis why using names defined by a company? Why not using something agnostic? What if any company disappears in the future?

@james @dave @theDanielJLewis or decides to change a name, like this

James Cridland Jun 29

@ruisan @dave @theDanielJLewis Because the literal definition of the image size and layout is also defined by that company. I do not see any issue in doing that - it’s not the only image, but this particular image specification is authored by Apple.

Daniel J. Lewis Jun 29

@james @ruisan @dave Makes sense. I can see both sides.

@theDanielJLewis @james @ruisan Think of it as a pass-through value. You're saying, "there is an image spec defined by this certain app, and I want to provide it the thing it wants without having to go do a bunch of proprietary stuff on their portal".

@theDanielJLewis @james @ruisan And, as a side benefit, others can see it publicly and might decide it's a nice format and pick it up as well - directly from the creator instead of having to scrape the proprietary platform's website.

Daniel J. Lewis Jun 29

@james @dave I think "hero" is fine unless Apple will be asking for different hero-image sizes.

@james @theDanielJLewis Change made.

@james @theDanielJLewis 10-4. Will change.

Daniel J. Lewis Jun 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.

@theDanielJLewis This is good feedback. 👍👍

Nathan Gathright Jun 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.

Daniel J. Lewis Jun 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).

Nathan Gathright Jun 25

@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?

Daniel J. Lewis Jun 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.

Nathan Gathright Jun 25

@theDanielJLewis Agreed!

Daniel J. Lewis Jun 24

@dave As for the deprecation, the simplest thing would be to move the old spec out of the tags folder into a deprecated folder. But the other possibility is that we add "Front Matter" tags to the doc, and maybe I can clearly display "deprecated" in the list on podcasting2.org.

@theDanielJLewis You're in charge. I'll do whatever you tell me to.

Daniel J. Lewis Jun 25

@dave Here's the easiest way to do it:

Leave the file where it is, but git mv it with a new name: images-(deprecated).md

That will display as "Images (Deprecated)" in the Tags nav on Podcasting2.org.

And that also makes it obvious for anyone looking at the files.

James Cridland Jun 25

@dave @theDanielJLewis @nathan This looks nice (with my feedback about the apple/showhero width).

I'm also very pleased to see we have the conviction in our beliefs to deprecate a tag. Bravo!

@james @theDanielJLewis @nathan Ok, how does this look?

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

Added author attribution (first of many) and Nathan's demo tool link:

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

Daniel, does the formatting of the attribution link look ok for pulling into podcasting2.org?

podcast-namespace/docs/1.0.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

Daniel J. Lewis Jul 3

@dave @james @nathan Just the "by" line?

Code-wise, it's fine. But it's placement and "by" might not be ideal for this kind of project. A prominent byline like that is better for articles.

I think it could be better to have a "Contributors" or "Collaborators" inline list at the bottom of the doc. That would allow for giving full credit to the people who made it possible, and not necessarily the one who wrote up the spec.

Or a "Credits" heading at the bottom, as common on npmjs.com.

@theDanielJLewis @james @nathan Ok good idea. I’ll fix it.

@theDanielJLewis @james @nathan How does this look?

Daniel J. Lewis Jul 4

@dave @james @nathan "Attribution"?

Sorry, that's the weirdest way to word that. "Credits," "Contributions," or "Contributors" make more sense and seem more accurate.

_Especially_ since "attribution" has such strong meanings in podcasting already.

@theDanielJLewis @james @nathan Give me a word to use.

@theDanielJLewis @james @nathan Credits?

Daniel J. Lewis Jul 4

@dave @james @nathan "Credits" is my #1. And then it's not redundant with "contributor" below, because I _do_ like the clarity of credit you included for who actually "authored" it versus who just contributed.

@theDanielJLewis @james @nathan Done:

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

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

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

GitHub

Daniel J. Lewis Jul 4

@dave I see a tiny problem that's breaking Podcasting2.org's display of this. I'll issue a quick PR.

@theDanielJLewis 10-4. Standing by...

Daniel J. Lewis Jul 4

@dave Sorry I'm still learning GitHub PRs, but it seems to have merged my changes into this PR: https://github.com/Podcastindex-org/podcast-namespace/pull/713

The problem was using <br> instead of <br />

Update podroll.md by theDanielJLewis · Pull Request #713 · Podcastindex-org/podcast-namespace

Fixed incorrect internal link on Podroll page.

GitHub

@theDanielJLewis Isn't <br> the proper HTML5 tag?

Daniel J. Lewis Jul 4

@dave Apparently, but it's crashing the Markdown translator. There's got to be a better way to do a linebreak inside a table.

@theDanielJLewis Seems to work on mine. I'm using JetBrains IDE. Are you using VS Code?

Daniel J. Lewis Jul 4

@dave IDE doesn't matter. It's Nextra, the tech stack running Podcasting2.org.

Daniel J. Lewis Jul 4

@dave @james @nathan But I do like that formatting.