- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 23 Sep 2011 11:26:07 +0300
- 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 UTC