[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 :)