[whatwg] "binary" encoding
jsbell at chromium.org
Mon Jun 11 09:20:55 PDT 2012
On Mon, Jun 11, 2012 at 6:03 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
... hasn't been getting much attention from me recently. I'll recap the
open issues and proposed resolutions to this list soonish.
> defines a binary encoding
> (basically the official iso-8859-1 where it is not mapped to
.... 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().
> Is it an idea to move that
> http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html somehow?
On its own, this use case is probably not strong enough to merit slipping a
pseudo-encoding into the platform, but...On its own, this use case is
probably not strong enough to merit slipping a pseudo-encoding into the
> do not think we want to give it an officially supported label, but it
> does make some sense to define it using the same infrastructure.
> http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html has the same need
> for converting certain types of DOMString.
... as there are other use cases then we should codify it. I have no
preferences as to label; the proposed JS API could specify a label for it,
but defer the specifics of the encoding to the Encoding spec. (I believe as
written I currently call out the special case that BOM detection should
never be done for "binary" which is already a special case, although BOM
detection vis-a-vis the API is itself an open issue)
More information about the whatwg