Allow serializing non-HTMLForm elements

[Seldaek]

My use case here is that I have a form inside a table row, unfortunately html does not allow that so we need to have something like: form > table > tr, tr, tr where every tr is a virtual form of sorts. If I serialize the form obviously I get all trs together which isn't what I need, I just want the inputs of a given tr tag. The patch allows this.

[defunctzombie]

Why can't you have form elements inside a table? I am pretty certain you can and just need an outer closing form tag.

I am hesitant to accept this PR because I don't see why or how html is preventing you from having a form enclosing your input.

[Seldaek]

You can have a form element inside a td, but not around nor within a tr (enclosing multiple td's). That just breaks the markup.

See https://jsfiddle.net/yrma5gmv/ for a demo.. As you can see in the console interestingly the form.one works fine and the inputs are accessible as being in the form, however the styling breaks because the elements aren't really part of the form anymore in the DOM, as the DOM gets rewritten to something like:

[defunctzombie]

And I presume that you want to have two form in the same table for a reason and can't split up the table into two tables any other way?

Is using divs an option here instead?

Alternatively, could you just use one form for the whole thing and prefix the input names with sections like <input name="section1.name">...<input name="section2.name">. Tho I suppose that would not let you know which form section was submitted.

I guess what I am trying to get at is a better understanding of your particular UX flow that you are creating because I am almost certain there is a way to do it without changing the behavior of this module. The reason I am hesitant to change the behavior like that is because the stated purpose of the module is serialize a form.

To make this possible tho I could see an API being expose like "serialize single element". Then you could pass it in whatever you want maybe? One issue I see with the PR here is whether it captures all form elements or we would constantly be updating with new tags, etc and I want to avoid that too.

[Seldaek]

I don't really need a form per se at all, as it's all handled by JS, I just need the form element to take care of a submit event in case user presses enter, then I need a form element to use with this library..

Using divs would technically be an option except I have a table that works fine and it's an actual table in which using divs would be a bit absurd.

I just see this patch as a nice added value in case someone passes something that's not a form, it'll find form elements in it. I don't see any reason to be bound to a form element per se in this day and age of one page apps and full JS frontends. I see your reluctance with regard to the list of tags included, but tbh new form inputs are not exactly a common occurrence and it's only a fallback method so as long as users provide a form tag the lib is future proof.