Is RSS at Risk?

I spent about a thousand words explaining RSS before I realized that, for the most part, if you are reading this blog I have to guess you have some familiarity with it (at least by just having heard of it). If you need some background, Wikipedia has a pretty good overview on RSS.

If you are a web site developer or author, there are three methods to get your Twitter feed or your Facebook business page information integrated into your site: via some sort of JavaScript-driven widget, via an API that is unique to each, or via RSS. This isn't limited to just Twitter and Facebook. PicPlz, Foursquare, and others provide these methods as well.

A JavaScript widget (whether via an embedded iframe or not) typically does not integrate well with a site, forcing the branding of the service, its color scheme, and its styles. For many sites, a Facebook widget or Twitter widget can look very out of place, almost like an afterthought. On top of this, because these widgets rely on JavaScript so heavily there is no alternative for those without JavaScript support (whether by choice, by restrictions, or by errors elsewhere on the page — see my post Beyond Hash-Bangs: Reliance on JavaScript Is a Bad Idea)

The API approach gets around styling issues, but often each API has its own proprietary offerings and syntax, requiring you as the developer to learn it, integrate it with your own platform, and spend time maintaining it as the API changes (possibly on a whim). While using this method you have control over how the data is styled on your site, relying on a free service means that you will have less input and recourse should a feature suddenly change (as I say, free doesn't mean good: You Get What You Pay For). Many APIs are reliant on JSON solutions as well, requiring JavaScript to perform the calls, and therefore the rendering, unless you are processing all of the features server-side.

The third method I mention, and the point of this post, is RSS. Because RSS has a standardized XML structure behind it (spread across parallel but unique versions, not counting variants like ATOM), as a developer you always know what to expect from an RSS feed. A JavaScript developer can just as easily parse the XML structure as a server-side coder. Once you have built a function to parse and display an RSS feed from one source, you can re-use it for any other RSS feed, forking it if you want to present the data in a different way on your site. This means you have complete control over the presentation (HTML, CSS and code structure).

In addition, most blog platforms (I'd say all, but someone might surprise me with one I don't know) not only provide RSS feeds of their data (and can even rely on a service like FeedBurner to provide additional RSS versions), they also support RSS import. This little feature means that if you provide content from your site as an RSS feed, any blogger can integrate it into his or her blog with only a few clicks.

An example of just how robust RSS can be is demonstrated with podcasts (and even vodcasts). The structure of a podcast file is really just an RSS feed with attachments, much like you might attach a file to an email. A regular RSS reader should be able to process the file, even if it cannot play the music. A podcast reader should, conversely, be able to read a standard RSS feed, even if there is no music to play.

Another powerful adaption is GeoRSS, which allows geographic data to be embedded in a feed. Syndicated content can be associated with locations on a map, something which has proven to be useful to the rise of location-based social media. For example, you can get your Foursquare history as an RSS feed, with each location tagged with geolocation data. In fact, a precursor to Foursquare, Brightkite, allowed users to generate custom RSS feeds to track specific spans of time, locations, groups of users, and even control how many items to display. When it came time for Brightkite to shutter its location-based services, it made all user data available to its users via RSS feeds.

Because of these reasons I have typically ignored hype expressing that RSS is on its way out. And then I stumbled across the post Twitter and Facebook Both Quietly Kill RSS, Completely, which was followed up a couple weeks later with Facebook Listens. RSS Added Back to Pages. Will Twitter be next?

This reminded me of an exchange I had on the Picplz API mailing list, where I asked if they would update the RSS they provided with geolocation data (since most photos are associated with a venue pulled from Foursquare). I was told that the RSS pre-dates the API and essentially that there aren't any changes in the pipe.

In just the last few days I have been struggling with the new MapQuest, trying to figure out how to embed GeoRSS in the new platform. In addition, I noticed that my "classic" MapQuest maps were no longer showing the embedded GeoRSS. After going through the support forum I found that GeoRSS is not (yet) supported in the new MapQuest, and nobody had noticed that it appears to be broken on the classic MapQuest (the solution they told me I should use for now).

So now I find myself wondering about the future of RSS. When Google Chrome doesn't even show an RSS icon or format it for display, when a new location-based service isn't adding the GeoRSS features, when a major mapping service doesn't support GeoRSS in its latest release, when Twitter buries the link for RSS, and when Facebook toys with its removal, I am concerned that they are contributing to the eventual demise of RSS.

I understand that content drivers (Twitter and Facebook) who survive on advertising revenues want to drive their brand and, ideally, their advertising to end users. Widgets that include a brand and drive people back to the advertising on the parent site make sense. For services and platforms (Picplz and MapQuest), pushing developers to a proprietary API increases the developers' investment in your platform, making it less likely for them to peel off when they can't simply apply their code to the next shiny new thing.

Unfortunately, these all combine to make the barrier to content syndication higher for everyone. While we can still wield an RSS parser to syndicate much of this content (often the one built into a blog, but typically a module within a CMS or other platform), it may be a matter of time before we lose the freedom to rapidly and repeatedly re-use a tool already in our belt. It may also be a matter of time before we as developers forget we should always build an RSS feed when we are instead enamored with the ability to claim our product or service has an API — even if it's not offering any more than an RSS feed can offer.

As developers we need to make sure we are helping our users, future developers, and ultimately our clients, by leveraging standardized tools. When it comes to content syndication and generally sharing data, RSS is the common denominator and typically worthy of implementation as the first step in a solution. If we aren't continuing to use it and expect it, the walled gardens and self-congratulatory APIs will catch up to us.

Related

• Rest in Peace, RSS, May 5, 2009.


• No, RSS Is Not Dead, and Neither Are RSS Readers, September 13, 2010.


• How to reboot RSS, September 13, 2010


• XML vs the Web, November 24, 2010.


• RSS Is Dying, and You Should Be Very Worried, January 3, 2011.


• Sure, RSS Is Dead — Just Like the Web Is Dead, January 4, 2011.


• What I mean by "the open web", January 04, 2011


• Why Big Media Wants to Kill RSS, and Why We Shouldn’t Let It, January 4, 2011.


• Blogging Forefather Seeks to Re-Invent Blogging, Again, January 5, 2011


• RSS: A Reply, January 14, 2011.


• Twitter and Facebook Both Quietly Kill RSS, Completely, May 8, 2011.


• Facebook Listens. RSS Added Back to Pages. Will Twitter be next? May 21, 2011.

Read More

HTML5 Goes to Last Call (of First Step)

If you follow the ongoing developments of HTML5, by which I mean the W3C specification and not the regular JavaScript and CSS sites-of-cool-gee-whiz bandied about across the web (Apple.com (Not Really) Updated to HTML5, Google Doodle: Bouncy Balls Aren't HTML5, Google, Arcade Fire Confused on HTML5), then you probably know that it has gone to Last Call as of two days ago. I think, however, that we all need a little context for what this means.

The version of HTML5 I am referencing here is the W3C version, not the WHATWG version. WHATWG has already stated that it will not be releasing discrete versions of HTML, owing partly to the modular nature of the specification. The W3C, however, is still keeping versions and sending the core HTML5 specification and related specifications to last call. Both organizations have been providing updates as they have them (W3C and WHATWG Provide HTML5 Updates), not counting the public mailing lists.

To clarify further, there are six specifications heading into last call, one of them is HTML5. The specifications are:

• HTML5


• HTML+RDFa 1.1


• HTML Microdata


• HTML Canvas 2D Context


• Polyglot Markup: HTML-Compatible XHTML Documents


• HTML5: Techniques for providing useful text alternatives

And just to keep things interesting, the W3C published three other documents at the same time, which are related to the six specifications mentioned above:

• HTML: The Markup Language Reference


• HTML5 diffs from HTML4


• HTML to Platform Accessibility APIs Implementation Guide

What's important to note here is that last call in this context does not mean that the HTML5 specification will be ready at 4:15am (in Buffalo, bars are open to about 4am, so last call is at about 4am). This is simply the last part of the first step of a four step process. The four steps:

1. Working Draft (WD): This is the first time a proposed specification is shown to the public and open for comment.


2. Candidate Recommendation (CR): Significant features are mostly locked and feedback is requested in how to implement the standard.


3. Proposed Recommendation (PR): The specification has been submitted to the W3C Advisory Council for approval. Changes at this point are rare.


4. W3C Recommendation (REC): The specification is final and endorsed by the W3C. This is what the general public considers a final standard.

To recap, we are approaching the end of the Working Draft step. This meets the timeline that the W3C laid out in the HTML Working Group Charter and a press release from mid-February (ok, Valentine's Day) of this year. The schedule that working group has been pushing all along puts the final release of HTML5 in the second quarter of 2014. The dates as laid out in the charter, as they correspond to each step in the process

1. Working Draft (WD): Last call: 2^nd Quarter 2011


2. Candidate Recommendation (CR): 2^nd Quarter 2012


3. Proposed Recommendation (PR): 1^st Quarter 2014


4. W3C Recommendation (REC): 2^nd Quarter 2014

If the HTML working group keeps making its deadlines, we are still three years out from a final standard (or set of standards, really). Given how complex these all are and how much debate is happening among them, it shouldn't be a surprise that it can take this long. For example, these two posts helped re-open the issue of alt attributes in HTML5: Image alt Attributes Not Always Required in HTML5, More on Image alt Requirement in HTML5.

If we're practical about all this, and I'd like to think we are, we are in the midst of a new set of browser skirmishes that have resulted in greater and greater support for many of the features to be included in HTML5 and its related specifications. Even if the semantic meaning of all the new elements can't be harnessed in CSS or even in search engine parsing, some of the more advanced features can be used in some of the more advanced browsers. These are all contributing to testing the specifications, something necessary for a specification to keep moving forward (indeed, test suites are a necessary part of the natural flow).

If you are interested in contributing to the specification, you have until August 3, 2011 to get your feedback to the working group. If you want more detail on what you can do or what is expected, go read the FAQ for HTML5 Last Call.

Now I'd like to put a little context in place here. Nearly a year ago I wrote about how CSS 2.1 was not yet a final specification (CSS 2.1 Still Not Final). CSS 2.1 was in the second step as a Candidate Recommendation. the CSS 2.0 specification was finalized in May 1998, but it's taken over 12 years to move the 2.1 revision along. That has not, however, stopped its real-world implementation by developers. It also helps that CSS 2.1 is just building on CSS 2, so it's not quite a fair analogue.

Related

• Last Call: W3C Invites Broad Review of HTML5 and Five Related Specifications


• HTML5 Spec Hits Last Call Status


• HTML5: Are We There Yet?

Read More

More on Image alt Requirement in HTML5

Nearly two weeks ago I wrote up a post outlining the W3C decision to no longer require the alt attribute on images in HTML5: Image alt Attributes Not Always Required in HTML5. I was genuinely surprised to see that was the most popular post on this blog and garnered the most re-tweets on Twitter I've ever had.

I pulled the alt decision off the W3C mailing list, before it was officially announced in any forum, so I suspected it might languish in obscurity for a while. I wasn't quite right. First, to recap the decision:

• The presence of aria-labelledby does not make missing alt conforming.


• The presence of role=presentation does not make missing alt conforming.


• The presence of <meta name=generator> makes missing alt conforming.


• Use of private communications does not, in itself, make missing alt conforming.


• The presence of title makes missing alt conforming.


• The presence of figcaption makes missing alt conforming.

Just over a week later, Steve Faulkner, member of W3C HTML Working Group along with other W3C working groups, provided a more in-depth and detailed overview, including a re-hash of the full decision in his post HTML5 Accessibility Chops: the alt decision.

On Friday, the HTML Accessibility Task Force mailing list took up the discussion of the alt attribute, starting in the email with the subject "[text] updated draft of clarification on alt validation." This message outlines the response to the alt decision, specifically targeting those issues with which the Accessibility Task Force has taken issue.

To distill the response on why the exception for the presence of <meta name=generator> should be re-examined (these are just the key points, descriptions of each are in the email):

• Evidence: deliberately omitting alt due to generator exception.


• Evidence: list of authoring tools (mis)using the meta generator.


• Evidence: lack of alt checking is harming:
  
  
  
  • A reintroduction of versioning.
  
  
  • Two tier document quality.
  
  
  • Generator is already in use for other purposes.
  
  
  • Drops all requirements on the floor.
  
  
  • Alternatives to the generator exception.
  
  
  
  

A distilled high-level list of why the presence of a title attribute obviates the need for an alt:

• Title has taken on the role of a visual element in the form of a tooltip and invisible when images are turned off, but alt is visible when images are turned off.


• Where images are disabled or inaccessible in current browsers such as smartphones saving bandwidth, title will be useless to users.


• Title text will now be generated on even decorative images, negatively impacting the user experience.


• A link to screenshots (IE8, Firefox, Chrome, Opera, Safari) is provided as an example of how a title and alt display when images are disabled.

Finally, on the decision that <figure> with an associated <figcaption> allows the exclusion of alt (also distilled):

• Given that <figcaption> lends itself to verbose text, this may be far more than is necessary for an end user, and removes the ability for the user to choose.


• Current use of <figcaption> tends to be for images users can see, whereas alt is for images users cannot see.


• Screen readers do not currently support <figcaption>, meaning it cannot effectively replace alt today.

Further discussion on this draft is scheduled for a meeting among the W3C HTML Accessibility Task Force today (May 2). In the meantime, feedback has been rolling in from other members on the list, some of them challenging the assertions made in the draft response. You can continue to follow the discussion by reading the thread in the April 2011 mail archive. Since May has just started and this thread crosses into May, you can catch up on the most recent discussion in the May 2011 mail archives.

Sadly, as evidenced by my posting silence for most of April, I won't be able to follow the results of a meeting today and will probably have to wait for the news like everyone else. If this topic interests you , then you may want to follow along on the W3C mailing list archives.

Read More