Un-phrases and other interesting things

This morning at a meeting, one of the participants shot out a couple of very funny phrases, which were essentially un-phrases.  What I mean is that they didn't make any sense because they in fact were a combination of 2 related phrases or just a complete mismatch.  Here's the first one:

1. "She's not the smartest light bulb in the the room".

And here are the two derivations, which if combined together produce the above phrase:

... not the brightest light bulb in the room (or box as I've more often heard it)
... not the smartest person in the room

What is humorous about this is that LIGHTBULBS AREN'T EXPECTED TO BE SMART, since they are not sentient or even animate objects, they are only expected to be bright.

2. (Speaking of the time-frame), "We need to stretch it down".  This is a verbose way of saying that the time frame needs to be compressed or shortened.

3. The word BETA pronounced bettah. This was a first for me. I was very interested to hear him pronounce alpha, but couldn't seem to work it into the conversation.

4. "We will do this VICE doing that."  This would appear to be a mismatch of the phrases "vice-versa" and "versus".  The phrase rendered correctly should have been, "We will do this VERSUS doing that".

Have a good Monday evening!

Developer Tools Compared (IE,FF,Chrome,Safari,Opera)

This post is part 1 of 2 comparing the relative functionality among IE, FF, Chrome, Safari and Opera's web developer tools.

Here is a spreadsheet I created to show the differences in features among the different browsers.  I will continue to update this as I learn about more features and add-ons.

I've branched out a bit from just the javascript debugger and tried to cover some of the useful tools as well that are part of the browsers.  Eventually, I'd like to grow this spreadsheet into a full on comparison of virtually every feature/bug in all the browsers.

The spreadsheet is not editable, but feel free to post comments if you find any issues or want to add something to it.

So here is a quick summary of what I found:

1. All the browsers can debug javascript and update CSS realtime.
2. IE and FF had the best command line interfaces. I had a hard time finding the command line in the other browsers, but will continue to try and find them.
3. Safari and Chrome have virtually the same interface (Did Google license Safari's developer tools?)
4. One should have no problem whatsoever debugging javascript and CSS issues in any of these browsers.
5. IE was surprisingly the most robust feature-wise, with a great many more features than any of the other browsers and missing only a color picker.

In part 2, I will provide a subjective rating of each of the browsers abilities to help web developers debug issues with their websites.

Key Events

Keyboard events can sometimes trip up even seasoned developers. 

I'm listing the keyboard events below in order that they fire:

1. Keydown - fires 1st when a finger pushes down on a key

    a. You can prevent any input from displaying in the textbox or textarea.

    b. This is the event that fires when a key is held down.

    *   Use this event to prevent users from inputting numbers where text is expected or ensuring that the input is always in the correct format.

    ** You can detect the keycodes and map them or you can just translate them to charCodes and use a Regex to determine input validation.

2. Keypress - fires 2nd when a finger keeps a key down.

    a. At this point its too late to prevent the character from showing, but you can still remove it after it has      displayed.

    * If you check a character and then remove it after determining it is bad, the user will see a visible flash where the character shows up and then disappears, which is probably not the desired effect.

3. Keyup - fires 3rd when a finger pushes release a key

    a. Really just a point in time at which you can say all the input has completed and the decisions to show or not show the characters have already been made. 

    b. You can trim or remove or reformat at this point also.

    * Remember that this event fires before a "change" event, because the "change" events requires "blur" or clicking/tabbing off the textbox. (This also applies to the "blur" event of course.)

KeyDown vs OnKeyDown

Sometimes it can be confusing whether you should bind the events to "keydown" or "onkeydown".  The recommendation is to use jQuery's browser-agnostic "keydown" event to do the binding.  It will figure out the correct event name for the browser currently running. 

*This of course applies to keypress and keyup as well as most of the other bindable events.

You should always use jQuery's event.which.  This will normalize the input for all browsers so that you don't have to check event.which and event.charCode and event.keyCode.

Inception

This is the genesis of a blog called Client-Side Scripting.  Its aim is to provide web developers and anyone else who may be interested with some of the best and most interesting client-side scripting techniques.  It will not be devoted solely to Javascript, although much of its content will probably be in that vein.

I am interested in HTML5, SVG, CSS3, Javascript, UI Design, and layout techniques.  If something really good comes along, I will probably be interested in that as well.  So let's get going and start up some nice conversations and get some good information disseminated.

I will always endeavor to answer any comments that solicit such. However, I may not respond to angry or negative comments, as I am not interested in arguments.