[whatwg] Form Serialization

[Michael A. Puls II]

On Tue, 06 Jan 2009 07:07:38 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 8 Aug 2007, Garrett Smith wrote:
>>
>> It would be useful to have:
>>
>>  HTMLFormElement.prototype.toJSONString
>>  HTMLFormElement.prototype.getDataSetString
>
> What are the use cases for this?
>
>
> On Thu, 9 Aug 2007, Michael A. Puls II wrote:
>>
>> Yes, these would be useful for 2 reasons that I can think of.
>>
>> 1. *Potential* ease of working around form handling bugs when you
>> really need to.
>> Although if the form handling is broken, the methods might be too, but
>> it still might be easier to get the broken data set and fix it instead
>> of generating the data set yourself. At least with getDataString, it
>> would show you what's going to be submitted.
>
> Are browsers actually buggy here?

Just Opera with action="mailto:". And, other browsers have differences with action="mailto:" that could be sorted out. HTML5 takes care of this, but fixing everything now would be easier if there was a getDataString.

But that's just a current example that should go away. But, later on, if getDataString was available, and there was some other issue, it could help make things easier to fix.

Also, I just always thought it was odd that you couldn't *directly* check what the browser was going to submit. I like a little transparency here. May want to modify the dataset before it goes out.

A while back, Opera (I think 8.x maybe) would submit the full path of an <input type="file" even though it would only provide the filename through input.value in JS. I, and some others, would browse to a local media file, submit the form to an iframe and get its src just to get the full pathname of the media file so the path could be added to the wmp plug-in's playlist via its scripting api. It was basically a local media player web page app. Getting a hold of the form dataset proved to be a good workaround.

There were other examples, but they escape me atm.

You probably won't buy it, but I like the idea of using a form as a user input data gatherer for in-page js-based apps where you do custom things with the data and often don't actually submit the data anywhere.

> Why would we not want the browser
> vendors to just fix those bugs rather than implement new ones?

If the vendor agrees it's bug, plans to fix it and can do it in a timely manner, sure. Otherwise, you get people to starting fixing things themselves (js libs do that in a way).

>> 2. Form handling extensions.
>>
>> If you want to support the foobambang: protocol, you could use the
>> object and its array values to generate a foobambang:-conforming URI and
>> open it (using the default handler for foobambang URIs).
>
> With the data: URL support, one can now do this using POST to a data:  
> URL,
> per spec (just have the data: page redirect to the appropriate URL). Does
> this handle this case well-enough?
>


<form action="data:text/html;charset=utf-8,%3Cscript%3Ealert(%22%%%22)%3C%2Fscript%3E" method="post">
    <input name="one" value="zip zam bam">
    <input name="two" value="meow bark quack">
    <button>submit</submit>
</form>

Looking at the spec, it looks like submitting that would alert "one=zip%20zam%20bam&two=meow%20bark%20quack". If so, I guess that could work for getting the dataset. But then, the  dataset is in a different page than the form.

I'm thinking more of:

form.addEventListener("submit", function(e) {
    e.preventDefault();
    alert(e.target.getDataset());
    // Do whatever custom stuff with the data I want
}, false);

Might even might form submit to XHR simpler code-wise.

-- 
Michael