17812 2012-07-18 06:53:35 +0000 :read-write should always apply to input elements if @readonly doesn't apply 2016-04-20 05:33:16 +0000 1 1 1 Unclassified CSS Selectors unspecified Other other NEW http://code.google.com/p/chromium/issues/detail?id=604154 P3 normal --- 1 contributor fantasai.bugs fantasai.bugs ian jackalmage jonas mike mounir Ms2ger tantek w3bugs public-css-bugzilla oldest_to_newest 70094 0 contributor 2012-07-18 06:53:35 +0000 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? ================================================================================ 72655 1 ian 2012-08-23 21:53:04 +0000 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. 77627 2 ian 2012-11-01 00:30:42 +0000 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". 82377 3 ian 2013-01-30 23:52:24 +0000 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. 83321 4 mounir 2013-02-19 14:01:29 +0000 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. 86055 5 ian 2013-04-12 18:50:45 +0000 Yeah, I dunno either. Can someone from the CSSWG update the Selectors spec to be clearer here? 86067 6 jackalmage 2013-04-12 19:35:32 +0000 (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. 86174 7 ian 2013-04-14 08:00:41 +0000 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. 86179 8 jackalmage 2013-04-14 17:07:35 +0000 Sigh, okay, I'll work up some text. Spoiler alert: it's meant to apply to form inputs. 86649 9 ian 2013-04-24 00:35:45 +0000 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. 86710 10 jackalmage 2013-04-24 19:55:32 +0000 (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 86780 11 mounir 2013-04-25 14:14:02 +0000 So that means that all <input> have :read-write applying unless they are readonly or they are type={button,reset,submit} ? 86801 12 jackalmage 2013-04-25 17:06:48 +0000 (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?) 86804 13 mounir 2013-04-25 17:24:54 +0000 Yes, 'image'. And maybe 'hidden' too, right? Every input type with a value mode equal to 'default'. 86814 14 ian 2013-04-25 20:27:24 +0000 Is a radio button a button? 86815 15 ian 2013-04-25 20:30:19 +0000 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.) 86816 16 jackalmage 2013-04-25 20:30:46 +0000 (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. 86817 17 jackalmage 2013-04-25 20:31:26 +0000 (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. 86823 18 ian 2013-04-25 22:20:06 +0000 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. 86934 19 mounir 2013-04-28 23:06:40 +0000 (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? 87014 20 ian 2013-04-30 17:07:35 +0000 I am going to try, but I don't have a good way to study CSS usage. 88334 21 ian 2013-05-29 00:00:32 +0000 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. 88376 22 mounir 2013-05-29 14:52:26 +0000 (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. 89184 23 ian 2013-06-12 17:54:34 +0000 Right, I meant drop them from CSS and other browsers. 89524 24 ian 2013-06-18 23:37:12 +0000 Tab, fantasai: given the data in comment 21, would you object to just dropping the feature from Selectors? 90147 25 ian 2013-07-02 21:47:53 +0000 Reassigning to CSS for further processing; please reassign back to me if we can't drop these after all. 125937 26 w3bugs 2016-04-20 05:33:16 +0000 Relevant new www-style thread: https://lists.w3.org/Archives/Public/www-style/2016Apr/0294.html