This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17812 - :read-write should always apply to input elements if @readonly doesn't apply
Summary: :read-write should always apply to input elements if @readonly doesn't apply
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: Selectors (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: fantasai
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 06:53 UTC by contributor
Modified: 2016-04-20 05:33 UTC (History)
9 users (show)

See Also:


Attachments

Description contributor 2012-07-18 06:53:35 UTC
This was was cloned from bug 15428 as part of operation convergence.
Originally filed: 2012-01-05 14:26:00 +0000
Original reporter: Mounir Lamouri <mounir.lamouri@gmail.com>

================================================================================
 #0   Mounir Lamouri                                  2012-01-05 14:26:21 +0000 
--------------------------------------------------------------------------------
Given that the reasons why bug 13390 isn't going to be fixed means the widgets can't be read only I guess it would make sense to have :read-write applying to them.
However, some of the input types for which @readonly doesn't apply shouldn't be considered :read-write like hidden, button, submit and reset. The ones that should be :read-write are: range, color, checkbox, radio and file.

I think the specs should add as a second item after: "The :read-write pseudo-class must match any element falling into one of the following categories:" (4.14.2, ":read-write"), the following case:
"input elements to which the readonly attribute does not apply and with a value mode different from value."
If the value mode seems wrong, we could list the types for which it applies or the types for which it doesn't.
================================================================================
 #1   Ian 'Hixie' Hickson                             2012-02-02 21:54:14 +0000 
--------------------------------------------------------------------------------
IMHO neither should really apply to them, but the way I read CSS3 UI every element should match one or the other.
================================================================================
 #2   Ms2ger                                          2012-02-03 09:33:42 +0000 
--------------------------------------------------------------------------------
Should we change CSS3UI?
================================================================================
Comment 1 Ian 'Hixie' Hickson 2012-08-23 21:53:04 UTC
So Selectors says "An element whose contents are not user-alterable is :read-only". What does "contents" mean?

fantasai: any chance Selectors could either be updated to be clearer about what :read-only and :read-write are supposed to match, or be changed so it's clear that it's up to us to define whether an element matches it or not? Ideally IMHO it'd be possible for elements to match neither, but if that's not possible, then how about just defining one as being :not(:the-other) and defining the former as defaulting to match/not-match except where otherwise specified? That would make things the simplest. Right now it's highly unclear what in Selectors is supposed to be normative and what is supposed to be descriptive.
Comment 2 Ian 'Hixie' Hickson 2012-11-01 00:30:42 UTC
Selectors is pretty clear now that they're opposites. :read-write matches anything "user-alterable". Buttons and checkboxes aren't really "user-alterable" as far as I can tell. You can interact with them, but then you can interact with a readonly text field too, it still isn't "user-alterable".
Comment 3 Ian 'Hixie' Hickson 2013-01-30 23:52:24 UTC
mounir: Unless there's an objection to comment 2, I plan to close this without changes. But I don't think the arguments against change are very strong, so if there's a strong argument for change (e.g. a use case where using :read-write to match radio buttons would be useful) then let me know. I don't really know what the use cases are here one way or the other.
Comment 4 Mounir Lamouri 2013-02-19 14:01:29 UTC
It's not clear to me what "content" is. By clicking on a checkbox, a radio, interacting with a file picker or a slider, you change there values. I don't know if that's what the spec has in mind. I would oppose those elemens/cases to buttons or <input type='hidden'>, <input type='image'> where you can't modify the value.
Comment 5 Ian 'Hixie' Hickson 2013-04-12 18:50:45 UTC
Yeah, I dunno either.

Can someone from the CSSWG update the Selectors spec to be clearer here?
Comment 6 Tab Atkins Jr. 2013-04-12 19:35:32 UTC
(In reply to comment #5)
> Yeah, I dunno either.
> 
> Can someone from the CSSWG update the Selectors spec to be clearer here?

The current text is *explicitly* designed to be generic, so the host language can decide what it means.  In other words, it's HTML's responsibility to define when different elements match :read-write; CSS can't possibly define it sufficiently for HTML while also being generic enough for other languages.
Comment 7 Ian 'Hixie' Hickson 2013-04-14 08:00:41 UTC
Tab: Well we're not going to get conceptual interop between host languages if we don't have more advice from the Selectors spec. Is a radio button "user-alterable"? Is a push button "user-alterable"? Is a <select> "user-alterable"? An iframe that you can scroll? A read-only control you can scroll? A <canvas> where JavaScript has been hooked up to allow the user to draw on it? Some guidance in the Selectors spec would be much appreciated.
Comment 8 Tab Atkins Jr. 2013-04-14 17:07:35 UTC
Sigh, okay, I'll work up some text.  Spoiler alert: it's meant to apply to form inputs.
Comment 9 Ian 'Hixie' Hickson 2013-04-24 00:35:45 UTC
I would assume it doesn't apply to radio buttons, since they're not alterable, just selectable, though, right? Or not? I'm unclear on what the intent is.
Comment 10 Tab Atkins Jr. 2013-04-24 19:55:32 UTC
(In reply to comment #9)
> I would assume it doesn't apply to radio buttons, since they're not
> alterable, just selectable, though, right? Or not? I'm unclear on what the
> intent is.

After trying a bit, I can't get the text any clearer without just explicitly listing out the HTML elements it applies to.

So, here's our interpretation instead.  Feel free to just put it into HTML.

:read-write should match:
* <select>, <textarea>, and all <input> types except the ones that are buttons.  (unless readonly or disabled)
* Any element with [contenteditable].

:read-only should match:
* everything else
Comment 11 Mounir Lamouri 2013-04-25 14:14:02 UTC
So that means that all <input> have :read-write applying unless they are readonly or they are type={button,reset,submit} ?
Comment 12 Tab Atkins Jr. 2013-04-25 17:06:48 UTC
(In reply to comment #11)
> So that means that all <input> have :read-write applying unless they are
> readonly or they are type={button,reset,submit} ?

Or disabled, yes.  (Also, type=image I think?)
Comment 13 Mounir Lamouri 2013-04-25 17:24:54 UTC
Yes, 'image'. And maybe 'hidden' too, right? Every input type with a value mode equal to 'default'.
Comment 14 Ian 'Hixie' Hickson 2013-04-25 20:27:24 UTC
Is a radio button a button?
Comment 15 Ian 'Hixie' Hickson 2013-04-25 20:30:19 UTC
I don't see anything wrong with listing control types explicitly in the Selectors spec, for what it's worth. That may be the best way to get interop amongst different host languages. Obviously it would have to be an open-ended, "define by example"-style definition, but even that would be better than just "user-alterable". (I don't think it makes sense to base the HTML spec on the description of intent given in a bug comment. That's not normative, and other languages aren't going to know about it.)
Comment 16 Tab Atkins Jr. 2013-04-25 20:30:46 UTC
(In reply to comment #14)
> Is a radio button a button?

No.  The list is what Mounir has said - type=button/reset/submit/image/hidden shouldn't be :read-write, because there's no state for the user to change.  Neither should any of the <button> types.  The rest of the form inputs should be, unless they're readonly or disabled.
Comment 17 Tab Atkins Jr. 2013-04-25 20:31:26 UTC
(In reply to comment #15)
> I don't see anything wrong with listing control types explicitly in the
> Selectors spec, for what it's worth. That may be the best way to get interop
> amongst different host languages. Obviously it would have to be an
> open-ended, "define by example"-style definition, but even that would be
> better than just "user-alterable". (I don't think it makes sense to base the
> HTML spec on the description of intent given in a bug comment. That's not
> normative, and other languages aren't going to know about it.)

Define the list of HTML elements that match it, and Selectors will link to HTML as an example.
Comment 18 Ian 'Hixie' Hickson 2013-04-25 22:20:06 UTC
We discussed this on IRC, and basically it seems none of us know what the use cases for these pseudo-classes (:read-only and :read-write) are. We should probably study how common it is for these pseudos to be used, and see how they are used, and work from there.
Comment 19 Mounir Lamouri 2013-04-28 23:06:40 UTC
(In reply to comment #18)
> We discussed this on IRC, and basically it seems none of us know what the
> use cases for these pseudo-classes (:read-only and :read-write) are. We
> should probably study how common it is for these pseudos to be used, and see
> how they are used, and work from there.

Is it really used? Currently, there are three implementations of :read-write / :read-only: Gecko, Presto and Webkit. On Gecko, it is prefixed and Webkit and Presto have a different behaviour. Presto has a behaviour that seems similar to what this bug requests while Webkit seems to stick to what the HTML specification seems to request.

I've put together a simple test case:
http://www.browserstack.com/screenshots/2841286b61558a924e8feb192cbd18200ef91646

We could add some telemetry checks in Gecko to see how much :-moz-read-write and :-moz-read-only are used but I doubt that would give us much interesting information because I doubt they are used widely.

Hixie, do you have any plan to check how those pseudo-classes are currently used?
Comment 20 Ian 'Hixie' Hickson 2013-04-30 17:07:35 UTC
I am going to try, but I don't have a good way to study CSS usage.
Comment 21 Ian 'Hixie' Hickson 2013-05-29 00:00:32 UTC
Looking just at HTML pages (not CSS files, so this only counts <style> elements and people talking about these in the page content itself, like this very bug), I found about 50k pages from a sample of billions that contain any of ':read-only', ':read-write', ':-moz-read-only', or ':-moz-read-write'. From this set, the page with the highest prominence (according to some obscure internal Google metric) was the HTML spec on the WHATWG site... :-) Most of the rest were also pages about HTML or CSS, dev tutorials, etc.

Here's some of the ones I saw that weren't to do with the Web:

 http://room-parttime.blogspot.com/2013/02/part-time-kfc.html
 http://www.filmystudio.com/2013/01/bengali-movie-deewana-2013-cam-rip-full.html
   These mention it in the same minified JS and I doubt would be affected
   by us dropping this feature. (There's a lot of these, they all seem to be
   Blogger-related, maybe?)

 http://www.reform-tone.com/
 http://www.corolla-kagoshima.jp/
   These uses it as a hack to target specific browsers.

 http://www.recycleformerseyside.com/education/recycling-game/
   I can't find where the match came from on this page.

Anyway, my conclusion is that we can probably drop :read-only/:read-write.
Comment 22 Mounir Lamouri 2013-05-29 14:52:26 UTC
(In reply to comment #21)
> Anyway, my conclusion is that we can probably drop :read-only/:read-write.

I would prefer to fix the specification instead of dropping them unless the CSS spec drops them too and all browsers implementing them drops their implementations.
Comment 23 Ian 'Hixie' Hickson 2013-06-12 17:54:34 UTC
Right, I meant drop them from CSS and other browsers.
Comment 24 Ian 'Hixie' Hickson 2013-06-18 23:37:12 UTC
Tab, fantasai: given the data in comment 21, would you object to just dropping the feature from Selectors?
Comment 25 Ian 'Hixie' Hickson 2013-07-02 21:47:53 UTC
Reassigning to CSS for further processing; please reassign back to me if we can't drop these after all.
Comment 26 Chris Rebert 2016-04-20 05:33:16 UTC
Relevant new www-style thread:
https://lists.w3.org/Archives/Public/www-style/2016Apr/0294.html