Intent to Implement and Ship: new FormData methods
Joshua Bell
Contact emails
Spec
http://xhr.spec.whatwg.org/#interface-formdataSummary
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!
Erik Arvidsson
Contact emails
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
Joshua Bell
On Mon, Sep 15, 2014 at 3:17 PM, 'Joshua Bell' via blink-dev <blin...@chromium.org> wrote:Contact emails
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.
Eric Seidel
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
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
> 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.
>
>
> 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.
>
>
Daniel Bratell
<blin...@chromium.org> wrote:
> Risk: None of the other browsers ship this yet. Moz doesn't even have a
> tracking bug.
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
wrote:
to the FormData API, not the FormData object itself which is already well
supported. So ignore me.
/Daniel
Dimitri Glazkov
Domenic Denicola
> 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:
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
Joshua Bell
Anne van Kesteren
<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.
entirely claim that was coincidence though...
--
https://annevankesteren.nl/
Joshua Bell
Chris Harrelson
Joshua Bell
TAMURA, Kent
Software Engineer, Google
Joshua Bell
Mike West
Joshua Bell
PhistucK
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.