Valid XHTML strict autocomplete workaround/hack for IE and Mozilla

Discussion in 'Javascript' started by Kenn White, Aug 22, 2004.

  1. Kenn White

    Kenn White Guest

    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>
    ....
     
    Kenn White, Aug 22, 2004
    #1
    1. Advertising

  2. Kenn White wrote:
    > f.setAttribute("autocomplete", "off");


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

    --
    David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
    Home is where the ~/.bashrc is
     
    David Dorward, Aug 22, 2004
    #2
    1. Advertising

  3. Kenn White

    Kenn White Guest

    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



    David Dorward wrote:

    > Kenn White wrote:
    >
    >>f.setAttribute("autocomplete", "off");

    >
    >
    > Setting the attribute dynamically using JavaScript still invalidates the
    > document, it just hides the problem from the validator.
    >
     
    Kenn White, Aug 22, 2004
    #3
  4. Kenn White wrote:
    > David Dorward wrote:
    >> Kenn White wrote:
    >>
    >>> f.setAttribute("autocomplete", "off");

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


    > 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.
     
    Richard Cornford, Aug 23, 2004
    #4
  5. Kenn White wrote:

    > 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.

    --
    David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
    Home is where the ~/.bashrc is
     
    David Dorward, Aug 23, 2004
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. darrel
    Replies:
    2
    Views:
    315
    darrel
    Aug 20, 2004
  2. Tom

    XHTML Strict and Script

    Tom, Nov 15, 2003, in forum: HTML
    Replies:
    6
    Views:
    688
    Woolly Mittens
    Nov 15, 2003
  3. Jerry

    hack for mozilla browsers?

    Jerry, Feb 14, 2004, in forum: HTML
    Replies:
    13
    Views:
    1,061
    Toby A Inkster
    Feb 16, 2004
  4. Amil Hanish

    autocomplete=off is not XHTML compliant

    Amil Hanish, Sep 4, 2007, in forum: ASP .Net
    Replies:
    1
    Views:
    6,046
    Jesse Houwing
    Sep 4, 2007
  5. 123Jim
    Replies:
    21
    Views:
    1,159
    Dylan Parry
    Jul 27, 2010
Loading...

Share This Page