- From: Joshua Bell <jsbell@chromium.org>
- Date: Wed, 11 Jan 2012 15:49:54 -0800
- To: Webapps WG <public-webapps@w3.org>
- Message-ID: <CAD649j64LQXiHqY=m-s9airCZtHVPGkN-gau5-SpUH4GXC4dmg@mail.gmail.com>
On Wed, Jan 11, 2012 at 3:12 PM, Kenneth Russell <kbr@google.com> wrote: > 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 > Thanks for the cue, Ken. :) As background for folks on public-webapps, the StringEncoding proposal linked to by Charles grew out of similar discussions to this in on the public_webgl@khronos.org discussion. The most recent thread can be found at http://www.khronos.org/webgl/public-mailing-list/archives/1111/msg00017.html If you read that thread it should be clear why the proposal is as "heavy" as it is (although, being mired in IndexedDB lately, it looks so tiny). Dealing with text encoding is also never as trivial or easy as it seems. As far as current status: I haven't done much work on the proposal in the last month or so, but plan to pick that up again soon, and it should be shopped around for the appropriate WG (public-webapps or otherwise) for feedback, gauging implementer interest, etc. Anne's work over on whatwg around encoding detection and BOM handling in browsers is valuable so I've been watching that closely, although this is a new API and callers will have access to the raw bits so we don't have to spec the kitchen sink or match legacy behavior. There are a few open issues called out in the proposal, perhaps most notably the default handling of invalid data. > > 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:50:31 UTC