Skip to main content

Bug Tracker

Side navigation

#10443 closed feature (plugin)

Opened October 06, 2011 08:36PM UTC

Closed November 25, 2012 03:23AM UTC

Last modified July 31, 2013 08:43AM UTC

serialize HTML5 form-associated elements

Reported by: mindplay Owned by: mindplay
Priority: low Milestone: None
Component: core Version: 1.6.4
Keywords: Cc:
Blocked by: Blocking:
Description

HTML5 adds support for form-associated elements:

http://www.w3.org/TR/html5/association-of-controls-and-forms.html#form-owner

This seems to be unsupported by the serialize() function. Here's a quick extension to serialize(), adding basic (but not complete) support for the form-attribute on input/select/textarea elements:

http://jsfiddle.net/mindplay/dPyP4/

Form-associated elements seem to be supported by current versions of FF and Chrome, but not by IE9 - that does not preclude full support by serialize() however, even in older browsers.

Since this is officially part of HTML5, I think it would make sense to consider adding support for this new concept in jQuery.

Attachments (0)
Change History (11)

Changed October 07, 2011 12:19AM UTC by dmethvin comment:1

owner: → mindplay
status: newpending

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?

Changed October 21, 2011 08:04AM UTC by trac-o-bot comment:2

resolution: → invalid
status: pendingclosed

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!

Changed July 13, 2012 02:30PM UTC by mstaff@dailybreak.com comment:3

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

Changed July 13, 2012 02:32PM UTC by dmethvin comment:4

Can you answer the question posed above?

Changed August 31, 2012 09:04AM UTC by iwan@reahl.org comment:5

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".

Changed August 31, 2012 01:26PM UTC by dmethvin comment:6

component: unfiledcore
priority: undecidedlow

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.

Changed August 31, 2012 01:27PM UTC by dmethvin comment:7

resolution: invalid
status: closedreopened

Changed August 31, 2012 01:27PM UTC by dmethvin comment:8

status: reopenedopen

Changed September 09, 2012 01:10AM UTC by dmethvin comment:9

type: enhancementfeature

Bulk change from enhancement to feature.

Changed November 25, 2012 03:23AM UTC by dmethvin comment:10

resolution: → plugin
status: openclosed

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.

Changed July 31, 2013 08:43AM UTC by info@corrupt-system.de comment:11

@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.