Read only text input

[emyarod]

ref: #2177 by @shixiedesign

A read only variant of Text input is suggested here: carbon-design-system/carbon-contribution#13 (comment)

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 Add edit--off icon svg & update metadata.yml #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:

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.

[kaylarakower]

@shixiedesign @emyarod Another proposal to consider (I created this issue prior to seeing @shixiedesign 's, so just some food for thought). The design was created for a slightly use case as none of the fields would be editable.

carbon-design-system/carbon-contribution#17

[stale]

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]

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]

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

[kaylarakower]

Not stale @shixiedesign

[asudoh]

Reopening this to restart some discussion - @aagonzales You had a question why tooltip is needed for read-only text input. I think @shixiedesign put this for overflow text, presumably it's difficult (or impossible) for user to go to non-editable text (input) box and move the cursor to see the whole content.

That said, if we have an alternate design to go without tooltip for read-only text input, I think it'll be a good idea. What do you think?

[aagonzales]

@asudoh where's the other issue this was mentioned in? (I couldn't find it again)

[asudoh]

@aagonzales Sorry I may not have been clear enough - It's #4015. The latest spec for read-only text input requests for a tooltip (presumably for overflow text). Definition tooltip is the closest, but definition tooltip (technically) cannot be activated by focus on <input>. #4015 is for supporting such use case in definition tooltip.

[stale]

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]

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

[dianasanborn]

Hi! Just wanted to follow up and see if there are any updates or changes to the design spec for this, regarding the last few comments about the tooltip.

I know a handful of teams on our end need this, so I want to make sure I'm pointing them to the right place for design guidance unless there have been any changes.

Is there an update on the implementation of this as well, or should our own teams start building this out?

[emyarod]

the design should be set already, but currently the implementation has been put on hold until further notice. when this is reprioritized I can update my previous PRs like #3054

[bertrandmartel]

Is there a readonly option for textinput at this time ? I think It's quite important for such a library

[godivareisen]

@emyarod @shixiedesign Does anybody have updates on the status of this effort? The DataStage team on Cloud Pak for Data has a requirement for showing read-only fields in our connector properties panel.

We consume the Elyra common canvas, so this would ideally be something that other teams using the canvas can leverage as well.

[abbeyhrt]

Included in #2177, closing in favor of the other issue.