- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 12 Jan 2012 09:10:39 -0800
- To: Glenn Adams <glenn@skynav.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, Kenneth Russell <kbr@google.com>, Charles Pritchard <chuck@jumis.com>, James Robinson <jamesr@google.com>, Webapps WG <public-webapps@w3.org>, Joshua Bell <jsbell@google.com>
On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams <glenn@skynav.com> wrote: > On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen <hsivonen@iki.fi> wrote: >> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell <kbr@google.com> wrote: >> > The StringEncoding proposal is the best path forward because it >> > provides correct behavior in all cases. >> >> Do you mean this one? http://wiki.whatwg.org/wiki/StringEncoding >> >> I see the following problems after a cursory glance: >> 4) It says "Browsers MAY support additional encodings." This is a >> huge non-interoperability loophole. The spec should have a small and >> fixed set of supported encodings that everyone MUST support and >> supporting other encodings should be a "MUST NOT". > > > In practice, it will be impractical if not impossible to enforce such a > dictum "MUST NOT support other encodings". Implementers will support > whatever they like when it comes to character encodings, both for > interchange, runtime storage, and persistent storage. Actually, such requirements often work relatively well. Many implementors recognize the pain caused by race-to-the-bottom support for random encodings. ~TJ
Received on Thursday, 12 January 2012 17:19:00 UTC