- From: Edward O'Connor <eoconnor@apple.com>
- Date: Thu, 20 Feb 2014 14:51:13 -0800
- To: public-webapps@w3.org
Hi Jonas, You wrote: > I'm not sure if we should return a dictionary or an array. Yeah, it should be an array. > The other thing is that it would be great if elements that wanted to > participate in submission didn't have to manually call addParticipant. Yes. > 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. > We could even make the built-in form controls like <input> and > <select> have a .formData() function which returns data in whatever > format we decide is the right one. Right. toFormData() or the like, parallel to toJSON(). > 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. Ted
Received on Thursday, 20 February 2014 22:51:40 UTC