I believe what he was saying (which makes sense to me, and I've submited
bug reports on it to both NCSA and Mosaic Comm. (should I send one to
Spry? :-)) is that the Accept header for inline images should be different
than the Accept header for regular references. That takes care of the
case where you can't handle Targa images. If you don't *want* to handle
them inline, then clearly it's up to the browser implementor to give the
user a way of specifying that seperately in the type->application prefs.
> >> o An extensions specification.
> >> This is most important for the HTML, although again it could apply
> >> 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
> >Ugh.
>
> Agreed. It seems like the HTML version, plus a "level" parameter would be
> sufficient. It won't determine every little feature supported on the
> client, but it will allow the level of support for standardized features
> to be determined by the server.
Okay, so you could do HTML/2.0+Mozilla
> >> scripts, but it doesn't really do much otherwise. So now you need
> >> to think about server smarts.
> >Which is where you get into problems with the above scheme. What's wrong
> >with giving each unique type a unique name (i.e. x-mozilla-html) That's
> >much easier than trying to make a server understand all kinds of different
> >pieces and how they might fit together (can you say AI).
>
> Seems to be the smartest thing to do, for experimental stuff like a
> document making heavy use of the new NetScape tags. In answer to those
> who say, "then we'll have 50 million 'x-<insert-client-name>-html' types",
> I say not really, because any tags of value will probably make their way
> into the standard, and will then become part of the level specifications.
The problem with having an entirely new type is that you now put the
onus on the user to add that type to their list of accepted ones, or
else you put them in a situation where their browser will claim not
to be able to read certain documents which in fact it could read, just
not well. HTML is upward compatible to some degree, and I shouldn't
be unable to read, say, a document that has a Table into it, at worst
I should get a warning (once please) that tells me there may be some
things that aren't supported.