Review FormData additions in XHR

[inexorabletash]

The FormData interface grew some additional methods beyond the historical append, which allow the keys/values to be inspected, modified, and so forth:

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

These have shipped (apart from the iterator?) in Firefox. We have them implemented behind an experimental flag in Chrome and are looking for any feedback from the TAG before we ship.

[mikewest]

While you're looking at FormData in general, you might as well also peek at the "opaque" FormData additions in CREDENTIAL: https://w3c.github.io/webappsec-credential-management/#opaque-formdata :)

[mikewest]

(Which are also implemented behind an experimental flag in Chrome for that API)

[domenic]

I raised whatwg/xhr#27

[dbaron]

It's almost orthogonal -- but I'd note there was a change from DOMString to USVString here, and whether it's in line with the guidance on which to use at http://heycam.github.io/webidl/#idl-USVString . It's possible the guidance (which also isn't particularly clear) needs updating and the change here was correct, but it seems like the sort of thing where we should have clear guidance on when APIs are supposed to use which. /cc @heycam

[mnot]

Discussed in Melbourne. Besides the issues discussed above (which we're still looking into), looks entirely reasonable. Should revisit in a call soon.

[annevk]

The reason it uses USVString is because when FormData is serialized, that's what you'll get. Seems bad to let the serialization format and object structure have different value spaces.

[plinss]

USVString use sounds fine, but one concern is interaction with other APIs that take DOMString, for example what happens when a FormData is constructed from a Form that contains elements with DOMString values set from script? What happens to any unpaired surrogates? The conversion from DOMString needs to be specified.

[domenic]

It is: http://heycam.github.io/webidl/#es-USVString

[plinss]

Ok, cool. Thanks.

[plinss]

Discussed 2016-04-13 telcon