Readonly of select

[bjarnef]

Description

Currently the readonly of uui-select just render as label, which I don't think is the right approach although browser only support readonly on native input and not select.

I found a few similar examples here:
https://storybook.rsuitejs.com/?path=/story/components-checkpicker--readonly
https://carbon.sage.com/?path=/story/select--readonly

However there's an aria-readonly attribute we can use instead.
https://helloanselm.com/writings/til-css-readonly-is-not-for-select-fields

The CSS props for select didn't quite seem to align with the ones on input. It may be a breaking change. Perhaps we can deprecate the existing one somehow.

It seems the name convension is: --uui-[element]-[css-property]-[state]

Generally speaking I think think readonly state should still render the editor, not disable it (meaning it can still be focused and text selected, but not change input/editor value).

If not already possible, we have in past (Umbraco 13) done the following with SendingContentNotification to set Readonly, but always swap the editor to e.g. Label property editor.
umbraco/Umbraco-CMS#16329

prop.Readonly = true;
//prop.Editor = "Umbraco.Label";
//prop.View = "readonlyvalue";

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Motivation and context

How to test?

Screenshots (if appropriate)

Checklist

• If my change requires a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[github-actions]

Hi there @bjarnef, thank you for this contribution! 👍

While we wait for the team to have a look at your work, we wanted to let you know about that we have a checklist for some of the things we will consider during review:

• It's clear what problem this is solving, there's a connected issue or a description of what the changes do and how to test them
• The automated tests all pass (see "Checks" tab on this PR)
• The level of security for this contribution is the same or improved
• The level of performance for this contribution is the same or improved
• Avoids creating breaking changes; note that behavioral changes might also be perceived as breaking
• If this is a new feature, Umbraco HQ provided guidance on the implementation beforehand
• 💡 The contribution looks original and the contributor is presumably allowed to share it

Don't worry if you got something wrong. We like to think of a pull request as the start of a conversation, we're happy to provide guidance on improving your contribution.

If you realize that you might want to make some changes then you can do that by adding new commits to the branch you created for this work and pushing new commits. They should then automatically show up as updates to this pull request.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[bjarnef]

An issue is that value can still be changed via keyboard though.

It ng-select here they set disabled when readonly but not sure this is best practise as readonly field should still be focusable.
ng-select/ng-select#1376

We could probably just return on keyboard arrows key press.

Update: Adjusted in b3419c4

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud