Re: [whatwg/encoding] Allow conformant implementations to support non-UTF-8 encodings (#144)

>> The Encoding Standard seeks to be normative over Web browsers. In the context of Web browsers, it would be bad to suggest that browsers can support other encodings, because that would result in Web content that's browsable in some browsers but not others. Importantly, additional encodings don't add any expressiveness to platform over UTF-8 anyway, since everything decodes to Unicode.
>
> The suggestion that huge parts of the web, which were created (in "good faith") using non-UTF-8 charset encoding, and continue to be created that way, should be made non-browsable so as to make browser behavior uniform, seems bizarre and, frankly, somewhat offensive. (And that's doubly the case considering how additional charset encodings are to be added in the future anyway.)

To be clear, in the text you quoted from me "other encodings" means encodings other than the ones defined in the Encoding Standard, i.e. I was responding to your suggestion of "voluntarily" supporting even more encodings. I didn't mean "other encodings" in the sense of encodings other than UTF-8. The purpose of defining non-UTF-8 encodings in the Encoding Standard is to keep legacy Web content working.

As for `TextEncoder`, it's not a legacy API. It's a new API. It's not the purpose of the Encoding Standard to facilitate the creation of new non-UTF-8 data.

So if you are implementing an email client in JS, `TextDecoder` gives you consumption everything except UTF-7, which you need to implement yourself. `TextEncoder` gives you emission of UTF-8. It's not a good idea to _send_ email in non-UTF-8 encodings these days even if it's necessary to be able to _receive_ non-UTF-8 emails.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/encoding/issues/144#issuecomment-390466383