- 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