[whatwg] StringEncoding: Allowed encodings for TextEncoder
jsbell at chromium.org
Thu Aug 9 10:42:07 PDT 2012
On Wed, Aug 8, 2012 at 9:03 AM, Joshua Bell <jsbell at chromium.org> wrote:
> On Wed, Aug 8, 2012 at 2:48 AM, James Graham <jgraham at opera.com> wrote:
>> On 08/07/2012 07:51 PM, Jonas Sicking wrote:
>> I don't mind supporting *decoding* from basically any encoding that
>>> Anne's spec enumerates. I don't see a downside with that since I
>>> suspect most implementations will just call into a generic decoding
>>> backend anyway, and so supporting the same set of encodings as for
>>> other parts of the platform should be relatively easy.
>> However I think we should consider restricting support to a smaller
>>> set of encodings for while *encoding*. There should be little reason
>>> for people today to produce text in non-utf formats. We might even be
>>> able to get away with only supporting UTF8, though I wouldn't be
>>> surprised if there are reasonably modern file formats which use utf16.
>> FWIW, I agree with the decode-from-all-platform-**encodings
>> encode-to-utf[8|16] position.
> Any disagreement on limiting the supported encodings to utf-8, utf-16, and
> utf-16be, while permitting decoding of all encodings in the Encoding spec?
> (This eliminates the "what to do on encoding error" issue nicely, still
> need to resolve the BOM issue though.)
http://wiki.whatwg.org/wiki/StringEncoding has been updated to restrict the
supported encodings for encoding to UTF-8, UTF-16 and UTF-16BE.
I'm tempted to take it further to just UTF-8 and see if anyone complains.
Jury is still out on the decode-with-BOM issue - I need to reason through
Glenn's suggestions on the "open issues" thread.
I added a related open issue raised by Glenn, summarized as "... suggest
that the .encoding attribute simply return the name that was passed to
the constructor." - taking this further, perhaps the attribute should be
eliminated as callers could apply it themselves.
More information about the whatwg