[rss] Support article text in <content:encoded> </content:encoded> tags #4

Closed
opened 2025-10-31 16:55:24 -05:00 by GiteaMirror · 1 comment
Owner

Originally created by @dezponia on GitHub (Mar 1, 2025).

Originally assigned to: @ricoberger on GitHub.

Problem

FeedDeck doesn't include the full article text if its provided within <content:encoded> and </content:encoded> tags in the RSS Feed.

RSS Feeds that provide the article content in the <description> and </description> tags work as expected with the full article text shown within FeedDeck.

While this may not be an issue for feeds that only provide snippets of the article it becomes an issue when sites offer feeds with the full article text.

For example Ars Technica and The Verge offers full article text feeds to paying subscribers which don't work because of this. These feeds only show the very limited Headline (<title>) and subheading/"second deck" (<description>), but misses the article body (<content:encoded>) so you have to click the "Open Link" button and read the article on their site.

Examples of sites that use <content:encoded> and </content:encoded> for their article text:

Examples of sites that use <description> and </description> tags for their article text:

Proposed solution/behavior:

Ideally if a feed provides <content:encoded> and </content:encoded> tags these should be rendered as article content in FeedDeck when you click the post to expand it. This content does not need to be shown before expanding the post.

The <description> and </description> should continue to serve as a quick description of the article in the feed and be cut off after a few lines if it goes on for too long. When the post is expanded the full description can be rendered. This is exactly how FeedDeck works today for LWN and GOL linked above and it works well.

This solution would make FeedDeck cater to both types of feed, those that use the <description> tag for the full article content, and those that compliment it with/use <content:encoded> for full article content.

Originally created by @dezponia on GitHub (Mar 1, 2025). Originally assigned to: @ricoberger on GitHub. ## Problem FeedDeck doesn't include the full article text if its provided within `<content:encoded>` and `</content:encoded>` tags in the RSS Feed. RSS Feeds that provide the article content in the `<description>` and `</description>` tags work as expected with the full article text shown within FeedDeck. While this may not be an issue for feeds that only provide snippets of the article it becomes an issue when sites offer feeds with the full article text. For example Ars Technica and The Verge offers full article text feeds to paying subscribers which don't work because of this. These feeds only show the very limited Headline (`<title>`) and subheading/"second deck" (`<description>`), but misses the article body (`<content:encoded>`) so you have to click the "Open Link" button and read the article on their site. **Examples of sites that use `<content:encoded>` and `</content:encoded>` for their article text:** - https://arstechnica.com/rss-feeds/ - https://www.theverge.com/ **Examples of sites that use `<description>` and `</description>` tags for their article text:** - https://lwn.net/headlines/ - https://www.gamingonlinux.com/rss/ ## Proposed solution/behavior: Ideally if a feed provides `<content:encoded>` and `</content:encoded>` tags these should be rendered as article content in FeedDeck when you click the post to expand it. This content does not need to be shown before expanding the post. The `<description>` and `</description>` should continue to serve as a quick description of the article in the feed and be cut off after a few lines if it goes on for too long. When the post is expanded the full description can be rendered. This is exactly how FeedDeck works today for LWN and GOL linked above and it works well. This solution would make FeedDeck cater to both types of feed, those that use the `<description>` tag for the full article content, and those that compliment it with/use `<content:encoded>` for full article content.
GiteaMirror added the enhancement label 2025-10-31 16:55:24 -05:00
Author
Owner

@ricoberger commented on GitHub (Apr 19, 2025):

Hi @dezponia, thanks for raising this issue. Until now we always preferred the description field over the content:encoded field. In #243 I changed this, so that now content:encoded field is preferred over the description field. The description field will only be used if the content:encoded field is not present or when the content of the field is longer then the content of the content:encoded field. I think this makes more sense when both fields are present.

@ricoberger commented on GitHub (Apr 19, 2025): Hi @dezponia, thanks for raising this issue. Until now we always preferred the `description` field over the `content:encoded` field. In #243 I changed this, so that now `content:encoded` field is preferred over the `description` field. The `description` field will only be used if the `content:encoded` field is not present or when the content of the field is longer then the content of the `content:encoded` field. I think this makes more sense when both fields are present.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/feeddeck#4