On the question of compatibility

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