Improve support for progressive enhancement

[sorvell]

Progressive enhancement is challenging for custom elements, especially form controls. While declarative Shadow DOM and aria reference target help to a limited extent, form elements in Shadow DOM will not submit or be submitted with forms.

In the absence of better platform support, the only viable option is for users to use native form controls as children of custom elements: <my-button><button>Hi</button></my-button>.

To support this use case, libraries should support this pattern as seamlessly as possible. They can do this by discovering and adapting to form related light DOM content.

For Web Awesome, some of this is challenging based on various approaches taken for different elements.

See the following proof of concept exploration.

Notes:

• wa-button: prevent default on a native button to prevent 2x submission; style correctly.
• wa-input: set value and possibly name, hide the native input.
• wa-checkbox: set value, checked, and possibly name, hide the native input.
• wa-radio: problematic due to the existence of wa-radio-group. Could this be deprecated or optional?

[claviska]

To support this use case, libraries should support this pattern as seamlessly as possible.

I appreciate your opinion on this but I disagree. Putting PE above all is not and never has been a goal of this project. To be frank, it feels more like a transitional stopgap that browsers, assistive devices, etc. are already filling reasonably well. I suggest we focus on improving the remaining cracks upstream instead of encouraging library authors to introduce worse APIs and experiences. As of this writing, I can't recall a single user asking for PE outside of this thread.

For Web Awesome, some of this is challenging based on various approaches taken for different elements.

In Web Awesome, we support both native styles for native form controls and Lit-based components. Folks are welcome to pick and choose, so we'll let usage determine which approach is most reasonable for them and their clients.

I'm not really seeing anything actionable from this discussion. We've already migrated every Web Awesome component to use ElementInternals so they're first-class form controls. Flipping every one of their APIs on their head just to facilitate PE — especially this late in the game — will just upset and confuse our users. I don't think that's something our team is interested in doing.

[sorvell]

I appreciate your opinion on this but I disagree. Putting PE above all is not and never has been a goal of this project.
... As of this writing, I can't recall a single user asking for PE outside of this thread.

Just to be clear, I think this is a very reasonable and defensible position to take. I do think that with the advent of declarative Shadow DOM and reference target, users may start asking for PE, but it's totally fair to take that feedback as it comes. The motivation here is mainly to extend the reach of the component set as far as possible and to help stem potential (possibly influencer driven) criticism.

Flipping every one of their APIs on their head just to facilitate PE

Enhancing from light DOM child form controls didn't seem particularly nasty to me based on the proof of concept I did, but I admit that's definitely in the category of famous last words.

I'm not really seeing anything actionable from this discussion.

Another important point to make here, imo, is that a motivated user can do this today, even without any direct support, by executing "hydration" code which takes any PE related light DOM form controls, copies whatever relevant properties to wrapping upgraded wa-* elements, and then removes them. So perhaps one action that could be taken is to add a section with this suggestion and possibly an example to the equivalent web awesome section on form controls.