Why I Removed My XSLT Feed Template

I've sadly stopped templating my blog feed to look pretty in a browser. But why? A combination of Lynx, long term support worries, and user confusion.

Lynx

I explicitly test my site in two classes of browsers, what I'd distinguish as application platforms and smart document readers. The application platforms are the browsers you're probably most familiar with. They're the ones that implement the vast majority of the W3C standards. Essentially Firefox, Chromium, and in most cases, Safari.

While current trends point to the list of application platform browsers ultimately just meaning Chrome one day soon, I hold out hope that web developers will continue working to ensure their code works on more than Microsoft Windows, sorry Google Chrome and users demand the same.

The other class are the smart document readers. These are browsers that mostly decode HTML documents for you. They may implement some CSS support and may even include some JavaScript support. They don't see the web as an application platform, but instead see it as hyperlinked smart documents. These are browsers like Pale Moon, Ladybird, NetSurf, Kristall, eLinks, Lynx, and w3m.

I'm not going to hold myself up as some sort of user agent compatibility hero or anything. I mostly develop in a recent version of Firefox and then double check my work in a couple other browsers. For example I recently tested my site in NetSurf and found it was usable but ugly. I've added fixing that to my work backlog. That aside there is one smart document browser I do explicitly support, and that's Lynx.

Why Lynx? Well, I think it's the best terminal based browser, but more importantly it makes a great accessibility target. It explicitly only looks at a site's HTML. This means it doesn't force me to go out of my way to fix things. Even the newest HTML is almost perfectly backward compatible to the beginning of the web. In general, there's not much to supporting it besides ensuring I don't overload the DOM with junk like huge navigation menus at the top or relying on images to convey meaning. You know, things that are considered best practices for accessibility. Essentially, by supporting Lynx, I get accessibility nearly free. It also means I can dump my site using Lynx and pipe it through text to speech software (something I often do to proofread my writing).

The ideal draw of the whole XSLT template like this is it can seamlessly provide the data formatted as either RSS or XHTML depending on the program looking at it. Essentially I was hoping I could give you a copy of the data and then a set of different rendering instructions for that data depending on context. Sort of what the web has been chasing for decades at this point.

The problem is that most smart document browsers don't support XSLT. If you try to view them in Lynx, it tries to render the minified XML RSS document by just ignoring tags it doesn't know about (which is everything) and ends up with an unintelligible minified mess. This left me two options, don't ship the RSS feed minified and let Lynx users suffer having to manually navigate past the index by copy pasting URLs, or, ship the feed as a proper HTML page and link to the RSS feed. I did the second but that somewhat defeated the entire point.

Long Term Support

Another consideration that changed my mind was weighing out the likely long term support of XSLT in browsers. If not enough people use something or the developers of browsers just dislike it enough, history shows they will just drop it. We've seen this with things like Gopher and FTP support, XUL and XPCOM, domain names that start with www, and other such "deprecated" APIs. In general I can't stand this churn for churn's sake, so I try and preemptively avoid things that will likely force me to do a bunch of work at their whim.

I'm pretty sure XSLT in the browser, given its relative lack of documentation compared to other browser features, and standing contempt for XML among developers means it isn't long for this world. Might as well stop relying on it being there now. On the bright side, the way I was using it means even if they remove it, it just reverts the document to the state it exists in now without the template. It would continue to work well into the future for any reader that doesn't apply the template transform.

That last point is also something worth considering a bit. What the template is doing is converting the data from RSS XML into XHTML. I have yet to find an RSS reader that parses and applies the template to the data before trying to interpret it, but in theory, nothing stops it from assuming that's what I want it to do. If a reader was applying XSLT templates to the document, that would break my feed for them. Removing it removes that possibility.

User Confusion

The last reason is ultimately the one that pushed me to remove it. I think it just added user confusion instead of reducing it. I assume just about everyone else using RSS readers expect the feed to be completely unstyled because basically nobody else styles it. When I styled the feed, I felt I had to add a paragraph explaining, no the page you're viewing in the browser that looks like HTML isn't really HTML and will actually work in your feed reader. That really should have been a sign that the whole project was a bad design. If you break people's expectations, you should be doing it because there's a good reason. Design aesthetics aren't a good reason to break things.

So instead of explaining that my feed that doesn't look like a feed really is a feed, I'm just going to make it look like every one else's feed. It's simpler and expected. To quote myself, angle brackets panic the users, but RSS feeds that look like HTML pages panic them more.

Notes About Doing It Yourself

I'm not going to remove my previous post explaining how to use the technique. You can still (at the time of writing) try it out yourself. Perhaps you feel differently about the benefits and drawbacks. I still think it's something worth trying out to understand what could have been if we went with XHTML instead of HTML 5. It's certainly not perfect, but kind of neat to provide a suite of different rendering instructions to interpret the same data for different contexts.