Hook components that should go into forms into Form Submission

[dfreedm]

As referenced in #223 (comment), we should ensure that form-ish elements like <mwc-radio> and others participate in forms.

We should investigate if Form Associated Custom Elements or the FormData event are simpler to integrate and/or polyfill.

[tschundler]

fwiw, an approach I've used is to wrap from elements in custom components and the webcomponent updates the value of the wrapped element. It could inject a hidden input into the wrapped light dom as a polyfill, or use one if it's already there to give the user more control.
(I'd like to switch some existing code to material, but can't since it isn't worth the dev effort for it to me more than a simple html/css change)

[adrm]

What would be the downside of not using shadowDom for form-y components? Maybe you can use other css encapsulation technique that exposes the inner input to the light dom, because as they are right now, sadly it is very cumbersome to use this components in a form. This is the approach Ionic uses for their components, for example.

[asyncLiz]

The downside is that element internals are unsafely exposed to external CSS styles. The purpose of shadow DOM is to provide protection and ensure that the elements are not affects by any external styles.

Luckily there are some great solutions for custom elements and forms as mentioned in this issue! The next step is implementing them.

While you wait for support to be built-in, you can always hook up the components today using FormData events. Here's a great blog post with instructions on how to do that: https://web.dev/more-capable-form-controls/#event-based-api

[adrm]

Thanks for the explanation. In the meantime, I am copying the value on changes to a hidden input so the form can access it. I hope we can all use FormData events soon but it seems that right now they are not supported by Safari and no easy polyfill is possible (https://caniuse.com/#search=formdata%20event). Great work you are doing over here. Thanks a lot!

[fernandopasik]

If the choice is to implement Form Associated Custom Elements there's a polyfill that might be worth investigating
https://github.com/calebdwilliams/element-internals-polyfill

[YonatanKra]

@dfreedm
I think that due to the limitations of the suggested polyfill and the fact it ElementInternals is supported only in chrome in the foreseeable future, taking the safe route of FormData event would be the best for now.
Because this will be an imitation of form fields API anyway, the API itself won't change, only the internal implementation.
One caveat here is that the FormDataEvent API is not supported in Safari.

[gullerya]

@asyncLiz and the team: since this discussion kind of ended with no concrete decisions, I'd be happy to hear your take on the subject.
Do you have any foreseeable plans to provide form association as part of MWC framework and if yes - how broad do you think you'll get it (submit, reset, validations, autocomplete, else)?

Having played with all those myself, on top of your components of course, I must admit that probably the cheapest solution is to take the native input elements into the lightDOM (while still wiring them into the MWC component lifecycle).
As @asyncLiz mentioned, this has the potential of styling interference, which is also problem to solve, but it looks like this is still more achievable than, for example, support the rest in any other way (pay attention that autocomplete, for example, while being more of a browser's concern, is not something that may be polyfilled, IMHO).

Any chance, that you may consider a component flavor where you allow custom slotted input to opt in, while having your own default one?

[fernandopasik]

Looking at the web components polyfills repo seems like there's no progress either:
webcomponents/polyfills#172
webcomponents/polyfills#173

Does this mean that the standards Form Associated Custom Elements and FormData event are not going to go through?

[asyncLiz]

Does this mean that the standards Form Associated Custom Elements and FormData event are not going to go through?

No, it does not. It only means there are currently other high priority items the team is working on, such as completing our catalog of components, full theming capabilities, ARIA support, and RTL support.

We know that native form submission is a highly anticipated feature, but please be patient while all the features for the project are prioritized! When there's an update or progress being made we'll post in this thread.

[fernandopasik]

Thank you for the update @asyncLiz, I'm also looking for the other priorities you mentioned. Exciting times!

[calebdwilliams]

Saw the element-internals-polyfill mentioned above and figured I'd drop in. That polyfill is mostly feature complete at this point except for

• file data as an argument to internals.setFormValue
• state restore (if I could figure out how to efficiently ensure the back button is being used, that becomes trivial)
• there is currently no way to reliably emulate native error messages on internals.reportValidity other than creating a custom element which feels like overkill

I'm also dropping a comment to follow this thread to see where material lands on this issue.

[initplatform]

Hello. Any updates on a timeline for this?