W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: String to ArrayBuffer

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 12 Jan 2012 09:54:34 -0800
Message-Id: <62BB5B2D-63AE-4067-9F4C-1162FEC187D7@jumis.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Henri Sivonen <hsivonen@iki.fi>, Kenneth Russell <kbr@google.com>, James Robinson <jamesr@google.com>, Webapps WG <public-webapps@w3.org>, Joshua Bell <jsbell@google.com>
To: Glenn Adams <glenn@skynav.com>
On Jan 12, 2012, at 9:17 AM, Glenn Adams <glenn@skynav.com> wrote:

> On Thu, Jan 12, 2012 at 10:10 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 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.
> 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.

Received on Thursday, 12 January 2012 19:41:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:30 UTC