2 ms·

I shall give my usual plea (for the OP and feed authors alike): except for podcasts, please deal in Atom rather than RSS if you have a choice. Let RSS die. Outs

• CharlesW 5y ago
  > …Atom is the technically superior format, including resolving various unspecified behaviour that does lead to inconsistency across clients, such as with respect to HTML markup in titles (which RSS has no answer for… The answer seems unambiguous in the RSS spec, which is that <title> is plain text (not HTML). The reason I know it's not unspecified is that entity-encoded HTML is documented as supported in other elements (e.g. <item><description>). Your evangelism for Atom is interesting because, of the hundreds of feeds in my newsreader, I don't believe any are Atom. So my impression was that Atom was "at least as dead as RSS" for user-facing applications, which makes me curious what the popular use cases are for it these days.
  • chrismorgan 5y ago
    The problem of RSS is that it’s not governed by any spec. Yes, the spec says <description> can contain HTML and doesn’t say that about <title>, but RSS is truly defined by usage rather than spec, much more than most formats. As a weak example showing this philosophy early on, from <https://www.rssboard.org/rss-0-9-2 https://www.rssboard.org/rss-0-9-2>, emphasis mine: > Further, 0.92 allows entity-encoded HTML in the <description> of an item, to reflect actual practice by bloggers, who are often proficient HTML coders. And that’s RSS in a nutshell, a format specified only in reaction to prevalent usage, where non-conformant documents are a normal part of life, and parsers are lax in a variety of unspecified ways because they’re reacting to usage. And what I have observed is various RSS feeds with titles containing characters significant to HTML being mangled by some feed readers, and various RSS feeds with descriptions that are plain text (possibly with characters like <, & and >, possibly not) so that some feed readers try to guess whether the <description> is in fact plain text or HTML. The very existence and popularity of <content:encoded> is an acknowledgement that <description> is broken. Atom is good in this regard because it provided a sane definition that people are vastly more likely to actually conform to; you can take the guesswork out of things. I still wish Atom supported providing both text and html values; e.g. in https://chrismorgan.info/blog/make-and-git-diff-test-harness/ https://chrismorgan.info/blog/make-and-git-diff-test-harness..., my HTML title is “Using <code>make</code> and <code>git diff</code> for a simple and powerful test harness”, while my text title is “Using `make` and `git diff` for a simple and powerful test harness”. On principle, I use the HTML version, but alas, most feed readers will strip the formatting and leave just “Using make and git diff for a simple and powerful test harness”. I took a look through some of the feeds I subscribe to; RSS is definitely the significantly more popular format among them, but Atom is common too.
• amadeuspagel 5y ago
  > And possibly the autodiscovery needs tweaking too, as I observe it not finding the feed on my site https://chrismorgan.info/ https://chrismorgan.info/, which is properly specified; my first guess is that it’s not coping with the type=application/atom+xml attribute. I fixed that: https://mergefeed.net/Untitled?urls=https://chrismorgan.info/ https://mergefeed.net/Untitled?urls=https://chrismorgan.info... > In related news, MergeFeed is currently vulnerable to injection attacks because it mishandles Atom titles that are specified as text. If you specify a title as HTML or XHTML, it filters out a <script> element properly (good! and while retaining inline formatting too!), but if you specify a title as text, it doesn’t escape the HTML (which is what it should do) or filter it (which would have been wrong but would at least have closed the security vulnerability). Proof of concept: https://mergefeed.net/-?urls=https://temp.chrismorgan.info/xss.atom https://mergefeed.net/-?urls=https://temp.chrismorgan.info/x... I fixed that too. But for now I wasn't able to fix it without also removing formatting. I might be able to figure out how to keep formatting without allowing XSS attacks later, but I'm not sure that's even a good idea. It's kind of a link aggregator and link aggregators generally don't allow formatting. You don't want people to try to gain attention that way, leading to an arms race.
  • chrismorgan 5y ago
    > I'm not sure that's even a good idea. It's kind of a link aggregator and link aggregators generally don't allow formatting. You don't want people to try to gain attention that way, leading to an arms race. Wait till you hear about Unicode bold and italics: https://yaytext.com/bold-italic/ https://yaytext.com/bold-italic/. (I hold that most tools being weak doesn’t mean that my tools should be weak, and I view text-only titles as weakness, one that can be solved without introducing problems, so long as you don’t get this encoding problem.)
  • chrismorgan 5y ago
    I think that autodiscovery is only finding the first feed. Since you’re aggregating feeds, I’d expect it to find all feeds on all pages. Sample page with multiple feeds: https://chrismorgan.info/blog/tags/fun/ https://chrismorgan.info/blog/tags/fun/ has the site-wide feed and then the tag-specific feed. I say only “I think” at the start of this comment because the entries in the second feed are a subset of the entries in the first, though it has a different feed ID and title, and I can imagine it possibly merging them. Losing formatting makes me a little bit sad. The widespread idea that titles are necessarily plain unformatted text is just bad. Italics especially are very regularly useful.