Re: [w3c/webcomponents] Need callback for form submit data (#187)

> Also, I'll restart the discussion about custom-element-based API.

Chrome's Autofill team told me that they need a way to distinguish form-associated custom elements from general custom elements, and a way to read/write their values.  So ```formdata``` event isn't enough. Google strongly wants something like [Proposal B](https://docs.google.com/document/d/1JO8puctCSpW-ZYGU8lF-h4FWRIDQNDVexzHoOQ2iQmY/edit?pli=1#heading=h.vm56ow8a24lu).

I think we need to do the following in addition to the current Proposal B.
- Form-associated custom elements must provide ```value``` setter.
- Provide a way to tell UA the current value of a form-associated custom element

For example,

    class MyControl extends HTMLElement {
      ...
      set value(v) {
        ...
        window.customElements.setFormControlValue(this, v);
      }

- UA can get such values without invoking user's JavaScript code because ```setFormControlValue``` stored values in UA beforehand.
- MyControl doesn't need to handle ```formdata``` event
- Autofill feature calls the value setter. It executes arbitrary JavaScript code, but UA can avoid its complexity by calling the value setter asynchronously.


As for the idea of exposing base class of form controls, which we discussed in the last F2F, I think it's a good idea in general. However I'm not sure if it's possible to upgrade native interface of undefined custom elements.

    var control = document.createElement('my-control');
    // 'control' should be an instance of HTMLElement
    customElement.define('my-control', class MyControl extends HTMLFormControlElement { ... });
    // 'control' should be upgraded to HTMLFormControlElement, and MyControl.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/187#issuecomment-387357622