Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wish it covered how to properly do images. All the SO posts on the topic suggest embedded HTML


I develop Unread (https://www.goldenhillsoftware.com/unread/).

I have some complex logic to find a hero image that is sometimes in a feed entry outside the HTML, and prepend it to the top of the article -- but only if there is not another reference to that image in the article. It is complicated because sometimes there will be hero-image.jpeg in the article and hero-image-1200x500.jpeg outside the article, and I have to judge whether the images are the same.

I am in favor of embedding the image into the HTML, and not adding it elsewhere.


I'm curious to see the point of view of another feed reader developer. Does all of this advise make sense to you and work well in your app? Is there anything that seems backwards or anything that I missed?


I mostly nodded as I was reading your advice. I particularly appreciate that you recommend including full article content in feeds, not changing entry IDs, and adding discovery `link` elements to HTML pages.


I don't think I have enough experience to write that advice. But from what I have seen embedded HTML is the most reliable.

You can also use enclosures but not all readers will display these. Notably WordPress puts every embedded image into an enclosure so a lot of places just ignore them to avoid duplicates.


It’s just crazy to me that RSS doesn’t have a property specifically for an image URL. Like, what’s the problem with that? Does ATOM have this support?


The question is what do you mean by "image URL". Is this a poster, hero image, site logo, the content of the post itself? This is what is lacking.

In RSS the main media attachment is the <enclosure> element. However like a lot of things in RSS it is poorly specified. For example it isn't even clear if you can have multiple. If you have multiple are they different representations of the same resource or different resources?

https://validator.w3.org/feed/docs/rss2.html#ltenclosuregtSu...

The solution to this is the Media RSS spec. (Which is also commonly used in Atom. XML namespaces are actually kinda nice.) This is a lot better if only because they contain the <group> element which makes it clear what different things mean. (Different representations or different resources.) Unfortunately support is still varied and it isn't always clear if this is just a copy of every image in the post (WordPress...), only semantically relevant images, or images that are the point of the entry but don't appear in the post.

https://www.rssboard.org/media-rss

So unfortunately the best path forward is probably yet another standard that makes these clear from the outset, and hoping that people actually follow the rules. Not an easy path forward.

Again, I'm not an expert on media in feeds, but based on the feeds I have seen trying to write a feed reader I would do the following if I was creating a feed with media in it.

1. Use Media RSS. Don't use <enclosure> at all unless you are a podcast.

2. Only reference interesting images directly. You are welcome to include whatever you want in the HTML for stylistic reasons but don't put reference it outside of the HTML unless it is actually an interesting image.

3. Put every media element in a group. Basically because WordPress puts everything into a media element and it is unclear if these are the same images, duplicates or even interesting at all (I don't need the author's avatar listed in the media elements WordPress...). Even if you only have one representation put it in a group just because it is unambiguous what you mean.

If anyone has more experience here I would love to hear what you think.


Presumably the parent commenter means some way to specific some additional per-item pizazz in the vein of Twitter cards.

Nothing stopping a reader from fetching the linked resource and pulling useful stuff out of the existing Open Graph annotations, of course...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: