On Mon, Aug 6, 2012 at 11:39 PM, Jonas Sicking <jo...@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 <pidgeo...@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
