- From: Joshua Bell <jsbell@chromium.org>
- Date: Mon, 11 Jun 2012 09:20:55 -0700
- To: WHATWG <whatwg@whatwg.org>
On Mon, Jun 11, 2012 at 6:03 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > http://wiki.whatwg.org/wiki/StringEncoding ... 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 > 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(). > 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 platform, but... > I > 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)
Received on Monday, 11 June 2012 16:22:17 UTC