Intent to Implement and Ship: new FormData methods

193 views
Skip to first unread message

Joshua Bell

unread,
Sep 15, 2014, 3:17:47 PM9/15/14
to blink-dev

Contact emails

jsb...@chromium.org


Spec

http://xhr.spec.whatwg.org/#interface-formdata


Summary

The FormData object allows pages to programmatically construct a list of key/value entries that can be submitted via XHR just like an HTML form. Previously, the object was write-only via a single append() method.


The spec was fleshed out to add has(), get(), getAll(), delete(), and set() methods to allow inspection and modification.


Motivation

Discussion:

http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0370.html

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22680


TL;DR: Added in anticipation of using FormData as a response type from XHR/Fetch, making inspection of HTML form data easier, and potentially persisting the data/applying it to an HTML form later. Practically speaking, this also makes the object easier to test from script.


Definitely not high priority since most of the uses are aspirational.


Compatibility Risk

Medium. 


Risk: None of the other browsers ship this yet. Moz doesn't even have a tracking bug.


Risk: The new methods have not yet made it into the W3C copy of the spec.


Risk: Note that there's no way to enumerate the entries with the new method; it's anticipated that'll be done via ES6 Iterators (spec blocked on Web IDL growing some annotations for that). So there will be further additions to the interface.


Mitigation: The interface ends up being very similar to URLSearchParams (https://url.spec.whatwg.org/#interface-urlsearchparams - Blink hasn't implemented that yet either), which at least indicates it's a common pattern. It's also based on ES6's Map but has getAll() since multiple entries can have the same key; keys are also restricted to just strings.


A polyfill for this is plausible: (1) implement a pure-JS FormData polyfill, (2) hook XHR's send(), detect the polyfill, copy the entries into a native FormData, and send() that.


Ongoing technical constraints

None. Purely additive to the existing FormData implementation. Patch is pretty straightforward.


Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yep.


OWP launch tracking bug?

Nope. Seems pretty minor.


Link to entry on the feature dashboard

Nope. Ditto. If there was another implementation out there it probably wouldn't be worth sending this "intent". But since there's not...


Requesting approval to ship?

Yep!


But.... we could plop the methods behind --experimental-web-platform-features (i.e. just Implement, but not Ship) if there's any concern about "going first", and we can wait a few releases and/or until we get another implementation out there.

Erik Arvidsson

unread,
Sep 15, 2014, 3:28:19 PM9/15/14
to Joshua Bell, blink-dev
On Mon, Sep 15, 2014 at 3:17 PM, 'Joshua Bell' via blink-dev <blin...@chromium.org> wrote:

Contact emails

jsb...@chromium.org


Spec

http://xhr.spec.whatwg.org/#interface-formdata


Summary

The FormData object allows pages to programmatically construct a list of key/value entries that can be submitted via XHR just like an HTML form. Previously, the object was write-only via a single append() method.


The spec was fleshed out to add has(), get(), getAll(), delete(), and set() methods to allow inspection and modification.


Motivation

Discussion:

http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0370.html

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22680


TL;DR: Added in anticipation of using FormData as a response type from XHR/Fetch, making inspection of HTML form data easier, and potentially persisting the data/applying it to an HTML form later. Practically speaking, this also makes the object easier to test from script.


Definitely not high priority since most of the uses are aspirational.


Compatibility Risk

Medium. 


Risk: None of the other browsers ship this yet. Moz doesn't even have a tracking bug.


Risk: The new methods have not yet made it into the W3C copy of the spec.


Risk: Note that there's no way to enumerate the entries with the new method; it's anticipated that'll be done via ES6 Iterators (spec blocked on Web IDL growing some annotations for that). So there will be further additions to the interface.


Since we are shipping with for-of and Symbol.iterator we should make iteration a checkbox when shipping new collections.

We also have binding support for iterators now:

 

Mitigation: The interface ends up being very similar to URLSearchParams (https://url.spec.whatwg.org/#interface-urlsearchparams - Blink hasn't implemented that yet either), which at least indicates it's a common pattern. It's also based on ES6's Map but has getAll() since multiple entries can have the same key; keys are also restricted to just strings.


We have a CL for this but it is blocked on oilpan.

 


A polyfill for this is plausible: (1) implement a pure-JS FormData polyfill, (2) hook XHR's send(), detect the polyfill, copy the entries into a native FormData, and send() that.


Ongoing technical constraints

None. Purely additive to the existing FormData implementation. Patch is pretty straightforward.


Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yep.


OWP launch tracking bug?

Nope. Seems pretty minor.


Link to entry on the feature dashboard

Nope. Ditto. If there was another implementation out there it probably wouldn't be worth sending this "intent". But since there's not...


Requesting approval to ship?

Yep!


But.... we could plop the methods behind --experimental-web-platform-features (i.e. just Implement, but not Ship) if there's any concern about "going first", and we can wait a few releases and/or until we get another implementation out there.




--
erik


Joshua Bell

unread,
Sep 15, 2014, 4:21:09 PM9/15/14
to Erik Arvidsson, blink-dev
On Mon, Sep 15, 2014 at 12:27 PM, Erik Arvidsson <a...@chromium.org> wrote:


On Mon, Sep 15, 2014 at 3:17 PM, 'Joshua Bell' via blink-dev <blin...@chromium.org> wrote:

Contact emails

jsb...@chromium.org


Spec

http://xhr.spec.whatwg.org/#interface-formdata


Summary

The FormData object allows pages to programmatically construct a list of key/value entries that can be submitted via XHR just like an HTML form. Previously, the object was write-only via a single append() method.


The spec was fleshed out to add has(), get(), getAll(), delete(), and set() methods to allow inspection and modification.


Motivation

Discussion:

http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0370.html

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22680


TL;DR: Added in anticipation of using FormData as a response type from XHR/Fetch, making inspection of HTML form data easier, and potentially persisting the data/applying it to an HTML form later. Practically speaking, this also makes the object easier to test from script.


Definitely not high priority since most of the uses are aspirational.


Compatibility Risk

Medium. 


Risk: None of the other browsers ship this yet. Moz doesn't even have a tracking bug.


Risk: The new methods have not yet made it into the W3C copy of the spec.


Risk: Note that there's no way to enumerate the entries with the new method; it's anticipated that'll be done via ES6 Iterators (spec blocked on Web IDL growing some annotations for that). So there will be further additions to the interface.


Since we are shipping with for-of and Symbol.iterator we should make iteration a checkbox when shipping new collections.

SGTM. Perhaps land this behind the --experimental-blah-blah flag with iterator support, and at least wait for the spec to catch up?

Eric Seidel

unread,
Sep 15, 2014, 9:35:11 PM9/15/14
to Joshua Bell, Erik Arvidsson, blink-dev
I would make this runtime switchable regardless.
RuntimeEnabledFeatures are super-cheap to add:
http://blink.lc/blink/tree/Source/platform/RuntimeEnabledFeatures.in
And are useful for separating implementation decisions from shipping
decisions. :)

FormData seems super-well fit for Blink-in-JS once we get there. It's
entire purpose appears to be a data-pickler...

IMO we should implement these now and wait until we're done
implementing to make a shipping decision. But I don't feel strongly
one way or another.

On Mon, Sep 15, 2014 at 1:21 PM, 'Joshua Bell' via blink-dev

Sigbjorn Finne

unread,
Sep 16, 2014, 2:00:20 AM9/16/14
to Joshua Bell, blink-dev
lgtm, it rounds out that interface.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20038#c2 sort of covers
iterator support on the spec side. Perhaps there have been progress on
that front since then?

--sigbjorn
> Risk: Note that there's no way to *enumerate* the entries with the new
> method; it's anticipated that'll be done via ES6 Iterators (spec blocked on
> Web IDL growing some annotations for that). So there will be further
> additions to the interface.
>
> Mitigation: The interface ends up being very similar to URLSearchParams (
> https://url.spec.whatwg.org/#interface-urlsearchparams - Blink hasn't
> implemented that yet either), which at least indicates it's a common
> pattern. It's also based on ES6's Map but has getAll() since multiple
> entries can have the same key; keys are also restricted to just strings.
>
>
> A polyfill for this is plausible: (1) implement a pure-JS FormData
> polyfill, (2) hook XHR's send(), detect the polyfill, copy the entries into
> a native FormData, and send() that.
>
>
> Ongoing technical constraints
>
> None. Purely additive to the existing FormData implementation. Patch is
> pretty straightforward.
>
>
> Will this feature be supported on all five Blink platforms (Windows, Mac,
> Linux, Chrome OS and Android)?
>
> Yep.
>
> OWP launch tracking bug?
>
> Nope. Seems pretty minor.
>
>
> Link to entry on the feature dashboard <http://www.chromestatus.com/>
>
> Nope. Ditto. If there was another implementation out there it probably
> wouldn't be worth sending this "intent". But since there's not...
>
>
> Requesting approval to ship?
>
> Yep!
>
>
> But.... we could plop the methods behind
> --experimental-web-platform-features (i.e. just Implement, but not Ship) if
> there's any concern about "going first", and we can wait a few releases
> and/or until we get another implementation out there.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
>

Daniel Bratell

unread,
Sep 16, 2014, 5:31:07 AM9/16/14
to blink-dev, Joshua Bell
On Mon, 15 Sep 2014 21:17:43 +0200, 'Joshua Bell' via blink-dev
<blin...@chromium.org> wrote:

> Risk: None of the other browsers ship this yet. Moz doesn't even have a
> tracking bug.

Opera shipped this feature for a while, before we switched to Chromium, if
you want an implementation to compare with. I don't know if the spec is
the same or not now compared to two years ago though (this would be Opera
12.1x).

/Daniel

Daniel Bratell

unread,
Sep 16, 2014, 5:42:10 AM9/16/14
to blink-dev, Joshua Bell
On Tue, 16 Sep 2014 11:30:52 +0200, Daniel Bratell <bra...@opera.com>
wrote:
And sof correctly pointed out to me that this thread was about additions
to the FormData API, not the FormData object itself which is already well
supported. So ignore me.

/Daniel

Dimitri Glazkov

unread,
Sep 16, 2014, 10:48:36 AM9/16/14
to Daniel Bratell, blink-dev, Joshua Bell
LGTM to implement behind flag. Pls send a separate intent to ship when ready. (IOW, what Eric said :)

:DG<

Domenic Denicola

unread,
Sep 16, 2014, 1:51:05 PM9/16/14
to Erik Arvidsson, Joshua Bell, blink-dev
From: a...@google.com [mailto:a...@google.com] On Behalf Of Erik Arvidsson

> On Mon, Sep 15, 2014 at 3:17 PM, 'Joshua Bell' via blink-dev <blin...@chromium.org> wrote:

>> Risk: Note that there's no way to enumerate the entries with the new method; it's anticipated that'll be done via ES6 Iterators (spec blocked on Web IDL growing some annotations for that). So there will be further additions to the interface.
>
> Since we are shipping with for-of and Symbol.iterator we should make iteration a checkbox when shipping new collections.
>
> We also have binding support for iterators now:

We're thinking we should add this to WebIDL more generally: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183

The idea would be to add e.g. [MapLikeIterable] to the class to give it keys(), values(), entries(), [Symbol.iterator](), forEach, with key-value semantics. There are a few unresolved issues as to exactly how to spec this generically.

PhistucK

unread,
Sep 19, 2014, 6:55:51 AM9/19/14
to Domenic Denicola, Erik Arvidsson, Joshua Bell, blink-dev
Exactly my thoughts. I remember (I do not have examples, though) a lot of similar collections (or dictionaries, or maps. Various names for the same purpose) and wonder why we need to create yet another type of collection.


PhistucK

Joshua Bell

unread,
Sep 19, 2014, 1:03:33 PM9/19/14
to PhistucK, Domenic Denicola, Erik Arvidsson, blink-dev
The w3.org issue captures that sentiment as well - see especially comment 12 by Tab.

FWIW, URLSearchParams and FormData both end up being extremely similar APIs for access/mutation, not just iteration. They're MultiMaps (not something in the ES6 collections, but perhaps something we should push for in ES7) with restricted key/value domains.

I believe we're slowly lurching in the right direction here.

Anne van Kesteren

unread,
Sep 19, 2014, 2:16:03 PM9/19/14
to Joshua Bell, PhistucK, Domenic Denicola, Erik Arvidsson, blink-dev
On Fri, Sep 19, 2014 at 7:03 PM, 'Joshua Bell' via blink-dev
<blin...@chromium.org> wrote:
> FWIW, URLSearchParams and FormData both end up being extremely similar APIs
> for access/mutation, not just iteration. They're MultiMaps (not something in
> the ES6 collections, but perhaps something we should push for in ES7) with
> restricted key/value domains.
>
> I believe we're slowly lurching in the right direction here.

Don't forget about Fetch's Headers, it looks like these as well. Can't
entirely claim that was coincidence though...


--
https://annevankesteren.nl/

Joshua Bell

unread,
Oct 2, 2015, 2:28:47 PM10/2/15
to Anne van Kesteren, PhistucK, Domenic Denicola, Erik Arvidsson, blink-dev
*bump*

We've had these methods in behind the experimental flag since January. Since then:

* Moz has shipped everything but the iterator.
* ES6 iterators are nailed down and shipping in other places
* WebIDL has settled down for map-like things with iterable<key, value>
* XHR spec has been updated to reflect this, and Blink's impl matches.

How do we feel about "shipping" these now?

Chris Harrelson

unread,
Oct 2, 2015, 2:34:03 PM10/2/15
to Joshua Bell, Anne van Kesteren, PhistucK, Domenic Denicola, Erik Arvidsson, blink-dev
Sounds pretty good to me.

Have you filed for a TAG review?

Joshua Bell

unread,
Oct 5, 2015, 7:11:23 PM10/5/15
to Chris Harrelson, Anne van Kesteren, PhistucK, Domenic Denicola, Erik Arvidsson, blink-dev

TAMURA, Kent

unread,
Nov 9, 2015, 6:08:33 PM11/9/15
to Joshua Bell, blink-dev
It looks not for FormData.

--
TAMURA Kent
Software Engineer, Google


Joshua Bell

unread,
Nov 9, 2015, 6:38:14 PM11/9/15
to TAMURA, Kent, blink-dev

Mike West

unread,
Feb 23, 2016, 3:43:36 AM2/23/16
to Joshua Bell, Eiji Kitamura, TAMURA, Kent, blink-dev
Ping! Joshua, this has been floating around behind the flag for quite some time. It's done, so far as I can tell... What are your plans with regard to shipping? :)

-mike


-mike

Joshua Bell

unread,
Feb 23, 2016, 12:13:36 PM2/23/16
to Mike West, Dru Knox, Eiji Kitamura, TAMURA, Kent, blink-dev
Hah, I knew I was forgetting something.

Somehow this didn't make it onto the review list back in October.

Only status change since then is the TAG review, which seemed fine (except for some confusion by TAG members about the status of USVString).

@dknox - can you make sure this gets on I2S Review list?

PhistucK

unread,
Feb 23, 2016, 12:17:51 PM2/23/16
to Joshua Bell, Mike West, Dru Knox, Eiji Kitamura, TAMURA, Kent, blink-dev
I suggest that you simply post a new intent to ship, almost the same, plus the TAG review and a link to this intent to implement (and ship... yes...).


PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
Reply all
Reply to author
Forward
0 new messages