This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24603 - [Custom]: Need callback for form submit data
Summary: [Custom]: Need callback for form submit data
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14968
  Show dependency treegraph
 
Reported: 2014-02-10 16:09 UTC by Erik Arvidsson
Modified: 2015-07-06 08:04 UTC (History)
8 users (show)

See Also:


Attachments

Description Erik Arvidsson 2014-02-10 16:09:15 UTC
<form>
  <my-custom-input name="abc"></my-custom-input>
</form>

Right now there is no way to have custom elements include data in form submissions. We should add another callback for this

I believe we need to add a callback that is called before the submit event.

Strawman:

document.registerElement('input', {
  prototype: {
    __proto__: HTMLElement.prototype,
    beforeSubmitCallback: function() {
      switch (this.type) {
        case 'checkbox';
          if (this.checked)
            return this.value;
          return undefined;
        ...
      }      
    }
 }
});

Basically, the contract is that the return value of the callback is used a the form value. If undefined is returned nothing is serialized.

This is of course a bit too simplistic but it might be enough to get started.

Things to keep in mind:

- Radio buttons need to check outside itself
- input[type=file]. Return Blob|File|data url?
- input[multiple]. Array of values?
Comment 1 Boris Zbarsky 2014-02-10 16:20:44 UTC
If <my-custom-input> is a subclass of <input>, why can't it just set the .value to the thing it wants to submit?

If it's not a subclass of <my-custom-input>, you have other problems too, like form validation not knowing anything about it and so forth...
Comment 2 Erik Arvidsson 2014-02-10 16:30:48 UTC
I agree it might be simpler to just subclass input but at some point we should explain how input is implemented too. That also includes explaining form validation and requestAutoComplete and probably tons of other things.
Comment 3 Boris Zbarsky 2014-02-10 16:37:53 UTC
Sure.  If we do that we need to make all the relevant algorithms robust to script randomly doing unexpected things.  E.g. getting the value from an input can change the values of other inputs if it's done in arbitrary script....

The way input is implemented in practice, in ES terms, is that it has private slot (closure variable, weakmap entry, whatever) that stores a value string, and various form operations can retrieve that string without running any untrusted (from the point of view of the form) script in the process.  Whatever setup we come up with for explaining input would be best if it preserved those invariants....
Comment 4 Anne 2014-02-12 18:16:49 UTC
What about form association and label association? It seems you need hooks for those too.
Comment 5 Dimitri Glazkov 2014-05-08 20:51:20 UTC
There's another proposal here: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0448.html
Comment 6 Hayato Ito 2015-07-06 08:04:13 UTC
Moved to https://github.com/w3c/webcomponents/issues/187