- From: Robin Berjon <robin@w3.org>
- Date: Mon, 03 Mar 2014 15:02:01 +0100
- To: Jonathan Kelly <jonathank.kelly@gmail.com>, "public-nextweb@w3.org" <public-nextweb@w3.org>
Hi Jonathan, On 25/02/2014 18:56 , Jonathan Kelly wrote: > Hi Robin, I took a couple of read throughs of this spec and it's super > simple to follow (which is awesome for a non-expert at reading specs). Good to hear! > Not to get away from the main gist but could something like this be > prototyped in something like Polymer (or any framework that aims to > extend DOM semantics)? Not in full. It is possible to support the encoding itself partially as shown in http://darobin.github.io/formic/json/ but there are issues: 1) The real form data set is built by the browser at form submission time. It includes information (such as which button was used to submit) that simply isn't available before the submission is actually triggered. We could probably hack something to track submission but it would be pretty clunky. 2) When submitting a form the browser navigates and shows the result. But you can't trigger a navigation to a POST. There are really horrible hacks that we could use that would intercept the submit, implement it using XHR, fake navigation using the History API, and replace the document with the response from XHR. But it would be wrong, and wouldn't cover all cases. So this is not something that can really be polyfilled. > I'm really tempted to try something like this but > as you mention in the spec, its up to the server to check the encode > type of the form before determining the parsing mechanics. Does this > ultimately mean that server side languages would need to change to > implement this spec in the future? The languages wouldn't have to change. The libraries that handle form submissions would just need to support application/json, but that's very easy. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 3 March 2014 14:02:10 UTC