[Feature proposal] Add orientation attr to radio group component #3069
Description
This issue proposes adding an attribute of orientation to the API of radio-group to support common scenarios of having groups of radios which align horizontally as well as vertically.
I don't believe the list here is exhaustive, but below are a few design systems which expose an orientation for their radio group components:
*NOTE: One of the above uses a boolean prop of inline.
The case for adding an orientation attribute
Ease of use: Currently to change the orientation from vertically stacked to horizontally aligned a user would need to use their own CSS and target a part within the radio group component. I think this is OK and some of the design systems have examples which illustrate it. As a user, I could see how this might be convoluted or overly cumbersome compared to simply passing an attribute and having a CSS class added that takes care of this for me.
Flexibility: One of our principles for FAST is empowering developers through a flexible API and I believe this change supports that goal. While not exposing the attribute here, we are taking a prescriptive approach to the layout of this control. This leaves out some design systems and requires them to fend for themselves in implementing this. I would propose that adding this attr increases the flexibility of controls and allows all design systems to accomplish their goals in terms of "layout" within a radio group. If we do not include the attribute, teams need to extend our model to add their own support (and possibly our template if our suggested approach to adding classes is via the template). All that could be avoided by simply broadening the API to account for this.
Why orientation as opposed to another name?: I'm not opposed to using another name in place of orientation. Several other controls already include an orientation attribute, so there is precedence for the naming here. Additionally, orientation-like language is often used by the design systems which implement this behavior (horizontal/vertical). This would map 1:1 with other controls which have different visual orientations.
One issue that could be brought up here is that the other controls which currently support orientation have functional behaviors associated to them*. I think this is a fair argument for why it's included there and why it may not be appropriate here. I would argue that while there may be similarities in naming of the attributes, I'm not sure we should always expect full parity with the behaviors. It seems reasonable to me that we should have consistency between controls but that full parity is not required. To set it as a principle, the following seems reasonable:
Orientation will always have a visual impact, but may or may not have functional implications to the control.
With the above said, I'll reiterate that I'm primarily interested in including this functionality and not at all married to the name orientation.
*NOTE: While there is not currently a difference in keyboard or functional behavior as outlined in the W3C spec, I would see a future where vertical and horizontal keyboarding does differ to create alignment with other controls (slider, tree view, menus). Leveraging orientation here would set us up for success from a future extensibility standpoint.
Countering potential issues
Precedence for visual attributes on components: This is somewhat countering a possible objection for having visual attributes. We have precedence for purely visual attributes on controls; both button and anchor support an appearance property which changes the visual appearance only. In cases where we see visual commonalities across design systems such as button, our principle is to expose support for those as first-class attributes. It seems reasonable to follow that here.
This creates a delta between checkbox and radios - is that a problem?: My perspective here is that this is not a problem as the existence of a radio group control creates a delta in terms of how one would implement and visually style the controls already. We platform html radios (input[type="radio"]) and Aria radios (role="radio") have different requirements in terms of how they are implemented to ensure an accessible experience. With the html radios, association can be done with the name attribute and all the radios are magically associated within a radiogroup and things are communicated to assistive technologies (AT) as expected. Following the same pattern with aria radios creates issues - a parent with role="radiogroup" is required and the behavior is fundamentally different. Checkbox doesn't have the same issue here as the expectations and implementation are a bit different for the control. If we had a control to group checkboxes I would advocate for the same API, but checkbox doesn't have that requirement.
It's possible that we could create a strictly visual control that manages this layout which would provide easy support to laying out checkboxes as well. I'm not opposed to that though I'm not sure how it would fit into our current story for fast-components. Regardless of where that might land, I would still advocate for the attribute in radio and simply leverage that visual control within the template.