- From: Chris Rebert via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2016 22:18:00 +0000
- To: public-css-archive@w3.org
cvrebert has just created a new issue for
https://github.com/w3c/csswg-drafts:
== [css-ui][selectors] :read-only and :read-write ==
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](https://html.spec.whatwg.org/multipage/scripting.html#selector-read-only)
(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.](https://github.com/w3c/web-platform-tests/pull/2843#issuecomment-211687381)
* 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
Please view or discuss this issue at
https://github.com/w3c/csswg-drafts/issues/127 using your GitHub
account
Received on Wednesday, 18 May 2016 22:18:02 UTC