W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2012

Re: [whatwg] Encoding: API

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 19 Oct 2012 08:24:10 +0200
Message-ID: <CADnb78i=4gMcUYasfGbq9ja8BxyUc94wSf6Gh2YXiWRwFtP=gg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: WHATWG <whatwg@whatwg.org>, Joshua Bell <jsbell@chromium.org>
On Thu, Oct 18, 2012 at 4:16 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Thu, Oct 18, 2012 at 3:54 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> * TextDecoder.decode()'s view argument is no longer optional. Why should
>> it be?
> It buffers the "EOF byte" when in streaming mode, eg. when the last byte of
> the stream is a UTF-8 continuation byte, so any encode errors are triggered.
>> * TextEncoder.encode()'s input argument is no longer nullable. Again,
>> why should it be?
> Likewise for encoding, to flush errors for trailing high surrogates.

I made these arguments optional now (and named them both input). Note
however that the way you get the EOF byte/EOF code point is by
omitting the dictionary (whose stream member defaults to false), but I
can see how not passing any arguments as a final call is convenient.


>> I also raised the issue of whether TextEncoder should really support
>> utf-16/utf-16be as the encoding standard tries to deprecate non-utf-8
>> encodings.
> The whole point of this API is to support legacy file formats that use other
> encodings.  (It's probably questionable to not support other encodings, too,
> eg. filenames in ZIP file headers, but starting out with Unicode is fine.)

I thought it was mostly about reading legacy formats, but fair enough.

Received on Friday, 19 October 2012 06:27:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:46 UTC