Text Area, Input Field Text, Input Field Number - align behaviour when focusing component in readonly state

[thrbnhrtmnn]

Description / User story

Currently the Text Area, Input Filed Text and Input Field Number components each behave a bit different when they are focused while in readonly state. This task includes the sync on this with design and the alignment of all 3 components.

Requirements / Prerequisites

• none

Acceptance Criteria

• [x] The correct behaviour when focusing the 3 components in readonly state has been found together with design:
  • inputs are focusable in readonly state
  • input values must be selected if present (regardless of the state)
• [ ] The Text Area can be focused in readonly state and doing so will select the value
• [ ] The Input Field Text can be focused in readonly state and doing so will select the value
• [ ] The Input Field Number can be focused in readonly state and doing so will select the value

Additional information

• ...

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[thrbnhrtmnn]

Hey @larserbach , I think this component fix will need some sparing with design. Just FYI. This task is not planned in yet.

[thrbnhrtmnn]

After discussion with design, we should probably remove the background/default/focus tokens for all the components, as the background color should not be changed in the focus state.

Another idea is to implement a pattern description for the focus states.

We also need to do research, if we should even show a focus ring in readonly state. And also if components should be able to receive focus.

[thrbnhrtmnn]

After todays discussion, we decided to do the following research:

• Does input fields (Text Area, Input Field Text, Input Field Number, Select?) need an active state (which we currently name focus state in design)?

Also it is clear, that in readonly we need the focus state.

[larserbach]

After todays discussion, we decided to do the following research:

• Does input fields (Text Area, Input Field Text, Input Field Number, Select?) need an active state (which we currently name focus state in design)? Also it is clear, that in readonly we need the focus state.

Outcome of research:

• Input fields do not have active states.
• Input fields usually do not have hover (except cursor changes) - though this pattern exists for example in the UI of figam
• Input fields have no pressed state - I could not find a single occurance
• Input fields have focus states usually visualized with change of stroke-color / stroke-width
• In rare occasions other properties (e.g: background-color) of the field change on focus

I would propose the following:

Input fields have the following states which can evoke a visual change:

• rest

• hover (Ideally the hover tokens inherit from rest, but can be overridden)

• focused

• focused dominates the other states. Meaning, that if a field is focused, hover will not be applied

• pressed can be removed

Readonly

I looked at adobe spectrum and atlassian

• Yes, inputs are focusable in readOnly states
• in spectrum readonly evokes a change in the visual appearance
• in atlassian the appearance is detached from the readOnly state (see below)

I would propose:

• inputs are focusable in readonly state
• input values must be selected if present (regardless of the state)

[thrbnhrtmnn]

Hey @larserbach , thanks for the research and the proposals.

I have a follow up question: Should our focus state only provide tokens for the stroke-color and stroke-width or should we also define a background-color? If we would define a background-color, would focusing a readonly input also overwrite the background-color or only the stroke-color and stroke-width?

I will update this ticket to make sure that the readonly state is as intended in all input components (Text Area, Input Field Text, Input Field Number), meaning that all input fields are focusable in readonly state and that the value will be selected when focusing them.

I will also create a new task to remove the pressed state, to update the focus state to only define the stroke-color, stroke-width (and potentially background-color) and to make sure the focus state always dominates the other states.

[thrbnhrtmnn]

As discussed with @larserbach , we decided to use all tokens we provide for the focus-state, thus the background-color would also change when focusing a readonly component.

Interesting ideas we stumbled upon while doing the research:

• Atlassian has an appearance property, which either shows or not shows the input field border
• Also in the Atlassian DS the readonly property is only functional and does not change the visual appearance
• Google always uses a caption when the readonly state is shown to inform users that the input is readonly, but there are also no visual changes differentiation the readonly state from other states