This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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? ================================================================================
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.
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".
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.
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.
Yeah, I dunno either. Can someone from the CSSWG update the Selectors spec to be clearer here?
(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.
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.
Sigh, okay, I'll work up some text. Spoiler alert: it's meant to apply to form inputs.
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.
(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
So that means that all <input> have :read-write applying unless they are readonly or they are type={button,reset,submit} ?
(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?)
Yes, 'image'. And maybe 'hidden' too, right? Every input type with a value mode equal to 'default'.
Is a radio button a button?
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.)
(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.
(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.
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.
(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?
I am going to try, but I don't have a good way to study CSS usage.
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.
(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.
Right, I meant drop them from CSS and other browsers.
Tab, fantasai: given the data in comment 21, would you object to just dropping the feature from Selectors?
Reassigning to CSS for further processing; please reassign back to me if we can't drop these after all.
Relevant new www-style thread: https://lists.w3.org/Archives/Public/www-style/2016Apr/0294.html