production-grade support for forms / input elements about elix HOT 5 CLOSED

Thank you for the nice words!

As for supporting a backward-compatible means of submitting input data with a form, I'm not sure what the best way to proceed would be.

• Apple will eventually support ElementInternals and its forms features.
• While Elix has polyfilled features in a few cases, we usually only take on that cost when the polyfill can be fairly self-contained. In this particular case I think it might be challenging to create a single Input that both supports forms directly on browsers that allow that, and uses a hidden input on Safari. Those cases are pretty different, and likely to be extremely surprising to component users — especially those who don't care about forms.
• E.g., someone might easily have styling that affects regular input elements. Depending on how the styles are written, that styling might affect a dynamically-create input and make it visible to the end user. Because that behavior would only manifest itself on Safari, it might be confusing/challenging for someone to determine where and why the extra input was being created.
• This trick wouldn't work in cases where Input or one of its subclasses are being used in the shadow of another element (like ComboBox).

Given this, I think the best that could be managed would be to create an unofficial Input-like component that can be used in situations where: a) someone needs a forms solution now for Safari, b) they are willing to use an unofficial component, and c) only needs to work at the page level (not in shadow). We've considered adding a separate repo for components that are on the margins of what Elix can officially support — if we were to do that, this kind of Input-like component might belong there.

We're currently busy with a number of other priorities, but if you're interested in pushing this idea further, I'm happy to review your work and provide recommendations. For now:

• There are other things that can update the value of a component than typing in an input: another component may set the value property, for example. I'd recommend having your input handler use setState to update the component's value state, then have a render implementation that renders the value to the hidden input.
• Similarly, any state that needs to be rendered to the hidden input (like the name property in your example) should similarly be applied in render. That ensures that dynamic changes to name, etc., will get rendered to the input.
• A simpler place to hide the input might be inside the component itself as a light DOM child. The input will still be in the page DOM, and hence should be submitted with a form, but is less likely to cause problems. E.g., if something on the page dynamically moves the component, the input would move as well.

from elix.

...and thank you for considering my feedback and providing hints.

I can understand that you want to keep elix clean and not add shaky workarounds ;-) And the unofficial Input-like component you describe smells like trouble to me, I would rather not do that.

Your answer got me thinking in a different direction: I started investigating a polyfill for ElementInternals. Might make for a much more elegant solution? Little time right now, but I'll try to provide an update within a month, if you are not faster.

from elix.

I hadn't known about the polyfill. Please let me know how your investigation goes.

Since I think your original questions have been answered, for now I'll go ahead and close this.

from elix.

I tested the polyfill, seems to work fine with elix Input element (just need to load it early enough, no code change required). I tested on Firefox 76 (polyfill active) and on Chromium 78 (polyfill inactive).

Currently (v0.0.15) the emulation is not 100%: see this issue. Until it is fixed, the form data can be accessed with the FormData API.

from elix.

@JanMiksovsky I just tested a newer version of element-internals-polyfill (v0.0.21) where the emulation improved:
a custom element can now be accessed like a normal input with form['my-custom-element']. It is not perfect (custom element cannot be found with form[n] or form.elements), but to me it looks like it covers 99% of the cases.
Maybe worth a mention in the elix documentation?

from elix.