Custom Software Development

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.

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.

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.

I’ve been on the lookout for a good AJAX DataGrid component for some time now, hoping to find one that I can add to my bag of tricks. Most data-driven web applications need to show data in a table or grid at some point or another. There are quite a few for .NET programming, but if you just want the JavaScript to plug into your app, there are not as many choices.

Writing a flexible and powerful AJAX DataGrid is a complicated task and, speaking for myself, not one that most developers will want to tackle. Using a 3rd party component makes a lot of sense. However the commercial vendors of AJAX DataGrids out there are charging ridiculous amounts for licensing. I’m sure these prices will come down to Earth as more open source options become available.

The most promising open source DataGrid I’ve found is the Rico LiveGrid at www.openrico.org. But from what I can tell, it’s a read-only display of data. I could be wrong about that, but I haven’t seen any example code to show edit capability with LiveGrid.

The most most impressive commercial DataGrid in my opinion is the nitobi Grid at www.nitobi.com but it’s not exactly cheap. If anyone knows of any other options out there and/or has a preference for one of these, please leave some feedback. I’d be interested to read some other opinions.

Terminology:

JIT Rendering: “Just in Time” rendering is the ability to show part of your data and load more dynamically as you scroll down.

Edit in Place: The ability to click on a cell and edit the data with no page reload

Input Controls: The ability to use drop-downs, checkboxes, etc when editing in place.

Frozen Columns: The ability to allow scrolling through your records but keep a column or row “frozen” as you can in Excel.

UPDATE: I get a lot of requests and questions from people who are using mm_menu.js about how to use it or about some compatibility issue.  Let me be clear that I don’t use or recommend mm_menu.js.  It is old, outdated code and does not follow current best-practices.  If you use mm_menu.js, I would fully expect you to run into browser compatibility glitches and other troubles.  The patch below only fixes the I-Beam problem in FireFox, nothing else.  If you want my recommendation, I use Son of Suckerfish which is a pure CSS menu solution (with the exception of a few lines of javascript for IE6 compatibility).  If you prefer auto-generated code you can use something like the CSS Menu Generator.

ORIGINAL ARTICLE:

If you happen to work with a designer that uses DreamWeaver, you’ve probably seen mm_menu.js. It the “engine” file that DreamWeaver includes to make dropdown menus work. One obnoxious thing about this file is that the mouse cursor for FireFox still looks like an I bar instead of the normal hand/pointer icon.

If you’re like me, you have absolutely zero interest in debugging this javascript or any of the machine generated garbage that comes with it. Today is your lucky day because attached to this post is a replacement for mm_menu.js that you can just swap out with the old one and ba-da-bing, FireFox shows the cursor correctly. I read about this somewhere which gave me the idea and probably some of the code too. Unfortunately I forget where that is so I can’t link to the reference source. Anyway, if you care, do a diff on files if you want to see the difference, which is very minor.

Download mm_menu.js Patched for FireFox