Monthly Archives: May 2007

Brett asks the CSS Guy if the Row Locking with Checkboxes is fixed

Brett writes:

I am trying to implement your row over selection technique but have found that clicking the actually checkbox does not work. It would be great if this could work. Clicking the row works and checks the box but if it is checked and you click the checkbox, it doesn’t work. Did you ever fix this?

Brett, prompted by your letter, yes, now I have.

Brett is referring to this post, and specifically, this particular example.

I had my function set up so that if any part of the row was clicked, the checkbox would check. When I clicked the actual checkbox, it would show a checkmark, but since the checkbox is a part of that row, my function would run, too, which would then think it’s time to uncheck the checkbox. In a fraction of a second, it would look like the checkbox never checked, but the row changed color anyway, sending the wrong signals to the end user.

What I needed was a way to listen if the checkbox was checked, and if so, don’t run the extra function that ended up unchecking the box.

There are two JavaScript property/methods that helped prevent that other function from running – cancelBubble for IE, and stopPropagation() for everything else. I don’t want to bore my audience, so keep in mind this explanation is more for my noob scripting reference.

I’m told to use cancelBubble like so:

window.event.cancelBubble = true;

and I’m told to use stopPropagation like this:

event.stopPropagation()

but I need to implement it like this:

someElementHere.onclick = function(BLAH) {
  if (window.event && !window.event.cancelBubble) {
    window.event.cancelBubble = "true";
  } else {
    BLAH.stopPropagation();
  }
}

Here’s that idea implemented in a function, actually working:

function lockRowUsingCheckbox() {
  var tables = document.getElementsByTagName("table");
  for (var m=0; m<tables.length; m++) {
    if (tables[m].className == "pickme") {
      var tbodies = tables[m].getElementsByTagName("tbody");
      for (var j=0; j<tbodies.length; j++) {
        var checkboxes = tbodies[j].getElementsByTagName("input");
        for (var i=0; i<checkboxes.length; i++) {
          checkboxes[i].onclick = function(evt) {
            if (this.parentNode.parentNode.className.indexOf("selected") != -1){
              this.parentNode.parentNode.className = this.parentNode.parentNode.oldClassName;
            } else {
              addClass(this.parentNode.parentNode,"selected");
            }
            if (window.event && !window.event.cancelBubble) {
              window.event.cancelBubble = "true";
            } else {
              evt.stopPropagation();
            }
          }
        }
      }
    }
  }
}

Once again, a link to that example in action.

Validation Hints for your form

Stijn writes:

Now I ran into a site a while ago that had a basic form with a gray border, if I would enter a correct contents the outline would be green, if I would enter something like: fake@fakemail as the contact mail address the outline would be red. I really like this effect but can’t seem to find a tutorial on it. Maybe you have a good solution?

I’m not sure if we can check if the email address is a real email address on the fly, but I think I get what you’re asking.

As someone is typing an in an input field, it would be nice give feedback to the user as they are typing if they have satisfied that field’s validation criteria. This article will explain one way of achieving this effect using JavaScript and CSS.

Go straight to the final example to see it in action, and to download a zip of the html, css, js, and images used.

Stijn’s question asked about changing the border color of the text input. I’m going to describe a different feedback mechanism here (changing the fieldset) because some browsers, namely Safari, don’t care much for borders on text inputs.

Start at the beginning – testing for length

Let’s start with field for creating a username.

<fieldset>
  <label for="username">Create a Username:</label>
  <input
    type="text"
    id="username"
    maxlength="16" />
</fieldset>

For our form, in order for the username to be valid, it should be at least 8 characters long, and no more than 16 characters. The maxlength attribute in the HTML takes care of the high limit. As for the low limit, that’s where we can introduce some JavaScript.

JavaScript

In English: The function tests to see if the length of what I typed is greater than 7 characters. If so, do something. If not, do something else.

function checkUsername(whatYouTyped) {
  var txt = whatYouTyped.value;
  if (txt.length > 7) {
    ... do something to indicate job well done ...
  } else {
    ... do something else ...
  }
}

As for what to do, what if we took the containing fieldset and changed it’s class to something like “welldone”?

function checkUsername(whatYouTyped) {
  var fieldset = whatYouTyped.parentNode; 
  var txt = stringinput.value;
  if (txt.length > 7) {
    fieldset.className = "welldone"; 
  } else {
    fieldset.className = ""; 
  }
}

The class can be defined in the CSS to assign a background color to the fieldset.

fieldset.welldone {
  background:green;
}

We need to check for this validation on every keystroke, so we attach it to the HTML using onkeyup, like so:

<fieldset>
  <label for="username">Create a Username:</label>
  <input
    type="text"
    id="username"
    maxlength="16"
    onkeyup="checkUsername(this);" />
</fieldset>

View Example 1 – checking for input length.

A step further to indicate “almost there”.

We’ll also have people create a password. We’re a good company, so we let them create a password with as little as 4 characters. But we also feel a sense of responsibility to encourage (not impose upon) people to use longer passwords, at least 8 characters, as a security measure.

The HTML for the password field will look like this:

<fieldset>
  <label for="password">Create a password:</label>
  <input
    type="password"
    id="password"
    onkeyup="checkPassword(this);" />
</fieldset>

The JavaScript will be modified to serve an additional outcome based on length.

  • If the password is at least 4 characters long, that’s good enough to continue.
  • If the password is at least 8 characters long, that’s even better, because it’s oh-so-very secure.
function checkPassword(whatYouTyped) {
  var fieldset = whatYouTyped.parentNode;
  var txt = whatYouTyped.value;
  if (txt.length > 4 && txt.length < 9) {
    fieldset.className = "almostthere";
  }
  else if (txt.length > 8) {
    fieldset.className = "welldone";
  }
  else {
    fieldset.className = "";
  }
}

View Example 2: checking for various input lengths.

Validating against regular expressions

If your password required letters AND numbers AND special characters, things get a little more complicated. You can’t just test for length anymore, you have to match the input to a certain pattern.

Same for email addresses, which follow a certain pattern: blah@blah.blah.

Now I’m no regular expression expert. The one I’m about to use in the next example is not necessarily one I put my stamp of approval on. Basically, I did a quick google search and pulled up the first regular expressions that worked to get the point across.

Here’s the HTML for the email input:

<fieldset>
  <label for="email">Enter your email address:</label>
  <input
    type="text"
    id="email"
    onkeyup="checkEmail(this);" />
</fieldset>

And here’s the JavaScript, which matches the input text to a regular expression, and changes our fieldset class accordingly. Update 2011 June 14: turns out this regex stinks, and freezes/crashes the browser as the input reaches 30 characters.

function checkEmail(whatYouTyped) {
  var fieldset = whatYouTyped.parentNode;
  var txt = whatYouTyped.value;
  if (/^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/.test(txt)) {
    fieldset.className = "welldone";
  } else {
    fieldset.className = "";
  }
}

View Example 3: testing against a regular expression.

Make it prettier

We’ve shown some butt ugly validation hints so far – it’d be nice to do something a little prettier. Remember Form Field Hints? Here’s an example to show how the validation hint concept can build nicely upon the Form Field Hints concept.

View Final Example: Validation Hints with Form Field Hints


This post was ported from an old host and CMS, so many comments were lost. Below are the comments that I found were most helpful regarding this post that I salvaged. Some links or attributions may not be working correctly.


Karen in Wichita said:
Alas, it’d fail on my perfectly-legit primary email account (I suppose we’ll see if it works in the comment field). ‘+’ *is* valid in the username side of things, though not many form designers seem to believe it.

@Karen:
So it does. I blame the regular expression, which I just borrowed from some other source and I don’t endorse.
I realize that very few designers will read the part of the article that says “i don’t endorse this regular expression”, so if there are any regular expression experts out there who can offer one to use for email (and note – it should allow a “+” sign for that first part of the pattern), please share and I’ll include that with the zip.

Shawn asks the CSS Guy about styling disabled text inputs

Shawn writes:

This problem probably doesn’t come up very often, but I was wondering if you knew of a collection of ‘disabled text box’ styles.

I’m going to assume you mean input fields of type=”text”, as opposed to textareas. I never think about disabled text inputs as I rarely use them. For those who want clarification, a disabled text input usually has a grayed-out look, and the value is not able to be modified by user input. It’s has the disabled attribute, like so:

<input
  type="text"
  value="you cant edit this"
  disabled="disabled" />

And here’s an image of what it would look like, right under a enabled text input for comparison, as rendered in Firefox:

As for styling it…

You can style a disabled text input as much as you could any other text input. It can be targeted with the following selector:

input[disabled='disabled'] {
  ... styles go here ... 
}

Which means “Take all the <input> tags with the attribute of disabled set to “disabled”, and apply the following styles…

IE6 doesn’t understand that, so if it’s really important to you to show something other than a grayed-out text box to IE6 users, consider adding a class to your input as well, like so:

<input
  type="text"
  value="you cant edit this"
  disabled="disabled"
  class="disabled" />

So now it comes down to which styles would you apply? We don’t have same styles at our disposal that could be applied to regular text boxes, as IE doesn’t pick up on a text-color assignments for disabled text boxes, Safari ignores border designations for all text boxes. Here is an example of giving a background color, new text color, and probably the only thing I could think of that might be useful, a cursor style that doesn’t give an indication that there is editable text.

input[disabled='disabled'] {
  background:yellow;
  color:blue;
  cursor:default;
}

Here’s what that looks like.

Fugly.

If anyone else has attempted to style disabled inputs, let us know what you did, and why you chose to do something different than the default browser presentation.

Also see: Styling disabled form controls with CSS.