> How about parameters on the Accept: header?
>
> User-Agent: NCSA-Mosaic/2.5
> Accept: image/gif, image/jpeg,
> text/html; tables=yes; forms=yes; images=yes,
> audio/basic
>
> (I *think* that's the right semicolon/comma precedence.)
>
> This should require a minimal change to browsers,
> as the HTML features supported by a browser are
> more or less fixed.
The main problem I see with this solution is that it is HTTP specific.
HTML is an SGML application. I believe it is best that a solution is
targeted more in the SGML realm so authors have more control on how a
document will appear based upon a client's conformance level. Plus not
all HTML documents are served via HTTP.
> On the server side, the GET processing module could
> pipe all HTML documents through a CGI filter that
> selectively downgrades the document to eliminate
> features that the browser doesn't support,
> either replacing them with <PRE> (e.g., tables)
> or a canned message saying that this part of the
> document could not be viewed.
Here's where I think it would be better if authors could state in the
document itself what alternatives should be used based on a clients
capabilities. For example, an author might want a list to be used in
place of a table for clients w/o table support, instead of the table
being converted to a <PRE> construct.
--ewh