- From: Chris Rebert <csswg@chrisrebert.com>
- Date: Tue, 19 Apr 2016 15:00:56 -0700
- To: Simon Pieters <simonp@opera.com>, CSS WG <www-style@w3.org>
- Cc: François REMY <francois.remy.dev@outlook.com>
On Tue, Apr 19, 2016, at 12:58 AM, Simon Pieters wrote: > In this pull request: > > https://github.com/w3c/web-platform-tests/pull/2843 > > we discussed whether the definition of :read-only pseudo-class makes > sense. > > WebKit follows the spec; Chromium and Edge don't; Gecko doesn't yet > support these. Looks like Gecko has prefixed versions of these, which follow the spec modulo the same discrepancy as https://crbug.com/604117 Testcase: http://jsbin.com/poleje/1/edit > :read-only is defined as being :not(:read-write). As an example, a <div> > or an <input type=button> should match :read-only. Chris Rebert notes > that > he thinks this is unintuitive, and Francois Remy also questioned the > correctness of the MS Edge issue. Given contenteditable it's possible to > argue that any element can become writeable, though. To clarify, I was agreeing that having non-disabled inputs of type checkbox/range/color/radio/file match :read-only is unintuitive. The user can interact with such inputs and modify their values, which makes them writeable IMHO. (The fact that HTML doesn't allow the [readonly] attribute on them is an annoying inconsistency, which, like Francois, I wish HTML would fix.) I don't really have a position on whether :read-only == :not(:read-write) is good or not. As for inputs of type submit/button/reset/image/hidden, assuming we stick with a binary notion of :read-only/:read-write, I would deem them :read-only since the user cannot normally directly modify their values. Other than type=hidden, they are interactive insofar as they're clickable, but they aren't editable. Cheers, Chris -- http://chrisrebert.com Browser 🐛 of the day: https://crbug.com/419108
Received on Tuesday, 19 April 2016 22:01:21 UTC