[vaadin-radio-group/vaadin-radio-button] Does not propagate name attribute to children's input fields.

[knoobie]

Description

Using a RadioButtonGroup in a custom form area of the Login Form is not possible because we can't apply a name attribute to the corresponding input. Other fields support it, see:

LoginOverlay loginOverlay = new LoginOverlay();
IntegerField code = new IntegerField("One-time code");
code.getElement().setAttribute("name", "code");
loginOverlay.getCustomFormArea().add(code);

https://vaadin.com/docs/latest/components/login#custom-form-area###

Expected outcome

Using RadioButtonGroup::getElement::setAttribute("name") or RadioButton::getElement::setAttribute("name") is progapated to all input elements to allow usage in Login Form.

Minimal reproducible example

    RadioButtonGroup<?> group = new RadioButtonGroup<>();
    group.getElement().setAttribute("name", "myField");
    
    group.getChildren().forEach(child -> {
      child.getElement().setAttribute("name", "myField");
    });

Environment

Vaadin version(s): latest

[web-padawan]

The name property is actually missing from the vaadin-radio-group and it uses generated name instead - in https://github.com/vaadin/web-components/pull/2572 it was added and used to be set on all radio buttons. We should add name property to radio-group to make this configurable.

[ethan-massie-vectorsolutions]

This is a major issue for us. In the current state the radio group is unusable in HTML forms. I don't see a work around for this either since any name set on the radio buttons are overwritten by the radio group (even if a custom input is slotted). Is there something I am missing here? For context we are using the web components directly.

I would be happy to contribute to this when requirements are outlined.

[knoobie]

@rolfsmeds you might wanna re-evaluate the labels 🙂 for me it's just "annoying".. for other it looks more severe

[rolfsmeds]

Our "impact" labels are about how large a portion of our userbase we estimate to be affected by the issue in practice. Impact:low means only a marginal fraction are likely to be affected, and I feel that this assessment stands true for this issue, since extremely few use our components in regular html forms (typical Flow and Hilla usage being unaffected), and quite few use radio buttons in the Login form.

@web-padawan would you mind defining specs for this so that @ethan-massie-vectorsolutions could contribute?

[web-padawan]

Here is a quick prototype with a name property on vaadin-radio-group: https://github.com/vaadin/web-components/compare/feat/radio-group-name

The change is quite small so I think we could just implement it in 24.6

[ethan-massie-vectorsolutions]

@web-padawan @rolfsmeds thanks for all of the work on this issue! I've noticed some other form fields do not support standard HTML forms (like vaadin-select). Has your team looked into implementing ElementInternals on these form fields? It would be beneficial for anyone using web standard forms if this API was implemented.

Alternatively, having hidden native form elements that mirrored the components value and validity would also solve these issues.

This is of course out of scope for this particularly issue and would need it's own issue.

[web-padawan]

We have a tracking issue for adding form participation support: https://github.com/vaadin/web-components/issues/79. I think it would be easier to add it once we fully switch to Lit (although we could prototype using attachInternals() with Polymer too).