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 :)

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

I raised https://github.com/whatwg/xhr/issues/27

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

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

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.

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.

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

Ok, cool. Thanks.

Discussed 2016-04-13 telcon