Bug Tracker

Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#10443 closed feature (plugin)

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.

Change History (11)

comment:1 Changed 7 years ago by dmethvin

Owner: set to 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?

comment:2 Changed 7 years ago by trac-o-bot

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!

comment:3 Changed 7 years ago by mstaff@…

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

comment:4 Changed 7 years ago by dmethvin

Can you answer the question posed above?

comment:5 Changed 6 years ago by iwan@…

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:

  1. because it uses a different URL for submissions; and
  2. because submitting #main_form may be prevented by validation of inputs belonging to #main_form
  3. 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".

comment:6 Changed 6 years ago by dmethvin

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.

comment:7 Changed 6 years ago by dmethvin

Resolution: invalid
Status: closedreopened

comment:8 Changed 6 years ago by dmethvin

Status: reopenedopen

comment:9 Changed 6 years ago by dmethvin

Type: enhancementfeature

Bulk change from enhancement to feature.

comment:10 Changed 6 years ago by dmethvin

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.

comment:11 Changed 5 years ago by info@…

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

Note: See TracTickets for help on using tickets.