A member of my family recently was buying something online and was making the payment via PayPal's form for non-PayPal members to pay through a credit card. When she tried to tab from one field to the next a border (outline) appeared around the next label and field instead of the field receiving focus. This is definitely an unwanted change from normal tabbing behavior. So when I got back to my own machine, which has the necessary developer tools, I first went to the page in Firefox 3.6 where I did not see the problem. Next I navigated to the page in Firefox 4 where lo and behold the issue occurs.

It turns out that the issue is triggered by the wrapper paragraph element having "overflow:auto" set, even though no scrollbar was generated. So I recommend that you use "overflow:hidden" instead or, better, use an alternative (that doesn't require adding any extra elements to the markup), or even better: use inline-blocks instead of floated elements. Keep in mind that this could also be an issue in navigational menus for people who choose to navigate through pages with the keyboard alone.

Before this change in Firefox, we needed to give a normal element, e.g. a <div> (not a link or form control), (that didn't have a scrollbar) tabindex="0" in order to make it able to receive focus via tabbing (and still do for other browsers).

I'm not sure whether this is a good change for usability or not. However, we do have an issue that needs to be addressed by being more thoughtful about using "overflow:auto" in our stylesheets. I'd love to hear your thoughts and if anyone knows why the Mozilla developers made this change, I'd appreciate hearing it.

It seems pretty much everyone is aware of the up and down (or left and right) arrows of scrollbar. However, there are several more features to a good scrollbar. Most people also notice the drag-bar, but did you realize that the length of the drag-bar relative to the "track" (or "gutter") is used to indicate how much of the page is currently in view? Also have you ever clicked in the track itself to make the page scroll one screen's-worth?

Before making your own scrolling mechanism, I'd like to remind you that the keyboard and mouse (and other pointing devices) can also be used to scroll. The arrow keys and, for full-size keyboards, the "page up" and "page down" keys are nearly universal scrolling controls, but have you realized that the spacebar, "home", and "end" keys can also be used to scroll in many web browsers as well? Mice and trackballs often include a scroll-wheel these days and, likewise, touchpads often include a special region to drag your fingertip on to scroll.

The reason I'm writing this is that most of the custom scrollbars I've seen are missing many of those features. To be clear, I'm not saying all custom scrollbars are bad. For those who would like to create your own scrollbar design here are two scripts that I would recommend: jScrollPane and FleXcroll. At least in some configurations, those scripts support all of the features mentioned above. They might be difficult for people, especially novice users, to identify on the page though.

This has been a public service announcement aimed at graphic designers in the hopes that they'll rethink creating custom scrollbars and other scrolling controls that cause frustrating user experiences.

Related:

• Scrolling and Scrollbars
• Comments on Scrolling and Scrollbars

Please don't turn photos into animated GIFs. Most photographs, by their very nature, use thousands, if not millions, of individual colors. The GIF image format, however, is limited to a maximum of 256 colors per image (and for animated GIFs all frames have to share the same palette of 256 colors). I don't know whether most Web users notice when an image has been overly limited in the colors used to display it that the natural gradients found in photos are absent. But it certainly bothers me and I'm not even a graphical designer.

I'm curious whether the people who (mis)use animated GIFs in this fashion don't have experience with Flash (which seems to be favored by many designers) or just find making a GIF simpler. Either way, I would advise an alternative solution: the use of JPEGs (the best format for displaying photos in web pages) and a little JavaScript to handle the animation. JavaScript libraries, like jQuery, can make it easier to write the necessary code. One could even optimize it a bit by using CSS sprites instead of making each frame be a separate image.

I don't often write about security (other than to remind various people of the need to always validate form submissions on the server), because despite its extreme importance it's not one of my specialties. However, recently I've had a disturbing thought about the utmost importance of keeping your email accounts secure.

You see, if someone were to gain unauthorized access to an email account, he could look through the messages to see what sites the account has been used to sign up for and then on many of those sites the "forgot my password" form could simply be used to request the password be emailed to him. This has the potential of one breach leading to dozens of further breaches.

One simple thing that might help a little that I seem to remember seeing used is to ask the user to provide both the username and the email address. Of course, if the username is included in the email messages, then this wouldn't be much help. This wouldn't always help though, because sometimes the username is the same as the "local-part" (part before the "@") of the email address. On other sites this isn't possible because they use the email address as the username.

So do you have any suggestions as to what might be a good way to maintain the convenience of being able recover a lost password and yet mitigate this threat of unauthorized access to multiple accounts as a result of a security breach to an email account?

Related:

• You're Probably Storing Passwords Incorrectly
• OpenID: Does The World Really Need Yet Another Username and Password?

There are several ways to cause an element to expand in height to contain its floated descendants. Of course some are better than others. (This has been discussed elsewhere before, but since not everyone is a CSS expert, I thought I'd write down my own thoughts on the strategies for dealing with this issue.)

The Old Ways

The oldest way (pre-CSS) is to use a <br clear="all"> element. Besides the fact that the HTML "clear" attribute has been deprecated, that's really a misuse of that element anyway. Several <div class="clear"></div> or <div style="clear:both;"></div> elements sprinkled throughout a page is another common sight. Some people (including me) argue that adding extra elements, muddying the nice clean markup, to just fix a presentational (or stylistic, if you prefer) issue is a practice to be avoided. So what are the alternatives?

"Float Nearly Everything"

The simplest one is the "float nearly everything" technique. If you float the container element, then it will automatically grow in height with its floated descendants. I often use this approach on the page header container and the wrapper of content columns and then give the footer "clear:both".

The Aslett/PIE Technique

Another, albeit more complex, (and my second favorite) approach is the Aslett/PIE technique. (Here's a second article on it.) These days, you can use a cut-down version of the code for it, if you are not supporting IE5.0/Win and IE5/Mac. (In the interest of brevity, I won't explain the intricacies of how it works here, but if you have any questions, feel free to ask.)

.clearfix:after { /* for non-IE browsers and IE8+ */
  content:".";
  display:block;
  clear:both;
  height:0;
  visibility:hidden;
}
/* the next two rules for IE6-7 must be separate and be in this order */
.clearfix {display:inline-block}
.clearfix {display:block}

Or, if you prefer this:

.clearfix:after { /* for non-IE browsers and IE8+ */
  content:".";
  display:block;
  clear:both;
  height:0;
  visibility:hidden;
}
*:first-child+html .clearfix {min-height:1px} /* for IE7 */
* html .clearfix {height:1%} /* for IE6 */

I rarely actually apply that "clearfix" class to any elements. Typically, I add more selectors (e.g. "#nav:after, .container:after, .clearfix:after"), so that I can target elements that already have a class or ID.

The Overflow Control Technique

In 2005, Paul O'Brien discovered a new, simpler approach: "overflow:auto" or "overflow:hidden" will cause an element to contain floated descendants (assuming it doesn't have a specified height). It's clean and simple and definitely demonstrates his impressive level of expertise. (I've learned a great deal from him over the last few years.) However, I, for one, prefer not to hide overflow usually. Also there is a second unexpected side-effect that can also occur in some browsers.

Odd Side-effect of hiding overflow

The strange side-effect that can occur with the overflow property happens when a floated element is next to an element that has "overflow:auto" or "overflow:hidden" and has a margin on the same side as the float. The (left or right) margin will be doubled in Firefox 1-2, Safari 1.2+, Google Chrome, and Opera 9.5-10.1. Here's a little live demo: (The four blue boxes will not be the same width in the aforementioned browsers.)