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

Created on 19 May 2016  路  17Comments  路  Source: w3c/csswg-drafts

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

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

selectors-4
Source
picture cvrebert
👍1

Most helpful comment

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.

picture MatthewRaymond on 16 Dec 2017
👍4

All 17 comments

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.

tabatkins picture tabatkins on 24 May 2016

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

cvrebert picture cvrebert on 25 May 2016

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.

tabatkins picture tabatkins on 25 May 2016
👍4

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

Complete shot in the dark: @foolip ?

cvrebert picture cvrebert on 10 Jun 2016 
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

zcorpan picture zcorpan on 10 Jun 2016

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
cvrebert picture cvrebert on 11 Jun 2016

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

Usually Chromium project assumes features with such values are removable.

tkent-google picture tkent-google on 1 Aug 2016

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

fantasai picture fantasai on 2 Aug 2016

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

foolip picture foolip on 2 Aug 2016

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.

sab39 picture sab39 on 1 May 2017

On Mon, May 1, 2017 at 6:51 AM, Stuart Ballard notifications@github.com 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