W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR2] Avoiding charset dependencies on user settings

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 23 Sep 2011 11:26:07 +0300
Message-ID: <CAJQvAufEO2bAZp+zyqd+TGUX+izDXnRv5_+GQ14gfi+q5b0MDQ@mail.gmail.com>
To: public-webapps@w3.org
On Thu, Sep 22, 2011 at 9:54 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> I agree that there are no legacy requirements on XHR here, however I
> don't think that that is the only thing that we should look at. We
> should also look at what makes the feature the most useful. A extreme
> counter-example would be that we could let XHR refuse to parse any
> HTML page that didn't pass a validator. While this wouldn't break any
> existing content, it would make HTML-in-XHR significantly less useful.

Applying all the legacy text/html craziness to XHR could break current
use of XHR to retrieve responseText of text/html resources (assuming
that we want responseText for text/html work like responseText for XML
in the sense that the same character encoding is used for responseText
and responseXML).

Applying all the legacy text/html craziness to XHR would make data
loading in programs fail in subtle and hard-to-debug ways depending on
the browser localization and user settings. At least when loading into
a browsing context, there's visual feedback of character misdecoding
and the feedback can be attributed back to a given file. If
setting-dependent misdecoding happens in the XHR data loading
machinery of an app, it's much harder to figure out what part of the
system the problem should be attributed to.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Friday, 23 September 2011 08:26:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT