- From: Larry Masinter <masinter@adobe.com>
- Date: Tue, 17 Feb 2009 11:32:09 -0800
- To: Ian Hickson <ian@hixie.ch>
- CC: HTML WG <public-html@w3.org>
If there were multiple languages which used the same namespace, (or multiple versions, HTML 5 and HTML 6 or whatever) then imp.createDocument needs to choose which language it is creating a document *in*, no matter how that version is indicated in the serialization. I imagine the simplest implementation would be that imp.createDocument creates a document in the same language or version in which the script was embedded. That would make sense even without the XML serialization. So a script in a HTML2 document would create a HTML2 dom, and a script in an HTML5 document would create a HTML5 dom. This should be the case even if the script doesn't explicitly insert the namespace, version indicator, doctype, or have an explicit MIME type. > ...browsers are required, for compatibility with legacy content, XHTML1, > DOM2 HTML, and DOM2 Core, to return an element that, when inserted into a > document, displays either an image as indicated by its "src" attribute, or > text as indicated by its "alt" attribute. Legacy compatibility is one among several design goals which are often traded off in the design process. The existence of legacy table@summary attributes seems to have little weight in the discussion, so the fact that there might be scripts which would execute differently in HTML1 vs. XHTML2 or XHTML5 would need to be evaluated using only the same criteria. > This is the case regardless of HTML5 or XHTML5 -- this has absolutely > nothing to do with this working group, it is based purely on specs that > were created in the late 90s, around a decade ago, years before HTML5 > started. This is the world in which we find ourselves, writing HTML5. In http://lists.w3.org/Archives/Public/public-html/2008Aug/0765.html you said "HTML5 started from a clean slate". So what previous specifications say has not, apparently, been previously upheld as an inviolate design principle. What is the consistent principle actually being applied here? > A spec that changes the requirements around this script in a way that is > incompatible with existing browsers, content, and specs is going to have a > great deal of trouble getting implemented by Web browsers. Thus, we really > have very little room to manoeuver here -- HTML5 is constrained here, like > in so many other places. Frankly, I would think scripting compatibility is most likely the least feasible of all of the kinds of compatibility that are desirable, and that the cases which would actually differ between XHTML2 and XHTML5 are as rare as ones that would differ about the differences between XHTML1 and XHTML5. In fact, a new namespace for XHTML2 would likely have even more impact, in terms of things that would needlessly break. > XHTML claims > (section 1.1.2) that "strict element-wise backwards compatibility is no > longer necessary", and thus it exempts itself from the aforementioned > constraints. Considering "clean slate" quote above, whether the document itself states its compatibility requirements or it is merely a mailing list posting by the editor doesn't seem to me to be significant: compatibility needs to be judged on actual impact on existing implementations, no? > In conclusion: XHTML5 does not have a new conflict with XHTML2 even if > both use the same namespace. The conflict, insofar as there is one that > matters, already exists between XHTML1 and XHTML2, and exists irrespective > of XHTML5. I believe this issue to therefore be out of scope for the HTML5 > specification, and do not propose to do anything about it (except for > changing the "relationship to XHTML2" section if they do indeed publish a > version of XHTML2 that reuses the same namespace). There was a request to review the versioning and namespace issues, and I volunteered to do that. I would suggest that this issue won't go away until we document the arguments more carefully than has been done in the past. At a minimum, the "relationship to XHTML2" section will require working group review and consensus, and so is legitimately a working group issue, and thus not out of scope. > I would like to recommend that future discussion on the subject of > versioning focus on versioning in the face of DOM Core implementations and > the script given above, as that will help prevent discussion that could > not solve the problem (e.g. anything to do with DOCTYPEs, version="" > attributes, or MIME types, none of which are present in the above snippet, > despite that snippet creating an XHTML1/5 element). Script compatibility is certainly another requirement, and I didn't see it among those raised in the many emails and wiki pages I reviewed prior to posting about the topic (as requested.) However, I do think versioning in scripting makes the most sense under the assumption that scripts create elements in the same version as the document in which the script is embedded. I confess that I don't understand how scripting works in multi-format compound XML objects, since the operation of HTML scripting and SVG scripting and SMIL scripting etc. seem to be defined as if the scope of "document" was the entire document and not one sublanguage or another. Do Atom feeds allow scripting within the HTML which is embedded, or is the issue of versioning within DOM scripting only a single-language-document issue? > I would also like to > recommend that any discussion for new features continue to consider the > need for graceful degradation, which requires us to continue to use the > same namespaces and tag names as is supported by legacy browsers, at the > very least for existing features, and ideally wherever possible. I agree that "graceful degradation" is a high priority among the many sometimes conflicting design goals, and that reckless use of different namespaces would hamper accomplishing that goal. I don't think I would go so far as saying that "graceful degradation" was absolutely a higher priority than every other design goal, or that continued use of the same namespaces and tag names was an absolute requirement of that highest priority goal, or that every bit of W3C work should have the same compatibility goals as HTML5. Regards, Larry -- http://larry.masinter.net
Received on Tuesday, 17 February 2009 19:32:56 UTC