- From: Robert Burns <rob@robburns.com>
- Date: Fri, 20 Jul 2007 07:03:34 -0500
- To: HTML WG <public-html@w3.org>
Compatibility with existing UAs The issue of compatibility is an important part of our design principles. It is often raised without careful consideration of what compatibility might mean: as if it can only mean one thing. In our earlier discussion on namespaces, Maciej offered the following definition of compatibility[1]: quote1) Given a typical document in namespace Foo authors to Foo version A (as informed by action use of Foo), what is the likelihood that it will be interpreted and presented as intended by an implementation of Foo version B? This is the practical degree of namespace compatibility between A and B. unquote I think this definition might be a good place to star for compatibility (though it really doesn't address the namespace issue). However, in determining this likelihood, I think we can identify several levels or categories changes to modifications to HTML that could cause compatibility issues. From most severe compatibility problem to least severe compatibility problem: 1) no modifications that would break compatibility with existing browsers (i.e., redefine either: <script>, <style>, <title>, <link>, <meta>, <html>, <ol>,, <ul>, <table>, etc. There are also less obvious compatibility-breaking changes such as using a <caption> in a table which causes problems because of the heroic efforts UAs take to repair ill-formed and even invalid code. Other changes to other content models might have similar negative results. Especially since these are very subtle and very obscure compatibility breaking changes, they are not exposed without careful testing (much of it already performed by WhatWG). 2) no modification that would add an element incapable of behaving as intended within existing browsers (e.g., XHTML2 <handler> element) 2a) especially if the addition of a new facility was accompanied by the immediate removal of the current means for this behavior 2b) especially if the addition of a new facility was accompanied by the deprecation of the current means for this behavior 2c) unless current facilities to accomplish the same results (though perhaps not as easily) are still included in document conformance 3) no modification that would not have a default presentation as intended in existing browsers. 4) no modifications to the HTML that would require a browser to make any changes before claiming 100% full conformance with HTML5. At times I get the feeling some are aiming at (4) :-). For example my proposed change to UA conformance for XML processing of the <img> element only violates (4). However, it cause quite a stir on the list and was dismissed repeatedly as violating our compatibility design principle. Number (4) aside, in my view (3) should not be that big of a concern for us if the facilities were adding are useful for authors and users. I don't have the ability to test this hypothesis, but I would imagine that the number of pages on the web that do not have either a embedded or linked stylesheet must be very small. Those that do exist in any appreciable number must certainly have very utilitarian aims and would not really be candidates for using new HTML5 semantics and therefore would not suffer the problem of having the wrong default presentation. For any other page that wanted to take advantage of new HTML5 semantic elements (this does not include <video> and <audio> and the like their presentation is not merely a matter of properly applied default CSS), we could publish an HTML5 recommended CSS stylesheet under a suitable open source license. Everyone would simply link to their own html5.css. So that is my motivation for listing (3) where I did: these things can be used immediately upon HTML5 reaching recommendation status (if not sooner). The bulk of my phrase element proposed enhancements fall into the category (3). The proposal of <quote> (subject to testing verification) likely has better compatibility than <q>, considering IE does not even present <q> correctly today (and it give authors a way to use in-line quotes across browsers immediately in a HTML5 document conforming way). Most other browsers could even be configured through a publicly available HTML5 default stylesheet to respect the @needsmarks attribute on <quote> (and <q> if we attach it to that element too). So I would say any modifications that fall under category (4) nor (3) should be any great concern to us: especially for any proposed facility that really serves authors and users. Level (2) is more complicated. Proposals such as <canvas>, <video>, and <audio> all fall under (2c) Many DOM additions or content attribute additions such as @ping likewise fall under (2c). On the other hand, some XHTML2 proposals fall under (2a) or (2b) and these changes are what I think have given XHTML the reputation for being backwards incompatible. I guess the elimination of <script> from XHTML2 might be considered a level (1) incompatibility: especially if UAs took the removal of <script> in the HTML namespace very seriously. Some of the content model changes like the introduction of structural inline elements to previously strictly inline containing elements causes some sort incompatibility between the text/html serialization and the xml serialization (though this may be another issue entirely). Take care, Rob [1]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/0814.html>
Received on Friday, 20 July 2007 12:04:18 UTC