- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 12 Feb 2009 00:56:33 +0100
- To: Larry Masinter <masinter@adobe.com>
- Cc: HTML WG <public-html@w3.org>
Larry Masinter wrote: > The fact that one language makes <title>abc</title> equivalent > to <meta property="title" content="Document Title"/> and the other > does not does mean the languages are incompatible. But the elements > "title" and "meta" have the same meaning as vocabulary items, their > usage is different in the two languages. I mentioned many more issues other than that one, and I didn't say all of them had namespace incompatibilities. That one, at least in theory, may not have a direct impact on the namespace. But it has other issues, like interacting with the DOM (document.title), and lack of defined processing requirements. This would create significant problems for implementations, which makes it effectively incompatible anyway. But these are some of the elements that are not backwards compatible and cause namespace conflicts: * <label> - Used as both a list label and, although the spec isn't entirely clear about this, an XForms control label. * <input>, <select>, <textarea> - Uses the XForms processing and content models. This is a very major incompatibility relating to both DOM APIs, processing and authoring requirements. * <object src=""> vs. <object data=""> - Unnecessarily changes the attribute, and fails to define processing requirements. e.g. What happens with <object data="..." src="...">? How does that affect UA processing, and what effect does that have on the DOM API? * Renaming <script> to <handler> - Unnecessarily renaming, effectively introduces a second element for exactly the same purpose. I believe there are others, but I'd have to go hunting through the spec to find them. >> Basically, the only solution to this issue that should be considered is >> that we continue using the namespace and the XHTML2 WG use a different >> namespace. > > It is not a useful style of argument to assert that the only > solution that should be *considered* is the one you favor. > Certainly there are other solutions that should be considered, > such as using the same namespace and resolving any compatibility > issues that might otherwise arise. It wasn't an argument. It was a conclusive statement based on prior arguments raised in previous discussions, some of which I linked to, and the fact that there is no technical justification for us to even consider changing our namespace. (Though I'm not really all that concerned about what the XHTML2 WG does.) >> Otherwise, I will propose closing the issue. > >> Absolutely, keeping this issue open is unnecessary. The issue is >> entirely political, with no technical justification for us to keep it >> open. It should be closed immediately. At most, a separate issue >> should be raised with the XHTML2 WG to make them use an alternative >> namespace. > > That isn't what I propose, actually; what I propose is continuing > to use the same namespace, but resolving any vocabulary incompatibilities, > (not language or processing rule incompatibilities, note) either > by changing XHTML5 or XHTML2 to remove the vocabulary incompatibility, > or renaming the element or attribute name in one or the other to > remove the vocabulary incompatibility. Considering that work on HTML5 initially started in part because the XHTML2 WG failed to address the many issues, including the compatibility issues, that isn't really going to be a viable option. If it were, it would have been done years ago. For now, the quickest option is for us to keep using the namespace as we always have and close the issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Wednesday, 11 February 2009 23:57:20 UTC