Did a little benchmarking, and found this out: JavaScript Events onkeypress and onkeydown fire at the same rate. They fire 16 times per second, or about once every 267 milliseconds.

Why this benchmarking? If you’re using either onkeypress or onkeydown to trigger some action in your JavaScript code, you could wind up triggering that action 16 times in a second. What if it’s a request that triggers some DB processing or an expensive UI action (like creating a closure with a potential memory leak)? That’s something you should avoid. Solutions?

• Use onkeyup to trigger your event. It fires once only, when the key is released.
• Create a flag which your onkey… function checks before executing. The first call sets the flag; before it returns, it unsets the flag. In the meantime, you won’t run (and re-run) expensive operations over and over.

Either way, watch out for the “spamminess” of these Events, and how often they fire.

technorati tags:javascript, events, onkeypress, onkeydown, onkeyup

The Firebug Command Line API lets us get even more out of Firebug. Study it!

technorati tags:firebug, debugging

Adobe’s running a bus tour to introduct/promote its new AIR framework to developers like you and me. A bus tour? With an API? Very Web 2.0.

technorati tags:adobe, air

Here’s what will be changing (added, dropped, altered) when HTML4 is replaced with HTML5. Get to know these guys. Make friends. They’ll be around for a while.

technorati tags:html, html4, html5, w3c

This one took me way too long to figure out. (And yes, it’s a stupid mistake that led to way too much debugging). Firefox allows this as a valid object:

{  foo: 'bar', baz: 75, }

Note the extra comma that shouldn’t be there as there’s no successive name/value pair. IE throws a fit at this, and declares the object invalid. (I tried to see if this is valid or invalid code in a JavaScript spec, but my quick research didn’t yield any results. It seems wrong from a coding-standards point of view.)

Note also that if this type of code appears anywhere in an object you’ve created, like as a property or method IE will declare the entire Object invalid.

technorati tags:object, literal

A pretty comprehensive list of CSS Selectors and Pseudo Selectors and browser support

technorati tags:css, browsersupport, selector

As a Aptana fan, it’s time to tout one of its features. (Prerequisite: download the app. It’s a really good IDE that becomes a must-have app if you’re doing anything with RIA or Rails, as they’ve merged RadRails into their larger project.)

In the Aptana perspective of the IDE, click the little yellow triangle with an exclamation point in it, right under the top menu bar on your screen. See a bunch of little yellow triangle icons and bars appear around the document you’re working on? Those are warnings; they show you things your should fix to improve your code and knock out minor bugs (missing semicolons in your JavaScript, missing alt attributes on your images, etc.). Improve your code! Click the yellow triangle!

Why can’t I ever remember this?

filter:alpha(opacity=[0..100]);

technorati tags:ie, css, opacity

Just for the heck of it, I’ve been messing around with YUI’s Drag and Drop utility. In the past, over on Phondoo, I’d used Dojo’s Drag and Drop implementation, so it took a little bit of work to get used to the YUI way of doing things.

The essential difference in the two is that Dojo’s implementation is more widget-y (if that’s a word) while YUI’s implementation is more customizable. Dojo Drag and Drop more or less works out of the box; with the YUI version, you’ll have to write a bit more custom code to achieve the out-of-the-box Dojo effects. However, because it’s so customizable, you’ll be able to really turn it into an application with a look-and-feel that’s all your own.

Because bulleted lists improve readibility, here’s pretty much exactly what I just said, all bulleted out for scanability:

• Dojo’s widget-ness– Without any customization, you’ll be able to do a lot more with Dojo’s Drag and Drop. Basically, Dojo’s provided a fill-in-the-blanks kind of implementation, where you create a couple objects, and bang! it all works. With YUI, you’ll need to write more code.
• YUI is more customizable– YUI’s Drag and Drop API has a lot more exposed, especially in regards to event bubbling: you’ll be able to access more points in time during an interaction cycle with YUI.
• YUI has a more open API– You have a lot more access with the YUI drag and drop API. Event bubbling aside, you can more easily customize (or choose not to implement) pieces of the Drag and Drop cycle, which leads to code that fits your situation better.

Which works better? Well, if you’d like to get up and running right away, Dojo’s widget-y implementation is your choice. If you’re not afraid to write some code, YUI will give you a more robust, customized solution. In all, once you’ve gotten used to (and learned to enjoy and take advantage of) YUI’s event bubbling you’ll find that these hooks can make all the difference in your application (they provide many more opportunities to have your code do something when it needs to be done). Both implementations are very nice, work very well, and, although I’d give YUI the edge, come recommended.

technorati tags:yui, dojo, draganddrop, javascript, dhtml