W3C home > Mailing lists > Public > www-style@w3.org > April 2016

RE: [css-ui][selectors] Definition of :read-only

From: Francois Remy <frremy@microsoft.com>
Date: Tue, 19 Apr 2016 16:21:21 +0000
To: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
CC: Benjamin Poulain <benjamin@webkit.org>, Chris Rebert <csswg@chrisrebert.com>
Message-ID: <BN3PR0301MB088360CAD1F228B6E29BEBB5D66C0@BN3PR0301MB0883.namprd03.prod.outlook.com>
I think the right fix would be to make the readonly attribute apply on input[type=checkbox|color|file|radio], or at least include them in things which can match :read-write. This is out of scope for the css working group, though. I also think input[type=hidden] should not be marked read-only, it is never even readable. I don't care if we make it match :read-write or not (you could argue its intended user is the page author, for which it is perfectly readable and writable by script).

The case of submit/image/button/reset is however worth discussing. While no browser on Windows currently does, it may make sense to say those are read-only, because you cannot change their value (but they do send a value if they submit the form, or at least for some of them do).

I don't disagree with making :read-only be :not(:read-write) to handle [contentEditable] better, but when I saw the test case stating non-sensical things like "input[type=file] should be :read-only" etc..., and saw it is interoperably broken in all Windows browsers (only Safari works "according to the spec" and it doesn't run on Windows), I can safely state this is not a behavior we intend to alter at this point.

Now, if the working group takes a decision and other vendors like Google and Mozilla also agree to follow that new definition of :read-write/:read-only, we can of course reevaluate our position.

> -----Original Message-----
> From: Simon Pieters [mailto:simonp@opera.com]
> Sent: Tuesday, April 19, 2016 12:59 AM
> To: www-style@w3.org
> Cc: Benjamin Poulain <benjamin@webkit.org>; Fran├žois REMY
> <francois.remy.dev@outlook.com>; Chris Rebert <csswg@chrisrebert.com>
> Subject: [css-ui][selectors] Definition of :read-only
> 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.
> :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.
> Benjamin says he does not intend to change WebKit; meanwhile the Edge
> issue appears to be closed as "By design". I don't care which way we go here
> but someone needs to change their mind if we want interop here. :-)
> Chromium and Edge bugs about :read-only not matching the spec:
> https://bugs.chromium.org/p/chromium/issues/detail?id=604154

> https://developer.microsoft.com/en-us/microsoft-

> edge/platform/issues/7229941/
> WebKit bug to update these selectors (fixed in 2014):
> https://bugs.webkit.org/show_bug.cgi?id=136566

> Gecko bug to implement :read-only and :read-write:
> https://bugzilla.mozilla.org/show_bug.cgi?id=312971

> --
> Simon Pieters
> Opera Software

Received on Tuesday, 19 April 2016 16:21:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:58 UTC