Progressive enhancement is a fairly well known concept. Start with a valid, semantic and, most importantly, usable page and then add the niceties to it with javascript. If javascript isn't available or something breaks, then you don't have the niceties but you still have a usable page. Like I said, this is especially important for user input. Nothing is more frustrating than not being able to use a form because some half-wit developer thought they'd do something clever with javascript... or so my users tell me, anyway.

So, getting back to the radio buttons. We should set up some requirements.

• Instead of radio buttons, we'd like to see an icon which has two states: on and off.
• The icon behaves exactly like a radio button:
  1. Clicking on it or its label activates it.
  2. Clicking on a different button in the group deactivates it.
  3. Accessible via the keyboard or mouse
• With javascript turned off, it should still work
• Minimal extra markup required.
• Cross browser

The styles, including the icon images will be handled via CSS, so each radio button will need a class to identify which icon to use. We'll also need a class to identify which radio buttons should be replaced with images. This leaves our HTML fairly standard:

<input type="radio" name="sex" value="male"
    class="image_radio male_icon" id="male_radio" />
<label for="male_radio">Male</label>
<input type="radio" name="sex" value="female"
    class="image_radio female_icon" checked="checked" />

I've not given the second radio button an ID or label, just to demonstrate that both are optional. I'm not much of a fan of the overuse of ID attributes...

Almost all the styling is done via CSS, of course:

label.image_radio {
    width: 16px;    /* the same size as our icons */
    height: 16px;
    display: inline-block;
}
label.image_radio input.image_radio {
    margin-left: -9999px;
    /* this effectively hides the radio button
    without removing it from the document flow */
}

/* define the icons for each radio */
label.male {          background-image: url(male_off.png);   }
label.male.active {   background-image: url(male_on.png);    }
label.female {        background-image: url(female_off.png); }
label.female.active { background-image: url(female_on.png);  }

So, if you were to take a look at this in your browser, you'd see a completely unstyled page with standard radio buttons. Excellent. Without the javascript, we haven't broken anything. Now, let's enhance.

Before I jump into the jQuery, I'll just get on my soapbox for a quick second to note that if it weren't for IE, the following code would be a single statement (kinda). If you click on a label associated with an input, IE doesn't pass the click event on to the input so we have to manually add those labels into our result set before applying the click event.

And that's all there is to it. There's probably still quite a bit more work you could put into it (for example, though it's still completely accessible via the keyboard, there's no visual indication that a particular button has focus), but it provides nice progressive enhancement for your radio buttons. With some very small tweaks, the same code could also apply to checkboxes too!

Javascript, on the other hand, returns the first determining value in the statement.

That is, when using ||, the result will be the first truthy value or the last value.

When using &&, the result will be the first falsey value or the last value.

"Truthy" and "falsey" here obviously means a value which, when cast to a boolean, is true or false, respectively. Falsey values are 0, -0, false, null, undefined, and NaN. Truthy values are everything else (including "0", empty arrays and empty objects).

Knowing this gives us the opportunity to use a handy little shortcut for setting some default values for variables.

The other important thing to know about the boolean operators is that they will short-circuit the processing once enough information is known to determine the output. That is, when using &&, if the first parameter is falsey, then it doesn't matter at all what the second parameter is, since the output will always be false(y), so it skips evaluating that parameter. Similarly with ||, if the first parameter is truthy, then we can stop right there. This allows us to write a slightly more efficient default-value routine.

If the first parameter is truthy, then it stops right there and never actually evaluates the second parameter which would assign a value to a. This is a bit more efficient than the first example, since there is only ever an assignment when it is required. How slight is this gain? Over 1,000,000 loops, running the first method took ~1640ms compared to ~1400ms for the second, so it's not going to make even a vaguely noticeable difference, but it doesn't hurt to do things the best way, right?

Though I've got plenty more reputation than I could possibly need (that is, I have full user-moderator rights), this has affected my score. A lot. Like -4250. Bummer. I ask a lot of questions and I think doing so is a really good thing, so I'm a little disappointed to see it go this way in discouraging new questions. Good questions already only attracted a fraction of the number of votes which good answers receive, so I guess I don't see it as fixing anything which was broken in the first place.

As you'd imagine, it stirred up a bit of malcontent in the comments thread (though, this happens with any change):

This constant changing and making it all retroactive to all previous votes cast is crap. When people signed up you told them the rules and awarded points based on those rules.

I understand that things change and need to be changed in order to keep possible issues and problems in check. However rolling back people’s points is a jerk move and one you seem to have no issue doing.

I feel bad for the people [who have lost much rep], but we all get the added bonus of *having our questions answered* when we ask them. I think this change just shifts the focus of asking a question away from gaining reputation and towards getting an answer. Just as it should be.

I can understand the need of the changes *now*, but why punish those who helped bootstrap the system by providing lots of questions in the beginning?

Well, that’s demotivating. I’m pretty close to 10K, and this rule-change/recalc will drop me back to 8.7K.

Not much incentive to keep running on the rat machine, is it?

I feel this guy's pain. Though it's obviously not the main reason I or anyone else would visit the site, trying to achieve a "high score" is one key feature, and knowing that it could be arbitrarily taken away from you just like that is quite demotivating. Though how can you argue when the site owner says this:

I think it’s healthy for everyone to realize that rep is kind of an arbitrary concept, and think about what it means to them, to anyone else, and why.

Overall, it seems as though not many are actually too concerned about the change in rep, but there's quite a lot of people who are very annoyed at the fact that it is being applied retroactively. There was a bit of a discussion/speculation about the notion that this was technically the only way to do it, which is rubbish. Yes, you don't want to have to keep a history of rules and the dates they changed, since that would grow unwieldy and awkward very quickly. Here's a smarter way to do it: get the Community User to double every single vote, then halve the score to +5. Done.

For a website built on community contribution, I'm just saddened to see how little they actually listened to their users. Perhaps only the voices of the top users were heard? The ones with nothing to lose anyway.

The "Voice Control" ad for the Ford Mondeo.

If you're going to make an ad touting a new feature such as voice control, it'd probably be a good idea to not highlight how buggy your software is.

jQuery 1.4 has been released. Kinda.

It's a little baffling to me, considering the first release candidate was only announced one day ago, yet the dedicated jQuery 1.4 website proudly states "jQuery 1.4 has been released!", but alas, there is no link. The nightly build still reads "1.4a2-pre", so I guess it's up to me.

jQuery 1.4 is here.

It's a tad overdue. The roadmap slated it for a November 2009 release, and it's been promised for a while now, but it's here now anyway. I was looking at a jQuery cheat sheet which contains the new functions introduced in 1.4, and two of them jumped out at me: nextUntil() and prevUntil. They seem to be very similar to something I've seen before. Kinda. Maybe I'm just seeing things.

This is something that I struggled with when I started playing with AJAX techniques, too. It's quite understandable how so many people run into this issue. I mean, virtually other bit of code you write is executed in the order you write it. You'd expect that the alert() above would be run after load() function has run. Of course, you forget that A is for Asynchronous.

Solving the problem the wrong way: SJAX
The first logical step that many people seem to move to is to avoid the situation altogether. If making an asynchronous call is causing this problem, we'll just switch to synchronous calls - problem solved! This is entirely the wrong way to do it. Synchronous XHR calls will allow the the code sample above to run as the developer would hope, but it has the very nasty side effect of freezing the browser while it waits. No further code is executed until it get the response from the server. This is often overlooked due to poor testing. On a developer's local machine, the request completes in milliseconds and everyone's happy. In real life, a slow connection or an overworked server can render the user's browser useless for 30 seconds or a minute. Depending on the browser, you can't scroll the page, change tabs, open new links, etc. This is probably not the "improved user experience" you were hoping to deliver.

Solving the problem the right way: callbacks
When setting up an XHR call, you are able to specify a function to be run when its status changes. Using vanilla javascript, this can be a pain, but libraries such as jQuery make it much simpler.

You do have to adjust how you think about your program flow, but once you starting thinking with portals AJAX, you'll never look back.

Addendum
The basic message of this post has been synchronous XHR is evil, but I should mention the ONE place where its use is legitimate: inside onunload events. These events are called when the user leaves the page or closes the browser. If you want something to happen then, such as automatically saving a page, then asynchronous XHR will not help, since the browser closing or page changing will cancel the request immediately. In this scenario, locking up the browser while the request is being processed is somewhat acceptable. Just remember to test that it doesn't take too long!

As you can see, I have been treating it as a bit of a game - trying to get a high score, trying to beat the other players. Obviously that's not my only motivation, but you know what I mean: it's always nice to see rewards for your work, even if it's just a number. As such, I've looked at the profiles of some of the people above and around my score and very quickly noticed a trend: the top users on Stack Overflow ask barely any questions. Below is a graph of the number of questions and answers from the top 36 users:

Can you see me on there? Waaay over on the right, with 250 questions - sixteen times the median! My question-to-answer ratio is right on 4, whereas the median in this group is 139. There are two people there with reputations well in excess of 35,000 who have never asked a single question. Obviously, this baffles me.

It really makes me think about who these people are, and what they are doing in their daily jobs such that they have no questions? Some of the people we're talking about here literally wrote the book on their chosen field of programming, so they're probably excused, but still... no questions? It leads me to draw some conclusions:

1. This person knows everything there is to know about C#, or Ruby, or PHP. They are never posed with any programming problems they can't solve without help.
2. This person considers asking the Internet for help to be unprofessional, or that the Stack Overflow community would be helpful in answering their questions.
3. This person works in an environment with a lot of other really-smart people, and help is attained offline.

In response to these:

1. Learn something new, man! Pick up some Javascript, or Go! or a new Framework in your current language, but choose something.
2. This doesn't seem too likely, and I hope it's not true. If someone who was already active in a Q&A forum had a question but withheld it to save face, that would seem a bit vain to me. I personally have no problems asking questions which would seem simple to my peers.
3. Well... top effort! Lucky you.

To me at least, asking questions is a sign that you're learning. I always have questions about the work I'm doing, whether it's how to actually get it right, or whether there's a better way than what I'm already doing.

What's your opinion on the matter? If you're a Stack Overflower, what's your question:answer ratio?

This is actually one of my biggest pet peeves in reading jQuery related information, whether it's questions or answers on SO, or in numerous blogs or articles. It's such a common occurrence that I found myself shouting at the screen whenever I saw it:

83.333% of jQuery is Query.

The one thing you must always remember is that jQuery is a query tool. Sure it's not just that any more, but it was born from inspiration taken from my previous-favourite javascript library, Behaviour (now defunct, but written by Ben Nolan).

It seems like a lot people get into jQuery by reading a "Top 20 Best Ever Amazing Useful jQuery Plugins Of All Time" list, where the only code they provide is this:

...and they really don't realise the massive power sitting right in front of them in the selectors and traversal functions. Here's an example of what I mean:

This is naturally followed with inexplicable code like this:

Here's my rule of thumb: for each behaviour you're writing, if you use more than one id selector, you're doing it wrong. Ids should be used only as an entry, as a front door to the house which is your HTML. From there, you can use intelligent selections and traversals to get everything you want. Here's how I'd rewrite the HTML above, assuming there was only ever going to be one menu:

That's right: every single one of the ids and classes (except for the front door) were completely redundant and unneeded (get it? ah, nevermind.)

Along with the much cleaner HTML comes much cleaner jQuery:

This is just an example, and not actually tested and functioning code, but with a very few changes, this tiny snippet would provide all the behavioural code needed for nested menus to any depth, without a single class or id being added anywhere else.

If your HTML is littered with ids for the sake of javascript, please take another look at it. Is there any other way you could select or traverse your way to that element? If the only selectors you are writing start with a hash, then you're not using jQuery to it's potential. By my reckoning, you're only at about 16.667%.

Linebreak added for legibility.

If you were wanting to know the functions which exist in a particular class or file for an application or similar, you'd be better off using the PHP Reflection functions which are very powerful and much more robust than any regex solution. I'm just using this regex for my text editor so it will detect all the functions in the current file. The default regex didn't handle all the less-used styles such as "protected static final function".