23971 2013-12-03 14:15:58 +0000 Define an encoding for formerly latin1 2014-11-04 15:04:13 +0000 1 1 1 Unclassified WHATWG Encoding unspecified PC All RESOLVED WONTFIX P2 normal Unsorted 1 annevk annevk hsivonen mike www-international sideshowbarker+encodingspec oldest_to_newest 97042 0 annevk 2013-12-03 14:15:58 +0000 The web does not have latin1, but we do need it for HTTP and stuff. We should probably also expose it to the API. "identity" makes some sense, but only in one direction. "bikeshed" also makes sense. We should not expose this encoding to HTTP charset= or <meta> overrides. This is only for internal matters (such as XMLHttpRequest) and developers using the API. 97047 1 hsivonen 2013-12-03 14:45:08 +0000 Would be good to see some pointers to HTTP code that actually uses de jure ISO-8859-1 and not windows-1252 decoding. Do you have pointers? 97048 2 annevk 2013-12-03 14:52:54 +0000 That's a good point. In XMLHttpRequest this is used for methods and headers. While most of that is restricted to 0x00 - 0x7F, header values can be pretty much any octet. 97517 3 annevk 2013-12-12 16:23:39 +0000 http://dump.testsuite.org/xhr/header-with-bytes.php is an example of that. Header has 0x80 as value. Comes out as U+0080 (and not as €). 104567 4 annevk 2014-04-28 15:24:52 +0000 "unicodelatin1" might be an acceptable name. Unicode refers to this block as "Latin-1 Supplement" so that does not seem too bad. 114488 5 annevk 2014-11-04 15:04:13 +0000 My understanding is that user agents have dedicated routines for original "latin1" type of conversion in the HTTP layer and potentially elsewhere. If we do indeed want something similar we should probably add statics on String and ArrayBuffer or some such for such conversion. The Encoding API can then remain for actual encodings only.