Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom is better than RSS, in ways that matter

chrismorgan.info

Post reply on HN
Print view View original

51–60 of 111 posts

Re: Atom is better than RSS, in ways that matter

#51

Post by tjansen »

chrismorgan wrote: post #47
tjansen wrote: post #31

I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow. In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt a…

Consider the title of my article: “Atom is better than RSS, in ways that matter ”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.) We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t…

> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles?

1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers that don't support the same subset. No renderer can allow it completely (...). HTML sanitation/injection becomes a much bigger problem when it's not limited to a text body that can be relatively easily sandboxed.

2. If you allow every feed to define its own font style or even color, that makes a list of posts look like a 2005 MySpace page. :)

It is producing bad UIs. Renderers can't really render it as plain text, as they might lose a part of the meaning. But they also can't really allow it because it might make their output look like trash. In the end, that would force renderers to develop complex heuristics of which elements and styles to allow, which to modify (do your HTML titles support dark mode? accessibility?), and which to filter out.

3. I don't see the practical value of having in a headline. If it shouldn't be rendered in a different way for obvious reasons, and XML is not designed for human consumption, what is it good for? Who is the consumer of the tag? AI?

Re: Atom is better than RSS, in ways that matter

#52

Post by chrismorgan »

tjansen wrote: post #51
chrismorgan wrote: post #47

Earlier quoted context omitted.

Consider the title of my article: “Atom is better than RSS, in ways that matter ”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.) We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t…

> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? 1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers…

Here’s an example of in titles being quite valuable: https://chrismorgan.info/blog/make-and-git-diff-test-harness....

Inferior plain text: Using make and git diff for a simple and powerful test harness

Better plain text: Using `make` and `git diff` for a simple and powerful test harness

Better HTML: Using make and git diff for a simple and powerful test harness

I use the second for the and og:title on my site, and the third in the and feeds. It will unfortunately be turned into the first by some feed readers, but that’s their problem. (Some feed readers do accept a subset of HTML phrasing content.)

> If it shouldn't be rendered in a different way for obvious reasons

I don’t perceive your obvious reasons.

Re: Atom is better than RSS, in ways that matter

#54

Post by BoingBoomTschak »

latexr wrote: post #36

Personally, I don’t care at all since we’ve gotten JSON feeds. https://en.wikipedia.org/wiki/JSON_Feed Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated rea…

sfeed and newsboat don't support it, though. I do note that elfeed does.

Re: Atom is better than RSS, in ways that matter

#55

Post by tjansen »

chrismorgan wrote: post #52
tjansen wrote: post #51

Earlier quoted context omitted.

> We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? 1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers…

Here’s an example of in titles being quite valuable: https://chrismorgan.info/blog/make-and-git-diff-test-harness... . Inferior plain text: Using make and git diff for a simple and powerful test harness Better plain text: Using `make` and `git diff` for a simple and powerful test harness Better HTML: Using make and git diff for a simple and powerful test harness I use the second for the and og:title on my site, and t…

I agree that it makes sense on that page. But only because the rendering of the page is completely under the control of the author, and the page shows only that one page. It's different if the text is rendered by an RSS reader in a different context. You don't know the font, color, or text weight it is rendered with in an RSS reader (which also depends on the context, like unread posts being bold). Imagine the same title in a list of post titles. I think it would stick out and make the list much harder to read.

Re: Atom is better than RSS, in ways that matter

#56

Post by masfuerte »

chrismorgan wrote: post #47
tjansen wrote: post #31

I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow. In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt a…

Consider the title of my article: “Atom is better than RSS, in ways that matter ”. That emphasis belongs there, and it’s mildly bad to lose it. (For presentation on my own site, I also control the line break position on larger screens; but that wouldn’t be appropriate for feeds, where you can’t control the presentation.) We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t…

There is precedent. The HTML title element cannot contain markup. Titles may be cited in many places and formatting may not be available. If a title requires formatting to convey its meaning it's a bad title.

(Not that I want to defend RSS. In early versions valid RSS wasn't necessarily even valid XML. It is very poor.)

Re: Atom is better than RSS, in ways that matter

#57

Post by rhdunn »

mbirth wrote: post #39
latexr wrote: post #36

Personally, I don’t care at all since we’ve gotten JSON feeds. https://en.wikipedia.org/wiki/JSON_Feed Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated rea…

But JSON doesn’t allow you to run it through an XSLT and get a normal webpage out of it, does it?

XSLT 3 (via XPath 3.1) has support for maps, arrays, and parsing JSON to/from those or an XML representation. The XML representation is easier to work with in 3.

There's a draft version of XSLT 4 that Saxon supports which adds more capabilities for working with map and array types.

Re: Atom is better than RSS, in ways that matter

#58

Post by rhdunn »

leephillips wrote: post #10

The article is correct. Anyone who knows what they’re doing builds an Atom feed, not RSS. In fact, I thought this was common knowledge a decade ago.

Unless they are building a podcast application which is predominantly RSS 2.0 based with some extensions from itunes and others to provide additional podcast-specific metadata such as episode and season information.

Re: Atom is better than RSS, in ways that matter

#59

Post by vivzkestrel »

munch117 wrote: post #41
vivzkestrel wrote: post #28

Earlier quoted context omitted.

- the idea behind storing the raw feed items instead of processed ones is - what happens if your processing logic changes 6 months down the line? - for example today you decide you want to remove all extra spaces and lowercase all titles before storing them - 6 months down the line you want to revert, what now?

Absolutely store the raw data. For the reasons you state. But also store derived data. Titles, authors, dates, article texts. You need those for whatever your application does. You don't want your application logic to be working with the raw text. > how will you handle updates to the feed? When polling, consider using HTTP HEAD to check for changes before GET. What you do when an article ID reappears with different c…

so how do you store raw xml data in postgres?

Re: Atom is better than RSS, in ways that matter

#60

Post by gchamonlive »

tjansen wrote: post #55
chrismorgan wrote: post #52

Earlier quoted context omitted.

Here’s an example of in titles being quite valuable: https://chrismorgan.info/blog/make-and-git-diff-test-harness... . Inferior plain text: Using make and git diff for a simple and powerful test harness Better plain text: Using `make` and `git diff` for a simple and powerful test harness Better HTML: Using make and git diff for a simple and powerful test harness I use the second for the and og:title on my site, and t…

I agree that it makes sense on that page. But only because the rendering of the page is completely under the control of the author, and the page shows only that one page. It's different if the text is rendered by an RSS reader in a different context. You don't know the font, color, or text weight it is rendered with in an RSS reader (which also depends on the context, like unread posts being bold). Imagine the same t…

If html in titles were an opt-in feature from the beginning none of this discussion would be happening
Post reply on HN