- From: Philip Ronan <philronan@blueyonder.co.uk>
- Date: Tue, 31 Jul 2007 18:22:41 +0100
- To: public-html@w3.org
Hi. This is my first post here, so I'm probably doing something wrong. But anyway, bear with me... ==PREAMBLE== Websites often use environment discovery techniques to vary the content of HTML pages depending on the client's browsing environment. Here are a few examples: (1) A web page providing instructions on how to download an image might contain the following: Right-click on the image and choose "Save As..." from the pop-up menu. But if the client is using a Macintosh system, this should be changed to the following: Click on the image while holding down the Control key, and choose "Save As..." from the pop-up menu. (2) A web page that contains a few characters of Japanese will not display correctly on systems where Japanese fonts have not been installed. This can be fixed by replacing the Japanese characters with images. But if the client is able to display Japanese, then it would be better to stick with the characters. (This could be detected by, for example, looking for "ja" in the "Accept-Language" request header. (3) A website with user-selectable CSS stylesheets could use a cookie to store the client's preferred style and set this stylesheet as the default stylesheet for subsequent page views. ==PROBLEM== Tailoring content in this way makes it incompatible with web caches. For example, in case (1), if a Macintosh user accesses a cached copy of a page tailored for a Windows user, then the image download instructions will be displayed incorrectly. According to the HTTP specification (RFC2616), content that varies in this way should include a Vary header. So in case (1), the server should flag the page with the HTTP header "Vary: User-Agent". Unfortunately, this would make it almost pointless caching the content since there are thousands of different user agents in widespread use (even browsers of the same version running on the same operating system will often produce different User-Agent headers). Cases (2) and (3) would require the headers "Vary: Accept" and "Vary: Cookie", leading to similar problems. If pages cannot be cached successfully, then they have to be fetched directly from the originating server at each request. This results in increased server load, heavier web traffic and slower page load times. Currently the only workaround for this problem is to use Javascript to modify the page content based on the client's environment. This is not possible in all browsing environments, so it is impossible to be sure that the user is shown the correct content. ==PROPOSED SOLUTION== This could be fixed by providing all clients with a single uniform HTML source preloaded with all the available options, and implementing some form of environment discovery that the client can use to choose the most suitable alternative. Nested <OBJECT> elements offer similar capabilities for embedded items, and could be expanded to solve this problem by adding "selector" and "match" attributes as in the following examples: Case (1): <OBJECT selector="User-Agent" match="Macintosh"> Click on the image while holding down the <B>Control</B> key, <OBJECT> Right-click on the image </OBJECT> </OBJECT> and choose "Save As..." from the pop-up menu. Case (2): The word "honcho" originates from the Japanese word <EM>hancho<EM> <OBJECT selector="Accept-Language" match="ja"> (班長) <OBJECT> (<IMG src="hancho.png" alt="班長">) </OBJECT> </OBJECT> Case (3): <HEAD> : <OBJECT selector="Cookie" match="style1"> <LINK rel="stylesheet" type="text/css" href="1.css"> <OBJECT selector="Cookie" match="style2"> <LINK rel="stylesheet" type="text/css" href="2.css"> <OBJECT> <LINK rel="stylesheet" type="text/css" href="3.css"> </OBJECT> </OBJECT> </OBJECT> : </HEAD> I hope the above examples speak for themselves. Notice that in case (3) there are three different options nested one inside the other. The value of the selector attribute could correspond to an HTTP request header, but could instead be selected from a range of well- defined preset values such as "operating-system", "installed-scripts" or "screen-size". In particular, the handling of cookies should probably include the ability to specify a particular key-value combination, e.g., <OBJECT selector="Cookie:«key»" match="«value»">, where «key» is the name of a cookie, and «value» is a string to be matched against the value of this cookie. ==BENEFITS== Environment discovery would make it possible to provide content that tailors itself to individual browsing environments without becoming uncacheable. ==DRAWBACKS== The proposed system of tags (ALTERNATIVE, CHOICE and DEFAULT) will make content incompatible with earlier browsers. This could perhaps be solved by providing the alternative content in some other way such as attribute values, or by cloaking with HTML comments. ps: Sorry if this issue has been dealt with already. I searched the archive but didn't find anything. -- Phil Ronan philronan@blueyonder.co.uk
Received on Tuesday, 31 July 2007 18:24:43 UTC