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 16:13, 5 August 2006

1,329 bytes added ,  5 August 2006
→‎Possible solutions
Line 30: Line 30:
== Possible solutions ==
== Possible solutions ==


1. The ideal solution would be to persuade the web and financial communities to employ other techniques. Good luck with that.
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.


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


3. More plausibly, we could create and support a microformat ([http://microformats.org/wiki/introduction Microformats Wiki: Introduction to Microformats]) recognizing a <code>class="disable_form_history"</code> and treating it as equivalent to <code>autocomplete="off"</code>. When serving the same resource in an HTML representation (e.g. with content negotiation), it would then be possible for an XSL transformation to add the correct <code>autocomplete</code> attribute and leave the class untouched, with something along the lines of:
3. More plausibly, we could and 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 converting content for serving as HTML, the XSL transformation to HTML would be trivial:
 
<blockquote><pre>
<xsl:template match="@formhistory:formhistory="on"">
  <!-- Replace with autocomplete attribute -->
  <xsl:attribute name="autocomplete">on</xsl:attribute>
</xsl:template>
 
<xsl:template match="@formhistory:formhistory="off"">
  <!-- Replace with autocomplete attribute -->
  <xsl:attribute name="autocomplete">off</xsl:attribute>
</xsl:template>
</pre></blockquote>
 
(As a sidenote, if we went down that 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.)
 
Following the example of XHTML accessibility roles, we could create an associated microformat ([http://microformats.org/wiki/introduction Microformats Wiki: Introduction to Microformats]) that would overload the <code>class</code> attribute. Accessibility uses "axs" as a delimiter to prevent namespace collision; we could use "fh". So we'd end up supporting:
 
<blockquote><code>class="some_css_class some_other_css_class fh disable_form_history"</code></blockquote>
 
and
 
<blockquote>
<code>class="fh enable_form_history"</code>
 
The two variations are necessary because an input might have autocomplete enabled within a form that generally wants autocomplete disabled (thanks to richmoore for pointing that out to me).
 
When serving the same resource in an HTML representation (e.g. with content negotiation), it would then be possible for an XSL transformation to add the correct <code>autocomplete</code> attribute and leave the class untouched, with something along the lines of:


<blockquote><pre>
<blockquote><pre>
Line 47: Line 76:
</pre></blockquote>
</pre></blockquote>


4. Another good option would be develop a simple XHTML module in a non-XHTML namespace, such as <nowiki>http://www.mozilla.org/xmlns/formhistory</nowiki> or better yet a vendor neutral URI, and add support for an <code>autocomplete</code> (or <code>disableformhistory</code>) attribute in that namespace. Unlike with microformats, there would be no risk of name collisions. Also, the XSLT transformation to HTML would be trivial:
(N.B. This XSL definitely needs testing.)
 
<blockquote><pre>
<xsl:template match="@formhistory:disableformhistory">
  <!-- Replace with autocomplete attribute -->
  <xsl:attribute name="autocomplete">off</xsl:attribute>
</xsl:template>
</pre></blockquote>
 
(As a sidenote, if we went down that 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.)


5. Other alternatives might include some sort of XUL/XBL extension. However, I suspect any implementation would be dependent on JavaScript, which would not satisfy those using <code>autocomplete</code> for putative security reasons.
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, however, 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, which uses proprietary Opera  CSS, XBL, and HTC to mimic XHTML 2 on current user agents.
 
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.
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/30711"