Client-side validator for contact information form (name, phone, e-mail)

My recent post had some things to fix. I think this should be well structured and written for you.

How does this code look to you? If something needs to be changed please tell me.

// Gets all elements by ID's
function elem(id) {
    return document.getElementById(id);
};
//

//Check box id"RadioGroup1_0" will be checked on start up of page (Phone)
window.onload = function () {
    document.querySelector("#RadioGroup1_0").click();
    //

//Gets my Form name (form) and on submission (submit) checks the rules below...

/* first name must be greater than 0
last name must be greater than 0
email must be greater than zero and follow the email reg ex
phone must be greater than 7 but shorter than 11
*/
    var form = document.getElementById('form');
    form.onsubmit = function (e) {
        var rules = [
        ['first-name', elem('first-name').value.length > 0],
        ['last-name', elem('last-name').value.length > 0],
        ['email', elem('email').value.length > 0 && /^([a-zA-Z0-9_\.\-])+\@(([a-zA-Z0-9\-])+\.)+([a-z0-9]{2,4})+$/.test(elem('email').value)],
        ['phone', elem('phone').value.length > 7 && elem('phone').value.length = 65 && charCode = 97 && charCode = 48 && keyCode <= 57) || (keyCode === 8));
    return ret;
}

Validation problems

Beware of overzealous validation. It's easy to create bugs by rejecting valid input. For example:

• Some people have only one name, so the one of the name fields must be allowed to be empty.

• Names often contain non-ASCII characters. Validation must not tell the user their name is invalid!

• Email addresses can contain more characters than you think. For example, "Hello, world!"@localhost.localdomain is a valid address. The validity rules are complex, so if you try to implement them with a regex, you will get it wrong. Fortunately you don't need to reject all invalid addresses, only the most common mistakes. So /@/ is enough validation for practical purposes.

• Phone numbers can be long, because of country codes and extensions. They can also contain characters like +-()x.

You can avoid these problems by not doing much validation. Don't do unnecessary work that creates bugs!

I wouldn't bother with the event filters at all, especially for the name, where any character should be accepted.
Style

onlyAlphabets should be called onlyLetters (it allows letters, not whole alphabets!), or onlyNameChars, since it also allows some other characters.

e.which ? e.which : e.keyCode can be simplified to e.which || e.keyCode.

This conditional...

if ((charCode == 64) ||
    (charCode == 32) ||
    (charCode >= 65 && charCode = 97 && charCode <=122))
    return true;
    else return false;

...can be simplified to:

return charCode == 64 ||
       charCode == 32 ||
       charCode >= 65 && charCode = 97 && charCode <= 122;

...but character codes are hard to read. It might be better to use the string form instead, via operations like String.fromCharCode and charCodeAt.

There are too many blank lines. It's OK to leave one blank line to separate sections (like a paragraph break), but (like anything that consumes lines) they reduce the amount of code that fits on one screen, they should be used only when they improve clarity enough to be worth the extra scrolling.

StackExchange Code Review Q#51126, answer score: 6