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

Jump to navigation Jump to search

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

Revision as of 19:36, 7 August 2006

4,474 bytes added ,  7 August 2006
→‎Possible solutions
Line 28: Line 28:
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]. But I think that will never happen.
 
4. 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:


<blockquote><pre>
<blockquote><pre>
Line 76: Line 80:
(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.
 
=== 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.)
(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 different 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. This would not require not XSL but a namespaced class attribute like so:
<INPUT TYPE="text" CLASS="fh disable_form_history" NAME="sensitive ID="sensitive">
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>
=== 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 a but a drop in an ocean of XSL complexity. (I expect such complexity to be increasingly standardized as XHTML support grows.)


== Appendix: Autocomplete alternatives ==
== Appendix: Autocomplete alternatives ==
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/30827"

Navigation menu