One of the more confusing things I’ve run into with Javascript is the way mouse and keyboard events really work. It makes sense when you think about it, but I have trouble explaining it to others (which means that, while I get it, I haven’t mastered it myself). I found a good rundown at Quirksmode. Not surprising, I guess, but I’m posting this in case anyone else is looking for one.

There’s a lot to be said about how good prototype and script.aculo.us are. They provide a number of great extensions to the out-of-the-box JavaScript experience. The problem I have is that they’re usually way too much for most simple tasks. The two libraries, when just loading prototype and the script.aculo.us effects, are almost 90KB. I realize we’re in the brave new world of fast bandwidth and fast computers, but the idea of having that much cruft when all I want is $(), Class.initialize, and some basic movement APIs.

The last time I got frustrated with this, when writing the little alerts prototype below, I ended up doing some googling and found bytefx. It’s a small library that provides the basic low-level effects for moving, fading in/out, and resizing. The compressed/packed version (using Dean Edwards’s Packer) is 2.89KB. Very nice. Uncompressed, it’s only 18K, or about half of script.aculo.us’s 30K+ effects lib.

Adding some boilerplate code gives me a safe, dynamic library that avoids duplicates and other items. This is what I’m doing for the alerts library:



It works very nicely and avoids duplication. The dynamic loading was inspired by script.aculo.us’s dynamic loading, but modified for simplicity (all of my stuff waits for document onload because I want it to not hold up the page).

If you’re looking for a simple, small, fast library to do basic DHTML effects, bytefx is my choice.

Update: I did find one thing I patched in bytefx when I used it for the alerts. I added the line in bold below. It was breaking the fixed-position alert in Safari and changing the behavior in Firefox, which bugged me even if it didn’t break Safari.

I hacked together a little plugin tonight while avoiding the wedding planning now staring us in the face. So, now you can enjoy the videos in the RSS feed if you happen to be using a desktop aggregator or a tool like Bloglines. In honor of the new functionality, and as a test to make sure it actually works through FeedBurner, I give you this video:

Hope that worked.

So, I noticed earlier today that none of my posts were showing up in Technorati. I’ve found that whenever this happens, and it happens relatively often, the problem stems from the HTML on this site not validating properly. Since I’m using XHTML 1.0 Strict, this means that anything the least bit unusual generally breaks the page.

I have a couple of custom fixes I’ve had to include to the WordPress installation which disappear every time I upgrade WordPress. I have to figure this out, by the way, because I can’t be the only one impacted by this, so I must be doing something wrong… or it’s one of my custom written plugins. Hmmm.

Anyway, I tried embedding the YouTube player today and that destroyed the page. First of all, the embed tag isn’t part of HTML or XHTML 1.0. So, I can’t include it in the post, which means I can’t let Firefox users see the player. So, I decided to use SWFObject, a JS-based flash embedder. It went downhill from here.

Between X-Valid and the default wpautop and wptexturize, the whole script tag was getting destroyed. The CDATA block was getting ripped out, the > in the CDATA close tag was getting converted to &gt;, and there were <p> tags everywhere.

Even disabling wpautop and wptexturize (via the TextControl plugin) and disabling X-Valid for that post didn’t help. Everything was fine except something kept killing the final > on the CDATA close tag, which is supposed to be ]]>. After worrying about it, then thinking that I need to make another patch to my wordpress install (noooooo!), I just gave up and removed the CDATA blocks and made sure my JS didn’t have any characters that would break validation.

This isn’t a workable solution, so I’ll have to look more. A quick google shows that it might be the rich editor, but I’ll have to look later. Holy crap, though, this is an insanely annoying bug.

Update: And my custom fixes have been removed. CDATA elements still break validation, but the other issue I mentioned where I had to have a custom patch is now resolved. Turns out it was this ancient (by Internet standards) tagging plugin I was using to display the tags on each post. I’ve switched to Christine Davis’s excellent Ultimate Tag Warrior plugin. This plugin should be held up as a poster child for well thought out plugins, at least from a user standpoint. It imported the tags from the old plugin and set them up. There was one problem with the + signs I used for multi-word tags, but a little SQL magic and we’re all set. Still looking for a fix for the CDATA issue, but that will have to wait. I need to get to bed so I can finish a spec tomorrow morning.

You can tell how far browser standards have come when you see Flickr’s new all JavaScript-based Organizr. It replaces the annoyingly slow (on my Mac) Flash-based one. The Flash Organizr was slick, don’t get me wrong, but this is so simple that I’m amazed. I’m also impressed at the richness of the UI considering it’s all done in JS. (here’s more info on the updates)

This is far better than anything we’re doing at ESPN.com, which is still heavily Flash-based and still, well, heavy. It definitely looks better, but is it worth the tradeoff?

That reminds me, if I haven’t mentioned it, you should go check out Campfire. It makes a great scratch pad, even if it is just primarily IM on a web site. Now if they just would sell a downloadable version, it would make life a lot easier for me.