Re: OBJECT's type attribute in 4.01

At 08:34 PM 27/08/99 -0400, Dmitry Beransky wrote:
>The 4.01 spec refines the definition of OBJECT'S TYPE attribute as follows:
>
>    If the value of this attribute differs from the HTTP
>    Content-Type returned by the server when the object is
>    retrieved, the HTTP Content-Type takes precedence.
>
>Could someone explain the reason it was decided that http takes precedence 
>over the local type value?
>
>I would guess that between the author and the server, the author knows 
>better what the object's type should be.

I disagree.  As an example, suppose that I run Foo Site where I use OBJECT
to inline GIF images (with permission) from the Weather Site.  I'd be using
type="image/gif" with my OBJECT.

Now suppose that Unisys comes after the Weather Site for using unlicensed
GIFs, so the Weather Site quickly changes all its GIFs to PNGs.  Now even
though my Foo Site still uses type="image/gif", the Weather Site is sending
a content-type of image/png.  While I should update my Foo Site, I
shouldn't need to coordinate that update with the Weather Site--the browser
should trust the Weather Site's specified content-type.

>Imagine, for example, that I want to experiment with SVG files, but my ISP 
>doesn't know anything about SVG, or they know that it's still an 
>experimental standard, or for any other reason don't want to change the 
>server configuration.  In the mean time, the server continues to send my 
>SVG files as plain/text.  What am I to do, short of switching to a 
>different ISP?

Tell your ISP that you will switch if they don't let you add a media type.
There are lots of ISPs that allow adding media types, and there's little
sense experimenting with an inflexible ISP.

-- 
Liam Quinn
A Real Validator for Windows, http://arealvalidator.com/
Web Design Group, http://www.htmlhelp.com/

Received on Monday, 30 August 1999 09:52:40 UTC