Demonstrate interoperability with native forms.

[theengineear]

NOT planning on merging anytime soon — just wanted to start looking at how native form support will work.

No new functionality just yet. This change set just demos what it currently looks like to build form-associated custom elements via x-element.

[theengineear]

FYI @klebba — This was the thing I was messing around with last night. This silly emoji-picker example demonstrates most of the surface area for Form-Associated Custom Elements. The main thing that’s tricky is knowing when it’s reasonable to use properties pipeline versus regular getters / setters.

For example, the ElementInternals interface provides a .form getter which always returns the form element which is associated with your form-associated custom element. This sort of live lookup isn’t a good match for the memoization / computation happening in properties.

I think we have two choices:

1. Let hard things be hard — if you’re making a custom form control, you probably an expert and you will understand that you will need to know to use special patterns.
2. Try and update properties to allow for getter / setter style properties. We’d have to add a configuration flag for this and then reject them from the memoization / computation / type-checking pipelines.

I think it’s fine to go with (1) for now since it’s just currently how things work. I think we should try it and then maybe consider how we might incorporate (2) in some later release. The main benefit to (2) is that we make it possible for element authors to declare the entire property interface in one place — currently not something that’s possible if you’re trying to make a custom form element.