[6186] in www-talk@info.cern.ch
Re: Netscape v NCSA, Progress?
daemon@ATHENA.MIT.EDU (Larry Masinter)
Mon Oct 17 23:42:32 1994
Date: Tue, 18 Oct 1994 04:40:38 +0100
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: masinter@parc.xerox.com
From: Larry Masinter <masinter@parc.xerox.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
> I am far less concerned with whether or not they did the right thing
> than with how I'm going to support both styles of browsers. The
> benefits of the extensions are hard to ignore, but I have no clean
> way of telling whether a browser can support them.
The problem is that
accept: text/html
doesn't indicate which version/profile/release/level of "html" you
want. This is a problem for html now, but it's also a problem for
application/postscript in the face of Postscript level 2, for
image/gif in the face of embedded JPEG in GIF94, or even in the
negotiation over color, black & white, embedded images, etc.
I urge everyone to avoid releasing documents that use non-standard
extensions to HTML *as* HTML. If people want to extend their browsers
to accept some other document type, that would be lovely.
I urge Mosaic Communication Corp to 'fix' Mozilla to include a header:
accept: text/x-mozilla-html
and to fix their server to label their extended documents in that
form; this would allow servers to conditionally release different
documents depending on the content type, just as the web was
originally designed.
This would is a responsible and compatible way of releasing
experimental and non-standard extensions to HTML in any browser.
Don't call it 'html' until it actually *is* HTML.
If you want to infer that file:///localhost/foo.html is really
content-type text/x-mozilla-html, that's fine, too.
You know, there's good reason to get new features out for experimental
use! It's just that it's really easy to do in a way that is actually
compatible with the standards that are already released.
