Google Autofill - taming its overenthusiasm

Google's autofill is very clever, but sometimes too clever for its own good.

Google are very sketchy on details of how developers can work with the feature, and experimentation indicates that the rules at work are anything but predictable.

I had trouble with a field labelled "Country" where I wanted to set a code using my own country notation (England/Wales/Scotland/Northern Ireland - there seems no standard coding for these, and Google Autofill has no field that is relevant).

Google insisted that it could autofill this field (but got it wrong).

Step 1 - rename the Select field to exclude "Country" : no change.

Step 2 - insert a spurious and empty "span" tag in the middle of the word "Country" in the label field - ie Country

Success. Google no longer reckons it knows about how to fill the field and it remains uncoloured. But it's in no way elegant, and I fear that it may cause problems for some screen reader programs

Update 26 September 2007:
It gets worse. Google Autofill has picked up the word "Area" in a table of user-generated content, and decided that the field next to it (which has nothing to do with any sort of area, but is an edit box) must want my Area Phone Code. Except that I am in the UK, and our area codes aren't in the 3-digit format that Google expects. No worry, Google will decide that I'd probably like the first three digits of my UK area telephone code inserting whenever the word "area" appears next to a text box.

Fair enough - Google does enter that value automatically. But if the user has signed up for Autofill, Google interferes with the page to change the input to have a yellow background [background-color: rgb(255,255,160); - ie #ffffa0]

There is a solution in IE using "attachevent"
but it doesn't work in Firefox. Some have suggested adding

autocomplete='off'

to the specification of the input box, but that doesn't work in Firefox either.

For Firefox, the best that can be done is to over-rule the change to the background-color setting by using CSS like this:

.whitebox{
background-color: white !important;
}

(or an inline style that does the same). The "Important" setting will overrule the Google setting. However, anyone hitting the Autofill button on the toolbar will still get the nonsense data inserted.

Autofill is neat, but surely Google owes the world a method that allows developers to indicate that a form field - whatever its name or nearby text - is liable to fool the Autofill program, and so should be granted exemption from having its colour modified and Autofill enabled.

Firefox - preselecting a Select Option

Firefox doesn't cope with

selected value='3'>Pineapple

If you load a page, select the option, then use View Selection Source - you find that Firefox comes up with:

selected='selected' value='3'>Pineapple

BUT if you then put that into your HTML, it ignores that too.

Answer: use selected='true'.

Simple, but it took me a while to find it. Hope this saves grief for someone else

POSTSCRIPT - further woes on a field that had an ID containing two underscores (not adjacent to each other: it was "bookMode_0none_1RequestForm") - where Firefox (1.5.0.12) preselected the LAST option whilst it happily reported coding that showed a previous option selected.

Replacing the second underscore with an alphanumeric character sorted the problem. (No problem with the two-underscore term for name - it was ID that was the issue). But it's spooky stuff - extract the code with View Selection Source and paste into a new document and Firefox is fine with the two underscores. Could it be related to the fact that the code is being served up by php? No time to experiment more.

IE workaround - Losing unwanted padding within Input buttons in IE 6 (and perhaps IE7) using CSS

PROBLEM - IE adds over-generous padding to left and right of an input type="submit" button - and this gets to be a real problem at larger font sizes. The padding cannot be removed by adjusting padding or margin settings, but there is a way ...

(Note - the same problem doesn't apply if you use the specific "button" tag - but then IE adds new misery there by not allowing you to identify which of several submit buttons have been pressed!)

SOLUTION

FIRST, Set a CSS class for the button and specify this with "overflow: visible".

This loses all padding around the text so:

NEXT, restore sensible padding within this same CSS class - say 5px left and right.

The button now looks fine, but any containing table cell will be grossly too wide - it will be set to the same width as if the extra padding within the button was present, PLUS the extra padding you have added. So:

LASTLY, create a DIV around the "input" tag, and give this a CSS class which specifies:

• overflow: hidden
• width: (exactly the same as the table cell width you want)
  

Result - narrower buttons in IE, with no impact on Firefox or Opera (FF1.5 and Opera 9.21 anyway).

I've not managed to reproduce this within the constraints of Blogger's formatting, so you'll need to follow this link to see it in action.