RSS image tag
farski opened this issue · comments
It might be good to decide on a specific purpose for the RSS <image> tag. The image should never be larger than 144x400, so the uses are somewhat limited, but there may still be some good reasons to have an image that meets those requirements.
For example, a low-res thumbnail, that is always exactly 144x144.
Or if people don't think this is worthwhile, we should officially recommend that feeds not include the tag, and that parsers ignore it.
One potential long-term problem with the element is that it must be GIF, JPEG or PNG, which is somewhat limiting, given that new formats are becoming more prevalent (SVG, WebP, etc)
I'm guessing you made a typo there saying it should be "no larger than 144x400". Currently most podcasts serve images in that tag that are somewhere in the neighborhood of 1300 x 1300, and of course that is a square dimension.
Hi-res images are ideal, because podcast apps can easily resize them down to a thumbnail size of their choosing, but still have hi-res available for when it's needed.
@inorganik Unfortunately no, the RSS spec says that for the <image> tag:
Maximum value for width is 144, default value is 88.
Maximum value for height is 400, default value is 31.
(@inorganik I think you mean the <itunes:image> tag, which they request to be large/high quality as you describe)
That's silly, and no one will abide by that. It's impractical, and outdated. If we are designing a spec for today's podcasters and podcast listeners, we should respect them and design standards around how people actually use the feeds, rather than try to uphold standards set in 1999.
@kookster - no, the same size image is usually served in both image and itunes:image.
@farski I would challenge you to find 1 feed that abides by that spec
The real answer would be to reference a SET, but...
While hires images are good in cases where you're only viewing your own subscriptions or some limited list of recommended podcasts, and are absolutely necessary when the target display is BIG screen, there are cases where downloading smaller images is best... thumbnail images... hires would unnecessarily make the load much bigger. For example, scanning many SERIES images (perhaps hundreds). FWIW.
Agreed - why not add tags that clue us in to the intended use: image:144, image:600, image:1200
@inorganik well I guess you can call me "silly" - I abide by the spec.
Of course I agree the current standard is outdated, that's why we're talking about modernizing and changing it.
But, In the meantime, we also follow it, b/c valid feeds help those making clients to have predictable data and create a better experience, that's why we're here discussing standards.
I feel like this line of discussion is counter-productive, but here are 3 well known feeds that meet the spec with a different, smaller <image/> than what is in <tunes:image/>:
- Wait Wait Don't Tell Me: https://www.npr.org/rss/podcast.php?id=344098539
- The Moth: http://feeds.themoth.org/themothpodcast
- 99% Invisible: http://feeds.99percentinvisible.org/99percentinvisible
@kookster None of those feeds hold images in the <image> tag that are <= 144 wide. So none of those are adhering to the existing spec. We are specifically discussing the pixel dimension of the image in that tag are we not?
Let's move forward with proposals for how it should be, like you said. I don't mean to come of as confrontational, I just think it's unrealistic to set an expectation of 144x400 that no one will follow - afterall we are here for setting the spec for the future right?
@inorganik I agree the spec is outdated. There are feeds that adhere to it, and we have already decided that compliance with RSS 2.0 is a prerequisite of SM compliance at the feed level, so there's really not any wiggle room for us here, as far as what the spec says. If some people continue to choose to ignore it, as they have been doing all along, the extra pressure from SM is immaterial. They didn't care about violating RSS 2.0, and they probably won't care about violating SM.
I disagree that it's entirely impractical. I think there's value in having a standard low-res, low-bandwidth image available. The image tag seems like an okay tool to use for that for the time being, at least until someone suggests a replacement mechanism and people with the means start adopting it.
I'm also okay with people making an argument that the <image> tag should just be deprecated and phased out, even if there's no immediate replacement.
As things stand right now, syndicated.media won't be making any recommendations that directly conflict with RSS 2.0.
@farski gotcha, thanks for the clarification. I will say I'm disappointed syndicated media sticking to a such on old spec. I would say yes deprecate it - but it's a de-facto standard tag name. To make a proposal for a new tag would require 100's of thousands of podcasters and the tools they use to change.
Also, FWIW, any dimensions that are not square I think would be problematic with regards to podcasts specifically.
I will say I'm disappointed syndicated media sticking to a such on old spec
What's the alternative? If you think getting people to adopt a new tag is challenging (or even just using an existing tag slightly differently), I can't imagine how you'd think switching formats completely is a more reasonable path.
As things stand right now, syndicated.media won't be making any recommendations that directly conflict with RSS 2.0.
I agree. Standards are difficult to implement and so hard to get them to be widely adopted.
Anyway, I wonder if there is any chance of evolving without modifying them, at least in the initial phase.
I mean, there’s obviously a need of high resolution images at level (hir-es screens in phones and big hi-res screens in tablets). Without asking for a modification of the RSS standard Apple got everyone of us to use a <itunes:image> tag to fulfill that need. Podcachers parse it & creations tools integrate it in their feeds.
<itunes:image href="https://myURL.com/1.jpg"/>
<image>
<url>https://myURL.com/2.jpg</url>
<title>My Title</title>
<link>http://myURL.com</link>
</image>
<image:small>
<url>https://myURL.com/3.jpg</url>
<title>My Title</title>
<link>http://myURL.com</link>
</image>
<image:medium>
<url>https://myURL.com/4.jpg</url>
<title>My Title</title>
<link>http://myURL.com</link>
</image>
<image:big>
<url>https://myURL.com/4.jpg</url>
<title>My Title</title>
<link>http://myURL.com</link>
</image>
Would something like this be possible? Is this what we could name the kind of recommendation that do not directly conflicts with the standard? To what extent can the objectives of making a recommendation be met without proposing to modify the original standard?
Sorry for my english and the possible errors in the code, I am not a programmer nor a native speaker.
@PabloFernandezDelkader
if only native/tech speakers did as well as you...
BUT the thread is a bit confusing to me. Am I to understand that:
- we may or may not define SM-recommended usage of existing
tag
- we are not proposing any changes to RSS standard itself
- we may define a SM-IMAGE tagset, structure, and usage, similar to Apple... ... supporting various sizes to address different use cases and device formats
BTW, this last item has REAL benefits... reducing bits congesting internet, improving responsiveness, better layout appearance, ...
So, what are the goals for this thread?
(just trying to keep things moving along)
we are not proposing any changes to RSS standard itself
RSS 2.0 is locked. Proposing changes is a bad use of time, as they will never happen. We have adopted RSS 2.0, so there is no current plan to move forward with another document format (JSON, RSS 3.0, etc) at the moment.
we may or may not define SM-recommended usage of existing tag
Many people have started to recommend best practices for specs (RSS and namespace extensions that already have a foothold) that are ambiguous. I think this is one of the easier and more important things that SM will be doing in the short term
we may define a SM-IMAGE tagset
I fully expect we will create new tags under s SM namespace. Whether one or more that have to do with images will be included is up to people proposing ideas, and getting some traction.
This ticket, specifically, is about coming up with a plan for the future of the RSS 2.0 <image> tag. It has a definition that we can't touch, so we must work within it's definition. But we also know the definition doesn't really meet any real needs of podcasting, which is why I think a more directed, stricter layer on top of the definition would be valuable.
"I fully expect we will create new tags under s SM namespace. Whether one or more that have to do with images will be included is up to people proposing ideas, and getting some traction."
Is a new ticket needed for this? There is already one about the namespace itself, but this discussion is specific to an image tag that may or may not be defined under it.
#29 deals with images. If you're thinking of something else, feel free to make a new ticket
Makes sense but the topic does cover more than aspect ratio... perhaps title change? (again, I see now)
And I'll shift the meat of a post or two over there...