Use `<icon>` over favicon as feed icon
Problem
It seems the favicon of a domain is given precedence over a possible <icon> element in an Atom feed.
This breaks feed generator websites that allow users to create custom feeds with custom icons, since every user feed gets the same favicon instead of their custom icon.
For example, a kill-the-newsletter feed.
I didn't test it with other feed types like RSS or JSON.
Steps To Reproduce
Add feed https://kill-the-newsletter.com/feeds/iu8547vjdyb06za1lb1u.xml to NetNewsWire.
The feed's XML
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<id>urn:kill-the-newsletter:iu8547vjdyb06za1lb1u</id>
<link
rel="self"
href="https://kill-the-newsletter.com/feeds/iu8547vjdyb06za1lb1u.xml"
/>
<link
rel="hub"
href="https://kill-the-newsletter.com/feeds/iu8547vjdyb06za1lb1u/websub"
/>
<icon
>https://www.google.com/s2/favicons?domain=https://netnewswire.com&sz=32</icon
>
<updated
>2000-01-01T00:00:00.000Z</updated
>
<title>Test</title>
</feed>
Expected Result
The feed icon is the URL in the <icon> element.
Actual Result
The feed icon is the /favicon.ico.
The problem with icons specified in feeds is that they are often not square — and favicons are (pretty much always) square. The app really wants square icons!
(We will of course look into this in the future. There are things we can do. The above is just to explain why we went with favicons over icons specified in feeds in the first place.)
Thanks for the reply. I don't have strong opinions on the visuals like round vs square. The feed icon in the example above happened to be round, but it could've just as well been square.
I'd argue it goes against user intent to overwrite data defined explicitly in the feed (feed icon) with data defined implicitly by the domain hosting the feed (domain favicon). The feed is the core product the user explicitly acts on, while the domain hosting the feed is secondary and often not under the user's control. It makes sense to use data from the domain as fallback for data missing from the feed, but not to overwrite data explicitly set in the feed.
This looks similar to #4533 but in that case the favicon is being skipped as well. From https://validator.w3.org/feed/docs/atom.html :
icon | Identifies a small image which provides iconic visual identification for the feed. Icons should be square.
So I agree that <icon> should be preferred. Although from https://www.rssboard.org/rss-specification about the <image> tag:
Optional elements include
<width>and<height>, numbers, indicating the width and height of the image in pixels.<description>contains text that is included in the TITLE attribute of the link formed around the image in the HTML rendering.Maximum value for width is 144, default value is 88.
Maximum value for height is 400, default value is 31.
So the other ticket is a harder choice.
The problem with icons specified in feeds is that they are often not square
This may read as unintended snark, but getting the width and height of the downloaded Atom feed <icon>, comparing them, and falling back on the homepage's favicon in case they differ seems doable, IMHO.
I have no idea how much work it would be (so it's easy for me to say this 😅) but a fallback check like that seems like it would be a good idea. As I know you've had to deal with in the past, so many feeds are a mishmash of all of the various RSS standards so it's practically impossible to only pick the "correct" image. As a possible start I think the following precedence would match what most people expect:
- The
<icon>channel element - The
<image>channel element - The favicon corresponding to the homepage URL domain
- The favicon corresponding to the feed URL domain
The fallback strategy would be to download an image, check its dimensions, display if it's square or try the next one if it isn't. If none of the images are square I'd just display a generic icon like you're doing now but you could also use the first non-square image. This is a lot of downloading but it would only need to be done once when a channel is added.
Coming up with a more sophisticated implementation for this is certainly possible. But there is an important point: it isn’t done once per channel — we do this every n days (I think n is 3; I’d have to check to be sure).
The reason why is that sites change their images, and when that happens we get bug reports in NetNewsWire that the new image isn’t picked up. I tell people to wait a few days, and it will get picked up. (This is sometimes very, very frustrating to people!)
And that’s the main reason, other than time, that we haven’t made changes that require more downloading. There are enough complaints from site owners about bandwidth use by RSS readers, and NetNewsWire specifically, that I want to handle this very carefully.
ETags to the rescue, I guess. How is downloading an icon with a size of 1-2 KiB if optimized, like the favicon of this very site, every couple of days a problem, if downloading a feed needs dozens to low hundreds of KiB?
I understand why you are cautious, but sometimes people complain profusely and take things out of proportion.
IMHO, it would be much better if the automatic refreshing of feeds would be turned off, even if conditional loading is working properly. Then people would manually refresh the feeds when they actually want to read something. Defaults matter.
There are enough complaints from site owners about bandwidth use by RSS readers, and NetNewsWire specifically, that I want to handle this very carefully.
I completely understand. I was just reading someone complaining about overzealous RSS clients recently though thankfully not NetNewsWire in this case! If I wanted to take a stab at implementing something to see how it would look I'm guessing the place to start would be FeedIconDownloader? This is complicated by the fact that I don't know Swift but no better time to learn than now.
@timhillgit I don’t want to dampen your enthusiasm! But NetNewsWire’s image handling needs a complete re-work (for this issue and others), and it needs to be me doing that work. I hope you understand!
It seems NNW may be ignoring JSON feed favicon fields as well as the icon fields.