- From: John Franks <john@math.nwu.edu>
- Date: Mon, 29 Jan 1996 11:12:24 -0600
- To: www-talk@w3.org
In article <2.2.32.19960127205744.006bce54@204.145.225.20>, Bill Weinman writes: > The Accept string, or perhaps a new tag of some sort, would > give a list of features that the client can render. (It seems > inappropriate to define lots of new MIME-types for this.) > > Then the content could be coded with conditionals that would > give either low-level or feature-rich content on an object-by-object > basis. > > That way I wouldn't have to have entirely different source > for all the different combinations of support implemented by > all the different browsers. > Several servers already offer conditional constructs on the server side. (See for example, http://hopf.math.nwu.edu/docs/parse.html#if ) This is easy to use and gives great flexibility to the site maintainer. It allows different versions based on browser features, accept headers, remote host or domain, etc. There is some overhead in parsing the document as it is served, but generally this is fairly efficient. It has the drawback (shared by all current content negotiation methods) of not interacting well with caching. One suggestion has been a conditional HTML which is parsed and interpreted by the client. This seems to be a very good idea. It completely solves the caching problem. One drawback is that documents might become substantially larger if they contain all virtual versions. I am not very optimistic about its adoption, however. The SGML heritage of HTML is likely to be a stumbling block and the political problem of getting browser writers to accept such a scheme may well be insurmountable. -- John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Monday, 29 January 1996 12:14:13 UTC