Need a champion? StringView strawman

Brendan Eich brendan at mozilla.com
Sat Jan 11 08:53:09 PST 2014


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:annevk at annevk.nl>
> 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:bzbarsky at MIT.EDU>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Dwayne <mailto:rodneyd.teal at gmail.com>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Boris Zbarsky <mailto:bzbarsky at MIT.EDU>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Dwayne <mailto:rodneyd.teal at gmail.com>
> 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.
>
>
>


More information about the es-discuss mailing list