There is a clear market demand to represent tables in HTML on the World-Wide Web. The development and vendor community is moving rapidly to fulfill this demand, even while the specification for HTML tables is still under discussion.
But documents with table markup represent a potential interoperability problem, and a potential support burden for information providers.
For example, there is a significant installed base of users who access the web via the lynx browser on "shell accounts." Table markup will not be interpreted reliably by this installed base.
Information providers might have to choose between not using tables, compromising support for this user community, or mainaining alternate representations of the information, and cluttering up their documents with "if your browser supports tables..."
The web architecture is designed to gracefully incorporate new features. This statement outlines a strategy for graceful deployment of HTML tables on the web.
The web architecture acknowledges that new data formats will be introduced, and that data formats will evolve over time.
To account for this, the primary web information retrieval protocol, HTTP, supports format negotiation, where the client advertises its capabilities and preferences regarding data formats, and the server tunes its response to these preferences.
The installed base of web user agents generally advertises acceptance of the text/html internet media type. The installed base of servers uses text/html to label the data that they serve as well. Their shared understanding of the meaning of this term is given in the HTML 2.0 specification.
While clients should be robust in the face of errors, the onus is on the server to make sure the data agrees with the Content-Type: field of the HTTP response.
Hence, if information providers wish to put table markup, which is not part of the 2.0 specification, in their documents, they must not label it as text/html, since this would result in unreliable behaviour in deployed clients.
Documents with tables should be labelled as:
Content-Type: text/html; level=3
and clients that support HTML 3.0 will interpret them reliably.
Clients that do not support HTML 3.0 should act reliably as well, with some loss of functionality. The installed base of clients will generally offer to save the data to a file for later processing. Future releases of browsers that do not support level 3 features may attempt to interpret the document with respect to the HTML 2.0 specification, after giving the user some indication that some idioms might be misinterpreted.
If an information provider deems that having the documents saved to a file rather than displayed is too much loss of functionality, they may arrange for their server to detect the lack of level 3 support in clients, and in that case translate the level 3 features into level 2 representations, and return the result with a text/html content type. This conversion may be done in batch at the time the documents are made available, or at the time of the request, with caching employed for improved performance.
The need to detect a mismatch between the features used in a document and the features supported by a client motivates a requirement that authors should label documents with table markup distinctly from HTML 2.0 documents. Authors are encouraged to include an explicit prologue at the beginning of each document which uses tables:
<!DOCTYPE HTML "-//IETF//DTD HTML 3.0//EN">
But since the installed base of server software generally determines the content type of a document before opening the file, we suggest that authors use a .html3 filename extension, or .ht3 on MS-DOS filesystems.
If the cost of deploying this convention at a site is too high, a server administrator may assume that all documents with the .html extension may have level 3 features, and label them as text/html; level=3, or convert them as above.
The need for servers to be able to detect lack of support for tables in clients motivates a requirement that clients that support tables should make this apparent in their requests, since it is impractical to change the operation of the installed base of clients.
Client implementors are encouraged to support the full HTML 3.0 specification, and announce this in each request ala:
Accept: text/html; level=3
We tested the case of returning the latter response header to Netscape 1.1beta, and it worked; i.e. the document was displayed as expected. The Arena browser is being updated to handle this case. We haven't tested Netscape with x-html.
The long-term viability of the World-Wide Web as a global information service depends on the graceful deployment of new features over time.
Support for the installed base of applications during the introduction of new features does not come without cost, but considering the cost of destabilizing the installed base, it is worth the extra effort.
The above strategy allows software with the capability to support table markup in HTML to be deployed without causing the installed base of applications to behave unreliably, and without an undue maintenance burden on the part of information providers.