Readonly text input has no indication it is readonly besides not allowing input

[Diegovsky]

I expected readonly inputs to be visually distinct from normal inputs, like one with disabled is.

[claviska]

Native readonly styles are identical.

<input value="ABCDEFG">
<br><br>
<input value="ABCDEFG" readonly>

I've seen some pretty bizarre attempts at styling readonly text fields differently, but I'm not sure we should deviate from this default.

[Diegovsky]

Often times, it is better to deviate from the default. Styling can be done by checking for the readonly attribute. I found this to work pretty reliably:

sl-input[readonly]::part(base) {
    background-color: var(--sl-input-background-color-disabled);
    border-color: var(--sl-input-border-color-disabled);
    opacity: 0.5;
    cursor: not-allowed;
}

sl-input[readonly]::part(input) {
  color: var(--sl-input-color-disabled);
}

I think I'm not alone when I say readonly inputs should be styled differently by default. I doesn't need to be exactly the same as disabled, but it would be nice to have some indicator or gray background.

[claviska]

I'll caution you that the styles you recommend (shown below) will be confused with "disabled" form controls, which are very different.

Read only controls:

• do not allow the user to modify the value
• allow the user to focus the input, select, and copy the text
• participate in form submission
• remain in the tab order

Disabled controls:

• do not allow the user to modify the value
• don't allow the user to focus the input, select, or copy the text
• do not participate in form submission
• are omitted from the tab order

The grayed out appearance of disabled form controls is ubiquitous, so mimicking it for readonly form controls will mislead users and may even result in data being unexpectedly submitted.

The use cases for readonly seem to vary, so it's up to the consumer to decide how to convey a readonly state, which is often does in context rather than visually. It's probably easier for most people to add the styles they want then to remove or override whatever opinionated styles we try to add.

[Diegovsky]

I understand what you pointed out: readonly inputs still show up in screenreaders, can be selected, etc. In our use case, we're making inputs readonly precisely because we wanted the same results as disabled, except for the fact that we also wanted data to be sent. I completely understand the reasoning behind the current design's choice, though. However, I also think we're not the only ones using readonly like this.

Considering it would be useful to reuse shoelace styles, it would be nice if all of shoelace's "states" had their own separate css class that the user can refer to. For example, the stylesheet I showed earlier could easily be turned into a .sl-input-disabled class that the user can use at their discretion. I think this is even better than my last suggestion, because it increases reusability for end users while also keeping up with updates on shoelace.

If this turns out to be too much work, I would be satisfied with some documentation snippets that show how styles are affected when different states are in place (disabled, pressed, hover, etc.) so that styling is easier.

Either way, I'm very happy with shoelace, it's an awesome library that we use in all our projects. Thank you very much for taking the time to engage with me.