MozillaWiki

The autocomplete attribute and web documents using XHTML: Difference between revisions

Page Discussion

The autocomplete attribute and web documents using XHTML (view source)

Revision as of 20:31, 9 March 2011

14,271 bytes added ,  9 March 2011
no edit summary
No edit summary
 
(39 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Executive summary ==
Many important web content producers, including banks and Google, insist on using the non-standard HTML <code>autocomplete</code> attribute for either security or usability reasons. When writing HTML, such authors should declare and validate against a custom doctype including the <code>autocomplete</code> attribute ([http://www.benjaminhawkeslewis.com/legacymarkup/examples/html-4.01-strict-plus-autocomplete.html 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.
If the W3C adopts Web Forms 2.0 then this problem will be solved.
If that doesn't happen, by adopting my solution and supporting a small XHTML module and delimited <code>class</code> microformat, browsers could enable authors serving XHTML 1.0 as text/html to trigger the same behaviour with <code>class="fh disable_form_history"</code> ([http://www.benjaminhawkeslewis.com/legacymarkup/examples/xhtml-1.0-strict-plus-autocomplete-html-compatible.html example XHTML 1.0 document]) and authors serving XHTML properly as application/xhtml+xml to trigger the same behaviour with a namespaced attribute (<code>fh:form_history="off"</code>) ([http://www.benjaminhawkeslewis.com/legacymarkup/examples/xhtml-1.1-plus-formhistory-with-dtd-draft1.xhtml example modularized XHTML document]). Those authors who wish to serve both XHTML and HTML properly using an XSL transformation would could convert to the HTML <code>autocomplete</code> attribute with simple XSL rules.
== Background ==
== Background ==


Line 4: Line 14:
<code>form</code> and text and password <code>input</code> elements of HTML 3.2 with an [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/autocomplete.asp <code>autocomplete</code> attribute] which allowed site authors to disable this feature on a case-by-case basis. Gecko-based browsers gained an autocomplete feature in 2000, and by 2001 they too were forced to support the <code>autocomplete</code> attribute ([http://devedge-temp.mozilla.org/viewsource/2003/form-autocompletion/index_en.html Netscape Devedge: How to Turn Off Form Autocompletion]). The primary motivation for the attribute at that time was that banks believed disabling autocomplete was a necessary security measure for the login information on their websites, and would bar from their services browsers that had autocomplete features without support for disabling them.
<code>form</code> and text and password <code>input</code> elements of HTML 3.2 with an [http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/autocomplete.asp <code>autocomplete</code> attribute] which allowed site authors to disable this feature on a case-by-case basis. Gecko-based browsers gained an autocomplete feature in 2000, and by 2001 they too were forced to support the <code>autocomplete</code> attribute ([http://devedge-temp.mozilla.org/viewsource/2003/form-autocompletion/index_en.html Netscape Devedge: How to Turn Off Form Autocompletion]). The primary motivation for the attribute at that time was that banks believed disabling autocomplete was a necessary security measure for the login information on their websites, and would bar from their services browsers that had autocomplete features without support for disabling them.


In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]). And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants.
In practice, disabling autocomplete is not a particularly effective security measure. Even in the days of Internet Explorer 5, any machine could be compromised by keylogging that would of course be undeterred by a mere <code>autocomplete</code> attribute. Thanks to the rise of User-Agent spoofing, it became increasingly difficult to exclude browsers like Opera that support form history but ignore the <code>autocomplete</code> attribute by default ([http://www.opera.com/support/usingopera/operaini/index.dml Opera's Settings File Explained]), or browsers like ELinks and OmniWeb that have form history and ignore the attribute entirely. And now that web users increasing edit the content delivered to them from the server to suit their own preferences, circumventing the <code>autocomplete</code> attribute is trivial ([http://www.squarefree.com/bookmarklets/forms.html#remember_password Remember Password Bookmarklet]) even in Mozilla browsers that claim to support it "perfectly" ([http://developer.mozilla.org/en/docs/How_to_Turn_Off_Form_Autocompletion Mozilla Developer Center: How To Turn Off Form Autocompletion]). Nonetheless, even technical opinion is divided over whether <code>autocomplete</code> offers valuable protection against casual attackers or merely lulls users and web authors into a false sense of security, leaving them vulnerable to more determined assailants.
 
I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS - Information on Cheque Clearing and Cheque Fraud ] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]).


I don't know of a formal statement of the current attitude of banks towards <code>autocomplete</code>, but I suspect many still believe it to be an important safeguard, notwithstanding the flaws I've just mentioned. As late as November 2004, financial standards bodies like [http://www.apacs.org.uk/ APACS] were insisting that sensitive systems make use of the attribute and failure to use it could spell public relations disaster ([http://news.bbc.co.uk/1/hi/business/3995019.stm BBC News: Bank moves to close web loophole]). Security consultants like McAfee's Corey Benninger continue to recommend that site owners employ the <code>autocomplete</code> attribute ([http://www.internetnews.com/dev-news/article.php/3624796 Developer: Browser Cache: Goodies For Hackers]). The developers of the [http://whatwg.org/specs/web-forms/current-work/ Web Forms 2.0 specification] were forced to support the <code>autocomplete</code> attribute ([http://whatwg.org/specs/web-forms/current-work/#the-autocomplete Web Forms 2.0 Working Draft: The <code>autocomplete</code> attribute]) even though they do not believe it offers any genuine security benefits ([http://article.gmane.org/gmane.org.w3c.whatwg.discuss/3054 Lachlan Hunt kicking off an epic thread on the subject at the WHATWG mailing list]).
 
Here's a non-exhaustive list of major banking groups I've found currently making use of <code>autocomplete</code>:
 
* [http://www.citigroup.com/ Citigroup]
* [http://www.hsbc.com/ HSBC]
* [http://www.bankofamerica.com/ Bank of America]
* [http://www.jpmorganchase.com/ JPMorganChase]
* [http://www.compassweb.com/index.html Compass Bank]
* [http://www.rbs.com/ Royal Bank of Scotland]


In 2004, Kevin Gibb's [http://www.google.com/webhp?complete=1&hl=en Google Suggest] found a new use for the <code>autocomplete</code> attribute: disabling the browser's autocompletion in order to allow a website's own JavaScript autocompletion to begin with a blank <code>input</code> field. Although it is possible to achieve a similar effect without the attribute, Google has set a precendent and now such non-standard code is churned out by Ajax developers, libraries, and toolsets everywhere. For example, Ruby on Rails's autocomplete helpers use it.
In 2004, Kevin Gibb's [http://www.google.com/webhp?complete=1&hl=en Google Suggest] found a new use for the <code>autocomplete</code> attribute: disabling the browser's autocompletion in order to allow a website's own JavaScript autocompletion to begin with a blank <code>input</code> field. Although it is possible to achieve a similar effect without the attribute, Google has set a precendent and now such non-standard code is churned out by Ajax developers, libraries, and toolsets everywhere. For example, Ruby on Rails's autocomplete helpers use it.


In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support (e.g. ELinks has form history but does not recognize the attribute), <code>autocomplete</code> is here to stay.
In summary, it seems that despite being non-standard, having known security flaws, being replicable with alternate techniques, and suffering from limited browser support, <code>autocomplete</code> is here to stay.


== The Problem ==
== The Problem ==
Line 20: Line 40:
2. The web is gradually transitioning from HTML to XML-based markup, helped by minority browsers that can parse the application/xhtml+xml internet media type correctly.
2. The web is gradually transitioning from HTML to XML-based markup, helped by minority browsers that can parse the application/xhtml+xml internet media type correctly.


3. When writing HTML, it is trivial to express the <code>autocomplete</code> attribute using the SGML standard by creating a custom DTD and using that as your doctype. You can create such a DTD by simply adding the following line to the HTML 4.01 DTD:
3. When writing HTML, it is trivial to express the <code>autocomplete</code> attribute using the SGML standard by creating a custom DTD and using that as your doctype. You can create such a DTD by importing an HTML DTD and then simply adding the following line:


<blockquote><code><!ATTLIST (form|input) autocomplete (on,off) #IMPLIED></code></blockquote>
<blockquote><code><!ATTLIST (form|input) autocomplete (on,off) #IMPLIED></code></blockquote>
I've put up some example DTDs at my site:
* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-frameset-plus-autocomplete.dtd HTML 4.01 Frameset plus autocomplete]
* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-transitional-plus-autocomplete.dtd HTML 4.01 Transitional plus autocomplete]
* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-strict-plus-autocomplete.dtd HTML 4.01 Strict plus autocomplete]
* [http://www.benjaminhawkeslewis.com/legacymarkup/dtd/iso-html-15445-2000-plus-autocomplete.dtd ISO/IEC 15445:2000 HTML plus autocomplete]
To use such as custom doctype, simply declare it like so:
<!DOCTYPE html SYSTEM "http://www.benjaminhawkeslewis.com/legacymarkup/dtd/html-4.01-strict-plus-autocomplete.dtd">
Contrary to common misapprehensions, declaring a custom DTD in this way does '''not''' trigger Quirks mode, not even in IE 5/Mac. Unrecognized doctypes with a URI are interpreted in full Standards mode. See:
* [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp#cssenhancements_topic2 MSDN: CSS Enhancements in Internet Explorer 6]
* [http://www.opera.com/docs/specs/doctype/ The Opera 9 DOCTYPE Switches]
* [http://developer.apple.com/internet/bestwebdev.html Apple Developer Connection: Web Development Best Practices]
* [http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing Mozilla Developer Center: Mozilla's DOCTYPE Switching]
* [http://www.ericmeyeroncss.com/bonus/render-mode.html Eric Meyer on CSS: Picking a Rendering Mode]
I've added an [http://www.benjaminhawkeslewis.com/legacymarkup/examples/html-4.01-strict-plus-autocomplete.html example document using the Strict version] to my site.


4. The X in XHTML stands for "extensible". But because all elements and attributes are namespaced in XML and the W3C jealously guard their XHTML namespace from extension by others, a site author may not do the same with XHTML-based markup. While it is certainly possible to build a custom XML DTD to include an <code>autocomplete</code>, the act would be meaningless as the W3C have made it clear they would not regard documents extending the XHTML namespace in this way as even using XHTML at all ([http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform XHTML Modularization 1.1: Working Draft: Conformance Definition], also see [http://alistapart.com/articles/customdtds2/ A List Apart: More About Custom DTDs]).
4. The X in XHTML stands for "extensible". But because all elements and attributes are namespaced in XML and the W3C jealously guard their XHTML namespace from extension by others, a site author may not do the same with XHTML-based markup. While it is certainly possible to build a custom XML DTD to include an <code>autocomplete</code>, the act would be meaningless as the W3C have made it clear they would not regard documents extending the XHTML namespace in this way as even using XHTML at all ([http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform XHTML Modularization 1.1: Working Draft: Conformance Definition], also see [http://alistapart.com/articles/customdtds2/ A List Apart: More About Custom DTDs]).
Line 28: Line 76:
5. Therefore there is no current way to use a simple markup attribute to turn off autocompletion when using XHTML.
5. Therefore there is no current way to use a simple markup attribute to turn off autocompletion when using XHTML.


== Possible solutions ==
== A solution? ==


Whichever solution is adopted, it is at present only important for Mozilla, KHTML, and WebKit developers to recognize it, as (AFAIK) only browsers based on their engines both correctly parse application/xhtml+xml ''and'' claim to allow form history to be disabled by site authors.
Whichever solution is adopted, it is at present only important for Mozilla, KHTML, and WebKit developers to recognize it, as (AFAIK) only browsers based on their engines both correctly parse application/xhtml+xml ''and'' claim to allow form history to be disabled by site authors.


1. ''If'' we agree that <code>autocomplete</code> is ultimately detrimental to security, the ideal solution would be to persuade the web and financial communities to employ other techniques. Good luck with that.
=== The options ===


2. The next-best solution would be to persuade the W3C to include the autocomplete attribute in an XHTML module similar to the [http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Legacy Legacy module]. But I think that will never happen.
1. The very best solution would be to radically overhaul XHTML and JavaScript to make it easy to write secure web applications. [http://www.webappsec.org/lists/websecurity/archive/2006-08/msg00011.html Andrew van der Stock has some pointers over at the Web Application Security Mailing List.] However, that will likely take years and will still leave the problem of legacy browsers. Would-be XHTML authors need a solution to this problem now.


3. More plausibly, we could add browser support for a <code>formhistory</code> attribute in a vendor neutral URI such as <nowiki>http://www.legacymarkup.org/xmlns/formhistory</nowiki>, and implement it in a simple XHTML module. When serving the same resource as HTML following content negotiation, the XSL transformation to HTML would be trivial:
2. ''If'' we agree that <code>autocomplete</code> is ultimately detrimental to security, the next-best solution would be to persuade the web and financial communities to employ other techniques. Good luck with that.
 
3. Failing that, a good solution would be to persuade the W3C to include the autocomplete attribute in an XHTML module similar to the [http://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html#a_module_Legacy Legacy module]. When I originally drafted this proposal, I thought that would never happen, but it looks like there's a fighting chance Web Forms 2.0 (which comes in HTML and XML flavours) will be adopted by the W3C - and Web Forms 2.0 includes the "autocomplete" attribute. :) See [http://my.opera.com/community/forums/topic.dml?id=153013&t=1155219050 my discussion with Opera's Anne van Kesteren] and keep an eye out for Web Forms 2.0 news in September!
 
4. Still let's not count our chickens until they've hatched. Failing that, we could add browser support for a <code>formhistory</code> attribute in a vendor neutral URI such as <nowiki>http://www.legacymarkup.org/xmlns/formhistory</nowiki>, and implement it in a simple XHTML module. When serving the same resource as HTML following content negotiation, the XSL transformation to HTML would be trivial:


<blockquote><pre>
<blockquote><pre>
Line 76: Line 128:
(N.B. This XSL definitely needs testing.)
(N.B. This XSL definitely needs testing.)


4. Other alternatives might involve using proprietary extensions, such as XUL/XBL. I suspect any implementation would be dependent on JavaScript, which would not satisfy those using <code>autocomplete</code> for putative security reasons. It would also be inferior to a cross-browser solution. However, such extensions might prove useful for backporting support for namespaced or microformated autocompletion instructions to old versions of browsers, whether Mozilla (with extensions or XUL/XBL), Konqueror (with [http://developer.kde.org/documentation/tutorials/kparts/ KParts]), or even to Internet Explorer (with [http://msdn.microsoft.com/workshop/components/htc/reference/htcref.asp HTC]). For an inspiring example of what can be achieved with such extensions, have a look at [http://w3future.com/weblog/gems/xhtml2.xml Sjoerd Visscher's XHTML 2 page at W3Future], which uses proprietary Opera CSS, XBL, and HTC to mimic XHTML 2 on current user agents.
5. Other alternatives might involve using proprietary extensions, such as XUL/XBL. I suspect any implementation would be dependent on JavaScript, which would not satisfy those using <code>autocomplete</code> for putative security reasons. It would also be inferior to a cross-browser solution. However, such extensions might prove useful for backporting support for namespaced or microformated autocompletion instructions to old versions of browsers, whether Mozilla (with extensions or XUL/XBL), Konqueror (with [http://developer.kde.org/documentation/tutorials/kparts/ KParts]), or even to Internet Explorer (with [http://msdn.microsoft.com/workshop/components/htc/reference/htcref.asp HTC]). For an inspiring example of what can be achieved with such extensions, have a look at [http://w3future.com/weblog/gems/xhtml2.xml Sjoerd Visscher's XHTML 2 page at W3Future], which uses proprietary Opera CSS, XBL, and HTC to mimic XHTML 2 on current user agents.
 
6. Use JavaScript to set the attribute.
 
<blockquote><pre>
document.getElementById( "MyInput" ).setAttribute( "autocomplete","off" )
</pre></blockquote>
 
=== Conclusion ===
 
At present the most practical option is 4, hopefully aided by 5.
 
(As a sidenote, if we went down the namespaced route, we might like to create a more general <nowiki>http://www.legacymarkup.org/xmlns/legacyml</nowiki> namespace as a retirement home for all sorts of legacy markup that the W3C would, admirably but somewhat impractically, ignore.)
 
== How would Option 4 help web authors if implemented? ==
 
Option 4 would affect web authors differently depending on what sort of markup and internet media (MIME) type they are using.
 
=== Authors who want to use ''only'' HTML ===
 
If they declare that they are authoring according to a W3C HTML doctype, but use the <code>autocomplete</code> attribute then they are simply generating junk markup (as has always been the case). What they should do is use a custom DTD (as described above). Because of browser support, this is the best option for those who want to use <code>autocomplete</code> for security.
 
My suggestion would allow developers to author HTML according to W3C DTDs and disable autocompletion in supporting browsers, using a namespaced class like so:
 
<blockquote><pre><INPUT TYPE="text" CLASS="fh disable_form_history" NAME="sensitive ID="sensitive"></pre></blockquote>
 
This would be a great option for people creating Ajax applications like Google Suggest.
 
=== Authors who want to use ''only'' XHTML ===
 
I cannot emphasize enough that the use of the <code>autocomplete</code> attribute is currently utterly ''impossible'' in XHTML documents. With my proposal implemented, authors could at last use an attribute that does the same thing as the <code>autocomplete</code> attribute. Browser support would be less widespread, but browser support for XHTML as a whole is less common and browser support for the attribute is patchy in the first place (e.g. Opera, ELinks, etc.).
 
Using my attribute would require the import of a namespace (and ideally a suitable doctype). Such imports are common in the XHTML world, as they are required to mix in goodies like SVG, MathML, and XForms. Here's what such a document might look like:
 
<blockquote><pre>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC
    "-//LegacyMarkup//DTD W3C XHTML 1.1 plus FormHistory"
    "http://www.legacymarkup.org/2006/08/xhtml-formhistory/xhtml-formhistory.dtd">
<html xml:lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:fh="http://www.legacymarkup.org/xmlns/formhistory">
<head>
<title>Example document</title>
</head>
<body>
 
<form action="http://www.example.com/someaction" method="post">
<div>
 
<label for="non_sensitive">Your non-sensitive data:</label>
<!-- UAs implementing the HTML autocomplete attribute
SHOULD autocomplete this field (the default behaviour): -->
<input type="text" name="non_sensitive" id="non_sensitive"/>
 
<label for="sensitive">Your sensitive data:</label>
<!-- UAs implementing the HTML autocomplete attribute
SHOULD NOT autocomplete this form: -->
<input type="text" fh:formhistory="off" name="sensitive" id="sensitive" />
 
</div>
</form>
 
</body>
 
</html>
</pre></blockquote>
 
Edit by FunkyRes - mpeters@mac.com
 
I'm sorry, but this wiki page is incorrect. It is easier in xhtml to add an attribute than it is in html.
 
xhtml makes it very easy to do this. I do it.
 
<blockquote><pre>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd" [
<!ATTLIST form autocomplete CDATA #IMPLIED>
]>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
</pre></blockquote>
 
Note the magic in the DTD declaration -
 
<blockquote><pre>
[
<!ATTLIST form autocomplete CDATA #IMPLIED>
]
</pre></blockquote>
 
With that, my xhtml properly validates, no need to create a custom DTD.
Only gotcha is that you must send the application/xhtml+xml header with the document, but if you are using xhtml, you should be sending that header anyway.
 
Someone with better writing skills than me should properly update this page so that it presents things in a factual manner.
 
=== Authors who want to write XHTML 1.0, but use content negotiation to serve XHTML 1.0 as text/html (i.e. tag soup) to user agents that don't support XHTML ===
 
This group *must not* use the existing autocomplete attribute when serving as text/html (because it's not XHTML), and (I think) *must not* use the proposed namespaced attribute (because it's not HTML). But it is trivial for them to use the proposed microformat in ordinary XHTML 1.0, just like this:
 
<blockquote><pre>
<input type="text" class="fh disable_form_history" name="sensitive id="sensitive" />
</pre></blockquote>
 
=== Authors who want to write XHTML, but use content negotiation to serve HTML as text/html to user agents that don't support XHTML ===
This is the group to whom the XSL transformations are relevant. Serving ''both'' XHTML and HTML requires a transformation, usually using XSL. My suggestion would require one additional template rule. Given such authors will often be transforming not only vanilla XHTML, but XForms, SVG, etc. to HTML equivalents, such a template rule is but a drop in an ocean of XSL complexity. (I expect such complexity to be increasingly standardized as XHTML is more widely adopted.)
 
Another way to serve both html and xhtml is to use a libxml2 based tool, such as PHP DOMDocument class, to construct your document.
 
First you look at the $_SERVER['HTTP_ACCEPT'] variable to see if the client accepts application/xhtml+xml. If it does, you construct (or import) your document in a DOMDocument object using an xhtml Doctype. If it doesn't, you construct (or import) your document in a DOMDocument object using an html Doctype.
 
Then to serve, you use print $doc->saveXML() for xhtml capable clients and $doc->saveHTML() for the rest. No need to use an XSL transform.
 
Most server side dynamic languages have bindings to libxml2 that allow for this kind of thing.
 
== Appendix A: What about WHATWG? ==
 
Update: If Web Forms 2.0 is adopted by the W3C, then the namespace issues I discuss below will disappear.
 
I welcome and support the work of WHATWG on Web Forms 2.0 and Web Applications 1.0. When Web Forms 2.0 is finalized, it seems set to become a welcome addition to the HTML armoury. Unfortunately, I do not believe it currently offers much to help XHTML authors. Unlike my microformat, Web Forms 2.0 offers nothing at all to authors of XHTML 1.0: there is no way to incorporate its <code>autocomplete</code> attribute in their markup. And unlike my namespaced attribute, its <code>autocomplete</code> currently cannot be legitimately included in an modular XHTML document, as far as I can tell. Although Web Forms 2.0 claims to be XHTML as well as HTML, it seems incompatible with the W3C's specifications for XML markup, according to which only the W3C alone is allowed to extend the "http://www.w3.org/1999/xhtml" namespace. [http://whatwg.org/specs/web-forms/current-work/#xhtml-module-def The Web Forms 2.0 XHTML Module] is at present an only a curiosity. By extending this namespace, it violates the [http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/conformance.html#s_conform_module W3C's own specification for XHTML Family Modules]: "The module definition's elements and attributes must be part of an XML namespace [XMLNAMES]. If the module is defined by an organization other than the W3C, this namespace must NOT be the same as the namespace in which other W3C modules are defined." Nor, judging by the [http://www.w3.org/TR/xhtml-modularization/conformance.html#s_conform_module Working Draft for the next version of the Modularization specification], is that requirement likely to change in the future. So Web Forms cannot be part of a conforming XHTML host language or XHTML integration set document - that is, it cannot claim XHTML conformance of any sort that would currently be recognized by the W3C.
 
The [http://www.w3.org/Submission/2005/02/Comment W3C Team Comment on Web Forms 2.0 Submission] shows no sign of the W3C budging on this issue. Conversely, WHATWG have so far rejected pleas to place WHATWG elements and attributes in an XML namespace other than "http://www.w3.org/1999/xhtml". This perhaps isn't terribly surprising, given that WHATWG arose in the context of an [http://www.w3.org/2004/04/webapps-cdf-ws/papers/opera.html Opera and Mozilla position paper] openly critical of namespace overuse. See also the following threads on the WHATWG mailing list:
 
1. [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-June/000286.html Is this introducing incompatibilities with future W3C work? (June 2004)]
 
2. [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/001267.html clear naming for WHAT work (July 2004)]
 
It is not yet clear whether this divergence between the W3C and WHATWG on namespacing in XHTML modularization should matter. But clearly for those to whom it does matter, Web Forms offers no solution to the problem addressed by this proposal.


(As a sidenote, if we went down the namespaced route, we might like to create a more general http://www.legacymarkup.org/xmlns/legacyml namespace as a retirement home for all sorts of legacy markup that the W3C would, admirably but somewhat impractically, ignore.)
Having said that, I think there is a strong case for implementations of Option 4 to allow room to adapt any changes by Web Forms 2.0 to the <code>autocomplete</code> attribute to the XHTML world. One question for discussion is whether Option 4 should mimic Web Forms's requirement that: "Support for the attribute should be enabled by default, and the ability to disable support should not be trivially accessible, as there are significant security implications for the user if support for this attribute is disabled." Notably, Opera currently disables support by default, and the ability to enable support is not trivially accessible.


== Appendix: Autocomplete alternatives ==
== Appendix B: Autocomplete alternatives ==


Some readers may be interested in what else is possible with present technology and markup.
Some readers may be interested in what else is possible with present technology and markup.
GavinSharp
Confirmed users, Bureaucrats and Sysops emeriti
722

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/30720...290137"