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

Re: String to ArrayBuffer

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 12 Jan 2012 09:59:20 -0700
Message-ID: <CACQ=j+dEifsWHXJ6uBBc7QnDd-KAUS3KSrPPSA_=hwyigr2hQA@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: 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 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.

Regarding use of the word "support" in the context of character encodings,
it would be useful if folks would explicitly qualify support as applying to
one of these three uses (interchange, runtime storage, persistent storage).
Received on Thursday, 12 January 2012 17:08:08 GMT

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