Carbon: Read only form controls

[shixiedesign]

A read only variant of Text input is suggested here: https://github.com/carbon-design-system/carbon-contribution/issues/13#issue-421692303

The “Disabled” option is not viable, as the label and entered data is not accessible. Proposal is to simply remove the line at the base of the "Filled" version of the component, so that it closely matches with the Disabled component, but passes accessibility.

Overview of component (updated May 13)

• Read-only variant will be keeping underline and dropping the background of the field. We need the underline for low-vision users to recognize this as a text field. Also loosing the underline makes the element a button-style, which would be confusing.
• Not moving the text position after all. Keeping text 16px away from left of border helps with preserving the form structure.
• Regular text cursor and allows text selecting
• Add not-editable icon, icon in PR https://github.com/carbon-design-system/carbon/pull/2710
• Optional tooltip when hovering not-editable icon, to provide reason for the field being read-only
• Overflow text in the field will show in tooltip on hover
• Should be considered a state, possible readonly attribute
• Follow the standard readonly attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-readonly

Design spec (updated May 13)

In context explorations:

[chrisconnors-ibm]

awaiting specification.

[lovemecomputer]

i have a couple of questions for implementation:

• semantic: if this is a unique state, should we think of it as being labelled read-only/readOnly?
• design: have we decided on design spec for this?

[elizabethsjudd]

From my understanding the implementations should follow the standard readonly attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-readonly

[shixiedesign]

Thanks everyone for the thoughts and discussion. I've updated the original issue description with spec, and summarized all the comments here. This issue is now ready for development!

[shixiedesign]

Note

Moving issue back to visual design stage to figure out the following potential changes:

• Potentially removing not-allowed cursor. Waiting on feedback.
• Lock icon with tooltip containing reason why field is read-only

[lovemecomputer]

should we afford for any kind of status messages/icon/tooltip/etc as part of the pattern for readonly input fields? (typically on forms, if i can't edit something, i want to know why and where i need to go to be able to do so).

i can see the case for product teams being responsible for this, but if we have a particular suggested pattern for how to handle that hinting, we could build it in. (e.g. a lock icon in in the field that can launch a tooltip)

[shixiedesign]

Lock icon is a good idea @lovemecomputer ! Lemme try it out...

[shixiedesign]

Thoughts everyone?

[lovemecomputer]

@shixiedesign yeah that makes sense! especially nice that it fits in the spot we already have for show/hide password :)

[shixiedesign]

Talking to Anna and Lauren, the lock icon has potential confusion with the idea of security. I tried making a not-editable icon too. See below...

Do you guys have more context on which is better? @JordanWSmith15 @werdnanoslen

Changes below include:

• ditching not-allowed cursor. It's a bit too aggressive
• icon & icon hover tooltip for showing reasons why this field is not editable
• not-editable icon or lock icon?

[JordanWSmith15]

@shixiedesign I think the edit with the cross-out is better for my use cases. Locks might make the user think that they can click to unlock, or that there is somewhere they can go to unlock, which is not the use-case (in my product anyway).

[shixiedesign]

Finalized design spec. Ready for dev 🤖 updated May 23

Light variant spec

Only difference from default is changing field background to $field-01 so it is the same as background color.

[JordanWSmith15]

🎉

[emyarod]

@carbon-design-system/design do we want to apply this to number inputs and textareas as well?

also, is there a light version for this variant?

[chrisconnors-ibm]

(@emyarod please tag @shixiedesign directly for questions like this.)

[shixiedesign]

Yep there's always a light variant. I will provide spec in a minute. And yes to number input. I'd say no text area at the moment until we see a need arises. 👍

[JordanWSmith15]

@shixiedesign I didn't want to get into it, as the text input is my immediate need, but numeric input becoming read-only is also a use case for me, including just about every other component for user input: Check box, date picker, radio button, slider and toggle (to name the most common). These could still be represented the same way though... a line with text shown as non-editable. You did this with "expiration date" in your in-context example, whith the date picker component. Seems to work well enough.

[shixiedesign]

Team agreed to adding Read-only state to

• [x] Text input
• [x] Number input
• [x] Date picker

Slider and toggle should be following disabled state in these situations, or a number input at read-only state. Waiting on text area component until need arises.

[emyarod]

@shixiedesign for the number input and date picker, do we still want the tooltip with the input field value?

also is there a mockup for read-only mobile number input?

[emyarod]

on a side note, this may depend on https://github.com/carbon-design-system/carbon/pull/2781 due to the tooltip usage for read only inputs

[shixiedesign]

@emyarod Tooltip with input field value should only show up where there's an overflow of content. This should apply to both number, text, and date input.

The tooltip on Edit--off icon should however be always available. On mobile devices, icon tooltip should trigger on tap (do we have that?)

Structurally, the spec should be similar to text input, where icon is 16px away from both edge of field and content of the field. See https://github.com/carbon-design-system/carbon/issues/2177#issuecomment-492047569

Number input read-only variant

Date & time picker read-only variant

[emyarod]

going to label this as an epic and track the read only versions of text input, date picker, and number input separately

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[JordanWSmith15]

@shixiedesign This one is marked as stale, which is OK I guess, but has the read-only states for text entry or anything made it into the sketch kits or component demos?

[jeanservaas]

Hi @JordanWSmith15

@shixiedesign is on vacay for the next week and a half so I'm trying to get up to speed on some of this stuff. So sorry for all the confusion!

According to our process ( @laurenmrice correct me if i'm wrong) our components don't go into the kit if they haven't been developed. I know the read only form has a design spec from shixie that's been passed off to dev and is here in this PR:

https://github.com/carbon-design-system/carbon/issues/3018

Apparently Shixie's already signed off on it, but @emyarod is waiting on a dev response for some code tweaks that were requested.

There's also number input and date picker read only versions but they haven't been built yet!

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[shixiedesign]

not stale

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[stale[bot]]

As there's been no activity since this issue was marked as stale, we are auto-closing it.

[JordanWSmith15]

@shixiedesign Is there any progress on this, or should we re-open it?

[stale[bot]]

We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.

[laurenmrice]

not stale

[asudoh]

Just for a reference to https://github.com/carbon-design-system/carbon/issues/3018#issuecomment-544746261 - Discussion on tooltip usage (read-only with overflow text) is blocking it from making progress.

One idea, as I stated there, is going without such "overflow text" spec. @laurenmrice @aagonzales Is it something we can do?

[tomlroach]

+1 to this issue.

We have all sorts of user permissions in our product now, and would like to be able to show those users with viewer permissions the values of various fields without having to use disabled styling (and thereby making them hard to read).

One option would be we just design a read only version of every page which uses text elements instead of input fields, but replacing input fields with read-only versions would be much less work and would allow us to have the read only and editable versions of the pages match up.

[lukefirth]

Maybe I'm missing part of the point here, but so far the requirements listed and the design exploration seems to be:

_"We want an editable field where edit is disabled for some reason (eg permissions). We want to make it clear it can sometimes be editable, but that time is not now and communicate why it isn't. We don't want to use the disabled state for this because the visual styling is too heavy"_

Which to me, sounds like the purpose of the disabled state, and sounds like we should be taking a look at the visual design of the disabled states if we are essentially exploring what seems to be a 'softer' alternative rather than another state for achieving/communicating almost the same thing (you can't edit this) slightly differently?

The reason this struck me, is that in some of the exploration our teams are doing is that many resources are by default in a 'read only' state, irrespective of the users ability to edit because they are just taking a look at something, I don't want to mess with it, just know what it is. - Eg my machine is running, here are the specs I have listed for it. They then would hit an edit button to turn that page/container/single field into an edit state, where the inputs all live.

I mocked a quick example:

The 'date activated' is disabled in the first case (and I stole the no-edit icon/tooltip from here to see how that would work), because there is something stopping me from being able to edit it, even though its in an editable context. However, the whole right panel to me is 'read only' these things have been saved and are in a 'read only' state, unless you choose to enter/reenter an edit state.

Am I losing my mind or are these 2 different things?

[emyarod]

some differences between disabled and read only inputs include: the value of a disabled input will not be submitted in an HTML form, and disabled inputs will also be unfocusable and unnavigable via keyboard. read only inputs will send their values in a form and also be focusable and keyboard navigable (just not editable)

[tomlroach]

I suppose conceptually there doesn't have to be any visual difference between an editable input and a read only input. They could be the same but editing is unavailable in a read only version.

For example this URL field in Typeform is not disabled, I can click into it, select the text etc. But I cannot edit it - it simply does nothing if I try to interact..

That's potentially an approach.

Luke shows another where he converts input fields into a similarly sized/shaped text component, although it's limited to text inputs/dropdown, and I don't quite see how it would be applied to radio buttons, checkboxes or other forms of input.

I would summarise the request as:

A point of view on how to represent settings which are not currently editable because they are in a read only state, in an easily legible format - i.e. without using disabled fields - which are extremely hard to read due to their styling.

[janhassel]

Just stumbled across this when using readonly prop with NumberInput. From the examples I see in this issues and out in the wild (for example shared link on box) the visual design currently implemented does not seem to match the intention of this input. Rather, it looks almost identical to disabled state due to its low contrast and the disallow-cursor. Is the visual design still being worked?

readonly:

disabled: