[selectors] :read-only and :read-write

[cvrebert]

Copying this over from http://lists.w3.org/Archives/Public/www-style/2016Apr/0294.html
(Disclaimer: My opinions are my own, not my employer's.)

:read-only is currently spec'd as (basically) :not(:read-write), and :read-write is currently spec'd as matching:

• <input> elements to which the readonly attribute applies, and that are mutable (i.e. that do not have the readonly attribute specified and that are not disabled)
• <textarea> elements that do not have a readonly attribute, and that are not disabled
• elements that are editing hosts or editable and are neither <input> elements nor <textarea> elements (i.e. contentEditable / designMode)

(A) This leads to an anomaly: Some inputs that the user can interact with to alter their "value" (which most folks would thus casually deem "writable") match :read-only instead of :read-write.
Namely, <input>s of type range, color, checkbox, radio, and file are :read-only since the readonly attribute doesn't apply to them.
(One can argue that this is a bug in HTML and that HTML should just allow the readonly attribute on these input types.)

(B) There's a question of whether the buttonish <input>s (types: image, submit, reset, button) should be :read-only or :read-write. Arguably, they should be :read-only since the user cannot normally directly modify their values. They are interactive insofar as they're clickable, but they aren't editable. However, Chrome and Edge currently have them matching :read-write, which doesn't conform with the current spec.

(C) There's a question of whether <input type="hidden"> should match :read-only or :read-write or neither. Per spec, it currently matches :read-only. But in Chrome and Edge, it currently matches :read-write.

(D) I think there's some question as to how useful the contentEditable case is, particularly when it's lumped together with the form input cases.

---

Current state of affairs (FWICT):

• WebKit matches the current spec and doesn't want to change their implementation until the spec itself is changed.
• Blink and Edge both suffer from 2 bugs relative to the current spec:
  • :read-only doesn't match <input>s to which the readonly attribute does not apply
    • https://bugs.chromium.org/p/chromium/issues/detail?id=604154
    • https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7229941/
      • As stated in a comment and on the www-style thread, the Edge folks (understandably) don't think the spec's current behavior here makes sense.
  • :read-write shouldn't match <input disabled> or <textarea disabled>
    • https://bugs.chromium.org/p/chromium/issues/detail?id=604117
    • https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7226201/
    • (Gecko's prefixed implementation also suffers from this bug)
• Gecko currently only has a prefixed implementation. Relative to the current spec, it has the one aforementioned bug.
  • Feature request / unprefixing bug: https://bugzilla.mozilla.org/show_bug.cgi?id=312971

---

And in light of the lack of compatibility and questions about the utility of these pseudos as-then-specd, it looks like Hixie asked the spec editors ~3 years ago in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17812#c24 whether :read-only & :read-write could be removed from the spec altogether, but he never got a reply.

---

@zcorpan @FremyCompany @makotokato @BenjaminPoulain @tabatkins @fantasai

[tabatkins]

I feel exactly as @fantasai does:

If it's Web-compatible and no-one else feels strongly about keeping it,
I don't mind. But I don't have that data.

[cvrebert]

Any opinion on the semantics in the event that removing it isn't web-compatible?

[tabatkins]

I'd prefer to define them properly, to be dependent on a host-language-defined editability boolean; I highly doubt that much content is purposely relying on :read-write matching type=text but not type=color. And if possible, define :read-only to also depend on that boolean, so elements that don't have an editability concept at all don't match either.

[cvrebert]

So, any vendor(s) want to add telemetry to see whether these can be removed?

Complete shot in the dark: @foolip ?

[zcorpan]

SELECT * FROM (
SELECT page, url, REGEXP_EXTRACT(LOWER(body), r'((?:.){50}:read-(?:only|write)\s*\{(?:.){50})') AS match
FROM [httparchive:har.2016_05_15_chrome_requests_bodies]
) WHERE match != "null"

326 resources match (out of 496,446 pages).

results-20160610-100007.csv.zip

[cvrebert]

Some observations from skimming the CSV:

• :read-write only occurs 1 time. Perhaps someone could run another query, limited to just :read-write, to see how (un)popular it is specifically?
• 58 are http://carrotquest.io and 30 are http://www.drift.com , both of which are Olark-ish live text chat widgets
• 20 are http://tagboard.com widgets, where the selector suggests it's being used as part of an account settings screen (.dashboard .content .account-tab#account-settings input:read-only)
• 17 are websites using the https://www.muicss.com CSS framework

[tkent-google]

FYI.
Google Chrome 52 has counters for :read-only and :read-write.

• :read-only is used in 0.006% of page views: https://www.chromestatus.com/metrics/feature/timeline/popularity/1377
• :read-write is used in 0.004% of page views: https://www.chromestatus.com/metrics/feature/timeline/popularity/1378

Usually Chromium project assumes features with such values are removable.

[fantasai]

Thanks for the feedback and data. Someone please Agenda+? :)

[foolip]

So, any vendor(s) want to add telemetry to see whether these can be removed?
Complete shot in the dark: @foolip ?

Sorry, I just fixed my email filters to make direct mentions like this stand out from all other GitHub mail. Glad to see my services weren't needed after all :)

[sab39]

From my (admittedly HTML-centric) perspective as a web developer using CSS, there's a definite use case for these pseudo-classes, but changing their meaning slightly would make them far more useful.

I see them as useful to allow a selector to match all text entry elements in HTML, which is otherwise not possible. The linked article can only suggest variations on this fundamentally flawed approach:

input:not([type]), /* all non-declared types */
input[size], /* text, search, tel, url email, or password */
input[type^=date], /* date, datetime, datetime-local */
input[type=color],
input[type=week],
input[type=month],
input[type=time],
input[type=number],
input[type=range] {
   /* styles */
}

This approach is problematic in many ways:

• It's unnecessarily clumsy and verbose.
• It presumes that the size attribute will be specified on all text inputs, which may not be the case.
• It is fundamentally tied to a specific user-agent - in fact, to a specific version of a specific user-agent - because user agents are rightly given free rein regarding the UI they present for the different <input> types, and do in fact make different choices from vendor to vendor and version to version.
• It cannot account for new <input> types that may be added to the HTML specification in the future

As currently specified, the :read-write pseudo gets partway to meeting this need, but does not offer a way to match readonly (other than a [readonly] attribute selector) or disabled text inputs because :read-only is defined too broadly.

I would suggest changing the specification of :read-only to match only elements that could support :read-write but are currently readonly or disabled.

[tabatkins]

On Mon, May 1, 2017 at 6:51 AM, Stuart Ballard ***@***.***> wrote: From my (admittedly HTML-centric) perspective as a web developer using CSS, there's a definite use case for these pseudo-classes, but changing their meaning slightly would make them far more useful. I see them as useful to allow a selector to match all text entry elements in HTML, which is otherwise not possible. The linked article can only suggest variations on this fundamentally flawed approach:

They don't do that, tho. As the SO answers state, :read-write doesn't match disabled form controls (tho it does in Chrome, at least), while it *does* match <textarea>, which isn't what you want. [snip]

As currently specified, the :read-write pseudo gets partway to meeting this need, but does not offer a way to match readonly (other than a [readonly] attribute selector) or disabled text inputs because :read-only is defined too broadly. I would suggest changing the specification of :read-only to match only elements that could support :read-write but are currently readonly or disabled.

Regardless of how we decide this, it won't support your use-case properly.

[sab39]

They don't do that, tho. As the SO answers state, :read-write doesn't match disabled form controls (tho it does in Chrome, at least), while it does match <textarea>, which isn't what you want.

Actually I would want it to match <textarea>, and anything that's contenteditable as well.

Regardless of how we decide this, it won't support your use-case properly.

Perhaps I'm misunderstanding the discussion here, and if so I apologise. I thought that the issue was that the currently specified behaviour of :read-only and :read-write is problematic, vague, and doesn't have clear use cases; and that (probably because of these issues) they aren't widely used and maybe aren't worth continuing to support at all.

My suggestion was to change the specified behavior of those selectors to give them a clearer reason for existence, rather than removing them entirely or continuing to support something that's not especially useful or used.

Specifically, my suggestion is to keep the behaviour of :read-write essentially unchanged, and define it explicitly as referring to any kind of editable text entry (that is, <textarea> and all <input> types that render as textboxes, as long as they aren't readonly or disabled, along with anything contenteditable), and change the definition of :read-only to mean "editable text entry controls where editing is disabled", so it'd match <textarea>s and textbox <input>s that are readonly or disabled.

Is there some reason why such a change can't be considered?

[MatthewRaymond]

Well, these pseudo-classes were originally created for XForms 1.1:

Selects any core form control bound to a node with the model item property readonly evaluating to true or false (respectively).

So the whole point wasn't that the element was interactive, but that it was bound to a node in the data model that had the property of being read-only. Read-only is a property of the underlying data model, not the control.

In HTML, the control elements have an implicit data model, but nothing has changed. The "readonly" attribute applies only to Web Forms elements. The other elements don't have an implicit data model. Thus, it's my feeling that :read-only should only apply to controls that are specifically set with the"readonly" attribute, and :read-write should match all controls that aren't "readonly". If we need a pseudo-class for editable elements, use something like :editable or :mutable instead of :read-write. We should never have a situation where :read-write is just :not(:read-only) or vice versa.

[css-meeting-bot]

The Working Group just discussed [selectors] :read-only and :read-write, and agreed to the following resolutions:

• RESOLVED: keep the selectors in the spec and work on defining and test cases as appropriate.

The full IRC log of that discussion

<dael> Topic: [selectors] :read-only and :read-write
<dael> github: https://github.com//issues/127
<dael> fantasai: Issue was filed to say they don't have a sensible def. or interop. FF doesn't support them. Proposal was to remove them. Alt was come up with a useful def. that's specced.
<dael> fantasai: Easiest is remove, but ti's a Q for the WG.
<dael> Rossen_: Based on Chrome 52 data seems like it's below threshold of what google would consider not removing. Q to the chrome folks, are you willing to remove this?
<dael> ericwilligers: If it's low I think if that's what the group pref. We haven't discussed.
<dael> Rossen_: I don't want to resolve now and then someone say nope we won't remove. Good we took exersize to review but no action will follow. It's good to have more commitment before we resolve. If you guys aren't okay to remove from the get go no reason to talk.
<fantasai> Testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%3Aread-write%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3Aread-only%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3C%2Fstyle%3E
<fantasai> It is not supported in Firefox afaict.
<fantasai> and parses as invalid
<dael> florian: Seems to be that the dsicussion isn't that it's useless but that it's not specced right. Maybe something sayinng this might be useful but we didn't get it right, feedback please in the spec.
<dael> ericwilligers: Has anyone come up with a different spec for that?
<dbaron> I think Firefox supports :-moz-read-only and :-moz-read-write
<dael> tantek: I think it came from a really old draft of css ui and then was assimilated into selectors. I recall there was some type of x-forms back in the day but I don't know if that's used anymore. Prob fine to drop from a modern we don't have use cases. Esp. if the threashold is low enough.
<dael> Rossen_: Is FF only one not supporting?
<dael> dbaron: We have support with moz prefix, but not unprefixed.
<dael> tantek: Regarding fixing b/c it's web exposed now there's a race condition where if it's low enough to remove we should do so to avoid having an emerging compat issue while we figure out how it should work. Then it can procceed without pressure.
<florian> tantek, fair enough
<dael> ericwilligers: I think usage has gone up. It seems to be 1.4% on the counter. So the thing you worried about has happened.
<dael> Rossen_: We're shipping unprefix. Chrome too. Not sure webkit. myles are you shipping it?
<dael> ??: Give me a second.
<ericwilligers> s/1.4%/.4%/ https://www.chromestatus.com/metrics/feature/timeline/popularity/1377
<Rossen_> s/??/mylies/
<Rossen_> s/mylies/myles/
<ericwilligers> 0.2% for read-write https://www.chromestatus.com/metrics/feature/timeline/popularity/1378
<dael> Rossen_: While we wait. ericwilligers you're sugegsting cunnet stats say we can't remove?
<dael> ericwilligers: Correct.
<dael> Rossen_: So I guess this is a moot point. That's why we wanted to have the illing to deprecate discussion. So the uptick in usage is too large to remove. So as brought by florian we can't remove so how do we fix them?
<dael> Rossen_: If we're not ready to discuss we can resolve this issue as not removing from spec and then we can work on further definition sep.
<dael> Rossen_: Not sure about fantasai if she's still tring to connect.
<fantasai> sgtm
<dael> Rossen_: Obj to resolve on keeping the properites as-is based on usage data and work on further defining their behavior?
<dael> myles: Our rendering is same as chrome, different then FF.
<dael> Rossen_: FF passes if you add the prefix.
<dael> Rossen_: Proposal is keep the selectors in the spec and work on defining and test cases as appropriate.
<dael> Rossen_: Obj?
<dael> RESOLVED: keep the selectors in the spec and work on defining and test cases as appropriate.

[annevk]

Since OP is about the HTML Standard, why isn't the issue raised against the HTML Standard?

[emilio]

Let's dupe this against whatwg/html#3501.

[shrpne]

I agree with @MatthewRaymond
I think it is very unintuitive, that such css

/* both matches <select> */
select:read-only {}
select:not([readonly]) {}

/* both matches <div> */
div:read-only {}
div:not([readonly]) {}

will be applied to such html

<div></div>
<select></select>