From: "Michael A. Peters" on
Andrew Ballard wrote:
> On Tue, May 26, 2009 at 4:36 PM, Michael A. Peters <mpeters(a)mac.com> wrote:
>> kranthi wrote:
>>> seems more of a firefox question than a PHP question...
>>>
>>> just replace <form id="formemail" method="post" action="UserPrefs">
>>> with <form id="formemail" method="post" action="UserPrefs"
>>> autocomplete="off">
>>>
>>> https://developer.mozilla.org/en/How_to_Turn_Off_form_Autocompletion
>>>
>> Thanks!
>>
>> I found that for xhtml I had to use following DOCTYPE to get it to validate:
>>
>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
>> "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
>> <!ATTLIST form autocomplete CDATA #IMPLIED>
>> ]>
>>
>> From what I gather though did not try, sent with improper text/html mime
>> type, browsers add a bogus ]> to top of output, declaring an ATTLIST should
>> only be done if sent as application/xhtml+xml
>>
>> I still have to check and see how opera reacts to that (IE gets html version
>> of my pages so it won't get that anyway, I can't test safari)
>>
>> html won't validate with that attribute, but that's OK I guess.
>> Maybe it will in html 5 (I don't know) but that's not even stable yet.
>>
>> I'd prefer it to be at the input level rather than form level, the problem
>> (and I think it is a firefox bug) is that it assumes an input before a
>> password the same form as a password is a login name.
>>
>> I *might* actually be able to just move the password field above the e-mail
>> change and fix it.
>>
>> But the autocomplete='off' is very useful to me for another form where users
>> add GPS coordinates, which are from within shasta county and thus all very
>> close, unless the records are for identical coordinates they'll never be the
>> same and if they are identical, using the autocomplete feature risks a
>> mistake of selecting the wrong one thus resulting in bogus data.
>>
>
>
> I just thought I'd toss this out there. Do you know that there is an
> effort to remove browser support this attribute (or at least give the
> user a browser configuration option to ignore it)?
>
> http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054
>
> This article discusses some of the issues involved.
> https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML
>
>
> The discussion is primarily centered around banks using it to prevent
> browsers from remembering your login credentials for their web sites,
> and the idea that the user should ultimately remain in control of the
> browser and that a website should not be able to assert control
> against the user's wishes (in this case by preventing the user from
> using the form manager or password manager to store the information).
>
>
> Andrew
>

I have no problem with browsers giving users an option to disable it.
I have no problem with browsers ignoring anything that is not defined in
the DTD - though technically the way I did it, that attribute is defined
in the DTD.

All a bank needs to do is provide a custom DTD and they can have it.
Browsers that refuse to autocomplete don't get certified and thus won't
work with the bank, many bank web sites are very picky about what a
browser must to before they'll certify it and allow it at their bank.

Several years ago I was stuck needing to install binary Netscape 7 in
Linux - same code base as Mozilla 1 - because Mozilla 1 wasn't certified
at my bank, Netscape 7 was.

Yes, you can fake browser strings and get around it, but only a few
people will.

Microsoft won't yank autocomplete="off" out of their browser, and
FireFox won't want IE to to be the only browser that works with banks.

Users who really don't want it could probably use a firefox extension
that ignores the attribute if they really want autocomplete in their
bank forms.

In my case I want it turned off because FireFox does the wrong thing. It
should look at the input name attribute before auto-completing, but it
doesn't - it assumes a password field means the field before it is a
login field.
From: "Michael A. Peters" on
Andrew Ballard wrote:

>
>
> I just thought I'd toss this out there. Do you know that there is an
> effort to remove browser support this attribute (or at least give the
> user a browser configuration option to ignore it)?
>
> http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054
>
> This article discusses some of the issues involved.
> https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML

That page says:

"When writing HTML, such authors should declare and validate against a
custom doctype including the autocomplete attribute (example HTML document).

However, there is currently no way to trigger the same user agent
functionality with an attribute in XHTML. This constitutes an
unnecessary obstacle to the adoption of XML-based markup."

That page is wrong.
It took me 10 minutes in google to find a way to do it in xhtml and have
the xhtml validate. And I didn't have to use a custom DTD. Only thing I
had to do is send the application/xhtml+xml header - which I already
send, as that's the proper way to serve xhtml 1.1.

From: Andrew Ballard on
On Thu, Jun 4, 2009 at 12:33 PM, Michael A. Peters <mpeters(a)mac.com> wrote:
> Andrew Ballard wrote:
>
>>
>>
>> I just thought I'd toss this out there. Do you know that there is an
>> effort to remove browser support this attribute (or at least give the
>> user a browser configuration option to ignore it)?
>>
>> http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054
>>
>> This article discusses some of the issues involved.
>>
>> https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_using_XHTML
>
> That page says:
>
> "When writing HTML, such authors should declare and validate against a
> custom doctype including the autocomplete attribute (example HTML document).
>
> However, there is currently no way to trigger the same user agent
> functionality with an attribute in XHTML. This constitutes an unnecessary
> obstacle to the adoption of XML-based markup."
>
> That page is wrong.
> It took me 10 minutes in google to find a way to do it in xhtml and have the
> xhtml validate. And I didn't have to use a custom DTD. Only thing I had to
> do is send the application/xhtml+xml header - which I already send, as
> that's the proper way to serve xhtml 1.1.
>
>

I wasn't really taking a position on the issue. I just thought it
worth noting that there seems to be a contingent that wants to remove
the attribute. From what I read, they have already conceded to
language that says a user-agent may choose to implement it, but is not
required to do so.

Andrew
From: "Bob McConnell" on
From: Andrew Ballard
> On Thu, Jun 4, 2009 at 12:33 PM, Michael A. Peters <mpeters(a)mac.com>
wrote:
>> Andrew Ballard wrote:
>>
>>>
>>>
>>> I just thought I'd toss this out there. Do you know that there is an
>>> effort to remove browser support this attribute (or at least give
the
>>> user a browser configuration option to ignore it)?
>>>
>>> http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054
>>>
>>> This article discusses some of the issues involved.
>>>
>>>
https://wiki.mozilla.org/The_autocomplete_attribute_and_web_documents_us
ing_XHTML
>>
>> That page says:
>>
>> "When writing HTML, such authors should declare and validate against
a
>> custom doctype including the autocomplete attribute (example HTML
document).
>>
>> However, there is currently no way to trigger the same user agent
>> functionality with an attribute in XHTML. This constitutes an
unnecessary
>> obstacle to the adoption of XML-based markup."
>>
>> That page is wrong.
>> It took me 10 minutes in google to find a way to do it in xhtml and
have the
>> xhtml validate. And I didn't have to use a custom DTD. Only thing I
had to
>> do is send the application/xhtml+xml header - which I already send,
as
>> that's the proper way to serve xhtml 1.1.
>>
> I wasn't really taking a position on the issue. I just thought it
> worth noting that there seems to be a contingent that wants to remove
> the attribute. From what I read, they have already conceded to
> language that says a user-agent may choose to implement it, but is not
> required to do so.

There is nothing to remove. It is a proprietary extension and not likely
to ever be accepted as part of the W3C standards. As such, it won't be
in any W3C DTD, but will always require a custom DTD be supplied
locally. Each browser supplier must decide whether to support it or
leave it out.

From my viewpoint, the bigger need is to educate administrators of
publicly available computers to disable autocomplete in the browser
configuration. If they would do that, when you go to the workstation in
the library, you can't see the credentials of the last user, and the
next user won't be able to retrieve yours.

Bob McConnell
From: "Michael A. Peters" on
Bob McConnell wrote:

>
> From my viewpoint, the bigger need is to educate administrators of
> publicly available computers to disable autocomplete in the browser
> configuration. If they would do that, when you go to the workstation in
> the library, you can't see the credentials of the last user, and the
> next user won't be able to retrieve yours.

It's not just public workstations.
It's your baby sitter's boyfriend who comes over after she has put your
little ones to bed.