55
edits
The autocomplete attribute and web documents using XHTML: Difference between revisions
Jump to navigation
Jump to search
m
The autocomplete attribute and web documents using XHTML (view source)
Revision as of 10:44, 9 August 2006
, 9 August 2006→Appendix A: What about WHATWG?
| Line 205: | Line 205: | ||
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. | 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: | |||
Having said that, I think 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. | 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. | |||
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 B: Autocomplete alternatives == | == Appendix B: Autocomplete alternatives == | ||