Quirky content considerations in RSS feeds

The separators I’ve been putting between each of the week’s end notes are HR elements styled as 3 blue dots. This is one of those seamless finishing touch things Gutenberg offers.

When output on the front-end of my site, several classes are added to the HR element so that it is styled properly:

<hr class="wp-block-separator has-text-color has-background has-vivid-cyan-blue-background-color has-vivid-cyan-blue-color is-style-dots" />

The style is then applied to a pseudo element:

.wp-block-separator.is-style-dots::before { .... }

This effectively accounts for a nice display in all modern browsers without me having to think about it.

When distributed via a feed, the styles are not included. The HR element remains, but feed readers may strip several of the classes that they aren’t using. This is similar to how email clients process HTML email.

Each feed reader makes its own decisions about this. The web version of Feedly includes the HR as a strong solid line with the wp-block-separator class intact. Feedly’s Android app appears to hide it entirely.

I’ve taken quick looks at Feedbin, Inoreader, Newsblur, and NetNewsWire and they all treat HR similarly: various shaded styles of a solid line.

Really, the only problematic one of these is Feedly’s Android app. Removing the hard line modifies the contextual display of each note. A reader may be confused when one line having to do with apples is suddenly another discussing beer.

One answer could be to replace HR elements in the feed output with an image that represents the break, but that seems a little silly. I like what Phil Gyford does with his week notes. Each starts with a § character that also acts as an anchor for direct linking. It’s probably more helpful to pursue an approach like that instead of altering the HTML just for the feed.

Another goofy example is emojis. WordPress provides full support for the capture and storage of emojis as well as a compatibility layer using the Twemoji project. This layer replaces raw emojis in content with hosted images on s.w.org. The pizza emoji becomes this in the feed:

<img src="https://s.w.org/images/core/emoji/12.0.0-1/72x72/1f355.png" alt="{actual pizza emoji}" class="wp-smiley" style="height: 1em; max-height: 1em;" />

The alt text has an actual pizza emoji in it, but if I put it there, it gets replaced with an image, so that code blurb becomes its own mini pizza recursion.

What’s cute about this is when a feed reader (or other source) tries to find an image that it can display alongside an article. If the only image in the article is this emoji, then things appear in an interesting way.

I’m not sure yet what to do about this. I’ll probably try to disable the emoji replacement in the feed to see what happens. I think in general it will be okay, though it does rely on the feed reader storing the data properly and on peoples’ browsers and devices supporting emoji. The biggest impact this has is probably on Windows browsers, though it seems like support is generally available now.

That’s all I have for now. I’m sure there are more. I just need to keep adding elements to blog posts and watching for the effects. 🙂