[selectors] :read-only and :read-write about csswg-drafts HOT 17 CLOSED

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.

from csswg-drafts.

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.

from csswg-drafts.

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.

from csswg-drafts.

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

from csswg-drafts.

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

Complete shot in the dark: @foolip ?

from csswg-drafts.

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

from csswg-drafts.

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

from csswg-drafts.

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.

from csswg-drafts.

from csswg-drafts.

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

from csswg-drafts.

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.

from csswg-drafts.

from csswg-drafts.

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?

from csswg-drafts.

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.

from csswg-drafts.

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

from csswg-drafts.

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

from csswg-drafts.

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>

from csswg-drafts.