> (someone wrote, attribution deleted)
>> "Daniel W. Connolly" <connolly@hal.com> wrote
>>
>> > It would be great if we could hash this out once and for all, and
>> > deploy the solution.
>> 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
> 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.
OK, but make it simple for people to use 3.0 features or they will not be used.
I would hate 3.0 to be shunted into some sort of backwater where it's main
purpose was to be discussed by sad-o academics while everyone else forks off on
a new development path.
> Plus not
> all HTML documents are served via HTTP.
Ah yes, documents served by FTP or through email, perhaps even NNTP when groups
with HTML postings appear...
Does this mean that all document conversion must happen on the client side,
then? Because if so, it means that all existing browsers become broken when HTML
3.0 documents start appearing on the net.
What does an existing browser do with a 3.0 imagemap where all the URL list and
stuff is in the document for client-side processing?
> 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.
Fine, but how do you express this so that existing clients can do the right
thing now, or be trivially modified to do so?
And, its a lot of effort for document authors to go to for a transitional period
where there are 2.0 and 3.0 browsers around.
-- Chris