Re: HTML variants and content negotiation

Brian Behlendorf wrote:
> II.  Introduce conditional constructs to HTML.  Basically create a new
> content-type, text/cond-html, say, and have it use either marked sections
> or PI's to implement a IF(feature|NOT feature), THEN (block) ELSE
> (block).  The "feature" would again be a registered keyword, which
> browsers would be responsible for setting appropriately.  Browsers which
> supported cond-html would indicate so in their accept headers of course,
> so there's still a big role for content negotiation.

I've been swamped lately so haven't been tracking this, however just a note that two things 
that are very useful in the same context as conditional presentation of HTML are "EXIT" (I'm 
done, stop presenting/parsing the file) and "INCLUDE".  The latter of course is something 
discussed in other contexts.  Basically, the functionality of cpp is very similar to what 
you'll want, including && and || capabilities.

> II - Positives:
>         Reduces the processing requirements on servers - servers can
>           be "dumb", and thus more scalable.

If you combine this with the browser passing in information then you could go either way.  
You could have a smart server which parses the information and only sends what is necessary, 
or you could have the browser do the parsing.

>         Proxy caches don't have to worry about feature-set negotiation
>           either - one document, not 2^(# feature-sets) possible documents.

That is definitely an advantage, proxy servers are a problem with server-side solutions. 
Although in practice I think the browsers on the other side of proxy servers tend for the 
most part to support the same type of capabilities.  Organizations with the wherewithall to 
put up proxy servers tend to also have standardized on browsers.

>      Negatives:
>         File bloat - conceivably documents could be 2-3 times as large as
>           normal, since the client will be throwing away what it doesn't
>           understand.
I can speak to that from experience.  While it's certainly possible to end up with extra 
large files, in practice you don't have to.  I think even our most complicated parsed files 
are at most 2x, and most far less.  However, and this could be a big "but", our server 
extensions are outside of the language, thus allowing:
#if Tables
<table>
#else
<pre>
#endif
...
#if Tables
</table>
#else
</pre>
#endif

If you are doing the extensions within the context of HTML parsing, that may not be a viable 
structure.  So at that point you could see a 2-3x expansion in size in some cases.

Broken/different browser implementations are a problem.  One advantage of server-side 
solutions is that we can work around them.  You mentioned the tables-within-tables and 
inline-within-tables ones.  There are more subtle onces such as whether or not percentage 
cell widths are supported (not in Netcruiser, with disastrous results (30% becomes 30 
pixels)).

Received on Monday, 8 January 1996 12:23:35 UTC