A directory of people who love RSS(andrewshell.org) |
A directory of people who love RSS(andrewshell.org) |
And so I wish people would stop calling feeds RSS, because it continues to compound the problem. Let RSS die! More than once I’ve seen people implement RSS feeds, at great pain and often with errors, simply because they hadn’t heard of Atom.
(I still need to decide which spec I hate more, RSS or OpenGraph. Hmm… RSS had more excuses for being bad, OpenGraph was just a spectacularly bad thing thrown over the wall by a company that should have known better. I drafted something examining how comprehensively bad it was some years ago, I should put it onto my new site and continue it at some point.)
We call them RSS feeds, RSS reader apps even if it might be implemented as an Atom feed.
While RSS is tricky to parse in practice, many of the challenges are due to invalid feeds, which Atom is not invulnerable to. Its very likely that there is a well-tested feed parser for your favorite programming language, so most developers using feed programmatically don't need to handle those challenges themselves.
For concerns like title encoding or summary vs full text description, you can handle those using namespaces. If you don't like any of the existing namespaces that do that you can create your own.
Password is vaultearly644988
Pardon the dust. There's an app tie-in that I'm almost done with too, a widget-first app that shows your RSS feed collections on your phone's home screen. It would really be great if we could start to bring about an RSS renaissance!
I have sneaked in.
Suggestions:
White or almost white text would be better.
Make “Add” button visible on homepage.
Make a possibility to batch suggest feeds - a lot of people have opml xml exports from Google Reader so they can give it to you. Processing info would be nice so I as a supplier would immediately know how useful I was.
Move explanatory part of RSS to some other part than homepage.
"White or almost white text would be better." -- There is some white text, headers and headlines mostly. Did you find the lack of contrast difficult to deal with?
"Make “Add” button visible on homepage." -- you mean like in the search results? That's a fine idea.
"Make a possibility to batch suggest feeds" -- I've been toying with how to handle OPML imports. Definitely a feature to come on the app, but I fear with mass submission on the vault I would be inundated with feeds, and the curation aspect would suffer. I want quality over quantity. But maybe there's a happy middle ground somewhere.
"Move explanatory part of RSS to some other part" -- yeah I guess this might be helpful to someone who doesn't know what RSS is, but then they probably aren't visiting anyway lol I'll give it some thought.
Appreciate it. Thanks again.
(Not judging, just testing my radar)
Can't blame them; it draws a bit more attention than normal.
https://pico.sh/feeds is an ssh app that is an rss-to-email service.
My favorite part of FeedLand is that you can see who subscribes to a blog and where else they subscribe. This makes RSS feel social, without the algorithmic tricks of traditional social media. Here's the listing for my blog, for example: https://feedland.com/?feedurl=https%3A%2F%2Falexsci.com%2Fbl...
We're going to have a new version pretty soon, hooking it up with RSS.chat.
I wish people would blog more like in the old days.
I don't really use RSS myself anymore, though; not since I stopped using Google Reader a few months before they pulled the plug. Wouldn't even know where to start nowadays.
Even though it's a simple standard that's been around for decades, there are still many sites which serve their feeds with a subtly wrong format. When something doesn't work, users come knocking on your door saying "it works in X reader but not in yours", so now you have to handle that and contribute to the ever growing list of out of spec edge cases that feed readers need to account for.
I think we should take Google to court over destroying blogs and force them to add back RSS support.
One of the downsides I saw when evaluating JSON Feed was that it doesn't use GUIDs, which can cause problems when the same post is present in multiple feeds (I.E. syndication).
When I last looked I found that every feed reader supporting JSON feeds also supported RSS/Atom and every website with a JSON feed also had an RSS or Atom feed, so it seems easiest to ignore the JSON Feed format.
There's not really a "standard" character set and an "emoji" one. There is an emoji block (U+1F600 to U+1F64F), and this heart (U+2665) is not in that. But this heart is an emoji, in that the data file emoji-data.txt for contains `Emoji=Yes` ("=Yes for characters that are emoji", —UTS #51) for this character. However, this heart has `Emoji_Presentation=No`, which "=Yes for characters that have emoji presentation by default" (—UTS #51).
So basically, it should present, by default, in its non-emoji appearance. (Though there seem to be a number of readers for whom that isn't true. I think that's macOS being badly behaved.) There are some characters that can flip/flop between a "text" (normal monochrome) presentation and an emoji presentation; all of the card suit characters are. Unadorned (e.g., just U+2665 alone) then, you have to follow the emoji default presentation rules. In some contexts, such as web pages, that's "just do what that Emoji_Presentation flag says" for those characters, but see [§Presentation Style](https://www.unicode.org/reports/tr51/proposed.html#Presentat...) for exceptions to the rule. (HN is not an exception.) But you can also follow the character with a variation selector, to try to force either text (U+FE0E) or emoji (U+FE0F) presentation.
There are a number of what I'd call "yeah that's definitely an emoji" outside the Emoji block, too. Like U+2705 "white check in green box" (which HN disallows me posting); that one is Emoji=Yes but also Emoji_Presentation=Yes)
(IDK if Emoji=Yes Emoji_Presentation=Yes is HN's filter … but that'd be what I would do, if I wanted to filter out emoji like HN does.)
UTS #51: https://www.unicode.org/reports/tr51/proposed.html#Emoji_Pro...
(Also, note that the title was changed; the original HN title was "I ♥ RSS")
♠♡♢♣♤♥♦♧
https://www.compart.com/en/unicode/U+2665
It's part of the card suite icons
♠♡♢♣♤♥♦♧
I think the reason its not stripped is because it's actually "U+2665 : BLACK HEART SUIT {valentine}" which predates the emojis. Lots of fonts and OSes will render these older unicode symbols as emojis
Unsupported unicode code points are just rendered using a place holder.
Chess pieces too. I think you could technically play a chess game here pretty easily if you were so inclined.