4 ms·

That article also has an XHTML 1.0 Transitional DOCTYPE, and wastes a request trying to load JavasScript for Google Plus.... this is not up-to-date information.

That article also has an XHTML 1.0 Transitional DOCTYPE, and wastes a request trying to load JavasScript for Google Plus.... this is not up-to-date information. The "advantages" are minor at best, and exclusively relevant to a developer, with very little impact on the end-user

kemayo 6y ago
> exclusively relevant to a developer Which would presumably be why the developer chose it, yes.
lucideer 6y ago
I wasn't expressing any opinion one way or the other, nor did I provide the article as a reference. The original commenter seemed to be questioning the choice of Atom over RSS, and that article is what they posted as their reference; which seemed odd to me since it argues for using Atom over RSS. Why would you consider RSS over Atom (you seem to exhibit a preference but you have also neglected to list any of the reasons)?
chrismorgan 6y ago
Not exclusively relevant to a developer. I have one or two things in my feeds that can’t be expressed in RSS, such as HTML markup in my titles (which I use for <strong>, <code> and I think <em>). I also have angle brackets in a title, which I would be afraid to do in RSS because I’m confident that some clients would butcher it, and they wouldn’t even be wrong since RSS don’t care.
- mikece 6y ago
  This, to me, makes me ask what the purpose of a feed even is. If it's to deliver data then RSS, Atom, JSON, or YAML shouldn't make any different at all. But if it's to deliver data and markup... now we're making decisions a client could override at best or result in unreadable/a11y unfriendly content at worst. Maybe it's just me but I've never considered the feed as a place to be putting markup but even if we want to go that route then RSS's <![CDATA[ ... ]]> addresses this. What am I missing?
  - kemayo 6y ago
    Markup's part of the data. Particularly in chrismorgan's example, where it's semantic content. As for CDATA, I think you're right that it'd work in this case (assuming that client apps cope with it there, but if the Atom equivalent works then presumably it should). I suspect that what we're looking at here is software which is poorly generating its RSS. Probably Wordpress, since I'm at least fairly confident that it doesn't put CDATA in its item titles regardless of their content.
  - chrismorgan 6y ago
    CDATA is purely a convenient way of encoding character data, of avoiding needing to escape <, & and > all the time. It doesn’t change the semantics at all, and if any client does vary the semantics based on this, it is wrong to do so. RSS doesn’t say what format any of its content is in. You have to guess if it’s plain text or HTML. This can easily go wrong. The result is that you can’t trust the handling of characters like <, & and > in titles or in supposedly-plain-text descriptions in RSS feeds. Seriously, just use Atom.

kemayo 6y ago

> exclusively relevant to a developer Which would presumably be why the developer chose it, yes.

lucideer 6y ago

I wasn't expressing any opinion one way or the other, nor did I provide the article as a reference. The original commenter seemed to be questioning the choice of Atom over RSS, and that article is what they posted as their reference; which seemed odd to me since it argues for using Atom over RSS. Why would you consider RSS over Atom (you seem to exhibit a preference but you have also neglected to list any of the reasons)?

chrismorgan 6y ago

Not exclusively relevant to a developer. I have one or two things in my feeds that can’t be expressed in RSS, such as HTML markup in my titles (which I use for <strong>, <code> and I think <em>). I also have angle brackets in a title, which I would be afraid to do in RSS because I’m confident that some clients would butcher it, and they wouldn’t even be wrong since RSS don’t care.

mikece 6y ago
This, to me, makes me ask what the purpose of a feed even is. If it's to deliver data then RSS, Atom, JSON, or YAML shouldn't make any different at all. But if it's to deliver data and markup... now we're making decisions a client could override at best or result in unreadable/a11y unfriendly content at worst. Maybe it's just me but I've never considered the feed as a place to be putting markup but even if we want to go that route then RSS's <![CDATA[ ... ]]> addresses this. What am I missing?
- kemayo 6y ago
  Markup's part of the data. Particularly in chrismorgan's example, where it's semantic content. As for CDATA, I think you're right that it'd work in this case (assuming that client apps cope with it there, but if the Atom equivalent works then presumably it should). I suspect that what we're looking at here is software which is poorly generating its RSS. Probably Wordpress, since I'm at least fairly confident that it doesn't put CDATA in its item titles regardless of their content.
- chrismorgan 6y ago
  CDATA is purely a convenient way of encoding character data, of avoiding needing to escape <, & and > all the time. It doesn’t change the semantics at all, and if any client does vary the semantics based on this, it is wrong to do so. RSS doesn’t say what format any of its content is in. You have to guess if it’s plain text or HTML. This can easily go wrong. The result is that you can’t trust the handling of characters like <, & and > in titles or in supposedly-plain-text descriptions in RSS feeds. Seriously, just use Atom.