Bobby delivered an excellent answer about password strength, so I will focus the code.

It states to match one non-line-break character followed by any of the following characters !,@,#,$,%,^,&,*,?,_,~, or a character in the range comma to comma, or any of the following (,). You repeat comma as if it were a separator, a character class need no separators, so putting a comma in a character class simply means that it will match comma. A dash on the other hand has a special meaning in a character class, so you will need to escape it if you want a character class to contain dash.

In general I would recommend escaping all special characters in regular expressions if you want to use their literal value, it helps you avoid mistakes like this dash, and makes the intention clearer.

Alternately if you for some reason only want the basic printable ASCII special characters you can easily include them all using ranges (use a character map to find such ranges):

Some people would like avoid such inline code altogether, personally I don't think it is so bad to inline a simple function call, but including all those parameters is a bit of an eyesore, and there is really no reason to have them, your function could easily fetch the same info itself.

Another thing to consider is that there is no guarantee that the keyup event will fire just because something was entered into the field. That would for instance be the case if something was mouse-pasted into the field, and I'm not sure that you can rely on keyup to fire on all devices that use screen keyboards. In any case I'd double-guard a live field validation function by also having it fire on the change event.

Bobby delivered an excellent answer about password strength, so I will focus on the code.

It matches one non-line-break character followed by any of the following characters !,@,#,$,%,^,&,*,?,_,~, or a character in the range comma to comma, or any of the following (,). You repeat comma as if it were a separator. A character class need no separators, so putting a comma in a character class simply means that it will match comma. A dash on the other hand has a special meaning in a character class, so you will need to escape it if you want a character class to contain a dash.

In general I would recommend escaping all special characters in regular expressions if you want to use their literal value, it helps you to avoid mistakes like this dash, and makes the intention clearer.

Alternately if you for some reason want only the basic printable ASCII special characters you can easily include them all using ranges (use a character map to find such ranges):

Some people would like to avoid such inline code altogether, personally I don't think it is a big deal whether or not to inline a simple function call, but including all those parameters is a bit of an eyesore, and there is really no reason to have them, your function could easily fetch the same info itself.

Another thing to consider is that there is no guarantee that the keyup event will fire just because something was entered into the field. That would for instance not be the case if something was mouse-pasted into the field, and I'm not sure that you can rely on keyup to fire on all devices that use screen keyboards. In any case I'd double-guard a live field validation function by also having it fire on the change event.

###Clean tables I'm not sure exactly what that Rails label does, but if anything is rendered in its place the result is most likely illegal HTML, and therefore possibly inconsistent browser behaviour. You can enclose a complete table in another element, or you can put an element inside a single td or th element. Anything in-between is generally not allowed.

Bobby delivered an excellent answer about password strength, so I will focus the code.

###Reg ex You have the following regular expression:

/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/

It states to match one non-line-break character followed by any of the following characters !,@,#,$,%,^,&,*,?,_,~, or a character in the range comma to comma, or any of the following (,). You repeat comma as if it were a separator, a character class need no separators, so putting a comma in a character class simply means that it will match comma. A dash on the other hand has a special meaning in a character class, so you will need to escape it if you want a character class to contain dash.

In general I would recommend escaping all special characters in regular expressions if you want to use their literal value, it helps you avoid mistakes like this dash, and makes the intention clearer.

In the context it seems strange that you include so few characters in a special character class. For this feature it seems logical to simply define special characters as anything not in the other character classes:

/[^A-Za-z0-9]/

Alternately if you for some reason only want the basic printable ASCII special characters you can easily include them all using ranges (use a character map to find such ranges):

/[\ -\/\:-\@\[-\`\{-\~]/

###Function call

You have the following in your HTML:

<input id="user_password" type="password" size="30" name="user[password]" onkeyup="chkPasswordStrength(this.value,document.getElementById('strendth'),document.getElementById('error'))">

Some people would like avoid such inline code altogether, personally I don't think it is so bad to inline a simple function call, but including all those parameters is a bit of an eyesore, and there is really no reason to have them, your function could easily fetch the same info itself.

Another thing to consider is that there is no guarantee that the keyup event will fire just because something was entered into the field. That would for instance be the case if something was mouse-pasted into the field, and I'm not sure that you can rely on keyup to fire on all devices that use screen keyboards. In any case I'd double-guard a live field validation function by also having it fire on the change event.

Bobby delivered an excellent answer about password strength, so I will focus the code.

###Reg ex You have the following regular expression:

/.[!,@,#,$,%,^,&,*,?,_,~,-,(,)]/

It states to match one non-line-break character followed by any of the following characters !,@,#,$,%,^,&,*,?,_,~, or a character in the range comma to comma, or any of the following (,). You repeat comma as if it were a separator, a character class need no separators, so putting a comma in a character class simply means that it will match comma. A dash on the other hand has a special meaning in a character class, so you will need to escape it if you want a character class to contain dash.

In general I would recommend escaping all special characters in regular expressions if you want to use their literal value, it helps you avoid mistakes like this dash, and makes the intention clearer.

In the context it seems strange that you include so few characters in a special character class. For this feature it seems logical to simply define special characters as anything not in the other character classes:

/[^A-Za-z0-9]/

Alternately if you for some reason only want the basic printable ASCII special characters you can easily include them all using ranges (use a character map to find such ranges):

/[\ -\/\:-\@\[-\`\{-\~]/

Here's a short explanation on how this works:

/[         // start of the expression/range
  \ -\/    // All characters from " " to "/"
  \:-\@    // All characters from ":" to "@"
  \[-\`    // All characters from "[" to "`"
  \{-\~    // All characters from "{" to "~"
]/         // end the range/expression

###Function call

You have the following in your HTML:

<input id="user_password" type="password" size="30" name="user[password]" onkeyup="chkPasswordStrength(this.value,document.getElementById('strendth'),document.getElementById('error'))">

Some people would like avoid such inline code altogether, personally I don't think it is so bad to inline a simple function call, but including all those parameters is a bit of an eyesore, and there is really no reason to have them, your function could easily fetch the same info itself.

Another thing to consider is that there is no guarantee that the keyup event will fire just because something was entered into the field. That would for instance be the case if something was mouse-pasted into the field, and I'm not sure that you can rely on keyup to fire on all devices that use screen keyboards. In any case I'd double-guard a live field validation function by also having it fire on the change event.