The browser indicates the media type preferences with the HTTP header field 'accept'. It can also include 'wildcard' media types, such as "text/*" or "*/*" where the * matches any string. "text/*" indicates that any type starting "text/" is acceptable. Some browsers routinely send wildcards in addition to explicit types they can handle. The intention of this is to indicate that the explicitly listed types are preferred, but if a different representation is available, that is ok too. 
accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */*
This is the 'accept' HTTP header field that the Microsoft Internet Explorer 5.0 sends in each request.
This is the 'accept' header field of the Microsoft Mobile Explorer emulator without spaces between the media types.
How can we use these media types for automatic content negotiation? Well, we think that this information is more or less useless. The Internet Explorer and Mobile Explorer tell an HTTP daemon or web application that it supports all media types because of '*/*'. All other media types listed above give an indication about the browsers' preferred media types.
In addition, we have another major difficulty: the media type 'text/html' does not provide any information about the version of the hypertext markup language, which might be for instance HTML of any version, Compact HTML, XHTML 1.0, XHTML 1.1 or XHTML Basic, respectively.
A third problem does not arise, if a browser type always requests the content over network connections with similar capabilities. i-Mode web browsers in Japanese cellular mobile phones only communicate over the NTT DoCoMo cellular network. The Palmscape web browser for Palm organizers might also send the requests over low-speed cellular networks. Browser types that can be installed on notebooks for instance might send their HTTP requests over a high-speed LAN as well as over a low-speed cellular network connection. Therefore, some browsers can be clearly associated with markup languages versions and presentation designs via the HTTP header field 'user-agent '.
However, you need to provide a version of your web site without high volume presentation styles for these browsers like Netscape Navigator or Internet Explorer that can communicate with your web server over networks with very different capabilities. Even if the user might disable the loading of the external CSS file in these browser types, you may assume that most users don't know about this feature and how to disable it.
If you would only take the 'user-agent' header field into consideration you would need to maintain a huge list of worldwide all HTTP clients. HTTP clients are not only well known web browsers but also WAP browsers, search engines, text readers, web page validators, and so on. If an unknown browser sends a request to your web server which default markup language shall your server send back? Can this browser render your default markup language? We don't know and your server, too.
You have another chance to avoid the maintenance of different versions of your web site. If you use only a single CSS file for your whole web site then your users would only need to load this file once. Therefore, you can keep one presentation design for all kinds of browsers independent of the network connection.
Would you like to provide different markup languages versions for different web browsers? If you would ask us, then we would answer: no! It should be sufficient to provide web pages that are coded in XHTML Basic and CSS. The requirement is that they at least apply to the Priority 1 guidelines of the W3C "Web Content Accessibility Guidelines 1.0" (see ).
The difficulty is only to support mobile browsers that require extensions to standard markup languages. These are AvantGo as well as Palm Web Clipping browsers for instance. Even if they support a subset of HTML 3.2 (see Chapter "AvantGo" and Chapter "Palm Web Clipping"), the extensions are proprietary. This means, that you would really need to provide different versions because the extensions do not conform to the XHTML Basic recommendation.
Copyright © 2001-2003 by Rainer Hillebrand and Thomas Wierlemann