Couldn't those selectors be maintained by the community? Instead of everyone deploying this on their own GitHub Actions, and having to fix it independently when it breaks, a single repo with all kinds of feeds maintained by everyone?
[deleted]
Show HN: RSS feeds for arbitrary websites using CSS selectors
111–120 of 134 posts
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#112It seems that RSS feed generators are a bit like static site generators: it's often thought to be easier to make your own than to learn to use someone else's. Anyway, here's another self-hosted open source RSS feed generator for arbitrary websites: https://github.com/hueyy/HungryHippo
Because the design of RSS/Atom put all of the complexity on the client (polling, state management, etc.) it's literally the same as static site generation. And by "the same", I don't mean "an equivalent but separate problem". I actually think having two separate generators—one outputting HTML, the other RSS—seems a bit wasteful. They're both parsing (presumably) the same content hierarchy and outputting it as SGML/XM…
This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed.
See https://sfeed.org. In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty.
Vinni, might you be interested in enabling the standard in Feed Me Up?
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#113Earlier quoted context omitted.
Because the design of RSS/Atom put all of the complexity on the client (polling, state management, etc.) it's literally the same as static site generation. And by "the same", I don't mean "an equivalent but separate problem". I actually think having two separate generators—one outputting HTML, the other RSS—seems a bit wasteful. They're both parsing (presumably) the same content hierarchy and outputting it as SGML/XM…
This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed. See https://sfeed.org . In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty. Vinni, might you be interested in enab…
There already is such a standard! https://microformats.org/wiki/hatom
Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though.
(That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#114Earlier quoted context omitted.
This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed. See https://sfeed.org . In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty. Vinni, might you be interested in enab…
There already is such a standard! https://microformats.org/wiki/hatom Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though. (That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
https://microformats.org/wiki/h-feed is the up-to-date version
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#115Earlier quoted context omitted.
This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed. See https://sfeed.org . In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty. Vinni, might you be interested in enab…
There already is such a standard! https://microformats.org/wiki/hatom Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though. (That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
Ah thanks, didn't know about hAtom, will investigate that.
I do think it's (much) easier to add some HTML classes than output an entire separate file.
I've been using Nuxt + Strapi as my new CMS stack, and while it's a big step forward in so many other ways, outputting an RSS feed is far from automatic.
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#116Earlier quoted context omitted.
There already is such a standard! https://microformats.org/wiki/hatom Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though. (That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
https://microformats.org/wiki/h-feed is the up-to-date version
I like this name better — the h prefix is cool in that it shows things are coming all the way from basic HTML.
Microformats, I see this is the proper way.
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#117I’m glad to see that you’re using Atom rather than RSS, but you’re still calling it RSS. Can I convince you to stop calling it that? It’s factually inaccurate, and keeps RSS, the inferior format, more popular by virtue of mindshare. Just call them feeds, the proper generic term.
RSS is fine for most uses, and is a much better "brand" than Atom.
There never was a valid reason to define a separate format rather than extending RSS to clarify ambiguities - I think its time to drop this bikeshedding and just think of Atom as a slightly different type of RSS.
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#118Earlier quoted context omitted.
There already is such a standard! https://microformats.org/wiki/hatom Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though. (That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
https://microformats.org/wiki/h-feed is the up-to-date version
Ah thanks - been out of that world for a long time now.
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#119Couldn't those selectors be maintained by the community? Instead of everyone deploying this on their own GitHub Actions, and having to fix it independently when it breaks, a single repo with all kinds of feeds maintained by everyone?
Yes, say more, please.
I've long been waiting for the rise of the unblocker. Community curated, like you suggest.
Ad blockers use filters to exclude. Like a blacklist.
My hunch is a strategy of using scrapers to extract OC, completely skipping over ads, would also be viable.
The output could be a bit more rich than today's Reader View.
Re: Show HN: RSS feeds for arbitrary websites using CSS selectors
#120Earlier quoted context omitted.
Why would a project on GitLab be running GitHub Actions? The project's doc acknowledges that git is distributed and can run an automation script of the user's choice of environment, and so should our language match this rather than implicitly endorsing a centralized service.
I think they simply meant 'instead of everyone running their own CI', not GH Actions in general - they're asking for a centralized feed repository and not one that is subject to people putting in work every few months to fix things that break, as that's likely to hurt adoption. In my opinion it sounds like a request for an open source/more community maintained feedly.com.
I'm aware of this. It's more that words matter and have power and we should not choose to adopt the language of a centralized platform when there are words that encompass all.