- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 11 Jan 2012 15:12:09 -0800
- To: Charles Pritchard <chuck@jumis.com>
- Cc: James Robinson <jamesr@google.com>, Webapps WG <public-webapps@w3.org>, Joshua Bell <jsbell@google.com>
The StringEncoding proposal is the best path forward because it provides correct behavior in all cases. Adding String conversions directly to the typed array spec will introduce dependencies that are strongly undesirable, and make it much harder to implement the core spec. Hopefully Josh can provide an update on how the StringEncoding proposal is going. -Ken On Wed, Jan 11, 2012 at 3:05 PM, Charles Pritchard <chuck@jumis.com> wrote: > On 1/11/2012 2:49 PM, James Robinson wrote: > > > > On Wed, Jan 11, 2012 at 2:45 PM, Charles Pritchard <chuck@jumis.com> wrote: >> >> Currently, we can asynchronously use BlobBuilder with FileReader to get an >> array buffer from a string. >> We can of course, use code to convert String.fromCharCode into a >> Uint8Array, but it's ugly. >> >> The StringEncoding proposal seems a bit much for most web use: >> http://wiki.whatwg.org/wiki/StringEncoding >> >> All we really ever do is work on DOMString, and that's covered by UTF8. > > > DOMString is not UTF8 or necessarily unicode. It's a sequence of 16 bit > integers and a length. > > > > To clarify, I'd want ArrayBuffer(DOMString) to work with unicode and throw > an error if the DOMString is not valid unicode. > This is consistent with other Web Apps APIs. > > For feature detection, the method should be wrapped in a try-catch block > anyway. > > -Charles
Received on Wednesday, 11 January 2012 23:19:46 UTC