Valid XHTML strict autocomplete workaround/hack for IE and Mozilla

K

Kenn White

Greetings.

Just spent a non-trivial amount of time figuring this out, and thought
it might be useful for others. (Working example at bottom of post)

Issue: For a login screen on a secure intranet site, I would *really*
like to have browsers not "remember" the username and password via
autocomplete. I have no control over the individual desktops, so that
rules out tying down the defaults in the browser prefs, or using some
group policy. It's not a public site, so I have some latitude to be a
little heavy handed, particularly given that many workstations are
effectively "common" machines, in which it would be a very Bad Idea for
Bob's login/password to be "remembered" when Jane accesses the same
login bookmark.

The traditional answer is either <form ... autocomplete='off'> which
historically has been an IE-only proprietary option (in recent years,
Mozilla's gecko engine has started recognizing it too), or use a series
of HTTP directives (private, no-cache, etc.) see:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=7a2b3772552c22e2&rnum=1

Problem: The XHTML Strict doctype recognizes no "autocomplete"
attribute, and thus any page that uses it will fail validation. I don't
really want to push a completely alternative DTD just for this one
issue, but making the problem go away for the 99% of browsers that my
user community will likely use *would be* highly desirable.

Solution: Here is my solution/hack (depending on your perspective):
Following body.onload, call the setAttribute method of the form (or
alternatively, any individual input box) to disable autocomplete.

Works in IE and Mozilla AND passes XHTML strict validation. Note that
Mozilla seems to ignore it (i.e., offers to save passwords) once the
first form element has had focus set. Thus, it's the last thing I do.
Also, in my example below, the more straight-forward approach of
f.autocomplete="off" only works in IE. Strange, because the Mozilla
Javascript console shows no error, and the DOM inspector even looks
identical to hard-coding the autocomplete="off" in the form tag.
Lastly, FWIW this doesn't work in Opera 7.22 -- the wand "feature"
cheerfully offers to remember your login.

-kenn

_________________________________

....
<script type="text/javascript">
function init() {
if (!document.getElementById) return false;
var f = document.getElementById('login');
var u = f.elements[0];
f.setAttribute("autocomplete", "off");
u.focus();
}
</script>
....
<body onload='init()'>
<form id='login' action='foo' method='post'>
<p id='l'>
<input type='text' name='u' value='' /> Username
<input type='password' name='p' value='' /> Password
<input type='submit' value='Login' />
</p>
</form>
....
 
D

David Dorward

Kenn said:
f.setAttribute("autocomplete", "off");

Setting the attribute dynamically using JavaScript still invalidates the
document, it just hides the problem from the validator.
 
K

Kenn White

Interesting. Depends on the definition of "valid" I suppose. In other
words, from your perspective, is a reference to, say,
body.onscroll='...' in a script "more" valid that <body onscroll='...'>
for an XHTML document? Or are they both strictly verboten? If so, in
the latter case, invalid what? XHTML? DOM 1? js 1.5?

I can think of a number of arbitrary element.[events/attributes] that
are commonly manipulated programatically, which have no XHTML strict
equivalent. Some would argue that *all* behavior-oriented element
attributes (onclick, onmousedown, etc.) should be jettisoned from the
XHTML DTD altogether, and strictly fall under the purview of scripting.
(In the same way that most presentational markup has largely moved to
CSS).

You have to admit that there is this weird intersection between HTML
attributes, the DOM, CSS pseudo-elements and js 1.5 properties which are
not always congruent (onhover for arbitrary elements like <th>, for
example -- IE does not obey when specified in CSS, but does through js,
or Opera allowing body.onscroll but seemingly ignoring element.onscroll).

Isn't there room for a pragmatic middle ground? For example, one
technique that I've come across (which I would argue *is* an
accessible-, ancient-browser-, and standards-friendly mechanism) to open
a link in a new window is:

<a href='foo' onclick='target="_blank"'> Foo </a>

Allows right click open-in-new-window/tab, degrades gracefully in screen
readers and non-js UAs, and passes XHTML Strict validation. Is this
evil? Playing fast-and-loose with the spirit of the W3C spec? Clever
hack? :)

-kenn
 
R

Richard Cornford

Interesting. Depends on the definition of "valid" I suppose.
<snip>

I imagine that what David considers invalidated would be the XHTML DOM
as it wouldn't strictly be an XHTML DOM if it contained elements with
attributes unknown in XHTML. However, the question is moot as the fact
that you are interested in IE at all means that you are serving these
pages as text/html and as a result they are XHTML in form only. The
browsers will interpret their mark-up as (error filled) HTML and build
an HTML DOM from them to be scripted.

Richard.
 
D

David Dorward

Kenn said:
Interesting.

Yes, please don't top-post.
Depends on the definition of "valid" I suppose.

You should probably take a close look at the DOM 1 specification, it
specifically says something about some of the properties mentioned in it
assuming the use of a Transitional DTD.
In other words, from your perspective, is a reference to, say,
body.onscroll='...'

I can't comment on this, I don't know enough about the property/attribute.
Isn't there room for a pragmatic middle ground? For example, one
technique that I've come across (which I would argue *is* an
accessible-, ancient-browser-, and standards-friendly mechanism) to open
a link in a new window is:

<a href='foo' onclick='target="_blank"'> Foo </a>

I'd argue that that is just rubbish. If you are going to foist new windows
on users, then why not just use a transitional DTD in the first place? That
least that way people who filter out target attributes with privoxy (or
similar) don't have to deal with the new windows.
Allows right click open-in-new-window/tab, degrades gracefully in screen
readers and non-js UAs,

I don't have any screen readers around to test it, but it could well cause
problems. I believe that some screen readers announce if a link will open
in a new window - it can't do that if the link won't open in a new window
until after it has been clicked.
and passes XHTML Strict validation.

What's the point of validation if you are only validating for the sake of
validating? There isn't much point in checking conformance to a standard if
you use tricks all over the place to do things the standard doesn't allow.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,044
Latest member
RonaldNen

Latest Threads

Top