- From: Robert J Burns <rob@robburns.com>
- Date: Mon, 16 Feb 2009 17:33:08 -0600
- To: HTML WG <public-html@w3.org>
ISSUE-60 No one has really answered this question (in the subject). Before engaging in lengthy discussions about how to solve the namespace issue, it would be a useful exercise to determine where the name collisions exist. I've pointed out the problem with HTML5 redefining the 'small' element before. This also goes for the 'strong' element and several other presentationally related elements. Lachy claims, but has not yet demonstrated, XHTML2 has name collisions with XHTML1. Though he has failed to demonstrate any, lets take that as a given. Those two problems represent namespace issues within each project and not between both projects. So first and foremost, each project needs to fix the namespace name collisions within its own draft. Secondly, we may require some coordination to avoid name collisions between XHTML2 and HTML5, though I've yet to see anyone provide an example. So as far as I'm concerned we haven't really identified a problem regarding namespace to solve yet. As an aside, some mention irretrievably irreparable DOM issues that XHTML2 has with itself. This claim usually goes along with some considerable hand waving, and no elaborated details whatsoever. So it is difficult o determine what it refers to. However, since XHTML2 has very little to say about DOM, I assume this is mostly related to the globalization of attributes. While XHTML2 should probably say something about this, it still doesn't constitute a name collision problem. If the 'href' DOM attribute is directly defined as a DOMString attribute on the HTMLAnchorElement or on the HTMLElement interface and inherited, does not constitute a name collision. In fact HTML5 could define it in the latter way and XHTML2 could define it in the former way, an implementation could implement it in the XHTML2 way; and HTML5 authors would never notice the difference (except through some inconsequential error). Like other namespace issues DOM namespace issues would have to be a name collision where a DOM attribute or DOM method of the same name returned different data or even the same data of a different type. A DOM issue cannot be simply based on the class hierarchical factoring of the interfaces. So before we write endless diatribes about which project needs to give up on the namespace, let's first identify some real problems with name collisions between the two projects (as opposed to the name collisions within each project that each project needs to fix anyway). Take care, Rob
Received on Monday, 16 February 2009 23:33:51 UTC