Stopping browser prompts in forms

[Christine Forber]

I have created a form that incorporates AJAX to provide suggestions from
the database contents for the given field. The problem is that many
browsers do their own "suggestions" based on previous values used for
that field. These browser suggestions sometimes completely hide the AJAX
suggestions. Is there some way to turn off this browser behaviour in the
form? (Yes, I know how to do it with my browser, but if it is happening
to me, it is happening to my customers and I want to stop that behaviour
only for the AJAX enabled fields in this particular form.)

Not sure if the solution is html or javascript, so sent this message to
both groups.

Thanks,
Christine

 

[Gregor Kofler]

Christine Forber meinte:

I have created a form that incorporates AJAX to provide suggestions from
the database contents for the given field. The problem is that many
browsers do their own "suggestions" based on previous values used for
that field. These browser suggestions sometimes completely hide the AJAX
suggestions. Is there some way to turn off this browser behaviour in the
form? (Yes, I know how to do it with my browser, but if it is happening
to me, it is happening to my customers and I want to stop that behaviour
only for the AJAX enabled fields in this particular form.)

Some browser know a "autocomplete"-attribute for input fields.
autocomplete="off" might help.

Gregor

 

[Thomas 'PointedEars' Lahn]

Christine Forber meinte:

[AJAX for auto-completion is hindered by built-in auto-completion]
Is there some way to turn off this browser behaviour in the
form? (Yes, I know how to do it with my browser, but if it is happening
to me, it is happening to my customers and I want to stop that behaviour
only for the AJAX enabled fields in this particular form.)

Some browser know a "autocomplete"-attribute for input fields.
autocomplete="off" might help.

If that was the case (I have not tested it), the attribute should be either
be declared (which however fails when parsed as tagsoup-HTML) or its value
set through a properly feature-tested DOM element property, because using it
as above would create invalid markup. Although no recent browser (I know
of) uses a validating (XML) parser, validity is crucial for a AJAX Web
application iff it uses XML or an XML application as underlying markup language.


PointedEars

 

[Christine Forber]

Christine Forber meinte:

Some browser know a "autocomplete"-attribute for input fields.
autocomplete="off" might help.

I only want to indicate when this feature should be turned off. Checked
and autocomplete="off" works in both FireFox and IE.

Many thanks.
Christine

 

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

Gregor Kofler wrote:

If that was the case (I have not tested it), the attribute should be either
be declared (which however fails when parsed as tagsoup-HTML) or its value
set through a properly feature-tested DOM element property, because using it
as above would create invalid markup.

Well, I never stated that it is valid. However, Google [1] uses this
proprietary attribute in their smart suggest version, and it is, well
....er... recommended in various AJAX publications. My own smart suggest
version seems to work without worrying about autocomplete attributes.

Gregor


[1]
http://www.google.com/webhp?complete=1&hl=en

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn meinte:

Well, I never stated that it is valid.

And you have not stated that it is not Valid, hence my remark.

However, Google [1] uses this proprietary attribute in their smart
suggest version,

IBTD. That Google uses some code is hardly a sign of interoperability of
it. Google's code is compacted bloat-code.

and it is, well ...er... recommended in various AJAX publications.

Which only proves once more that there are no good books about JavaScript
and related concepts. Too many scriptkiddies think they are the real experts.

My own smart suggest version seems to work without worrying about
autocomplete attributes.
[...]
[1]
http://www.google.com/webhp?complete=1&hl=en

Testing a snippet in one Web browser or a number of Web browsers is hardly
an indication of its quality, especially regarding interoperability among
(X)HTML user agents.


PointedEars

 

[Jeremy]

I have created a form that incorporates AJAX to provide suggestions from
the database contents for the given field. The problem is that many
browsers do their own "suggestions" based on previous values used for
that field. These browser suggestions sometimes completely hide the AJAX
suggestions. Is there some way to turn off this browser behaviour in the
form? (Yes, I know how to do it with my browser, but if it is happening
to me, it is happening to my customers and I want to stop that behaviour
only for the AJAX enabled fields in this particular form.)

Not sure if the solution is html or javascript, so sent this message to
both groups.

Thanks,
Christine

One technique I have seen used to solve this issue is to slightly vary
the "name" of the input. For example, adding a short string of random
characters or numbers to the end of the "name" can cause the browser to
not realize that it is the same field for which it has remembered
previous values. This, of course, requires slight changes to
server-side code in order to properly retrieve the value using the
appropriate modified key.

Then again, it might be rather presumptuous of you to assume that your
customers would rather use YOUR suggestions than the previous values
that they have entered on your site and on others. Just something to
consider.

Jeremy

 

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

And you have not stated that it is not Valid, hence my remark.

"Some browsers know something..." sounds pretty non-standard compliant
to me. Anyway, I should have pointed that out.

However, Google [1] uses this proprietary attribute in their smart
suggest version,

IBTD. That Google uses some code is hardly a sign of interoperability of
it. Google's code is compacted bloat-code.

ACK. You don't even have to rate their JS efforts. A simple search
produces a webpage with 292 errors, no doctype declaration, deprecated
markup (center-tags) etc.
But then: the OP could have used this very search engine and gotten
everything that can be said to solve this problem...

Gregor

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn meinte:

In fact, "not Valid" is a bit exaggerated. It is not (and AIUI cannot be
made) Valid HTML. It can be made Valid XHTML by declaring the attribute, as
mentioned above:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/dtd/xhtml1-strict.dtd"
[
<!ATTLIST input
autocomplete (off|on) "on"

>

]>

But the problem is that XHTML itself is not interoperable yet, and when
parsed by a tagsoup parser (which is highly likely if served as
IE-compatible text/html), part of the declaration is displayed (even with
Geckos, which is most unfortunate as they do have an XML parser.)

Therefore, trying to address this proprietary feature with an equally
proprietary property of the corresponding DOM element object appears to be
one of the better solutions. Especially since client-side scripting is
involved here anyway. For example:

....
<head>
...
<meta http-equiv="Content-Script-Type" content="text/javascript"></meta>
<script type="text/javascript">
// <![CDATA[
/**
* @depends http://pointedears.de/scripts/types.js
*/
function disableAutoComplete(f)
{
if (f)
{
for (var es = f.elements, i = es && es.length; i--
{
var e = es;
if (e.tagName.toLowerCase() == "input"
&& e.type.toLowerCase() == "text")
{
if (typeof e.autoComplete == "string")
{
e.autoComplete = "off";
}
else if (isMethodType(typeof e.setAttribute)
&& e.setAttribute)
{
e.setAttribute("autocomplete", "off");
}
}
}
}
}
// ]]>
</script>
</head>

<body onload="disableAutoComplete(document.forms[0])">
<form ...>
...
</form>
...
</body>


F'up2 cljs

PointedEars

 

[Christine Forber]

One technique I have seen used to solve this issue is to slightly vary
the "name" of the input. For example, adding a short string of random
characters or numbers to the end of the "name" can cause the browser to
not realize that it is the same field for which it has remembered
previous values. This, of course, requires slight changes to
server-side code in order to properly retrieve the value using the
appropriate modified key.

Then again, it might be rather presumptuous of you to assume that your
customers would rather use YOUR suggestions than the previous values
that they have entered on your site and on others. Just something to
consider.

In this particular case, entering any value except one from the
suggestions will end up in no hits for their search. So it does make
sense. I agree that this might well not be the case for all forms.

Christine

 

[Christine Forber]

Thomas 'PointedEars' Lahn meinte:

And you have not stated that it is not Valid, hence my remark.

"Some browsers know something..." sounds pretty non-standard compliant
to me. Anyway, I should have pointed that out.

However, Google [1] uses this proprietary attribute in their smart
suggest version,

IBTD. That Google uses some code is hardly a sign of interoperability of
it. Google's code is compacted bloat-code.

ACK. You don't even have to rate their JS efforts. A simple search
produces a webpage with 292 errors, no doctype declaration, deprecated
markup (center-tags) etc.
But then: the OP could have used this very search engine and gotten
everything that can be said to solve this problem...

I tried a Google search, but was obviously not using the right search
terms as I didn't find the suggestion to use autocomplete. Which is why
I posted here. I know better than to just post here without at least
trying Google first!

Christine