Scott Johnson has a great podcast/blog post on common RSS mistakes:

1. Putting session IDs into feed urls
2. Not validating your feed. Valid XML really, really matters. http://www.feedvalidator.org/.
3. Too many feeds.
4. Making it too hard to find the feed. There’s a standard logo. Use it. Link to it from every page.
5. Getting auto discovery wrong / not supporting auto discovery at all. Even today this happens all the time.
6. Not offering full content feeds.
7. Improper encoding of data. See point #2. (This happens even with “major” sites — I saw it today from Digg.com’s feed.
8. Not testing in multiple aggregators.
9. Trying to track the exit path of links.
10. Not testing specifically on the hell that is MS-Word data. “SmartQuotes” which I think are the devils handiwork in particular.
11. The feed:// psuedo protocol. Oy.
12. Placing XML purity over the care of the user.

As someone who has mostly consumed feeds I’d say that #4, #6 and #11 are the items that have bothered me the most. Especially #11, I’m tired of having to correct cut-n-pasted links out of WordPress blogs that still have the feed:// included in their feed URL.

I’m not much of a basketball player, but most Tuesday nights I manage to run up and down the court for about 90 minutes. After this week though I won’t be playing for awhile. Last Tuesday while coming down from a rebound I looked down just in time to watch the outside of my right ankle bend over and touch the floor. To make things worse I heard that wonderful cracking sound that lets you know that something bad has just happened. After getting home I found my ankle was quite swollen.

I spent most of yesterday at the getting checked out by my doctor, getting x-rays, crutches and an air splint. The good news was that the x-rays didn’t show a broken or fractured fibula. Not much fun sitting around icing my ankle trying to get the swelling down though.

So if you’ve ever looked down and wondered how far your ankle can bend, yes it can bend around touch the floor and snap back. After having done this myself I confirm the possibility, but wouldn’t recommend that you try it yourself.

Here is an interesting feature that I didn’t know about, you can compress JavaScript and use that file directly, just like the uncompressed version. So after gzip prototype.js you can use it in a web page with:

<script type="text/javascript" src="prototype.js.gz"></script>

No need for mod_gzip or mod_deflate in Apache. Compress the file once and enjoy the reduced bandwidth and load on your web server.

This is pretty cool because prototype.js (version 1.5.0_rc0) is 55,150 bytes. After gzip on my Mac OS X system prototype.js.gz shrinks down to 12,479 bytes. Easy way to loose 42,671 bytes. You can save another 98 bytes by using gzip -9, down to 12,381 bytes. Unfortunately none of the browsers seem to support bzip, which shrank prototype.js down to 11,556 bytes.

I’ve tested this on Firefox 1.5 and IE 6 on Windows; Firefox 2, Opera 9 and Safari 2.0.3 on Mac OS X. Before you get too excited there is one problem, this doesn’t work on Safari. All of the browsers that I tested showed no difference between gzip and non-gzip JavaScript except for Safari.

So if you want to properly support Safari in your web app you’ll have to skip this idea completely or look at some sort of browser detection mechanism (ick) which would serve uncompressed JavaScript to Safari.

Just a quick entry to note that I’m still working on the EditInPlace code. I’ve received some suggestions and bug reports that I’m working through. In addition to general features and fixes I’ve taken to rewriting the whole library using different approaches. While JavaScript is flexible in some ways, it is down right odd in other ways.

There are days when I wish that JavaScript would be replaced completely by some other embedded language. I’d suggest Python, but the white space issue would feel strange in the world of (X)HTML. Perhaps Perl, PHP or even Ruby?