[HN Gopher] Style your RSS feed
___________________________________________________________________
Style your RSS feed
Author : captn3m0
Score : 354 points
Date : 2023-06-20 10:04 UTC (12 hours ago)
(HTM) web link (darekkay.com)
(TXT) w3m dump (darekkay.com)
| acidburnNSA wrote:
| Awesome. I was able to get this going easily enough on my jekyll-
| created site that uses the jekyll-feeds plugin. You just have to
| name the template right and it just works.
|
| https://github.com/jekyll/jekyll-feed/#custom-styling
| kseistrup wrote:
| So instead of using a blog engine, you could just publish the
| feed and XSLT to style it as a blog.
| slow_typist wrote:
| In a parallel world the whole web is served as XML and XSLT
| directly from the databases, or from rss authoring software. Web
| servers only serve the blobs like images and other media. Content
| Management is done by combining rss feeds according to site
| hierarchy via an enhanced OPML dialect, also parsed client side.
| One or more feeds per page. Some pages show only the newest
| entry, others show the first ten with pagination, or all entries.
| This is configured via the OPML dialect. The data sources of a
| website can be completely federated. A machine readable licensing
| system enables integration of content from third parties on your
| site -- without any backend changes! Social networks are
| basically thousands or millions of different sources in one huge
| OPML file plus some intelligence in the XSLT. Efficient caching
| on the network allows for very small and cheap servers for every
| content creator. Even your tablet could serve your feed.
| arek_nawo wrote:
| I didn't know the RSS feed could be styled - it's an interesting
| insight.
|
| That said, on the RSS as a whole, for most websites (mostly
| publications I suppose), adding RSS feed is a set-and-forget
| thing.
|
| Sure, it's great for readers as it allows them to read all the
| content from one reading app but, on the other hand, the
| publication can't provide a custom experience, or - what's most
| important for some publications - display ads. That's likely why
| RSS is slowly moving into obscurity, at least IMHO.
| nordsieck wrote:
| > Sure, it's great for readers as it allows them to read all
| the content from one reading app but, on the other hand, the
| publication can't provide a custom experience, or - what's most
| important for some publications - display ads. That's likely
| why RSS is slowly moving into obscurity, at least IMHO.
|
| Sure. But a title-only RSS feed seems like a very reasonable
| compromise.
|
| And it's so much better than what everyone seems to have moved
| to, which is email notification.
| arek_nawo wrote:
| This might be the solution. RSS readers could serve as a
| general link aggregators (like HN), but with immediate
| listings of the latest content from your favorite sites. Too
| bad most just prefer to get rid of RSS entirely.
|
| On the other hand, I don't necessarily dislike the email
| model (especially when having dedicated address just for
| newsletters) but it's much less comfortable than RSS and
| quite limiting from the publishing standpoint (given how far
| behind emails are behind modern Web).
|
| Personally I still try to have RSS in all my content websites
| (with full content) as I'm primarily thinking about reach
| rather than ads. The ones that I haven't implemented RSS for
| yet, are just because it was more challenging or required
| more effort when integrating with e.g. CMS or something.
| zuppy wrote:
| i found out a tool that convets emails back into RSS, it even
| provides a custom e-mail address that you can use per feed.
| it can be self hosted, or used on their website (which is ad
| free): https://kill-the-newsletter.com
| timf wrote:
| There are a lot of feeds now with titles and maybe a short
| paragraph of text, like the beginning of the article or a
| summary.
|
| There is a world of difference between sites maintaining
| those feeds vs. nothing at all. Having a signal that an
| article is there with even the slightest amount of context is
| so much better than the alternative.
|
| It's mildly annoying to visit a site for the full text (with
| your ad blocker), but signing up for newsletters etc. from
| each site one-by-one is really painful.
|
| If I'm going to take 5+ minutes to really read something,
| it's OK to visit the site. That means something is
| interesting or relevant enough to invest my time in. That
| signal can usually be gleaned from a title and short
| paragraph. Compared to the number of new things published
| every day, it's relatively rare to find things worth those 5+
| minutes.
|
| From what I can gather, many people use RSS readers to follow
| 5-10 feeds, and they slowly look through and read most of the
| articles. It serves as a convenient way to follow their top
| few sites and maybe a few aggregators like HN. Other people
| track 100s of feeds and quickly scan what's happening, only
| diving into something if it's interesting or important.
|
| I'm building a service for the second type of person (mainly
| because I'm that type of person, TBH). No idea what the ratio
| of "completionists" vs. "scanners" is. Having title-only
| feeds is not ideal for the latter group, but it's usually
| fine.
| Tyr42 wrote:
| I'm definitely in the completionist group and that keeps me
| off twitter or other stream sites, (and large slack groups)
|
| I need to read the things in my feed, or maybe skip, or
| maybe save for later and maybe come back to it.
| tourmalinetaco wrote:
| I've found some respite in email-to-RSS, but its still not
| great.
|
| I'm definitely interested in a (hopefully FOSS) service for
| us "scanners". I average around 300~ articles in my RSS
| daily, and I'm always hungry for more information. Though I
| should probably see about re-organizing it all so I'm not
| as consistently overwhelmed.
| timf wrote:
| I want to make a FOSS reader that we can run on our own
| machines. It would poll on demand and be really good at
| archiving sites/posts. A combination of feed reader and
| scraping/archiving from residential IPs (at a low rate)
| where it will almost always be successful.
|
| I want to pair that with an (opt-in) service for syncing
| feed subscriptions and handing off a stream of things
| worth archiving (it's often not urgent that this happens,
| you just want to make sure it happens soon so the content
| is not lost in a few years). That service could be a very
| low cost monthly subscription thing plus a FOSS option
| that you could run on a cheap VPS, etc.
|
| 24/7 services are also essential for generating
| notifications when something in a filter is spotted,
| being able to have an email gateway, doing things like
| POSTing items to other sites automatically, etc.
|
| Making that "full" service FOSS is not in the near term
| plans, though. This is a distributed system that has run
| 100s of millions of jobs already, has a very specific
| security and monitoring setup, uses a number of queues
| and databases, etc. From my past experience, it's really
| hard to support people with on-premises distributed
| systems software like this (FOSS or not). I couldn't do
| this part alone (bootstrapping and can't afford to hire
| anyone yet).
| yetanother-1 wrote:
| Have you used any modern RSS reader recently like inoreader,
| they load the content of the page without visiting the
| publishing website. So still, no ads.
| nordsieck wrote:
| > Have you used any modern RSS reader recently like
| inoreader, they load the content of the page without
| visiting the publishing website.
|
| I'm happy with newsboat[1]; but I'm not surprised that
| people have integrated scraping into RSS readers.
|
| Fundamentally, that's not a problem with RSS, that's a war
| between scrapers and content providers. If the email
| newsletter model persists long enough, I'd expect that
| people will come out with "newsletter readers" that scrape
| websites too.
|
| I'm not sure there's a good long-term solution to the
| problem. Aside from constant vigilance (obfuscation).
|
| ---
|
| 1. https://newsboat.org/
| tourmalinetaco wrote:
| Actually, "newsletter readers" exist in a form already
| with email-to-RSS.
|
| https://kill-the-newsletter.com/
| crushingk wrote:
| Newsboat FTW
| johannes1234321 wrote:
| Adding ads into feeds works, just make them an entry in the
| feed. I have also seen embedded images with ads.
|
| Issue is that Google Ads and such don't offer this and you
| don't get the "typical" ad networks.
|
| If RSS were more popular there wouldn't be a problem to
| build the required tooling.
|
| Even when feed readers don't send cookies etc. while
| fetching you can do a permanent redirect to a feed with an
| unique ID in the URL and most feed readers will store that
| URL, thus you can do tracking (incl. personalizing URLs in
| the feed) and all that.
|
| What saves reader privacy currently is the small user base.
| arek_nawo wrote:
| Yeah, that's roughly aligns with what I've experienced.
| RSS is beneficial to publishers when reach is the top
| priority (e.g. it's a company marketing blog or the ads
| are "embedded" directly into the content).
| tannhaeuser wrote:
| Haven't tried now, but it should be possible to just use CSS as
| long as the feed is served as text/html to convince your browser
| to interpret <style> elements as stylesheets.
|
| Update: problem might be that browser sniffing for UTF-8 won't
| work, and that the doc might have multiple (RSS) title elements
| where the browser expects one (!) in head content
| darekkay wrote:
| Interesting idea. But another issue might be that RSS readers
| won't be able to parse the content correctly if it's not served
| as text/xml (just an assumption).
| tannhaeuser wrote:
| You can serve it as both text/html and text/xml, with feed
| readers accepting/negotiating the latter.
| darekkay wrote:
| Ah, makes sense!
| ryanbrunner wrote:
| I dunno that I would trust feed readers to do content
| negotiation properly. Again, I work with mostly podcast RSS
| feeds, but clients are generally atrocious about following
| standards (just ran into one recently where Apple Podcasts
| flat out ignores XML namespaces).
| Dachande663 wrote:
| Many, many years I had the misfortune to end up on a project that
| used Symphony[0] as the CMS for a client website. The entire
| theming system is based on XSLT, which makes some things really
| nice and simple, and other basic stuff an absolute pain in the
| arse (trees, parents, changing values based on something else
| etc).
|
| [0] https://www.getsymphony.com/
| adregan wrote:
| Feels strange to say, but while looking at those XSL files I'm
| thinking: that looks really good.
|
| I cut my teeth on HTML5 and JSON APIs from 2010 and beyond, so I
| never really had to work with XML.
|
| I've never felt wholly comfortable with the mixing of semantic
| markup and data with the presentational elements required for
| styling. While advancements in CSS have improved the situation, I
| really like the boundaries demonstrated here and the inversion of
| of priorities: ie. we fetch the data and then we consider
| presentation rather than downloading the presentational layer
| which then in turn fetches the data.
|
| I know there is a lot of baggage around XML, but this aspect of
| it really does seem superior.
| larusso wrote:
| Seeing a post about XSLT in 2023 :) in the midd 2000th when XML
| was all the rage I had to learn a lot of this stuff to be
| forgotten forever :). To be fair I think XML was a good idea with
| too much complexity and ambition. Our old backend was based on
| SOAP to talk to flash over an XML RPC protocol. Got to love it.
| charles_f wrote:
| The name XSL itself still gives me chives, nightmares of
| incorrect namespaces and undebuggable conversion issues
| bradgessler wrote:
| I wish more people would consider XML + XSLT to build out web
| applications to improve tooling and the ecosystem around it.
|
| I know it's not in style--today it's all about exposing data as
| JSON and then templating it with something like Web Components.
| Meanwhile this is stuff that XML and XSLT has been doing for over
| a decade.
| norswap wrote:
| RSS maybe not be dead, but it's definitely less alive than it
| uses to be. The number of "blogs" these days that don't have a
| feed is absolutely tremendous. The decisions of the browser
| companies to remove the RSS icons / deemphasize the features is
| criminal (especially Firefox, who doesn't have the nefarious
| interest the others have).
| WaitWaitWha wrote:
| I venture to say because in RSS various advertising can be very
| easily filtered out, and temporal & and geo-tracking can be
| completely eliminated.
| rhn_mk1 wrote:
| What about RSS eliminates tracking? Refreshing the feed is
| exactly the same HTTP request as fetching a page.
|
| With RSS you have to make the request periodically to stay up
| to date, so I'd say you trade some of that temporal tracking
| for extra geotracking.
| abdullahkhalids wrote:
| Many RSS SaaS providers would request the RSS once from
| their own server and then serve the cached request to all
| users subscribed to it. This basically makes it impossible
| to track the user in any form.
| rhn_mk1 wrote:
| This has nothing to do with RSS the protocol. There could
| just as easily be a SaaS scraping web sites and serving
| cached contents.
| [deleted]
| exoro wrote:
| Those blogs "don't have it" or "don't advertise it"? Seeing
| that most blogs are Wordpress or another platform that has RSS
| baked in by default it seems rare to come across one without a
| feed, even if you have to dig for it a bit.
| pphysch wrote:
| OTOH, RSS is looking more appealing than ever (in the last
| decade) with recent changes at Twitter and Reddit.
| julik wrote:
| XSLT... it's been a while I've seen that
| [deleted]
| jasonriddle wrote:
| Is it possible to style the rss feed for a Wordpress blog? I'm
| looking for the magical plugin that would help with this.
| ciroduran wrote:
| Do you remember when Feedburner promised to style feeds in a nice
| way while still providing RSS access for your feed readers? And
| then Google acquired it?
|
| Good times
| kmfrk wrote:
| I love RSS, but the one thing that almost makes me anxious is
| whether I'm going to make one of those mistakes that ends up
| republishing the whole RSS feed in people's readers.
| conesus wrote:
| NewsBlur tries to handle this case by comparing stories and if
| they match up to a certain percentage of the content, considers
| them duplicates.
|
| Here's the code that does the work:
|
| https://github.com/samuelclay/NewsBlur/blob/master/apps/rss_...
| rsolva wrote:
| What mistake typically causes this?
| chrismorgan wrote:
| Just changing the ID of an entry. (Atom:
| //atom:entry/atom:id. RSS: //item/guid.)
|
| The main time this happens is when people switch website
| backend or site generator or whatever, and don't take care to
| keep the same IDs. In practical terms, IDs are just opaque
| strings, but they're supposed to be IRIs (... even though you
| mustn't assume it can be dereferenced) and universally
| unique, so a common approach is to use the page's URL, which
| could lead to something like this if you change it:
| <link href="https://example.com/current-title/"
| type="text/html"/> <id>https://example.com/original-
| title/</id>
|
| Some systems avoid this by using a different form of ID, e.g.
| WordPress uses its internal post IDs: <link
| href="https://example.com/current-title/" type="text/html"/>
| <id>https://example.com/?p=12345</id>
|
| It doesn't need to be an https: URL, either; you'll sometimes
| come across UUIDs: <link
| href="https://example.com/current-title/" type="text/html"/>
| <id>urn:uuid:01234567-89ab-cdef-0123-456789abcdef</id>
|
| As a concrete example of changing things and keeping old
| things working, here's an excerpt from the template for my
| Atom feeds: <link href="{{ page.permalink }}"
| type="text/html"/> {%- if page.year < 2019 %}
| <id>{{ "http://chrismorgan.info/blog/" ~ page.slug ~ ".html"
| }}</id> {%- else %} <id>{{ page.permalink
| }}</id> {%- endif %}
| ttepasse wrote:
| An ancient proposal for stable IDs were Tag URIs [RFC
| 4151]: URIs which still have an understandable identifier
| like a domain but with a date encoded at the time of
| minting the URI which keeps the URI "valid" even if the
| domain lapses and minting "authority" moves to someone
| different.
|
| tag:chrismorgan.info,2019-01-01:blog/slug
|
| But the real problem, of course, is people caring: You'll
| need to store the ID with the content and continue using
| them when moving CMSs or domains. People, apart from your
| notable exception, don't do that.
|
| (Sorry for minting an example tag URI in your authority! I
| shouldn't have done that according to the RFC.)
|
| [RFC 4151] https://www.rfc-editor.org/rfc/rfc4151.html
| kmfrk wrote:
| I'm still not entirely sure. I think Reddit's had the same
| issue with some of its feed when subreddits went from private
| to public, so if even they struggle with it, then it might
| not be entirely straightforward.
|
| Not even sure RSS readers like Thunderbird have features to
| deal with duplicates like that.
| carrja99 wrote:
| I used to do this all the time back in the day, used to love it.
| kixiQu wrote:
| Consider sharing your OPML feed as a blogroll, too!
| https://tomcritchlow.com/2022/04/21/new-rss/
| petecooper wrote:
| I use Atom feeds for Github release / tag notification. The
| format is: https://github.com/org/repo/tags.atom
| https://github.com/org/repo/releases.atom
|
| For example: https://github.com/php/php-
| src/tags.atom
| https://github.com/textpattern/textpattern/releases.atom
|
| Chuck a bunch of those into your reader of choice, it works
| really well.
| mxmilkiib wrote:
| I use those to feed my release aggregator site
| https://libreav.org
| aendruk wrote:
| For a moment I puzzled over how you're applying XSLT to these
| but eventually figured out this comment isn't about the topic
| of discussion.
|
| Custom XSLT could be a fun feature for a feed reader.
| jamesq wrote:
| We style RSS feeds as part of our custom RSS tool. Most users of
| that aren't necessarily technical and so providing a more user
| friendly interface makes a huge difference. You can see an
| example at https://sniprss.com/sniprss/curiously-creative/
|
| I'd love to explore how we could do more with this as well as I
| see so much value but like it has been pointed out here, RSS is
| set and forget for many people and therefore isn't in the
| majority of user's minds. Also the utility of having content in a
| feed is undervalued IMHO.
| chrismorgan wrote:
| You don't seem to be doing the same thing: rather, you're
| sniffing for an Accept header, and if it includes text/html,
| you serve HTML, and if it doesn't, you serve an Atom feed with
| no XSL stylesheet.
|
| Incidentally, given this behaviour your response should include
| `Vary: Accept`. This is actually messing Firefox up a bit: open
| the document, it loads the HTML, View Source, it renders the
| source of the Atom, loading it from the cache according to the
| dev tools, not sure how it got there, _force_ reload and you
| get the source of the HTML. Your server is also not handling
| HEAD requests, but improperly responding 405 to them.
| leokennis wrote:
| I remember when Safari used to show RSS feeds in the title bar
| and used to render them with a nice filtering UI:
|
| https://www.askdavetaylor.com/3-blog-pics/safari-4-view-all-...
|
| Would love to get that back!
| billpg wrote:
| While I appreciate this approach, what I really want is when I
| click on an RSS link, the browser detects its an RSS and shows me
| a dialog telling me its an RSS page and shows a "Copy URL"
| button. If I click the button (or close the dialog) the browser
| returns to the page I was on.
|
| Making an RSS file look good for a human is nice, but it isn't
| for a human to look at.
| mawise wrote:
| With RSS autodiscovery[1] your browser (or today an extension)
| can identify an RSS feed and with one click submit it to your
| RSS reader. You don't even need to find the RSS link in the
| HTML.
|
| [1]: https://www.rssboard.org/rss-autodiscovery
| TheRealDunkirk wrote:
| No.
| robert_tweed wrote:
| If anyone is looking for a real-world example, the BBC does it:
|
| http://feeds.bbci.co.uk/news/rss.xml
| safety1st wrote:
| I'm not a frequent XSLT user but I'm aware for example that,
| for example, you can add any text you want to the presentation
| of the feed with <xsl:text>. Can you add script, images, and
| basically end up with something similar to a modern webpage?
|
| You have to wonder. What would the world look like if more
| publishers had gone the route of styling RSS or Atom feeds, and
| maybe supported and extended the relevant standards in the
| places they found those standards to be deficient? Could we
| have ended up with a world where content delivery was all RSS,
| the relationship was exclusively between you and the publisher,
| and we didn't need Meta as the middle-man sucking publisher
| profits dry while convincing our daughters to kill themselves?
|
| ...Nahhhhh, I'm sure that going full neanderthal, RSS LOOK
| SCARY, clubbing it over the head and removing it from a website
| is the better approach. /snark
| berkes wrote:
| I've never really liked JSON as replacement for XML. Had we
| continued with RSS, Atom and XML, not only would we make peer
| to peer distribution far easier, we'd have a very easy
| publishing mechanism.
|
| But we threw out XML for JSON. With JSON we need loads of
| custom, client side code to turn it into a DOM that the user
| can look at. With XML we only need XSLT. It won't work for
| all cases, but the majority of sites wouldn't need a single
| line of JS to renders sites. Yet here we are: shadow DOM,
| event listeners, useeffect, JSX, progressive hydration, and
| so forth and so on. To build web-experiences that we could
| deliver back in early 2000 but were deemed too complex and
| too daunting.
| ssdspoimdsjvv wrote:
| Good news, you can nowadays transform JSON using XSLT, even
| in the browser.
| kmac_ wrote:
| JSON is great, but lacks one feature that XML and its
| ecosystem has - extensibility and deep standarisation.
| XSLT, XML Schema, XML signing and encryption, native
| support of ids and refs, etc. All that missing points are
| doable with JSON or were added quite late, but yeah,
| standarisation is important.
| pjerem wrote:
| JSON somehow have standardisation with OpenAPI.
|
| But yeah, JSON is a pain. XML was pretty smart.
| michaelmior wrote:
| To be fair, many of the things you listed are able to
| implement features not possible with XSLT.
| darekkay wrote:
| > Can you add script, images, and basically end up with
| something similar to a modern webpage?
|
| Sure, you can use anything you would on a regular HTML page.
| I was consuming my local news website via their RSS feed in
| my browser, as it looked like a regular website (but without
| all the fluff). Unfortunately, they've dropped the custom
| view completely, and it's now back to raw XML content :(
| kixiQu wrote:
| The BBC and _other_ examples are present in the article under
| this heading: https://darekkay.com/blog/rss-styling/#examples
| robert_tweed wrote:
| Ah, I only skimmed the article and missed that. The BBC RSS
| feed was the main example I referred back to while I was
| learning XSLT around 2010-ish.
|
| AFAIK it's the only major implementation of this technique.
| Most other big sites that provided an RSS feed didn't bother,
| and most of those RSS feeds are dead now. The BBC one has
| hardly changed since those days and it still works really
| well as a dual-delivery system.
| Reitet00 wrote:
| I've seen that previously on https://curiosity-driven.org/ (the
| main page is a feed file) but I'm not sure if XSLT support won't
| get deprecated and/or removed in browsers (since it's quite an
| old tech).
| lkuty wrote:
| XSLT 1.0 is an old tech but not the more recent versions. IMO
| it is very powerful, as is XQuery, to handle XML documents in
| various ways.
| tannhaeuser wrote:
| I guess the point is that XSLT 2.0+ is not shipped as part of
| browsers, nor is it expected to be in the future, considering
| the only implementation is (commercially licensed) Saxon, by
| the author of W3C's XSLT spec himself ;)
| mickael-kerjean wrote:
| I can only hope this isn't the case, XSLT is a brilliant
| idea that's very underrated and a great tool to have in
| your toolbox.
|
| I don't count how many times I've seen people attempting to
| create simple reports from some XML taken from some obscure
| back office and try to reinvent the wheel by doing some
| JSON conversion and process that from some other program
| that build up an html report
| jordemort wrote:
| I do this both on my RSS feed: https://jordemort.dev/rss.xml
|
| ...as well as on my Atom feed: https://jordemort.dev/atom.xml
|
| ...using the same XSLT stylesheet for both:
| https://github.com/jordemort/jordemort.github.io/blob/main/p...
| acabal wrote:
| This is very cool and I explored doing this with our feeds at
| Standard Ebooks.[0]
|
| But there's a gotcha:
|
| This works fine if you serve the feed with `content-type:
| text/xml`, because with that content type the browser typically
| renders the result in-browser. But `text/xml` is technically _not
| the correct content type for RSS feeds_ , `application/rss+xml`
| is; and when you serve it with that content type, browsers
| typically either open a download window instead of rendering the
| feed, or they render it as plain text without styling.
|
| So you're stuck. Have a styled feed but serve it with the wrong
| content type, or be technically correct and serve it with the
| right content type, but no styling for you.
|
| Practically, content type really doesn't matter that much, and
| most (all?) RSS readers are fine with `text/xml`. But for those
| of us who like to be technically correct...
|
| [0] https://standardebooks.org/feeds/rss/new-releases
| idbehold wrote:
| Content negotiation is a thing that should be used. My browser
| sends this in the request headers when I open up one of those
| RSS links: Accept: text/html,application/xhtm
| l+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
|
| Which means it would prefer to get a response from the server
| in (basically) the order shown, but it will accept any response
| type (*/*). So ideally the server would be using that
| information and making the decision to serve the RSS feed as
| application/xml instead of application/rss+xml. AFAIK if the
| "subtype" (rss+xml in this case) has a + in it, then it
| basically means it conforms to the format after the + (e.g.
| application/xml) and thus is just providing a bit more context,
| but is still valid as the more generic version.
|
| Though I do think the browser should also keep that same thing
| in mind and attempt to render any application/whatever+xml in
| its XML renderer.
|
| Edit: another thing you could try to add this response header:
| Content-Disposition: inline
| acabal wrote:
| That's a great idea. I've gone ahead and implemented it!
| gizzlon wrote:
| Seems like Firefox does it's own styling of rss feeds? They all
| look the same to me =)
|
| Example: https://www.ghacks.net/wp-content/uploads/2019/04/rss-
| feed-p...
|
| _Edit: Nope, extension_ : https://code.guido-
| berhoerster.org/addons/firefox-addons/fee...
| ihuman wrote:
| Firefox removed built-in support for RSS feeds years ago. When
| I try to view the feed in that image, Firefox just downloads
| the RSS file (sometimes Firefox will show me the raw XML
| instead). You probably have an extension installed that styles
| them.
| gizzlon wrote:
| yeah, good catch.
|
| I have this installed: https://code.guido-
| berhoerster.org/addons/firefox-addons/fee...
| safety1st wrote:
| Excellent extension except for this caveat imo. And I've always
| considered it a travesty that Mozilla took this functionality
| out of the browser.
| 8organicbits wrote:
| I see 1-2% of viewers for my tech blog connect via RSS. I'm three
| posts in and adoption is increasing. It's higher than I expected.
| ryukafalz wrote:
| RSS is the easiest way to stay on top of new posts on small
| blogs. I'm unlikely to randomly browse to a blog that has one
| new post every few months or so, but if I add it to my feed
| reader I won't have to.
|
| A corollary: if you have a small blog and you'd like people to
| notice your new posts (without you promoting them on social
| media), make sure it supports RSS!
| low_tech_punk wrote:
| The significance of this trick goes far beyond just adding styles
| to RSS.
|
| The common practice is separating the the Human-readable
| interface (HTML) from the Machine-readable interface (XML) and
| build both of them on top of some source layer(e.g. a CMS or
| Markdown files)
|
| XSLT allows you to use XML as the source layer and build a
| presentation layer on top of that. Admittedly, the styling
| workflow can be cumbersome but you get a browser-supported
| templating language that seems Turing complete (anyone confirms?)
| and with the power of CSS, you can pretty much get a full
| featured static site generator that runs on the client!
|
| I've seen styled RSS once in a while and never thought about it
| until now. I'd love to give this technique a try. It feels like
| one of those Semantic Web ideas that should have taken off
| decades ago.
| Pathogen-David wrote:
| This is a fantastic guide, I've been meaning to try doing this to
| my website for a while but I wasn't sure if browsers even
| supported XSLT anymore. Guess this is my reminder to get around
| to doing it!
| dmje wrote:
| "Oh great, XSLT" said no-one, literally ever
| [deleted]
| chrismorgan wrote:
| As another example, mine:
| https://chrismorgan.info/blog/tags/meta/feed.xml. I've also
| deployed almost exactly the same stylesheet in one or two other
| places, e.g. https://ganintegrity.com/blog/feed.xml which also
| demonstrates pagination (very uncommonly encountered, and I have
| no idea of feed reader support, but a useful concept that allows
| you to keep your feed file small while still (at least nominally)
| containing all the historical entries).
|
| My XSL stylesheet is rather fancy in what it supports. Sometimes
| because I actually use that fanciness (e.g. supporting HTML in
| _all_ text constructs, not just <atom:content>, because I use
| HTML titles), sometimes just for the sake of correctness or
| completeness (e.g. passing through xml:lang as a lang attribute,
| or more obscure elements like atom:rights), and sometimes for
| things that I might use some day but haven't yet (e.g. turning
| audio/video enclosures into <audio>/<video> elements, for
| podcasts). https://chrismorgan.info/atom.xsl is for Atom, and
| I've also written an RSS variant of it, purely for use in
| podcasts since podcasts are stupidly stuck with RSS (and it's
| almost all Apple's fault and I hate it):
| https://temp.chrismorgan.info/2022-05-10-rss.xsl.
|
| Developing using XSLT is an interesting throwback to how web
| development used to be, because this stuff is basically frozen as
| it was twenty years ago. Almost all errors are fatal, diagnostics
| vary between nonexistent and poor (remember when you basically
| had to bisect to figure out what precisely broke things?), and
| the dev tools you've grown used to can't help you when anything
| goes wrong. Also there are probably more bugs than there used to
| be. And documentation is bad (a _lot_ of load-bearing
| functionality is completely undocumented). And browsers are much
| more inconsistent in their behaviour than you've grown used to
| (welcome back to the days of enforced trial and error, and
| _having_ to check things in multiple browsers). (You get some of
| the same weirdnesses if you try shipping HTML using XML syntax,
| but it's _mostly_ XSLT-specific.)
|
| Some particular issues:
|
| * The stylesheet needs client-side JavaScript to render any
| type="html" content (HTML serialised as text), because Firefox
| doesn't support the (admittedly optional) disable-output-
| escaping="yes" XSLT feature. (I'm puzzled by this lack even when
| using <xsl:output method="html"/>--and yes, Firefox and Chromium
| _do_ both produce HTML-syntax documents in this case, not XML-
| syntax documents. I check this by searching for an xmlns
| attribute an all elements' outerHTML, not sure if there's a more
| direct check and I'd love it if someone knew one, 'cos this stuff
| regularly _matters_ in JavaScript libraries--loads of libraries
| will break if run in an XML-syntax document due to assumptions
| made that no longer hold. OK, enough of this long parenthesis.)
| Therefore I recommend using XML syntax for the HTML instead
| (type= "xhtml" in Atom, no equivalent in RSS because RSS is a
| disaster), and expect to do so for whatever next refresh I do of
| my own website.
|
| * The stylesheet needs client-side JavaScript to resolve URLs if
| you use xml:base, since browsers just don't support that at all
| any more (if they ever did?).
|
| * If you make an error in the XSLT, Firefox will often point to
| exactly where the error is, but just as often give a completely
| useless generic old-school XML parse error screen. It validates
| declared XSLT 1.0 stylesheets, and is all round not very
| forgiving of errors, which is _good_ , except that I wish the
| error reporting was more reliable.
|
| * Chromium is more forgiving of errors, _mostly_ for the worse,
| blithely ignoring some XSLT 1.0 errors that you really wish it
| would point out because you have certainly done something wrong.
| On errors it won't overlook, it will leave you with an document
| empty save for an xml-stylesheet ProcessingInstruction, not put
| anything in the dev tools console, and print the error to
| _stderr_ (and with no stack trace in the XML _or_ XSLT, which is
| painful)--I'm mildly surprised with myself that I even thought to
| run it in a terminal to see if there was any output there, but I
| guess I was getting desperate one time when everything was
| working fine in Firefox but not in Chromium.
|
| * In Firefox, pages that use XSLT will sometimes just hang during
| loading (seems to happen very often, maybe even always?, when
| it's the first navigation in a new tab). Haven't ever filed a bug
| about this. My wild guess is that this probably started happening
| at some point in the switch to a multi-process architecture.
|
| * If you reload the page in Firefox while the dev tools are open,
| the dev tools are now effectively dead until you close and reopen
| them. Bear in mind also that the dev tools operate on the post-
| transform document, not on the source XML. Haven't ever filed a
| bug about this.
|
| If you try working on this stuff, you'll want to keep a copy of
| the XSLT 1.0 and XPath 1.0 specs open. They're the best
| documentation you're likely to find, and honestly pretty good.
| Because each is a single document, you can search through for
| keywords nice and easily.
|
| I've been very tempted to try shipping a website where pages are
| Atom documents (the list, a feed document, and individual pages
| entry documents), mostly just for fun, but I'd want to inspect
| browser support more carefully before doing this, and I'd _need_
| to nail down that Firefox hang first too.
| aendruk wrote:
| Here's the 22-year-old Firefox bug:
| https://bugzilla.mozilla.org/show_bug.cgi?id=98168
|
| And try putting xml:base on the atom:content tag.
| chrismorgan wrote:
| > _And try putting xml:base on the atom:content tag._
|
| I'm not sure what you mean. xml:base is supposed to work
| everywhere, for whatever is the appropriate scope, and my
| stylesheet copies the xml:base attribute across, and then
| includes JavaScript to make it more or less work, wherever
| you use it, since browsers don't support xml:base at all any
| more.
| jhvkjhk wrote:
| I wanted to style my RSS page for non-tech readers, but I thought
| I need to return XML or HTML based on HTTP Accept header,
| therefore not possible for my static blog.
|
| It's good to know that all I miss is a xml-stylesheet. I'm going
| to implement that once I'm free.
| vladharbuz wrote:
| This is very cute, not sure how I missed this. I never liked the
| aesthetics of the XML that shows up when you click an RSS feed.
| Will make some time to style my websites' feeds soon. :)
| nashashmi wrote:
| I had been waiting for this tech for the longest time. When it
| was finally implemented by all, RSS started falling out of
| favor. I went back to this now, and it took forever to try to
| come up with a stylesheet.
|
| I would say don't waste your time. Just get something off the
| shelf and start tweaking that one instead.
| earthboundkid wrote:
| https://www.theatlantic.com/feed/all/ has a styled feed.
| shortformblog wrote:
| I do this through FeedPress. Here's what my feed looks like:
| https://feed.tedium.co
| throw0101a wrote:
| > _RSS is not dead. It is not mainstream, but it 's still a
| thriving protocol, especially among tech users._
|
| RSS is alive and well and mainstream with podcasts.
|
| Also: how many folks use RSS(-as-protocol) and how many use Atom
| (RSS-as-feed)?
| darekkay wrote:
| Author here. What many people claiming "RSS is dead" for the
| last 20+ years mean is that RSS-as-feed (for written content)
| is not mainstream, and that's somewhat true. Most podcast
| listeners don't have a proper RSS reader apart from their
| podcast app. Also, big platforms removing existing RSS support
| is often taken as another sign of RSS dying.
|
| What's interesting is that this particular post had been posted
| by someone on HN before I've shared it anywhere. So it got
| through RSS right onto the HN front page. This is what I meant
| with "thriving, especially among tech users".
| derefr wrote:
| > Most podcast listeners don't have a proper RSS reader apart
| from their podcast app.
|
| Sure, but I would assume that "RSS is dead" isn't so much
| about consumer _awareness_ of RSS, but rather about the
| technology being invisibly supported and used in the
| infrastructure they make use of (through podcast clients et
| al) such that content _producers_ still care about publishing
| _through_ RSS.
|
| Like, if I said "TLS1.0 is dead", I wouldn't be referring to
| greenfield projects not using it any more; but rather to the
| fact that the browsers and libraries that invisibly use it
| (and nothing newer) are _themselves_ not being used by anyone
| any more -- so nobody on the content-delivery end has to
| think about supporting TLS1.0 clients any more, and can drop
| any code that was supporting that.
|
| But that's definitely not the case with RSS. There are still
| many important systems that depend on consuming RSS feeds. So
| there are people who still need to support RSS. So it's
| alive.
| [deleted]
| manuelmoreale wrote:
| My experience as someone who's in the tech sphere but writes
| not only about tech is that RSS is all but dead. Not sure if
| i'm an outlier in this but the % of requests in my server
| logs coming from RSS is very high.
|
| Like you I tried to figure out how many of those are actual
| users to have a sense of how many people still use it and the
| numbers still don't make any sense to me.
|
| That said, what do you think is the benefit of styling an RSS
| page? The point of the rss is to be consumed via an RSS
| reader so I don't see the benefit of having styles on a page
| like that. But maybe there's something I'm missing here.
| ryanbrunner wrote:
| I work in podcasts and not with written content RSS feeds,
| but at least in the podcasting world, I would take traffic
| from RSS endpoints with a grain of salt - a lot of reader
| clients like to request updates very frequently, and it's
| not unreasonable at all that a user that consumes your
| content primarily through RSS makes one or even two order
| of magnitudes more requests than someone who visits your
| site.
| manuelmoreale wrote:
| I wrote about my findings here[0] and honestly I don't
| even know what to make of those numbers. RSS stats are
| stupidly hard to track, especially if you only rely on
| server logs which is what I do.
|
| [0] https://manuelmoreale.com/poking-around-my-server-
| logs
| darekkay wrote:
| The parent might be referring to my other post [0]. Some
| RSS readers - at least Inoreader, Feedbin and Feedly -
| send the actual subscriber count as part of their HTTP
| request. Which is nice to get at least a minimum number
| of total subscriptions. Not sure if popular podcasting
| apps do that as well, though.
|
| [0] https://darekkay.com/blog/rss-subscriber-count/
| timf wrote:
| The author is pointing out that someone who clicks an
| RSS/Atom link and gets a page of gibberish is not going to
| understand all that XML, and they will likely just go back
| to the site confused.
|
| Instead, you can have a readable page with a message like
| the one in the post: "This is an RSS feed. Subscribe by
| copying the URL from the address bar into your newsreader.
| Visit About Feeds to learn more and get started. It's
| free."
| manuelmoreale wrote:
| I can see some value in redirecting people towards a page
| that explain what RSS is. Not entire sure about the first
| part about letting people know how to subscribe to an rss
| feed because people who decide to use an RSS reader
| probably know already how to use it since it's a somewhat
| technical tool but still, probably doesn't hurt to
| provide extra info.
| darekkay wrote:
| Yes, styled RSS feeds don't provide any value when consumed
| by RSS readers. But when I visit a blog and click an RSS
| feed link for the first time, it's nice to have a short
| preview of the existing posts without having to parse XML
| visually. The main benefit I see is however to educate
| people who don't know what RSS is. Imagine a person clicks
| "RSS feed" and all they see is some strange-looking file.
| On my feed [0], there is a big banner with a short
| explanation and a link to learn more about the technology.
|
| [0] https://darekkay.com/atom.xml
| manuelmoreale wrote:
| Yeah that's probably useful. Btw your recent blog posts
| are sorted in a weird order according to the dates.
|
| Also, and not sure why this is happening, I have the
| Reeder extension installed on safari and it usually
| automatically prompts me to open an rss link in the app
| but it doesn't happen in your case.
|
| I can't even use the button in the browser toolbar to
| open the feed in the app directly. The only way for me to
| add it is to manually copy paste the url.
| darekkay wrote:
| The posts are sorted by date, newest being at the top. I
| haven't posted much in 2022 and 2023, so maybe "Jun - Dec
| - Mar - Dec" looks confusing if you miss the according
| year?
|
| Regarding Reeder, I've included the feed in the markup,
| so I'm not sure what is going on. I will definitely have
| a look, thanks for the finding!
| manuelmoreale wrote:
| Ah I was confused because you have the last modified date
| displayed and those are all over the place.
| darekkay wrote:
| Oh, you mean in the feed preview. Yeah, they're sorted by
| _publish_ date but I only display the _last update_ date.
| I see that it 's quite confusing, I'll fix that. Thanks!
| butokai wrote:
| Not so sure about podcasts. At least where I am from (Italy) a
| great deal of podcasts are either Spotify exclusives, or
| consumed mostly through Spotify, or bundled in some producer-
| specific app (e.g. the state-owned radio does this, and doesn't
| provide feeds).
| tourmalinetaco wrote:
| The vast majority of podcast content is distributed via RSS.
| In fact if its _not_ distributed via RSS, no one is
| listening. It's so important its even advertised as part of
| Spotify's podcasting platform.[0]
|
| Of course Spotify has incentive to prioritize you listening
| in their app, but they can still put ads into the audio feed
| so it doesn't matter as much to them. And your state-owned
| radio is absolutely limiting their audience by not using the
| accepted standards for podcast content.
|
| [0] - https://podcasters.spotify.com/switch
| throw0101c wrote:
| > or consumed mostly through Spotify
|
| I would not be surprised if Spotify themselves get the audio
| from the source via RSS/Atom.
|
| No doubt the podcast creator may have to create an account
| and tell Spotify manually (and also on Apple, Google, etc),
| but once the feed is in their system the creators/producers
| just need to update things in one place and all the
| 'distribution points' get the new episode.
| jrochkind1 wrote:
| > RSS is alive and well and mainstream with podcasts.
|
| Spotify (and other big players) are doing their best to end
| this.
|
| As many as one in four podcast listeners currently use spotify
| to listen. The growing number of spotify-only podcasts are not
| available via RSS. Most of the listened-to podcasts may also be
| available as RSS, but the listeners wouldn't know either way.
| Spotify's goal is to be the chokepoint for podcasts.
|
| Spotify isn't the only one. The way to make money on podcasts
| is by being the distribution platform, and by locking people in
| with non-open standards.
| ryanbrunner wrote:
| Spotify still uses RSS as a distribution channel from your
| host to Spotify - you supply a RSS feed through Spotify for
| Podcasters or another ingestion service. They don't allow
| adding by RSS feed for end users, but that's not all that
| rare among players.
| jrochkind1 wrote:
| That is something spotify supports, yes.
|
| But there are also spotify-only podcasts, which are not
| distributed to spotify like that, are not available via RSS
| or any other method but a spotify client.
|
| This is an intentional business move by spotify. They are
| attempting to change the podcast landscape.
|
| Although googling for recent sources, it looks like there's
| been some pushback and slight retreat -- looks like their
| plan wasn't exactly working. Yet. I'm sure they haven't
| given up yet:
|
| https://www.theverge.com/2023/4/18/23688644/spotify-
| podcast-...
|
| > After the cancellations and resulting layoffs, members of
| the Gimlet union blamed Spotify's exclusivity strategy for
| disappointing numbers. Although the shows were not behind a
| paywall (free subscribers to Spotify could access them, as
| well), they did not enjoy the kind of wide distribution
| that the shows did before the acquisition. It's not like
| they don't have a big platform -- according to a study by
| Cumulus and Signal Hill, Spotify is tied with YouTube as
| the most-used podcasting platform. But even then, it only
| has about one-fifth of the market.
| nicolaslem wrote:
| Anecdotal but I used to listen to tons of Gimlet shows
| but they all either got canceled or disappeared from my
| player.
| Semaphor wrote:
| When I was young, naive, and still in HS, I thought XSLT would be
| the future. Imagine, one XML file, many representations! It could
| be your Database, your Website, everything! Writing one took
| forever, but never until I learned programming in university was
| I so amazed how some code had such a visible result.
| Cthulhu_ wrote:
| I just miss a lot of tooling and standards from XML that JSON
| never got, or if they did, it wasn't as... correct?
| hk1337 wrote:
| Symphony CMS took that to heart. https://www.getsymphony.com
|
| Not to be confused with Symfony framework.
|
| _EDIT_ https://github.com/symphonycms/symphonycms
| giantrobot wrote:
| While XSLT is far from perfect, what I always loved was it was
| built into the browser. People have spent/wasted twenty years
| rebuilding templating systems in JavaScript. Browsers have had
| it all along but because it's related to XML it seems web devs'
| brains just seize up thinking that's only used by boring old
| Enterprise development.
|
| To be more charitable I think the problem has always been
| tooling. There's not a lot of good design tools that have
| supported XSL stylesheets as output. You've always had to do a
| lot of manual editing to get make a decent stylesheet and do
| any complicated functions.
|
| What's annoying is XSL can be used for any XML documents like
| you said. Your "pages" could just be serialized database
| entries with a stylesheet on them. Since all the styling was
| done client side the server is really just an API server.
|
| This was a design conceit of ATOM. It was mostly used for
| syndication but it was meant to be an XML API interface. It
| supported posting to a server in the ATOM XML definition as
| well as pulling. The idea being you'd come across a server with
| an ATOM API and be able to post comments or whatever to it
| right from a browser, no HTML form or JavaScript required.
| marcosdumay wrote:
| Yeah, I was quickly dissuaded from that the first time I tried
| to write a XSLT.
|
| The same way that DTDs are very easy to work with... until you
| get a complex one created by a lot of people.
|
| XML is so incredibly full of horrible decisions that it's not
| funny. And they are never on the macro level of "this format is
| useless", they are always in the details.
| vidarh wrote:
| I once built an entire site where the frontend was XSLT applied
| to XML from the middleware that spoke to the various data
| sources. You could set a url parameter and switch off the
| server side transformation to let the browser do it client side
| (and another to transform it into RSS instead of HTML).
|
| I liked the overall approach of a declarative transformation,
| but XSLT is absolutely awful and the lack of an alternative
| that's supported by browser made me not do it again.
| rambambram wrote:
| Oh man, you bring back memories. It had so many appealing
| features, but trying to do all kinds of logic with XPath et
| cetera became annoying very quickly.
| sam_lowry_ wrote:
| Until very recently https://ted.europa.eu/ was build this
| way.
|
| It's probably still like that in the backend.
|
| I was always amazed how worked.
|
| What an underappreciated feat!
| vidarh wrote:
| The big challenge with XSLT was that the basics were
| verbose but easy - just pulling fields from the xml and
| putting them into a template. But then you ran into things
| that's simple with other solutions, like re-formatting
| dates and ended up with either humongous functions or
| biting the bullet and including multiple pre-formatted
| versions in the XML, and the moment you start down either
| of those paths you start to dislike XSLT pretty quickly.
|
| In a way modern React etc. frontends can be seen as a
| "fix", in the sense that at least it means most sites
| effectively have APIs, whether or not they officially
| expose them to users, but without the pain of XSLT. If they
| support server side rendering as well, they're getting
| close to what we were doing.
|
| And that was the original driver for the site design I
| mentioned - every URL was an API endpoint with a well
| defined set of expectations, letting you effectively
| explore the API by browsing the site as normal until you
| had sliced and diced the data the way you wanted and then
| just add a parameter to get it in the format you wanted
| (just as you can with Reddit - e.g. append ".json" or
| ".rss"). And I try to do that as much as possible still.
| starkparker wrote:
| XSLTs still get use in technical writing for DITA XML users.
| cf. https://www.oasis-
| open.org/committees/download.php/62943/201... (which is, of
| course, a PDF)
___________________________________________________________________
(page generated 2023-06-20 23:00 UTC)