read-only pseudo class behavior ambiguities in the documentation.

[B3rry]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/:read-only

What specific section or headline is this issue about?

:read-only

What information was incorrect, unhelpful, or incomplete?

The first paragraph states:

The :read-only CSS pseudo-class represents an element (such as input or textarea) that is not editable by the user.

However, this is inaccurate. The read-only pseudo targets editable fields that do not accept text. This can be verified by the following code:

<input type="checkbox" />
<input type="radio" />
<input type="text" />

input {
  outline: none;
}

input:read-write {
  outline: thick double blue;
}

input:read-only {
  outline: thick double red;
}

Sample output. Note how the checkbox, despite being "editable by the user," is targeted by the read-only styles.

What did you expect to see?

I think this should be mentioned in the documentation. That read only has unexpected (at least from my perspective) behavior. This could be an ambiguity-related issue similar to what can occur with in-range or other input-type specific pseudos, but I believe the documentation could benefit from this clarity.

Do you have any supporting links, references, or citations?

Not beyond the replicable code.

Do you have anything more you want to share?

No.

MDN metadata

Page report details

• Folder: en-us/web/css/_colon_read-only
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/CSS/:read-only
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/css/_colon_read-only/index.md
• Last commit: d3cdafc
• Document last modified: 2023-03-12T06:37:36.000Z

[B3rry]

More context:

The W3 forms specification page says: https://www.w3.org/TR/html401/interact/forms.html#adef-readonly

readonly [CI]
When set for a form control, this boolean attribute prohibits changes to the control.
The readonly attribute specifies whether the control may be modified by the user.

When set, the readonly attribute has the following effects on an element:

Read-only elements receive focus but cannot be modified by the user.
Read-only elements are included in tabbing navigation.
Read-only elements may be successful.
The following elements support the readonly attribute: INPUT and TEXTAREA.

How read-only elements are rendered depends on the user agent.

Further, 17.4 The INPUT element says:

readonly (readonly) #IMPLIED -- for text and passwd --

Based on these constraints (that you can only expect this behavior to be consistent with the definition for text-based input elements), I think it is beneficial to call out these caveats similar to how the in-range documentation specifies the min and max are related to element use.

[B3rry]

...but also the W3 spec seems... not consistent here.

Maybe "read" is being treated as the opposite of "write." Yes you cannot write into a checkbox or radio, but that is a meaningful distinction from the "but cannot be modified by the user" criteria in the spec.

[Josh-Cena]

See also: #27408, whatwg/html#9496

[OnkarRuikar]

Maybe "read" is being treated as the opposite of "write."

Yes, all that is not :read-write is being considered :read-only [ref]. The definition of :read-only relies on :read-write.
So :read-only applies to form elements on which the html readonly attribute doesn't work. Interaction using pointer devices is not considered editing the element.

The :read-only also applies to <div>, <p>, <button> elements (provided contenteditable is not set).

[annevk]

Right, perhaps a description such as this would be better:

:read-only matches elements that do not match :read-write, such as an element that is not editable by the user or a checkbox.

[CBID2]

Hi @B3rry! :) I made the change in PR #33193. Feel free to check it and see if it addresses your issue.