Brian Crescimanno

Today I spent a good deal of my time dealing with Javascript event handling and delegation using the Prototype javascript library with relation to some forms in our current project. In addition to simply firing and catching events using actual events, this applications also make use of the click() and focus() methods to fire these events in certain circumstances without user interaction. The issues I'm discussing here are specific to radio buttons and checkboxes across the three major browsers--but primarily focused on Firefox and Safari. The provided example does not use Prototype--it is plain vanilla Javascript. However, the proposed workaround does rely on the Prototype library (sorry, it was just faster that way--and it's also the implementation I used to solve the problem on my own).

What (I believe) the spec calls for:

When a radio button or checkbox is clicked with the mouse, the mouse click event will fire with it's target object set to the radio button that was clicked. The radio button will also gain focus.

Both Internet Explorer and Firefox exhibit this behavior exactly (on true user clicks--we'll get to the event simulation methods shortly). Safari, however, only fires the click event. The checkbox or radio button that was clicked does not receive focus as it should.

So let's just always observe clicks and leave focus to the birds

I told you we'd get back to the event simulation methods in a minute. Both Firefox and Internet Explorer exhibit some strange behavior when using these methods vs. actual events. In Firefox, the click() method generates an event with the target set to the calling element--not the actual target of the click. This is inconsistent with both Firefox's focus() method and Internet Exlorer and Safari's handling of both the click() and focus() methods. This example (Firefox, Safari, and Opera compatible) demonstrates the issue.

So where does the problem start?

In the case when you need to force a particular radio button to be selected by default and you have additional Javascript logic that must run based on that selection. Let's say you have 4 radio buttons as in the previous example and you wish the 3rd radio button to be selected by default (we'll assume there's some Javascript logic that must happen based on the user's selection that must also occur with the default selection). Because the user will not be interacting with the default selection, we must rely on event methods to fire our events. So we have some challenges:

• If we use click() and have our radio buttons listen for a click, Firefox will believe the target of the event is document. The radio button will be selected, but any additional logic based on knowing what was clicked (using event.target) will fail.
• If we use focus() and have our radio buttons listen for focus, Safari will see the radio button receive focus correctly when the page loads as we will be using focus(). However, any actual user interaction will fail as the focus() event will not fire.

A workaround

I intend to open a bug in the Firefox bug tracker for this issue (if one is not already open; I didn't find one with a quick glance through Bugzilla). Until then, I've written a little workaround that requires the Prototype library to function.

First, ensure that your radio buttons are set up to respond to focus events (since we know that Firefox will only react properly to those events when called programmatically.

$('my-form').getInputs("radio").invoke('observe', 'focus', eventHandler);

Now, observe for clicks to forward on:

$('my-form').getInputs("radio").invoke('observe', 'click', fakeClick);

Your fakeClick method should look like this:

fakeClick: function(e){
   var el = e.element();
   if(el.identify) { /* Filter out click() for FireFox */
      if(this.focused.identify() != el.identify()) {
         e.element.focus(); /* Throws the proper focus() for Safari */
      }
   }
}

The other aspect of this is that within your actual event handler, you need to be sure to set the this.focused to the element that currently has focus.

I've created an example Prototype-enabled JS class to show how the functionality works.

Conclusion

So there you have it, some basic information about a bug in Firefox and a bug in Safari that together make for some interesting times when handling events; and a workaround which I hope you will find useful in getting around these two bugs. Please note that the code is more of an example on how to implement it; though it can be copied verbatim if you wish.

Download ClickFix.js (2kb)

Technorati Tags: event handling, events, firefox, javascript, prototype, safari

I've been reading technical books for years on topics ranging from beginning programming guides with C to Adobe Photoshop tips and tricks.  Like most people in this field, I've long been a fan of O'Reilly books (I think my first one was a Perl 5 book somewhere around the 1999 timeframe).  However; recently, I've been hearing some negative things about their books and haven't really picked any up.  My most recent one is a several-editions old version of Javascript: The Definitive Guide.

I was also a fan of the Pragmatic Programmers Agile Web Development With Rails that I managed to purchase just at the wrong time--about 2 weeks before Rails 2.0 was released.  While the book was well written, it has been less than helpful with regard to learning to use Rails.

Despite these (and other) gems, I think most agree that technical books suffer from a lot of problems and are generally very poorly done.   I'm happy to say that I've found my most recent technical book purchase, Adobe Flex 3: Training From the Source to be among the best technical books I've read in many years.  It follows the paradigm of taking you step-by-step through building an application--and does so in such a way that it is easy for novice Flex developers to follow; and at the same time allowing more experienced developers to skip over details that aren't needed.  The book is organized into 26 "Lessons" each adding to the features of the application and employing new concepts.  One of the great parts about these Lessons is that each of them begins with a summary page that gives solid insight into what topics will be covered, and a surprisingly accurate estimate of how long the Lesson will take to complete.

If you're looking to get into Flex development, I highly recommend this title from Adobe.

Amazon: Adobe Flex 3: Training from the Source

Technorati Tags: adobe, books, flex, oreilly

Yesterday I was evaluating early design comps for a new project just getting underway here at AutoTrader.com and I fell into the trap of what I call Designing for Requirements, Not Objectives.

Neil and I were discussing the new versions of the comps that have surfaced since we returned from San Francisco and the improvements around them--at least, some of them.  With one comp in particular, Neil began to repeat the phrase "yeah, but it's not poppin' off!"  and the only argument I seemed to be able to formulate in reply was "True, but it's doing this to meet business requirement x."  After a few minutes of this, I was forced to concede the point that Neil was right and I was arguing from a hollow perspective.  Ask anyone who knows both of us and they'll tell you that Neil has taken to using me as affirmation--as in, "Oh you know I must be right if Crescimanno is agreeing with me!"  Long story short, we disagree often--if only as an exercise to keep the other thinking on the right path.

I'd fallen into the trap of seeing the design purely as a function of meeting the business requirements that have been defined for the project and failed to evaluate it based on the stated project objectives.  While the design presented did a fantastic job of meeting all of the business rules and requirements that had been created around it, the design completely fails to accomplish the primary goal of the project.  When there are many, many forces pulling projects in many, many directions, it's easy to get lost in things like business requirements, advertising specs, reporting, and other measures and to lose sight of the reason the project exists in the first place. It happened to me here; it's happened to many others in the past, and it will likely happen to others in the future.

In design, we often have to cater to multiple, often very disparate groups.  That's certainly the case in this project, and while this design caters to one group quite well--it doesn't serve the other at all.

Remember, when designing anything:

1. Take into account all of your audiences and do your best to serve all of them (recognizing that no one perfect solution for all of them at once exists)
2. Always keep the primary objectives of the project at the forefront of the design--and fit the business requirements within that framework.

At the end of the day, you can satisfy every business requirement in the specs--but if your design fails to meet it's objectives, it won't be successful.

Technorati Tags: Design

Adobe today announced the creation of the Open Screen Project to help facilitate the adoption of Flash and Flash-based technologies on a wide range of platforms. There's plenty of coverage out there today about this initiative--and it's no surprise. For years developers have been calling for an opening up of Flash and it looks like Adobe is ready to give it to us.

The big takeaway: Developers are now free to create their own versions of Flash Player.

First, this is fantastic news for the open source community and projects like Ubuntu who now have the opportunity to create a true "free software" version of the Flash player. Free software purists around the world rejoice!

But there's more to it than just Free Software. Apple's current SLA for the iPhone SDK would not allow Adobe's Flash Player to be ported to the iPhone platform (barring special exception, which I'm not entirely convinced Apple would be unwilling to give). Could Apple develop its own version of Flash Player optimized for the iPhone? The Open Screen Project certainly looks that way--and I honestly can't help but wonder if that's part of the reason Adobe's decided that now is the proper time to announce this project. Given the number of partners (and the conspicuous-in-their-absence-Apple) I'd hesitate to say that the iPhone SDK was a cause for this action; but it certainly may have influenced the timing. One thing's for certain; it very much puts the ball back into Apple's court on the issue of Flash on the iPhone.

I am one of the camp that believes Apple has no interest in seeing Flash on the iPhone. Flash competes too directly with a major Apple technology--Quicktime--for Apple to want to see it there. That said, with the onus now on Apple with regard to Flash on the iPhone, I think the boys at Adobe might have out-maneuvered ol' Steve on this one.

And that might be the most impressive part of it all.

Technorati Tags: adobe, air, apple, flash, flex, iPhone, iPhone SDK, open screen project

For the first time in a long time, I feel like it's actually for me to start blogging again--it's not that I have some conceited notion that the world actually wants to hear what I have to say.  It's more that after moving to AutoTrader.com in November, I feel like I've really found some direction.  All of my previous attempts at starting a blog focused (at least, in my mind) on my own design abilities.  Having found myself at ATC, I've come to accept a pretty sensible truth:  I am not an artist.  

Certainly I have some Visual Design skills; but they are not my strong suit.  My focus has always been on User Experience an Interaction Design and the best way for me to achieve those goals is to focus on User Centric development practices as an extension of User Centric Design.  It's with this mentality that I've chosen simply to install Wordpress, grab a theme I thought was nice, and get to the more important aspect of writing a Blog--actually writing it!

I'm back in Atlanta this week after attending the O'Reilly Web 2.0 Expo in San Francisco April 22-25.  The Expo was, for lack of a better description, a mixed bag.  Duane Nickull and James Ward of Adobe opened the conference for us on Tuesday with an Adobe Flex Boot Camp session which set a rather high bar in terms of conference sessions. Needless to say, after seeing the potential of Flex first hand, I quickly downloaded the Flex Builder 60-day trial and have been running through tutorials since I got back.   As my colleague Neil Green put it to me, "this shit sells itself"--and he was 100% correct.  When we look at Flash version penetration numbers, what we see is that over 98% of systems have Flash Player 8 or better.  What does this mean?  In the simplest terms:

• More people have Flash than have Javascript enabled
• More people have Flash than use any single version of any web browser
• More people have Flash than use any version of any web browser

In my opinion, those are some pretty staggering numbers.  Factor in that the Flash Player will render these SWF files identically on the 3 major platforms--under any browser--and you have a very compelling argument in favor of Flex-based development for the front end.  Especially given that my primary role at ATC over the past 7 months has been as an Ajax developer and my continuing battles with multiple browsers' disparate support for CSS...you get the picture.  Technology like Flex looks pretty good in the face of all of that.

What have you heard about Flex?  What do you see as the advantages and the drawbacks?  Are you looking at implementing it in your organization?    Basically--I've been sold on the idea of Flex; but I'd love to hear the downsides that I'm certain I'm overlooking (and let's try to avoid the "more obvious than obvious" things like "it's proprietary" and "it requires a plugin").  Thanks--that'd be great!

Technorati Tags: ajax, css, flash, flex, javascript, meta, web20expo