Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder

On Mon, Aug 6, 2012 at 11:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> I seem to have a recollection that we discussed only allowing encoding
> to UTF8 and UTF16LE, UTF16BE. This in order to promote these formats
> as well as stay in sync with other APIs like XMLHttpRequest.
>

Not an objection, but where does XHR limit sent data to those encodings?
send(FormData) forces UTF-8 (which is even more restrictive);
send(Document) seems to allow any encoding *except* for UTF-16 (presumably
web compat since that's a weird criteria).

I'm not sure that staying in sync with XHR--which has its own pile of
legacy code to support--is worthwhile here anyway, but limiting to Unicode
seems fine in its own right, especially since the restriction can always be
lifted later if real needs come up.

However I currently can't find any restrictions on which target
> encodings are supported in the current drafts.
>
> One wrinkle in this is if we want to support arbitrary encodings when
> encoding, that means that we can't use "insert a the replacement
> character" as default error handling since that isn't available in a
> lot of encoding formats.
>

I don't think this part is a real hurdle.  Just replace with "?" for
non-Unicode encodings.


On Tue, Aug 7, 2012 at 8:10 AM, Joshua Cranmer <Pidgeot18@verizon.net>wrote:

> I found that the wiki version of the proposal cites <
> http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html> as the way to
> find encodings.
>

That spec documents the encodings which are used anywhere in the platform,
but that doesn't necessarily mean every API needs to support all those
encodings.  It's almost all backwards-compatibility.

-- 
Glenn Maynard

Received on Tuesday, 7 August 2012 14:33:15 UTC