1. 42
  1.  

  2. 14

    I think the other reason is that, if you get the full post on the RSS feed, the site doesn’t get the chance to show you ads.

    1. 9

      I’m conflicted on the idea. I’ve been providing a full text RSS feed on my website after someone asked me, but at the same time, I really have put a lot of work into my site’s visuals. In particular, I now have side/margin notes and some articles have custom elements to display certain type of non-standard content. So yes, feed readers are nice, but I feel like the better argument is to ask site authors to think about accessibility themselves, instead of offloading the task to feed readers.

      1. 7

        Why rely on each site author to be an expert in accessibility when they could just use RSS? Offloading the task to feed readers seems like the obvious best solution here.

        1. 2

          I think that reducing websites to text / minimal colored markup is, in a way, limiting the medium quite a lot. Here’s, for instance, an interactive, browser-based rendition of Euclid’s Elements. I recall, at one point, seeing an interactive article about floating point numbers, and there’s also this article about maze generation that lets users follow the algorithms step by step. Such pages would not transfer over RSS.

          In my opinion, there’s a wealth of untapped potential in writing on the web. Interactivity and responsiveness can be used to help readers understand and digest information. I would like to see this potential explored. And perhaps, in an ideal future, thinking about accessibility will become as ubiquitous as literacy!

          1. 3

            Being blind or having a slow computer is also limiting. Accessibility should mean presenting as much content as possible in a standard format like RSS. Not doing so is limiting the range of people who are able to enjoy the content.

            If you want to experiment with a medium that can only be enjoyed by sighted people running a modern browser, by all means do so, but merely thinking about accessibility in a custom frontend should not be framed as an alternative to RSS.

            1. 1

              HTML is also a standard format. So, I agree with your statement of what accessibility should mean, and the repercussions of not making your content accessible. I also despise websites that use pointless JavaScript (I myself spent a few months with a cheap Chromebook as my main machine), but for the sake of this conversation, let’s leave them out, and talk about just your average article.

              I believe (and I could be wrong here) that HTML has better support for screen readers; there are well defined attributes for specifying image alts, languages, relationships between inputs, and the like. I think, then, that there are two possible issues with the average article:

              1. The HTML is not semantic, and is hard for some people to make sense of.
              2. The CSS is poorly done (contrast is low etc.)

              The first issue will carry over into RSS; all RSS feeds I’ve seen retain at least some of the HTML of the source. The argument for RSS (when JS is out of the picture) then boils down to replacing the CSS with other CSS. To me, this feels like the task of the web client, rather than that of every website maintainer.

              1. 2

                I believe (and I could be wrong here) that HTML has better support for screen readers

                Better than what? RSS? As you point out, RSS can contain HTML, so doesn’t it also support those HTML accessibility features?

                The argument for RSS (when JS is out of the picture) then boils down to replacing the CSS with other CSS.

                I wouldn’t say that. RSS semantically encodes information that can’t be semantically encoded in HTML, such as the notion of an entry and a sequence of entries, the title, publication date, and author for each entry, etc.

                Presenting a usable full-text RSS feed also forces the author to ensure their HTML doesn’t depend on CSS to be readable, which is the job of the webmaster and can’t be offloaded to the web client (whether it’s a brower or an RSS reader).

                1. 1

                  You make a great point (though the article itself, having glanced at it again, does seem to focus on effectively custom CSS).

                  In an ideal world, I’d prefer such semantic information to be encoded in HTML. The difference between an RSS feed with full text HTML and the original article page would then be CSS, which could be adjusted to a user’s preferences by a client (much like an RSS reader can be tweaked to display content differently). I would not, however, take the control of a page’s CSS completely away from the author - I feel like there’s something to it along the lines of “how the artist/author intended”.

                  Regardless, I’m completely in agreement about the need for HTML to be independent of CSS for presentability (same goes for JavaScript!).

                  Even before this conversation and article, I’ve been providing a full-text RSS feed for my website, and supporting the plain-HTML representation as first-class. I do, however, put work and thought into presenting my content in an effective and pleasant way, and would be happy to see that work be useful.

                  1. 1

                    I would not, however, take the control of a page’s CSS completely away from the author - I feel like there’s something to it along the lines of “how the artist/author intended”.

                    What would this mean in concrete terms? Are you saying you personally wouldn’t remove or modify CSS, or that there should be some mechanism to prevent it?

        2. 4

          The margin notes are pretty cool. I wonder if a good compromise would be to have an autogenerated note at the beginning of each post in the feed that some content might be missing, and follow this link to see it in its full glory? Personally the main hassle I have with excerpts is that it’s often hard to tell from the short snippet whether it’s something I actually want to read. If I can scroll through it quickly then that decision is easier.

          1. 1

            This is actually a good idea. I think that I will include such a note in my RSS feed. Thanks for the suggestion!

            1. 2

              Where is your RSS feed anyway? Most sites would have a something like this in the header:

               <link rel="alternate" type="application/rss+xml" title="RSS" href="/index.rss" />
              
              1. 1

                It’s here. Thank you for pointing out the missing HTML!

          2. 3

            Could you not code your feed so that it pulls the side margins too?

            For me (and this is just my opinion), if you’re content is somehow hindered or incomplete without these extra bells and whistles, your design is wrong.

            1. 2

              Margin notes are what they are. RSS feeds do not have a notion of spatial arrangement, and putting something in the margin is just not possible. I handle this by including the notes inline in the form [note: note text here], but this has the issue of just plopping a long piece of text in the middle of a sentence.

              I didn’t include margin notes just to be contrarian. I find them to be a pleasant addition when I read textbooks and articles (Crafting Interpreters is one other website that I think uses margin notes, to some extent).

              Also, see my other comment on this chain about the web as more than a text medium.

            2. 2

              I’m not telling you how you want to provide your content, just as a data point from a random reader:

              If I’m subscribing to your feed I’ll usually read the post in my feed reader. If it’s interesting and I know you are providing added value, I will still open it in a new tab and read it there. If the topic is not interesting I might still scroll and skim. But if you only provide a small excerpt you’d have to be one of the my most favorite blogs of all time that I will even subscribe, because it annoys me. I mostly read feeds on mobile, I don’t want to open it in a browser.

              Also, while my monitor might be miscalibrated, I can hardly read the white on green in your menu and the very thin font with light green links on white make me not want to read it there, anyway.

            3. 4

              I’ve done this for a long time on https://christine.website/blog.rss. It’s been a boon for the people that follow my blog. I regularly get traffic from some kind of RSS -> email syndication platform too. This lets people just read the blog content, viewership numbers be damned.

              1. 4

                If only formatted text is involved, then it sounds reasonable, but there are many interesting cases. For example, any kind of math, whether you pick MathML or KaTeX way, just isn’t going to work because even the most accessible option—KaTeX rendered offline, still needs fonts and styles. Thus the feed reader must either be natively KaTeX or MathML-aware, or act like a browser. The former is non-existent, the latter defeats the purpose.

                With long posts, the line between styling and essential navigation is also quite fine. You may write off marginalia as styling, but tables of contents or footnotes can seriously improve readability for long posts.

                If a post includes any interactive simulations etc. is also needs a browser, no way around it.

                1. 1

                  I generally rely on RSS for most feeds, but there are some (like MJD’s blog) that I know are gonna have a hard time with math notation, so I just visit it directly when I see the entry.

                2. 2

                  I used to do this but it kept causing problems for my readers.

                  Some (several?) popular feed readers krap out if they think a feed is even slightly malformed. This means that all of the HTML inside the feed also needs to be ‘correct’ or they refuse to show the user any articles.

                  The first time was some unhappiness with [video] tags (I think I provided an alternative video source with a mimetype that isn’t common/standard). The second time was a problem with [b] old-style [i] overlapped [/b] formatting HTML tags [/i] that probably were a violation of something somewhere, but still upset me given how trivial they were.

                  (Thankyou to the readers that reported problems to me)

                  I don’t like the philosophy of adding more dependencies to solve a problem, so I didn’t want to add an XML/HTML cleaner to my site. Even if I did I suspect it wouldn’t catch every quirk in every feed parser. In the end I reverted to putting summaries in the feed instead, the simplest and most robust solution to feed reader compatibility is to have as little in your feed as possible.

                  1. 2

                    It would be nice if the HTML generated in RSS feeds by static site generators was a little less gross. My old website used Jekyll, which produces a very ugly RSS feed when combined with syntax highlighting. When I switched to Zola, the new RSS feed had much nicer markup, but it defaults to just displaying an excerpt. It looks like the RSS page is a configurable template, so I might be able to get it to display the whole thing.

                    Edit: Fixed! My RSS feed now displays the whole article content. The HTML inside is still somewhat strange, but it does work now.

                    Edit 2: This inspired me to completely redo my website’s CSS. If you’ve noticed that smart quotes were broken on Zola for you before, I now have a “solution”: https://github.com/raphlinus/pulldown-cmark/issues/119#issuecomment-609107796

                    1. 4

                      One of the many complaints that the team that wanted to move RSS forward was that including HTML markup wasn’t well-defined in the RSS spec. I believe it’s better in Atom.

                      1. 1

                        One of the many complaints that the team that wanted to move RSS forward was that including HTML markup wasn’t well-defined in the RSS spec. I believe it’s better in Atom.

                        This was one of the reasons why W3C was pushing XHTML: any XML document can contain any other XML document without either having to be aware of the other. Atom was XML and so could contain XHTML, SVG, or any other XML content. WHAT WG effectively killed XHTML because Google didn’t want HTML to be anything other than a mechanism for writing GUIs that displayed adverts. The more you provide semantic structure to a document, the more you make it easy to identify and remove adverts and the more you are a threat to Google’s revenue stream. In an ideal Google world, everything would be rendered to a <canvas> by something that opaque executable code.

                        1. 1

                          XHTML had well-known usability issues for web authors too. The tooling was definitely missing for “compiling” source into valid XHTML, and the strict “fail for the slightest error” went against everything people were used to for web development.

                          (I tried hard to adhere to XHTML back when it was cool but I gave up).

                    2. 2

                      Makes me think about doing this myself, but I’ll need to get Hugo to behave correctly in rendering proper HTML markup. (especially since images are a pain for it)

                      1. 2

                        You really should do it.

                        1. 1

                          I’m working on it now, you could check https://teknikaldomain.me/index.xml if you wanted to see the moment it deploys and doesn’t magically break. (Meaning, in 4 years when computers behave correctly)

                          Luckily Cloudflare doesn’t cache XML files be default, or my RSS would only update every 2 days.

                          1. 1

                            Only one issue: some posts can have a banner image (or even a gallery / slideshow of banner images that flip through every few seconds) and that can’t reliably be translated into RSS, mainly because with my current knowledge of Hugo templates, conditionals, and page variables, I don’t know the way to either inset the images only if one exists, or a little “note: Due to the limitations of RSS, we’re unable to show the banner images for this post. Please visit the real post link to view them.” line at the fery top before the rest of the content.

                            …I could just put a generic “some resources may not have loaded” warning on everything but that feels… wrong somehow. Guess for right now it has to be images in the actual content only.

                            Edit: Found it!

                      2. 1

                        The other reason against it is the size of the resulting RSS feed. These feeds are downloaded very frequently (and not always with “If-Modified-Since”). Some sites have enough articles (or big enough articles) that if they used “full post” feeds they would be multiple megabytes. That’s enough to be annoying.

                        If you don’t like how a page looks it’s probably a better idea for your viewer to render it differently. Firefox has a “reader” mode and I’m sure an RSS reader could too.

                        1. 1

                          Surprised to see RSS/syndication used to side step an author’s styling decisions. You can certainly achieve that with feeds, sure. But can’t people’s browsers do that for them too?

                          A long time ago I used to provide a whole bunch of alternate CSS choices on my personal website, with a little widget to switch between them. I wonder if anyone still does that.

                          1. 1

                            Not necessarily, what with JavaScript, CSS and the like your browser will have a different experience for every site.

                            With RSS you start with the nuts and bolts of the post, then your reader does the rest. You could strip our CSS/JS etc so you have the same baseline for all sites your browse, but that would ruin the experience on a lot of sites that are not blogs.

                            1. 1

                              I’m still not convinced. Most blogs are relatively lightweight wrt javascript in my experience. Most style preference issues are things like “I don’t like this font” or “I don’t like these colours”. Firefox and other browsers have had features like “Override the colours specified by the page with your selections above” and the equivalent for fonts since the year dot. And for more over-reaching personal preferences, there have been plugins like Greasemonkey or User Stylesheets.

                              On the other side of the coin, even for lightweight blogs, there can be simple constructions that need custom CSS to make any sense. Such as floating image thumbnails with separate captions inside DIVs with specific class names. I’ve seen this over and over again on popular aggregator sites like the various “Planet Foo” sites. This remains a bugbear even for reading my subscriptions in my feedreader, and it has since RSS’s inception.

                              Whilst I’m on the subject of RSS feeds, by the way, one obstacle to getting user’s to consume your content via feeds is minifying your site, as you have done. Some readers indeed can parse out the URI automatically, but some old stalwarts (like rss2email) still cannot.