Guidelines

This page page lists some guidelines for writing feeds so that they will be displayed well in R3R. If you're a feed developer, please enable warnings (in the "Feeds" tab of the settings dialog).

General

1. Use the correct content type. Starting with 1.1.3.3, R3R uses the content type to decide which parser to trigger. If you use the wrong content type, R3R may use the wrong parser or no parser at all.
2. Do not use HTML in RSS.
3. Avoid character references.

RSS 3.0 Feeds

1. Limit lines to eighty characters. The RSS 3 spec states that readers not wrap lines and not to go to the next line until a newline character is encountered. R3R obeys the specification and allows lines to run on forever. So, if you don't want users to have to bother with horizontal scrollbars, limit lines to eighty characters.
2. When inserting a line break into a line, precede the characters on the new line with white space. Again, in accordance with the spec, text that is flat against the left is considered a new name (and will probably be rightly ignored). Whitespace before the text will let R3R know that this text is a continuation.
3. Avoid blank lines before the first item and after the last item. This will produce blank items. Such things aren't covered in the spec, so I don't know whether this is correct or not. However, it does reduce the code needed.

RSS 0.9–2.0

1. Due to the crudity of the XML parser in R3R 1.1.3.4 and earlier, there are a few things needed:
   1. Include no more than one item element per line. Do this:

      <item>
        <title>My Adventures</title>
        <description>My Adventures are cool!</description>
      </item>

      Not this:

      <item><title>My Adventures</title>
      <description>My Adventures are cool!</description></item>

   2. Do not span a tag across two or more lines.

ESF

1. Use tabs, not spaces, as separators.
2. The date should be a UNIX timestamp. R3R will support any format understood by the PHP strtotime function, but that use isn't global.
3. Avoid using more than three fields (time, link, subject) in each item. As of 1.2.1, R3R supports an optional forth field (description), but that's not standard and may be removed or replaced.
4. The standard content type for ESF is text/plain, which isn't as wise a decision as it appears to be. As of 1.2.1, text/x-esf is also supported. Starting in 1.3a3, the widely-used esf/text is also supported. It would be nice if other readers would follow suit; but for now, labelling your ESF feeds as text/plain is probably the best (or least bad, rather) practice, and anything else is proprietary.