Re: PNG support in IE4

Benjamin Franz (snowhare@netimages.com)
Wed, 27 Aug 1997 16:46:52 -0700 (PDT)


Date: Wed, 27 Aug 1997 16:46:52 -0700 (PDT)
From: Benjamin Franz <snowhare@netimages.com>
To: Ken Sykes <kensy@microsoft.com>
cc: lcrocker@calweb.com, www-html@w3.org
In-Reply-To: <E06360A02932CF118DA700805F14932705581870@RED-72-MSG.dns.microsoft.com>
Message-ID: <Pine.LNX.3.96.970827161605.28568B-100000@ns.viet.net>
Subject: RE: PNG support in IE4

On Wed, 27 Aug 1997, Ken Sykes wrote:

> 
> The syntax above works properly in current builds but was broken in PP2.
> Looking for the plugin is the correct thing to do here as the site
> author may want custom behavior for the data.  This is similar to how we
> deal with suggested MIME types from the server: if the server specifies
> the MIME type we don't second guess based on sniffing.  If the OBJECT
> tag doesn't find a plugin the builtin support will take over and render
> the image.

Have you fixed the 'always make a scrolling window with a border and
render images at a fixed size that seems to be independant of the actual
image size in that window with a minimum 20 pixels of white space around
it' bug? This alone makes OBJECT nearly useless in practice for even gif
and jpeg.

> >Also, IE4 does not send image/png in its HTTP-Accept headers, so
> >you can't do content negotiation either.  Finally, neither gamma
> >correction for color matching or partial transparency is supported.
> >In short, IE4 may claim to "support" PNG, but the claim is hollow.
> 
> We send */* at the end of our accept header list so there shouldn't be
> anything preventing PNG files from being sent.

Ok - my site has content type
'image/sooperdooperbuttotalllyunsupportedgraphicformat' available. I can
now safely send it to your browser with the assumption that you will
*SOMEHOW* render it usefully? '*/*' means dadda as far as content
negotiation is concerned. I see no reason to not just go: Accept: */* and
be done with it under your argument. (image/jpeg? image/gif?  text/html?
Why? '*/*' covers it all.) 

Without at least a *HINT* that you can render a given format, it will
simply never be sent. Commercial sites can't afford to throw things at
browsers that may not be handled. It has to work *ALL* the time. Not the
1% of the time a person just happens to have the plug in already. (And
ActiveX is *not* a solution. Even *IF* people trusted sites enough to let
them install random native code on their systems and were patient enough
to 200K of software to view a 20K image, the percentage of people using
browsers *capable* of doing so is under 40%).

> I'm not familiar with
> all the issues here but our current list is the result of compatibility
> testing over the last 6-12 months.  My understanding is the accept
> headers are generally ignored.

That is because of NS and MS sending nothing useful in them. If you don't
send anything useful in them - OF COURSE they get ignored. We *KNOW* that
as near to 100% of browsers as makes no difference support text/html,
image/jpeg and image/gif. Sending *THAT* information tells us nearly
nothing we don't already know. Sending '*/*' makes no sense at all. It
makes the Accept header a *meaningless* wastage of bytes. It might as well
not be sent at all as be sent with a undifferentiated '*/*' tacked on. The
'*/*' doesn't tell us *anything*. 

-- 
Benjamin Franz