Behaviorally, it's a dead practice. As individuals, we used to look at all content ingested by readers (programs or Google Reader/feedly) and ourselves cherry-

Behaviorally, it's a dead practice. As individuals, we used to look at all content ingested by readers (programs or Google Reader/feedly) and ourselves cherry-pick the articles, posts we wanted to see. Like an old newsgroup reader. Gradually that function has moved into programming beyond your control showing you suggested content filtered via models that show you only what they think you want to see. Buzzword: AI. Roll your eyes. Some sites would provide a teaser, others full content, some would put an advertiser's message in the body and a catchy title. It was up to the content maker. Typically there'd always be some reduction in the actual markup/content itself. Interesting things you really liked you might have clicked into and seen on the original site for a full experience, fed those people's ads and analytics. But the bottom line is it all largely interworked. One of my favorite things was using iGoogle or netvibes because those two flagships took RSS widgets. Using either custom programming or something like Yahoo Pipes you could cobble together something useful. Like make your own google homepage or dashboard containing both your calendar appointments, filtered gmail, and quirky things like server uptimes, alerts, API usage limits widgets, fun webcomics. From a publisher's perspective, RSS is still used to connect disparate publishing systems together since it's a standard. From one content management system you can pipe material to a blog widget, to a mobile app endpoint, to a partner site, to an affiliate. Direct site hosting is down but even now we use RSS to feed media partners like Facebook instant, Google News producer, Google News on [Voice] Assistant, twitter (via publish vendor), Apple podcasts (actually that might be JSON, but maybe wasn't always?), etc.