- From: Benjamin Franz <snowhare@netimages.com>
- Date: Wed, 27 Aug 1997 16:46:52 -0700 (PDT)
- To: Ken Sykes <kensy@microsoft.com>
- cc: lcrocker@calweb.com, www-html@w3.org
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
Received on Wednesday, 27 August 1997 19:47:17 UTC