55
edits
The autocomplete attribute and web documents using XHTML: Difference between revisions
The autocomplete attribute and web documents using XHTML (view source)
Revision as of 11:23, 5 August 2006
, 5 August 2006→Possible solutions
| Line 47: | Line 47: | ||
</pre></blockquote> | </pre></blockquote> | ||
4. Another good option would be develop a simple XHTML module in a non-XHTML namespace, such as | 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: | ||
<blockquote><pre> | <blockquote><pre> | ||
| Line 56: | Line 56: | ||
</pre></blockquote> | </pre></blockquote> | ||
(As a sidenote, if we went down that 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.) | (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. | 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. | ||
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. | ||