W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: HTML5 vs content type sniffing

From: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>
Date: Fri, 25 Jan 2008 23:22:15 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf-http-wg@w3.org
Message-ID: <20080125222215.GZ1632@polar.elf12.net>

On Fri, Jan 25, 2008 at 01:00:47PM +0100, Julian Reschke wrote:
> Frank Ellermann wrote:
> >Julian Reschke wrote:
> > 
> >>So, please have a look at
> >>   <http://www.hixie.ch/tests/adhoc/http/content-type/sniffing/>
> >>and supply feedback on the expected results
> >
> >I don't understand test case 11, I'd expect the same outcome as
> >for cases 9 and 10.
> That's because HTML5 tries to restrict content sniffing to precisely 
> three content type header values, see 
> <http://www.w3.org/TR/2008/WD-html5-20080122/#content-type-sniffing>.

That's the best: html5 rules over what "text/plain" really means.

Apart from that, I would like to ask you all:

a) Which Content-Type makes pretty clear that the entity should be shown 
   "as-is" in a specified encoding?
   (Meaning: show anything as something character like, exception: make 
   line breaks (where? In case of doubt, make one))
   [my "as-is" is what browsers do when showing "text without 

b) I request that any browser offers a possibility to show whatever it 
   receives "as-is" (as described in a)), the same way a browser can be 
   made to save whatever it receives in a file.
   Having a browser like that: what is the difference in
   "text/plain" being interpreted as "text/plain" or 
   [see html5 content sniffing to know why I care]
   The only difference I see is wheter I get the "save as" dialog 
   automatically or not...

c) Knowing that it is easy to make a browser treat something as 
   "application/octet-stream", but that it is not easy to make it handle 
   content as "text/plain" (or "as-is"): Is it desirable to make a 
   browser treat "text/plain" labled stuff as 

Received on Friday, 25 January 2008 22:21:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC