Re: [whatwg] Accessing local files with JavaScript portably and securely

On Wed, Apr 19, 2017 at 8:23 AM, Roger Hågensen wrote: > On 2017-04-19 11:28, Anne van Kesteren wrote: > >> I already pointed to https://wicg.github.io/entries-api/ as a way to >> get access to a directory of files and as a way to >> get access to a sequence of files.

Re: [whatwg] Persistent and temporary storage

On Mon, Mar 16, 2015 at 1:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Mar 13, 2015 at 5:06 PM, Joshua Bell jsb...@chromium.org wrote: A handful of us working on Chrome have been having similar discussions around what we've been calling durable storage. In its simplest model

Re: [whatwg] Persistent and temporary storage

Very timely! A handful of us working on Chrome have been having similar discussions around what we've been calling durable storage. In its simplest model a bit granted by the user to an origin, which then requires explicit user action before the data might be cleared under storage pressure, so it

[whatwg] AppCache error event details

We'd like to move forward on adding event details to AppCache errors. [1] I've fleshed out a proposal [2] that details the additions to the HTML spec. It introduces a new event type (ApplicationCacheErrorEvent) with reason (an enum), url, status, and message fields. Feedback would be

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

On Mon, Aug 12, 2013 at 4:50 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Aug 12, 2013 at 12:16 PM, Joshua Bell jsb...@google.com wrote: To recap history: early iterations of the Encoding API proposal did have base64 but it was removed with the suggestion to extend atob()/btoa() instead

Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

Back from a vacation, sorry about the late reply - hopefully still useful. On Wed, Aug 7, 2013 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote: On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu csh...@gmail.com wrote: If we plan to enhance the Encoding spec, I personally prefer a new pair of

Re: [whatwg] Adding a btoa overload that takes Uint8Array

On Mon, Mar 4, 2013 at 9:09 AM, Boris Zbarsky bzbar...@mit.edu wrote: The problem I'm trying to solve is sending Unicode text to consumers who need base64-encoded input. Right now the only sane way to do it (and I quote sane for obvious reasons) is something like the example at

Re: [whatwg] Encoding: API

, 2012 at 6:37 PM, Joshua Bell jsb...@chromium.org wrote: It sounds like there are several desirable behaviors: 1. ignore BOM handling entirely (BOM would be present in output, or fatal) 2. if matching BOM, consume; otherwise, ignore (mismatching BOM would be present in output, or fatal

Re: [whatwg] Encoding: API

On Wed, Oct 10, 2012 at 6:42 AM, Anne van Kesteren ann...@annevk.nl wrote: Hey, I was wondering whether it would make sense to define http://wiki.whatwg.org/wiki/StringEncoding as part of http://encoding.spec.whatwg.org/ Tying them together makes sense to me anyway and is similar to what we

Re: [whatwg] StringEncoding open issues

On Fri, Aug 17, 2012 at 5:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 17, 2012 at 7:15 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Aug 17, 2012 at 2:23 AM, Jonas Sicking jo...@sicking.cc wrote: - If encoding is utf-16 and the first bytes match 0xFF 0xFE or 0xFE

Re: [whatwg] StringEncoding open issues

On Mon, Sep 17, 2012 at 2:17 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Sep 17, 2012 at 11:13 PM, Joshua Bell jsb...@chromium.org wrote: I've attempted to distill the above into the spec in an algorithmic way: http://wiki.whatwg.org/wiki/StringEncoding#TextDecoder English

Re: [whatwg] StringEncoding open issues

On Wed, Aug 15, 2012 at 5:30 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Aug 14, 2012 at 12:34 PM, Joshua Bell jsb...@chromium.org wrote: - Create an encoder with TextDecoder() and if present a BOM will be respected (and consumed) otherwise default to UTF-8 Let's not default

Re: [whatwg] StringEncoding open issues

(not possible with eg. DOMString-SJIS). I don't feel strongly about this only because outputting UTF-16 is so rare to begin with. On Mon, Aug 6, 2012 at 1:29 PM, Joshua Bell jsb...@chromium.org wrote: - if the document is encoded in UTF-8, UTF-16LE or UTF-16BE and includes the byte order

Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder

Sorry if this is a dupe; I replied to this from my phone and an incorrect address, and my earlier reply isn't showing in the archives. On Fri, Aug 10, 2012 at 9:16 PM, Jonas Sicking jo...@sicking.cc wrote: The spec now contains the following text: NOTE: Because only UTF encodings are

Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder

On Wed, Aug 8, 2012 at 9:03 AM, Joshua Bell jsb...@chromium.org wrote: On Wed, Aug 8, 2012 at 2:48 AM, James Graham jgra...@opera.com wrote: On 08/07/2012 07:51 PM, Jonas Sicking wrote: I don't mind supporting *decoding* from basically any encoding that Anne's spec enumerates. I don't

Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder

On Wed, Aug 8, 2012 at 2:48 AM, James Graham jgra...@opera.com wrote: On 08/07/2012 07:51 PM, Jonas Sicking wrote: I don't mind supporting *decoding* from basically any encoding that Anne's spec enumerates. I don't see a downside with that since I suspect most implementations will just call

Re: [whatwg] StringEncoding: Allowed encodings for TextEncoder

On Tue, Aug 7, 2012 at 8:32 AM, Glenn Maynard gl...@zewt.org wrote: On Mon, Aug 6, 2012 at 11:39 PM, Jonas Sicking jo...@sicking.cc wrote: I seem to have a recollection that we discussed only allowing encoding to UTF8 and UTF16LE, UTF16BE. This in order to promote these formats as well as

Re: [whatwg] StringEncoding: encode() return type looks weird in the IDL

On Sun, Aug 5, 2012 at 11:44 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/5/12 1:39 PM, Glenn Maynard wrote: I didn't say it was extensibility, just a leftover from something that was either considered and dropped or forgotten about. Oh, I see. I thought you were talking about leaving

[whatwg] StringEncoding open issues

Regarding the API proposal at: http://wiki.whatwg.org/wiki/StringEncoding It looks like we've got some developer interest in implementing this, and need to nail down the open issues. I encourage folks to look over the Resolved issues in the wiki page and make sure the resolutions - gathered from

Re: [whatwg] StringEncoding: encode() return type looks weird in the IDL

On Sun, Aug 5, 2012 at 10:29 AM, Glenn Maynard gl...@zewt.org wrote: I guess the brokenness of Uint16Array (eg. the current lack of Uint16LEArray) could be sidestepped by just always returning Uint8Array, even if encoding to a 16-bit encoding (which is what it currently says to do). Maybe

Re: [whatwg] binary encoding

On Tue, Jun 12, 2012 at 2:29 AM, Simon Pieters sim...@opera.com wrote: On Mon, 11 Jun 2012 18:20:55 +0200, Joshua Bell jsb...@chromium.org wrote: http://wiki.whatwg.org/wiki/**StringEncodinghttp://wiki.whatwg.org/wiki/StringEncoding defines a binary encoding (basically the official

Re: [whatwg] binary encoding

On Mon, Jun 11, 2012 at 6:03 AM, Anne van Kesteren ann...@annevk.nl wrote: http://wiki.whatwg.org/wiki/StringEncoding ... hasn't been getting much attention from me recently. I'll recap the open issues and proposed resolutions to this list soonish. defines a binary encoding (basically the

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

Any further input on Kenneth's suggestions? Re: ArrayBufferView vs. DataView - I'm tempted to make the switch to just DataView. As discussed below, data parsing/serialization operations will tend to be associated with DataViews. As Glenn has mentioned elsewhere recently, it is possible to

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Sat, Mar 24, 2012 at 6:52 AM, Glenn Maynard gl...@zewt.org wrote: On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren ann...@opera.com wrote: Another way would be to have a second optional argument that indicates whether more bytes are coming (defaults to false), but I'm not sure of the

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Mon, Mar 26, 2012 at 2:42 PM, Anne van Kesteren ann...@opera.com wrote: On Mon, 26 Mar 2012 17:56:41 +0100, Joshua Bell jsb...@chromium.org wrote: Bikeshed: The |continues| term doesn't completely thrill me; it's clear in context, but not necessarily what someone might go searching

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Mon, Mar 26, 2012 at 4:12 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Mar 26, 2012 at 4:49 PM, Joshua Bell jsb...@chromium.org wrote: * A |stream| option, per the above Does this make sense when you're using stream: false to flush the stream? It's still a streaming operation. I

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Mon, Mar 26, 2012 at 6:24 PM, Glenn Maynard gl...@zewt.org wrote: I guess. It doesn't seem that important, since it's just a few lines of code. If this is done, I'd suggest that this helper API *not* have any special support for streaming (not to disallow it, but not to have any special

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Wed, Mar 21, 2012 at 12:42 PM, Anne van Kesteren ann...@opera.comwrote: On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking jo...@sicking.cc wrote: This leaves us with 2 or 3. So the question is if we should support streaming or not. I suspect doing so would be worth it. For

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Tue, Mar 20, 2012 at 7:26 AM, Glenn Maynard gl...@zewt.org wrote: On Mon, Mar 19, 2012 at 11:52 PM, Jonas Sicking jo...@sicking.cc wrote: Why are encodings different than other parts of the API where you indeed have to know what works and what doesn't. Do you memorize lists of

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Thu, Mar 15, 2012 at 5:20 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Mar 15, 2012 at 6:51 PM, Jonas Sicking jo...@sicking.cc wrote: What's the use-case for the stringLength function? You can't decode into an existing datastructure anyway, so you're ultimately forced to call decode at

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Fri, Mar 16, 2012 at 9:19 AM, Joshua Bell jsb...@chromium.org wrote: And just to be clear, the use case is decoding data formats where string fields are variable length null terminated. ... and the spec should include normative guidance that length-prefixing is strongly recommended

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Fri, Mar 16, 2012 at 10:35 AM, Glenn Maynard gl...@zewt.org wrote: On Fri, Mar 16, 2012 at 11:19 AM, Joshua Bell jsb...@chromium.org wrote: ... where output === view if view is supplied, otherwise a new Uint8Array (or Uint8ClampedArray??) Uint8Array is correct. (Uint8ClampedArray

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

FYI, I've updated http://wiki.whatwg.org/wiki/StringEncoding * Rewritten in terms of Anne's Encoding spec and WebIDL, for algorithms, encodings, and encoding selection, which greatly simplifies the spec. This implicitly adds support for all of the other encodings defined therein - we may still

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Wed, Mar 14, 2012 at 3:53 PM, Glenn Maynard gl...@zewt.org wrote: It's more than a naming problem. With this string API, one side of the conversion is always a DOMString. Base64 conversion wants ArrayBuffer-ArrayBuffer conversions, so it would belong in a separate API. Huh. The

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Mar 13, 2012 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: Something that has come up a couple of times with content authors lately has been the desire to convert an ArrayBuffer (or part thereof) into a

Re: [whatwg] API for encoding/decoding ArrayBuffers into text

On Tue, Mar 13, 2012 at 4:11 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Mar 13, 2012 at 5:49 PM, Jonas Sicking jo...@sicking.cc wrote: Something that has come up a couple of times with content authors lately has been the desire to convert an ArrayBuffer (or part thereof) into a

Re: [whatwg] Behavior when script is removed from DOM

On Wed, Dec 7, 2011 at 12:01 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Dec 7, 2011 at 11:27 AM, Adam van den Hoven a...@littlefyr.com wrote: On Sat, Dec 3, 2011 at 9:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Dec 3, 2011 at 7:38 PM, Yehuda Katz wyc...@gmail.com wrote:

Re: [whatwg] Specs for window.atob() and window.btoa()

On Sat, Feb 5, 2011 at 6:37 PM, Joshua Cranmer pidgeo...@verizon.netwrote: On 02/05/2011 08:29 PM, Jonas Sicking wrote: So my first question is, can someone give examples of sources of base64 data which contains whitespace? The best guess I have is base64-encoding MIME parts, which would be

Re: [whatwg] Specs for window.atob() and window.btoa()

On Fri, Jan 7, 2011 at 9:27 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Fri, Jan 7, 2011 at 12:01 AM, Boris Zbarsky bzbar...@mit.edu wrote: Note that it's not that uncommon to use atob on things that came from other base64-producing tools, not just from