- From: Joshua Bell <jsbell@chromium.org>
- Date: Tue, 12 Jun 2012 11:45:57 -0700
- To: WHATWG <whatwg@whatwg.org>
On Tue, Jun 12, 2012 at 2:29 AM, Simon Pieters <simonp@opera.com> wrote: > On Mon, 11 Jun 2012 18:20:55 +0200, Joshua Bell <jsbell@chromium.org> > wrote: > > http://wiki.whatwg.org/wiki/**StringEncoding<http://wiki.whatwg.org/wiki/StringEncoding> >>> >> > defines a binary encoding >>> (basically the official iso-8859-1 where it is not mapped to >>> windows-1252). >>> >> >> >> .... which is residue from earlier iterations. Intended use case was >> interop with legacy JS that used the lower 8 bits of strings to hold >> binary >> data, e.g. with APIs like atob()/btoa(). >> > > I think we should drop this and extend atob() and btoa() to be able to > convert base64 strings to ArrayBuffer[View?] and back directly. Agreed (I wanted a little more consensus before removing it). Now that we can get binary data into script directly will there still be active use of base64 + ArrayBuffers that will benefit from platform support? Anyone want to tackle specifying the atob/btoa extensions? As a strawman: partial interface ArrayBufferView { DOMString toBase64(); }; partial interface ArrayBuffer { static ArrayBuffer fromBase64(DOMString string); }; These don't handle data streaming scenarios, however. (This is completely orthogonal to Anne's question about whether a "binary" encoding should be specified somewhere to describe current implementations.)
Received on Tuesday, 12 June 2012 18:46:34 UTC