I think based on bugs and bz's advice the Dwayne has been misled by bad
old pre-WebIDL API in Gecko -- there's no reason to do any
string-viewing here. Certainly not punning bytes as points in a
character set encoding.
/be
Anne van Kesteren <mailto:[email protected]>
January 11, 2014 8:27 AM
Note that iso-8859-1 maps to windows-1252. There is an open bug on
exposing a label to the API that has the "real" iso-8859-1 behavior:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23971
Boris Zbarsky <mailto:[email protected]>
January 10, 2014 1:40 PM
OK, so specify ISO-8859-1, if that's what you're really doing. Or are
you saying that you just want "ascii" to be a synonym for "iso-8859-1"
here? But it'd be a lie, because ASCII actually means something, and
it means something different from ISO-8859-1.
But really, if you just have bytes, not text, why are you generating a
string from those byte values at all? This is where a typed array
would make more sense...
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Dwayne <mailto:[email protected]>
January 10, 2014 1:29 PM
I'm curious. What would you expect such an option to do?
Byte-inflate like ISO-8859-1? Byte-inflate but throw on bytes
with values > 127? Act as a synonym for ISO-8859-9? Something else?
Exactly how StringView handles the option now. If I generate a random
string using byte values then each char in that string should
correspond to a single byte when specifying the ISO-8859-1. It doesn't
really make since to use UTF-8 for bytes when that data should be
manipulated as bytes in the first place. In the case of data being
represented as a string but need to be handled as bytes.
https://bugzilla.mozilla.org/show_bug.cgi?id=957424
UTF-8 being the default is not the problem of course. Throwing an
exception for ASCII is.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Boris Zbarsky <mailto:[email protected]>
January 10, 2014 1:14 PM
On 1/10/14 3:47 PM, Dwayne wrote:
Currently the Mozilla TextDecoder Web API does not accept ASCII as a
valid encoding option
I'm curious. What would you expect such an option to do?
Byte-inflate like ISO-8859-1? Byte-inflate but throw on bytes with
values > 127? Act as a synonym for ISO-8859-9? Something else?
and defaults to UTF-8, if left unspecified.
Right, because it's meant for text, and for text UTF-8 is a pretty
reasonable default nowadays.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Dwayne <mailto:[email protected]>
January 10, 2014 12:47 PM
I disagree. I think this should progress. It doesn't have to add any
additional functionality to Typed Arrays. As it stands I would
consider it a replacement for the purposes of TextEncoder and
TextDecoder APIs. Currently the Mozilla TextDecoder Web API does not
accept ASCII as a valid encoding option and defaults to UTF-8, if left
unspecified.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
