- 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