On Jan 12, 2012, at 9:17 AM, Glenn Adams <[email protected]> wrote: > > > On Thu, Jan 12, 2012 at 10:10 AM, Tab Atkins Jr. <[email protected]> wrote: > On Thu, Jan 12, 2012 at 8:59 AM, Glenn Adams <[email protected]> wrote: > > On Thu, Jan 12, 2012 at 3:49 AM, Henri Sivonen <[email protected]> wrote: > >> On Thu, Jan 12, 2012 at 1:12 AM, Kenneth Russell <[email protected]> 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. > > I speak of enforcement. Will there be test cases to check for support of a > random encoding not included in a blessed list? I suspect not.
If it is an issue, an array of strings from a getSupportedEncodings method would solve that one. I don't see it being a particularly bad thing if vendors expose more translation encodings. I've only come across one project that would use them. Binary and utf8 handle everything else I've come across, and I can use them to build character maps for the rest, if I ever hit another strange project that needs them. -Charles
