Congratulations to all the winners of the IndiBlog Awards - and a special congrats to the five lucky winners who received a free copy of FeedDemon as a prize :)
On Saturday I attended Max It Out, a local charity event inspired by a 4-year old bacterial meningitis survivor whose parents are friends of mine. Bradbury Software was among the event's sponsors, which led to an almost surreal experience.
The fundraiser featured performances by country music stars, and the logos of each sponsor were projected onto a screen during the entire concert. For me, it was, well, very unusual to see the "TopStyle" and "FeedDemon" logos appear behind Keith Urban, Faith Hill and Wynonna as they played.
For the record, I've never been a huge country music fan, but I'm so glad that I attended the event and offered a small contribution through my sponsorship. Well over a quarter of a million dollars was raised for meningitis research, and nobody left that night without being touched by the dedication of parents whose children are affected by the disease.
I recently made plans to attend this year's South by Southwest conference and was reminded of a conversation I had at last year's SxSW. I was talking about RSS with someone who has long been a supporter of CSS-based web design, and he feared that the success of RSS meant that design has lost the battle to content. After all, RSS is all about content - when you read a site's feed in an aggregator like FeedDemon, you're not seeing the hard work put into that site's design. This lead to a comment that TopStyle and FeedDemon were in fact at odds with each other.
I hadn't considered that before, but it made sense. TopStyle is all about designing standards-compliant CSS-based designs, whereas FeedDemon enables skipping the design and just reading a site's content. But then it occurred to me that instead of being polar opposites, my programs are actually complementary. TopStyle's CSS creation enables the separation of layout from content, leading to smaller, faster-loading sites whose design information is contained in style sheets rather than interwoven with every page. This makes it much easier to repurpose a site's content for use in an RSS feed.
Plus, in many ways RSS is an offspring of blogging, and blogging tools rely heavily on CSS-based design. Just look at sites hosted by TypePad and Blogger, or sites which rely on blogging tools such as MovableType and WordPress - almost all of them use CSS to separate their layout from their content.
So, rather than being rivals, I think CSS has helped enable the spread of RSS.
"TopStyle was created by Nick Bradbury, creator of the HomeSite HTML editor. For those of you who like HomeSite, you'll love TopStyle Pro. This program is jam-packed with all kinds of features."And here's another one:
"TopStyle Pro is a very comprehensive (X)HTML/CSS editor. Overall, the program should make your Web design work flow much easier. If you already have a favorite program for developing Web sites, TopStyle Pro can work along side it, adding many other features not found anywhere else."
There has been a lot of debate following my initial post about Really Simple Subscription. Shortly after I suggested using the feed URI scheme, NetNewsWire developer Brent Simmons came out in favor it, and in the comments to my post we heard that Safari RSS (part of Apple's upcoming Safari 2.0) will use feed:// quite heavily.
But other solutions have been proposed, such as the Universal Subscription Mechanism (USM) authored by Randy Morin. I've spoken with Randy about USM, and he knows that I have a number of issues with the "reflexive auto-discovery" mechanism. However, part of his proposal includes convincing feed producers to provide the correct Content-Type header for their feeds, and I'm 100% in favor of this. Although having the correct Content-Type doesn't entirely solve the problem, it would take us a big step in the right direction.
If you're interested in this topic, be sure to read all the comments beneath Brent Simmons' post, including Danny Ayres' comment that he "can't actually see [much] conflict between these approaches, implementing one doesn't rule out implementing the other." I agree. We'd all be better served if we realized this isn't either/or situation and stopped endlessly debating which solution is better. I'm in favor of feed:// because it's simple for everyone to implement, but I'm also in favor of evangelizing feed producers to use the correct Content-Type. And once it's fleshed out some more and answers my concerns about privacy, I may like Dave Winer's solution as well.