While working with clients in the magazine and news publishing industries, I’d been tasked with producing some fairly complex columned layouts in HTML, which weren’t easily accomplished with CSS. In this post, I’ll explain a few of the tricks I used to meet those needs.
This week the W3C HTML WG finally made the sensible decision to remove the Atom conversion algorithm from HTML5. As a celebration, I’ve decided to organise a spot-the-difference competition, comparing the output of that awful algorithm with a genuine Atom feed.
It seems to me that the PubSubHubbub protocol is potentially quite dangerous, and I think the specification is flawed in not having a section on security considerations. Hopefully this is something that the authors of the specification will consider addressing.
Back when I first started working on Snarfer, I was intrigued by the idea of the RSS cloud element, and the possibility of real-time updates. With the recent announcement from WordPress.com that they would be supporting RSS cloud in all 7.5 million of their feeds, I figured the idea might be worth revisiting.
There was an article on The Daily WTF blog recently, about a guy that created an ASCII art rendering of the Mandelbrot set using nothing more than XSLT. My first thought, on reading that, was whether I could do something similar using an XML DTD; and instead of HTML, using an RSS or Atom feed as the final output.
In recent weeks, I’ve spent many a sleepless night pondering the seemingly simple task of designing a file format for storing the settings from a blog publishing system; essentially a number of key/value pairs. The only requirement was that the format be a dialect of XML.
There has been some discussion recently on the RSS Advisory Board public mailing list, regarding the possibility of assigning a namespace to RSS elements. My concern was that the introduction of such a namespace, could cause problems for many feed readers.
In a recent post on the Feed Validator mailing list, Sam Ruby asked whether there was still a widespread problem with using atom: and xhtml: prefixes in Atom feeds. The short answer is: yes.
Early one morning, while staggering home after a night of heavy drinking, I came up with the wild idea of a feed, constructed almost entirely from PE references within an XML DTD. The result would be a valid feed, yet would look nothing like a feed.
A few months ago, there was some discussion on the RSS Advisory Board mailing list regarding the format an email address should take in author, webMaster and managingEditor elements. I recently ran some tests to see how people were actually using these elements in the wild. The variety of formats I encountered was positively staggering.
One of the difficulties in dealing with international content, is the complication of right-to-left writing systems. In order to for an application to display such content accurately, it needs to know the writing system being used. Regrettably, RSS doesn’t provide an easy way to indicate that information.
How does one uniquely identify an item in a feed while still allowing for that item to be updated? RSS 2.0 has a guid element that fits the bill perfectly, but it’s not a required element and many feeds don’t use it. As a result, aggregator authors are left guessing, and nearly every one of them guesses differently.
As an aid to feed producers, I decided to put together a set of tests that could be run through my aggregator collection to determine, once and for all, the best form of encoding to use in RSS titles.
I’m sure everyone knows by now that upcoming versions of Internet Explorer and Firefox will be sniffing for RSS (and Atom) whenever you access a page that might plausibly be a feed. If this spares users from having to face an incomprehensible stream of XML, I’m all for it. Unfortunately, from what I’ve seen in recent builds, it’s not going to work very well.
I guess this now officially marks the start of my blog. I’ve been posting obnoxious comments on other people’s sites for long enough – it’s about time I got a place of my own.