Internet Outlook with Richard Wiggins | 17

A Plea for Open, Accommodating, and Adaptive Web Sites

The basic idea of negotiating capabilities between client and server was firmly in the minds of the community that built the Web. Much of the early design discussion took place on the www-talk mailing list, and Daniel W. Connolly was a leading participant. In October 1994 he lamented the number of sites that were offering content in a variety of formats, but requiring the user to specify their format capabilities. He feared we'd see page after page with choices for users to make:

Designers such as Connolly argued that the browser knows its capabilities, and the server knows its capabilities, and the two should negotiate a common ground. If Telnet could implement such negotiations, why couldn't the Web? And in fact the Hypertext Transfer Protocol (HTTP) has always provided a framework for such negotiations.

Less than a year after Connolly's lament, in September of 1995, IBM proudly launched their site for the U.S. Open tennis tournament. When I visited the site I was pleased to see a great deal of real-time content, including score updates presented using fairly elaborate tables in HTML. Believe it or not, use of tables was still a new thing back then, and I snickered as I logged onto AOL to prove that, by using tables, IBM had disenfranchised several million potential readers.

To my surprise and delight, I saw that the same scores were delivered to me in a courier font, with the <PRE> tag used. IBM had actually put the scores into some sort of database, and their web server software was smart enough to sense what kind of browser you were using, and adapt the presentation of content to match!

Actually, the nature of the negotiation wouldn't please an Internet design purist. The IBM server was looking at the name of the Web browser and making assumptions about the capabilities of each browser, which had been cataloged by the site designers. A purer and more robust approach would be to have the server negotiate each capability with the browser -- just as Telnet has always done, and just as we did in our hypothetical movie review example.

But still, that was progress! Maybe servers would adapt to the real needs of customers! Another prolific www-talk contributor (and creator of the HTML+ spec) Dave Raggett proposed on-the-fly conversion back on November 23, 1992:

Alas, it was not to be. New formats proliferated, and mechanisms for under-the-cover format negotiation, and on-the-fly adaptation by the server, never matured. A few reasons come to mind:

• A handful of very common formats were standardized quickly (e.g. use of GIF for inline images); negotiating "unusual" formats was by definition an uncommon need.
• Format translation on the fly may be difficult. Tools to translate from Shockwave streaming audio to Realaudio may not be readily available.
• Format translation may be expensive. It could take a lot of server resources to convert from one multimedia format to another.
• Format translation may be impossible. If Disney creates a VRML walkthrough of Disneyworld, it's not possible to represent it on a text mode browser.

Alas, I fear there's another, overarching factor: designer hubris. Many site designers latch onto a favorite proprietary presentation format, either out of personal bias, or because they've been bribed in some way by the format's creator, and they say, in effect, "Screw you if you can't cope with our format choice."

Consider a more recent IBM creation, the LL Bean catalog site. Connect to it with a browser that doesn't handle frames, and you're out of luck. You're told to go get a better browser and come back. I wonder if a blind person using "talker" browsers can buy from LL Bean?