The draft spec seems to be pretty clear that the form's id is used rather than name, did I miss something?

Also, exactly what use case is HTML5 trying to solve with this?

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

I'm having similar issues, can you reopen this ticket?

Can you answer the question posed above?

We have a similar issue.

Regarding the first question above - yes, the form's id should be used, not its name.

Regarding the second, my guess is it has to do with working around the fact that you cannot nest forms.

We have the following use case: we need inputs of one form to be visually part of another, yet the different inputs should submit different forms and adhere to different validations.

See, for example the HTML on http://jsfiddle.net/IwanVosloo/XDmJL/

#main_form is a form with some inputs but it includes a section where multiple files can be uploaded. Uploading of files is managed by #files_form (as is deleting a file that was already uploaded and thus displayed in the #files_input li)

With the correct server-side support, this works without javascript. But we want to enhance it using jQuery so that clicking on the Upload button uploads the file via ajax and updates #files_input li upon successful completion.

The separate #files_form is necessary:

a. because it uses a different URL for submissions; and

b. because submitting #main_form may be prevented by validation of inputs belonging to #main_form

c. adding more files is a different concern that has nothing to do with submitting #main_form, and especially not the inputs of #main_form (you don't want to submit them each time you add a file anyways)

That said, properly supporting form associated inputs that are not physically inside their form in jQuery probably has bigger repercussions than only to .serialize. HTML5 changes the meaning of "finding the inputs of a particular form".

Looking at the spec it certainly seems that they have not thought this through completely. For example they are proposing a form attribute for each input to indicate its owner, but since DOM1 there has been a .form property on each input indicating its "form owner". So now we have yet another property/attribute split but even worse because one is a string representing an id and the other is a reference to a DOM element.

I'm going to open this ticket and see where the spec is. For now it should be possible to use a selector to serialize whatever inputs you are interested in, since .serialize() takes either a form element or a list of input elements.

Bulk change from enhancement to feature.

Looking at all the issues that need to be resolved here, I think this would be better done initially as a plugin. If enough users find it useful we could consider putting it into core. If someone is interested in writing the plugin let us know.

Note that the changes in #12134 may prove handy here.

@dmethvin

Webshims has implemented the form-attribute. Here you find the code used to implement this: https://github.com/aFarkas/webshim/blob/588e06c274ca51709973babbcae6710d00e4dc4a/src/shims/form-shim-extend.js#L907-1073

As said before jQuery 1.9+ already supports HTML5 serialization and additionally gives enough hooks to implement this by a plugin. Fixing this in oldIE is quite heavy. Webshims implementation is good enough, but not 100% HTML5 compilant. If someone finds some improvements for this, please let me know.