[material-ui][Select] Select not propagating `readonly` attribute to input

[Yuwan]

[material-ui][Select] Select not propagating `readonly` attribute to input

[aarongarciah]

Important context: the readOnly HTML is only supported on input (only with some types like text, password, etc.) and textarea elements. Read more in MDN. readOnly is not supported on select elements.

I've been digging deeper into this problem and it's more complex than it seems. I've created these two demos to showcase the issues.

1. Using v5 (currently 5.15.19): CodeSandbox
2. Using the PR version: CodeSandbox

You can see the differences between when the .Mui-readOnly class is applied and when the readonly attribute ends up in the DOM between the two versions. We should rely on the .Mui-readOnly class name being present to style read-only inputs and not in the readonly attribute is present.

To get the .Mui-readOnly present, this is the way to do it as of today:

• <TextField select>: pass InputProps={{ readOnly: true }} (or using slotProps.input once InputProps gets deprecated in v6).
• <Select>: pass readOnly. inputProps.readOnly doesn't work, neither in the PR version.
• <NativeSelect>: pass readOnly. This gets the .Mui-readOnly class applied but the field is not read-only in practice.

---

Conclusions:

• Developers should rely on .Mui-readOnly class names to style read-only inputs and not in the readonly attribute being present or not.
• In the future, I think we should consider removing the support for read-only Select as it deviates from the native HTML element. Or at least make it accessible since it's no the case at the moment.
• Components that accept a read-only state like TextField should have a dedicated prop for it and developers shouldn't rely on passing InputProps={{ readOnly: true }} and the like.
• I think we should close the PR since it's not really solving anything if my analysis is correct.

cc @DiegoAndai

[DiegoAndai]

I agree with your analysis @aarongarciah 👌🏼 as well as with closing the PR

I'm adding this issue to the Base UI milestone so we can revisit it when the Select component is refactored on top of Base UI. When that happens, we can revisit the following:

• In the future, I think we should consider removing the support for read-only Select as it deviates from the native HTML element. Or at least make it accessible since it's no the case at the moment.
• Components that accept a read-only state like TextField should have a dedicated prop for it and developers shouldn't rely on passing InputProps={{ readOnly: true }} and the like.

[ZeeshanTamboli]

I confirm it's a bug. The readOnly attribute is not passed to the hidden input. Would you like to create a PR? We would also need to add a test.

[aarongarciah]

Note that even when we fix the issue and readOnly is propagated to the underlying input element, applying styles such as input[readonly] { color: lightgray } won't work because in the case of Select the input is visually hidden.

Also, although we support readOnly in Select, native select elements don't support readonly attributes (see HTML spec). It has no effect and even HTML validators will point it as an error. For example, readOnly in NativeSelect (which renders a plain select) end up in the DOM but has no effect.

---

Side note: we're not doing a good job of signaling states to assistive tech. When focusing the inputs in this demo https://mui.com/material-ui/react-select/#other-props the error, read-only, and required "states" are not announced.