Re: Form submission participation (was Re: Goals for Shadow DOM review)

On Thu, Feb 20, 2014 at 2:51 PM, Edward O'Connor <eoconnor@apple.com> wrote:
>> This could be done by having the <form> element attempt check for a
>> .formData property on any descendant that was added, and add any
>> elements that has such a property as a participant automatically.
>
> That doesn't handle this case:
>
> <form><p contenteditable></form>
>
> I'd like a way to declaratively say that that contenteditable
> participates with name foo.
>
> The obvious thing would be to literally add name=foo, but that doesn't
> work because of
>
> <form><a name=foo></a></form>
>
> so we'd need a different attribute name. participant=foo or something.

Is it really going to be a common case to want to submit a
contenteditable declaratively? I feel like in most cases using
contenteditable requires writing heaps of javascript. In part because
contenteditable implementations generally sucks and there's been a
historical lack of specs, but also because in many cases you don't
want a freeform HTML editor, but rather an editor of some other data
model that your page contains.

For example the contenteditable i'm typing in right now in gmail
attempts to implement en email editor, not a generic HTML editor.

In these cases you'd likely also want to submit something other than
the serialization of the markup in the contenteditable element.

However, if we do want to allow script-less form submission of
contentediable then I think having a "participant=foo" attribute would
work. We could define that when that attribute is set .formData goes
from returning null to returning a function. It's a bit weird but it'd
work. I assume that the function would return something like { name:
this.participant, value: this.innerHTML }?

>> The only tricky part is that form.controls is a live array. I don't
>> see a way of making form.controls contain custom elements without
>> synchronously running getters whenever an element is added as a
>> descendant of a <form>, which is not something we want to do. But live
>> arrays are evil anyway so we can probably just ignore integration with
>> that and instead add a form.getParticipants() function which returns a
>> non-live array of all participants.
>
> Yeah, I think we just say that form.controls is the legacy feature that
> only exposes built-in controls. form.getParticipants() works for me.

Agreed. form.controls is pretty crappy anyway in that it's live and
that it doesn't include <input type=image> elements for webcompat
reasons (stemming from an old Netscape bug :))

/ Jonas

Received on Friday, 21 February 2014 01:44:49 UTC