Autocomplete is a nice feature which fills in common form fields automatically for the user. However, in some cases you don’t want this to happen. IE uses a non-standard attribute (autocomplete=”off”) that can be added to an entire form or one specific input control. Besides the fact that this attribute will make your HTML markup fail compliance tests, Firefox seems to consider this tag merely a “suggestion” and will disregard it at times.

In particular, Firefox will *always* populate certain password fields. There is seemingly no way to tell Firefox not to fill in a field if it really wants to do so. This can be a very bad thing if you are dealing with a user preference page or something sensitive where you don’t want autocomplete to ever occur under any circumstance. Setting value=”" is equally worthless because Firefox seems to populate this value just after the page is rendered.

The following code however will work. The concept is basially to set a timeout a fraction of a second after the page loads which clears the password field. Technically Firefox still populates the field, however this script code removes it almost instantly. As an added bonus, because you are not using autocomplete=”off” your HTML markup should still validate. This code should be placed at the bottom of your page beneath your form.

<script language=”JavaScript” type=”text/javascript”>
// this brutally clears a password field in firefox
// compliments of verysimple.com
function clearPwBox()
{
if (document.getElementById)
{
var pw = document.getElementById(’MyPasswordFieldName’);
if (pw != null)
{
pw.value = ”;
}
}
}
window.setTimeout(”clearPwBox()”, 100);
</script>

This code could probably be made more generic by enumerating through the form elements and searching for a certain class name. This way you could have one script and simply append a classname to any field that you don’t want auto-complete to occur. This technique is similar to one posted on Chris Holland’s blog. Chris’s solution, however, is aimed exclusively at the Wc3 compliance issue. As you can see in his code he adds the autocomplete=”off” attribute, which allows the page to validate properly, but doesn’t solve the Firefox/Password field issue.

If you have a more graceful solution and/or decide to flesh this idea out, please post a comment and I’ll provide a link to your site.

Share This

I’m adding this post strictly for the reason that every time I need to do this I spend about 20 minutes searching for an example, only to find various broken posts and incorrect answers. This way works for me every time. If you have an alternate way that works better or is less code, please feel free to post a comment.


var a = document.createElement('a');
a.setAttribute('href', 'page.html');
a.appendChild(document.createTextNode('Click Me'));


The interesting thing to note is that the text inside the link is not actually an attribute, rather it’s a a separate child node within the A element.

Share This

I was working on an interface with a liquid layout recently that looked pretty good when the browser was at a relatively average width (600 to 1000 pixels). However, when I checked it on a really wide screen, the layout started to get a little wierd. Everything stretched as it should, but with a large window there was too much white space and the design started to break apart. Aside from designing the site differently, using CSS2 max-width property would probably be the best solution. But of course we haven’t quite made it to CSS2 yet unless we’re willing to ditch a good percentage of our customers.

However, it got me thinking that it would be interesting if the site could be styled completely differently depending the width of the browser window. For example, having certain sidebars visible if there’s enough room - otherwise showing them in the footer. After about thirty minutes of goofing off I had something working:

View The Working Example

The example page has all of the details and a link to the javascript that you can download. The basic idea is that the window.onresize event is handled, the window size is checked and a div tag className is set. using that className, you can code your CSS to behave differently at different widths. So, aside from having one javascript reference, your code can still be nice and clean.

Unfortunately, as usual IE 6 struggles to keep up [Update: Safari struggles as well]. I spend the next two hours trying to figure out why IE 6 calles window.onresize anywhere from 1 to 3 times whenever the browser is resized. Furthermore, it calculates the actual document width - not browser width. So, if your document is hard-coded at 800px, IE will always return a width of 800px, even if the browser window is smaller and there is some horizontal scroll. In the worst case, IE would get stuck in an infinite loop during some resizing as it would fire off onresize again and again as the page width adjusted to the style change. I took a rather ham-handed approach of just disabling the resizing event after 10 or so times in a loop.

If you have any feedback or ideas to improve upon this code and/or fix the IE glitches, please feel free to post a comment.

Share This