- From: M. Hedlund <hedlund@best.com>
- Date: Mon, 29 Jan 1996 10:12:17 -0800 (PST)
- To: John Franks <john@math.nwu.edu>
- Cc: www-talk@w3.org
On Mon, 29 Jan 1996, John Franks wrote: > 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. My recent thinking on this issue is that a form of conditional HTML could be implemented with <INSERT>. Give some <PARAM>'s that describe the conditions under which the insert SRC should be requested, and let the browser decide whether it should get the insert or not. <INSERT SRC="http://www.name.dom/path/table.html" TYPE="text/conditional-html"> <PARAM NAME="condition" VALUE="vendor-tables/1.1"> <P>Your browser doesn't recognize vendor-tables/1.1, so you're seeing this instead.</P> </INSERT> OR logic could be specified by giving more than one PARAM. AND logic could be specified by recursive INSERTS. Browsers that don't recognize <INSERT> get the fallback text. Advantages: * Works in keeping with "the SGML heritage of HTML." * Doesn't stuff all possible variants into one document (avoids filesize bloat). * Backwards-compatible. * Very cache-friendly (not only can primary docs be cached, so can <INSERT>s). * Avoids stuffing browser capability description into huge Accept header. Disadvantages: * Requires multiple GETs (possibly a good number of them). * Requires the browser to parse the <INSERT>s before issuing subsequent GETs. (Maybe we can get around this with <ALIAS>?) The only thing I can say about the first disadvantage is that HTTP is moving in a direction that will ease the hit of multiple GETs (Keep-Alive, HTTP-ng). Thoughts? Marc Hedlund <hedlund@best.com>, <marc@organic.com>
Received on Monday, 29 January 1996 13:16:10 UTC