Re: Marking elements as 'volatile'

> Back in the good old days where nobody had ever heard of dynamic HTML 
> pages, browsers had a 'subscribe' function, so one could automagically 

Subscribe ("channels") was contemporary with "dynamic HTML" (I'm not
convinced that you have used dynamic HTML in the comonly used way,
though - what you seem to be describing is database generated web pages,
which were also contemporary with subscribe).

Channels were business model driven, and failed as a business.  They were
part of a model in which companies paid the browser supplier for inclusion
in a channel directory.

> be notified when a page's content had changed. With dynamic HTML pages, 

In terms of this function, all they provided was a recommended polling 
interval.  The actual update was done by the browser trying to fetch,
hopefully using If-Modified-Since.  Their main purpose was to provide a list
of pages for pre-fetching (and a tree navigation scheme for the site) so
that the advertiser's content was immediately available in a reasonably
current form.

They were implemented as an (XML) metadata file.

> though, this function has become pretty useless. There's a dynamic list 
> of referrers, a "welcome back, your last visit was on <date>" message, 
> etc.

I think the main dynamic content that most sites are interested in updating
frequently are adverts.  That's one reason why "designers" learn (often
bogus) methods for turning off caching as one of the first hacks that they
learn.  The other reason that sites don't like caching is that it doesn't
give them as high a number of page views to quote to their advertisers and
doesn't allow click trailing.  The Microsoft channels implementation partially
addressed these by allowing the browser to accumulate page view statistics
on behalf of the web site (something that many people would disable).

> 
> I believe it would be useful to be able to mark dynamic, ever-evolving 
> elements in an XHTML document as 'volatile'. Volatile elements would be 
> ignored while checking whether a page is updated or not.

Checking for updates in this context is the job of the server, as a
browser would have to read the whole page anyway, before  it could check.
As such such markup could be done in a server only namespace, or even
private language.  Server side includes is an example of such a language,
and, in fact, server side includes are one of the reasons for a lack of
the reliable Last-Modified-Date meta data on the current web.  Basically,
in the unlikely event that the site didn't want to force the new adverts
on the user, they should not update the Last-Modified-Date and/or Etag.
They might need to inhibit public caches, losing most of the benefit, if
they wanted new users to get absolutely up to date pages.

As such, I don't think it is within the scope of HTML.

Received on Friday, 7 January 2005 08:03:25 UTC