A few thoughts.
Using a different type is not sufficient, as you say, different
browsers will add different pieces. Inline jpeg is a prime example,
but that can be addressed in a different manner.
I'm new to this discussion group, I've been writing HTML for almost
a year, but I only recently broke away from my previous job to do this
full time - my apologies if I'm treading on previoiusly discussed
territory.
I think we need the following:
o Accept-inline:
That should handle the issue of inline jpeg, as well as future
possibilities such as structured graphics, postscript, epsf and rtf.
o A version flag somewhere in the protocol
This is a MIME problem really, and I used to get in arguments over it
when that standard was being written and I was writing email software
in a previous life. This could just be for the HTML, but it sure would
be nice if you could tag every type you recognized with a version.
o An extensions specification.
This is most important for the HTML, although again it could apply
to other types. I guess what makes most sense to me here is that
anyone who comes up with a new revision of HTML subdivides it into
portions that they think it is likely or reasonable that someone
might implement in part. So if we thought of Mozilla's HTML as
being a full revision, then they might split off the image alignment
attributes into one extension part, mailto into another, and bundle
the rest. So then you might have a browser that supported (this
isn't a syntax, it's a concept) HTML/2.0+IMG_ALIGN/1.0+MAILTO/1.0
That's all find and dandy, and it's clearly helpful to your CGI
scripts, but it doesn't really do much otherwise. So now you need
to think about server smarts.
I would argue that the server needs to be able to do multiple files
for a URL already. I would love to store all my non-inlined images
in JPEG format, and if I get a request from a user who doesn't have
JPEG support. I would send them the GIF version (maybe even built
on the fly and then cached). Ditto for inline images. This is
kind of multi-part alternative where I send them the right alternative
and just that alternative.
Given that ability, it would be relatively straightforward to have
alternative HTML files as well. The server config could indicate
which file ending refered to which extensions, and then it could
choose the best fit.
Multiple files is a pain for the web site developer though. An
alternative would be to allow conditional code in a parsed HTML
file. If the processing demands are too high you could either
manually preprocess the file, or parse it once on first request
and cache the resulting alternative.
None of those options are very pretty. I'll be very interested to
see if any of the forthcoming commercial servers attempt to deal
with any of these problems.
P.S. My last message to this list somehow had all the Mime headers
duplicated, which made it impossible for me to read, and apparently
crashed a few mime mail applications. Hopefully this one won't do
the same. If anyone has any clues, please let me know.