- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 12 Aug 2013 18:27:04 +0100
- To: Joshua Bell <jsbell@google.com>, Jonas Sicking <jonas@sicking.cc>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, kg@luminance.org, Chang Shu <cshu01@gmail.com>
On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell <jsbell@google.com> wrote:
> FWIW, I've landed an experimental (behind a flag) implementation of the API
> in Blink/Chromium; changing it is definitely possible for us. I believe Moz
> is shipping it web-exposed already in FF?
Yes, since Firefox 18 (since Firefox 20 in workers).
> To recap history: early iterations of the Encoding API proposal did have
> base64 but it was removed with the suggestion to extend atob()/btoa()
> instead, and due to the confusion around the encode/decode verbs. If the
> APIs were something like StringToBytesConverter::convert() and
> BytesToStringConverter::convert() it would make more sense for encoding of
> both text (use StringToBytes) and binary data (use BytesToString).
I can't really speak for Gecko, but I suspect we wouldn't like
changing it over half a year after deploying it. Jonas?
> While we're re-opening this can of worms, there's been a request to add a
> flush() method to the TextEncoder/TextDecoder objects, which would behave
> the same as calling encode(null, {stream: false}) / decode(null,
> {stream:false}) but make the code more readable. This fails the "adding a
> new method for something that behaves exactly like something we already
> have" test. Opinions?
Adding that seems fine.
--
http://annevankesteren.nl/
Received on Monday, 12 August 2013 17:27:29 UTC