No, you don't need to send a bug report to Spry. AIR Mosaic does indeed only
send Accept: headers for the inline image types (currently only image/gif and
image/xbm) that it knows how to handle. :^) However, this does NOT solve
the problem in the long run. What happens when we move to a system that
requests the document _AND_ its components (e.g. inline images) via either an
MGET or a smart server with multipart MIME handling? At that point, we are
requesting a generic "document", and if it is an HTML document we want to get
its inlined images in the same multipart message, and we need to specify
which types we can handle internally, but if the whole document is an image
of a type we don't handle internally, we need to have our Accept: headers set
up for all the image types we handle externally.
>> >> 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.
> ...
>Okay, so you could do HTML/2.0+Mozilla
>...
>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.
You've just kind of contradicted yourself - doing an "HTML/2.0+Mozilla"
scheme would also require the user deliberately specifying that their
browser can handle those extensions, so where's the win? At any rate,
the only difference is whether you are trying to create a way for
browsers to specify to the server that they handle arbitrary
extensions to HTML. I'd rather NOT create that process, because I
believe doing so would take the some of the pressure off the HTML
standardization process. Hey, if somebody comes up with a cool new
feature, great, let's work it into HTML, if it can be agreed upon. If
not, then it probably doesn't belong in HTML. Realistically speaking,
we're not arguing about "experimental" tags here - I couldn't care
less if someone puts a document on their server and serves it up as
"text/html" with a few tags that they're trying out in their new
browser. We're talking about the process by which HTML itself
changes. I strongly believe that we MUST keep a strong core standard
in order for the WWW to not degenerate into chaos in terms of document
format standards, and facilitating an EASY method by which browser
authors can thumb their nose at the rest of the HTML design process
is not high on my list of priorities. I understand the difficulties
at this point for many software authors - MCOM and SPRY included -
who want to add new features to the Web. No problem, but let's
a) channel some of that driving force into driving the standards
(the faster the web grows, the better for SPRY, even if MCOM is
doing some of the driving :^), and b) mark newly-developed features
as experimental until they're ratified as "standard".
-Chris Wilson
:::::::::::::::::::::<<< NETWORKING THE DESKTOP >>>::::::::::::::::::::
Chris Wilson Spry, Inc.
WWW Technology Lead 316 Occidental Avenue S. 2nd Floor
Email: cwilson@spry.com Seattle, WA 98104
Phone: (206) 447-0300 FAX: (206) 447-9008
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::