Re: XMLNS in Inkscape and other editors

The thought process you're describing is a very dangerous way to
design a content sniffing algorithm.  These issues are quite subtle
and fragile.

In any case, the way to convince us to change the spec is to gather
data about the compatibility impact of the change.  Without data,
we're flying blind.

Adam


On Mon, Nov 23, 2009 at 11:36 AM, Joe D Williams <joedwil@earthlink.net> wrote:
>> the response is treated as text/plain
>
> We are using an html browser, so when we expect it is utf-8, then why not
> also expect that text/html is being sent?
> Especially if file begins with blank text, until unexpected character proves
> differently.
> Thanks,
> Joe
>
> ----- Original Message ----- From: "Adam Barth" <w3c@adambarth.com>
> To: "Joe D Williams" <joedwil@earthlink.net>
> Cc: "Julian Reschke" <julian.reschke@gmx.de>; "Boris Zbarsky"
> <bzbarsky@mit.edu>; "Gavin Carothers" <gavin@carothers.name>; "Maciej
> Stachowiak" <mjs@apple.com>; "HTMLwg" <public-html@w3.org>
> Sent: Monday, November 23, 2009 11:05 AM
> Subject: Re: XMLNS in Inkscape and other editors
>
>
>> On Mon, Nov 23, 2009 at 9:46 AM, Joe D Williams <joedwil@earthlink.net>
>> wrote:
>>>>
>>>> You're correct that BOMs are optional when you correctly specify the
>>>> media type of your content.
>>>
>>> Sorry if I'm off track or too limited in the definition, but no, I
>>> thought
>>> the BOM was optional if you intended to serve utf-8 regardless of the
>>> media
>>> type. Independent of anything else, if you get a utf-8 BOM, then you have
>>> utf-8. If you don't get a BOM it is also utf-8 (except for those media
>>> types
>>> that would never use utf-8?). Either way, in principle you know you have
>>> utf-8 (except for those media types that would never use utf-8?). .
>>
>> Indeed, which is why the response is treated as text/plain instead of
>> application/octet-stream.
>>
>> Adam
>
>

Received on Monday, 23 November 2009 19:41:21 UTC