Support :read-only and :read-write pseudoclasses (unprefix)
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
People
(Reporter: allan, Assigned: emilio)
References
(Blocks 3 open bugs, )
Details
(8 keywords, Whiteboard: [lang=c++][wpt-triaged])
Attachments
(3 files)
Bug 302188 "degraded into :-moz-read-only/:-moz-read-write, so this should track the real support for :read-only and :read-write. The main problem: How should these work for (X)HTML in an editable context?
Updated•16 years ago
|
Much has happened since 2005 and two engines now support those psuedoclasses (Presto and KHTML). I suggest we take a look at how they handle the situation, so that proper support finally can be implemented in Gecko.
Could be, but I need some kind of testcase or a description of the situation. "(X)HTML in an editable context" does in this case mean?
![]() |
||
Comment 4•14 years ago
|
||
designMode.
http://msdn.microsoft.com/en-us/library/ms533720%28VS.85%29.aspx ? If that is the the one we are talking about, it appears as if it is an IE proprietary property, which shouldn't matter to our implementation, I think? "Standards Information: There is no public standard that applies to this property."
I just realized that it's another name for contenteditable (correct?). If it is, I do not have any experience with it, but I'll experiment with it during the follow week and hopefully get some results.
![]() |
||
Comment 7•14 years ago
|
||
> I just realized that it's another name for contenteditable (correct?)
Yes, exactly.
I think the HTML5 specification provides the answer here: http://blog.whatwg.org/this-week-day-in-html-5-episode-22 ":read-write matches editable form fields and other editable elements, and :read-only matches any element that is not read-write" Is that the answer which is required to implement this properly?
![]() |
||
Comment 9•14 years ago
|
||
Maybe. Depends on whether that part of the spec is stable, for example.
![]() |
||
Comment 10•14 years ago
|
||
And note that in particular there was the claim that other UAs do something. I'd like to know what the something is, and whether it, say, matches the quoted spec text, before creating yet another just-so-incompatible implementation.
Comment 11•14 years ago
|
||
I can agree on the "stable spec part", but I thought we were supposed follow the spec, even though other browsers might do it wrong?
![]() |
||
Comment 12•14 years ago
|
||
For a finalized spec, sure (usually; it might still just be buggy). For a spec that's still being written, the right course of action may be to change the spec if there are discrepancies. Or not. Depends on the situation.
Comment 13•14 years ago
|
||
I see what you mean. I will try to put together a testcase to test the other browser implementations in, during this or next week. Actually, only Opera with the Presto engine is available to me, if you, or someone else has access to a browser with KHTML, you are may post your results here.
Comment 14•14 years ago
|
||
Ok, it wasn't as complicated as I first thought. Something might be incorrect, if it is, please tell me and I will correct it for proper testing.
Comment 15•14 years ago
|
||
I just spotted an error where I forgot a # at the editable selector, but that does not matter here. The conclusions from this is that Opera seems to match "contenteditable" with :read-only. This is wrong according to the spec found earlier. As far as I've understood it, the textarea and contenteditable should be treated the same way. Firefox/Gecko does this, and I support that, backed up by the (possibly unstable) spec and the fact that logic tells us that something with contenteditable is both read and writeable. I suspect that the contenteditable situation has simply been overlooked by Opera and it matches the standard :read-only.
![]() |
||
Comment 16•14 years ago
|
||
In Safari (4) the textarea has a green background, while the "test of the contenteditable attribute" text has a red background. So it matches neither :read-only or :read-write. And this situation (the right behavior not being defined) is why what we have is implemented with a prefix instead of polluting the "final" version as Safari and Opera are. We could change the behavior of the prefixed version; I'd be opposed to dropping the prefix until the relevant spec is in CR; that's the usual procedure.
![]() |
||
Comment 17•14 years ago
|
||
In Safari (4) the textarea has a green background, while the "test of the contenteditable attribute" text has a red background. So it matches neither :read-only or :read-write. And this situation (the right behavior not being defined) is why what we have is implemented with a prefix instead of polluting the "final" version as Safari and Opera are. We could change the behavior of the prefixed version; I'd be opposed to dropping the prefix until the relevant spec is in CR; that's the usual procedure.
Comment 18•14 years ago
|
||
(In reply to comment #17) > And this situation (the right behavior not being defined) is why what we have > is implemented with a prefix instead of polluting the "final" version as Safari > and Opera are. We could change the behavior of the prefixed version; I'd be > opposed to dropping the prefix until the relevant spec is in CR; that's the > usual procedure. The relevant spec has been in CR for a while: http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw
Comment 19•14 years ago
|
||
That said, the relevant spec doesn't really say how they're supposed to work.
![]() |
||
Comment 20•14 years ago
|
||
Right; the question is whether we should be dropping the prefix while the spec that does say what they should do is not in CR.
Comment 21•14 years ago
|
||
http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#matching-html-elements-using-selectors has a bit more detail, though, but is not in CR
Comment 22•14 years ago
|
||
(In reply to comment #16) > In Safari (4) the textarea has a green background, while the "test of the > contenteditable attribute" text has a red background. So it matches neither > :read-only or :read-write. That is because Safari does not support :read-only or :read-write at all. Neither Webkit, nor Trident does that currently. Gecko supports it as experimental, while Presto and KHTML has "full" support without prefix.
Comment 23•14 years ago
|
||
With three specs backing this up, and logic which tells us that an element with the "contenteditable" attribute is both read and writeable, I think we can safely say that this the intended/correct behavior. The good thing is that this is the way Gecko currently supports it. Therefore, I think the only thing we need to do is to remove the requirement for -moz in a patch. Are we ready to do this?
![]() |
||
Comment 24•14 years ago
|
||
Oh, I see. You really did mean KHTML and not webkit. Some people use them interchangeably... ;) I think my position is in comment 17; I'd like to know what David thinks.
Comment 25•14 years ago
|
||
I agree with comment 17; this also needs a good test suite testing all the relevant cases, not just contenteditable and textarea.
![]() |
||
Comment 26•14 years ago
|
||
In konqueror the "test of the contenteditable attribute" div is yellow until I click on it. Then it turns green and stays green after that.
Comment 27•14 years ago
|
||
Ok. I understand your opinions in this situation, while I think the spec is pretty obvious and isn't likely to change, but with so many different behaviors around, it's hard to know. Personally I believe that both Opera and KHTML is handling this wrong, and so says the spec(s). Opera have most likely overlooked the situation of contenteditable, and KHTML probably doesn't register the fact that it is editable until it actually gets edited. This just leaves me with two questions. When is the spec estimated to reach a point where you feel OK with implementing it, and, who would put together a large test suite for this?
![]() |
||
Comment 28•14 years ago
|
||
> When is the spec estimated to reach a point where you feel OK with implementing > it Ian's estimate is 2012 for HTML5 as a whole (this might not be a bad estimate; hard to tell so far). This section might get there sooner, perhaps. > who would put together a large test suite for this? Whoever wants to...
Updated•13 years ago
|
![]() |
||
Updated•9 years ago
|
Comment 29•9 years ago
|
||
Off the top of my head, some places to start investigating: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPseudoClassList.h SelectorMatches (in http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSRuleProcessor.cpp, see "// test for pseudo class match")
![]() |
||
Comment 30•9 years ago
|
||
The right place to start is probably adding tests per comment 25. The actual mechanics of dropping the prefix are pretty simple, but we need to figure out what various browsers, including us, are actually doing first.
Comment 31•9 years ago
|
||
Started writing some tests for :read-only and :read-write according to the WHATWG spec [1]. green -> test pass red -> test fail yellow -> neither selectors apply. radio and checkbox elements appear if the test passes, do not appear if the test fails. The test is for all input controls (minus hidden) and textarea with default, readonly, and disabled state; mostly all HTML (visible) HTML elements with contenteditable="true" and "false". There's also a test for a contenteditable="false" inside a contenteditable="true". I can't think of any other case at the moment. This is what I found accross UAs. == Chrome 39/Blink * input controls for which @readonly does not apply do not match :read-only nor :read-write (expected :read-only) * input controls for which @readonly applies, disabled state match :read-write (expected :read-only) * textarea readonly or disabled matches :read-write (expected :read-only) == Opera 26.0/Blink Same as Chrome == Internet Explorer 11.0/Trident Does not support :read-only, :read-write (maybe with prefix?) == Safari 5.1.7/WebKit * Same as Chrome and, * input type="color" matches :read-only (expected :read-write) contenteditable="true" does not match :read-write or :read-only (expected :read-write) == Firefox Nightly 36.0a1/Gecko * input type number matches :read-only (expected :read-write) * [Bug 620766] input controls for which @readonly applies, disabled state match * :read-write (expected :read-only) textarea readonly or disabled matches :read-write (expected :read-only) It looks like all browsers do not follow the spec for input controls for which @readonly applies and are disabled (spec says :read-only, all UAs match :read-write). Similarly textarea with readonly or disabled state matches :read-write for all UAs instead of :read-only. [1] https://html.spec.whatwg.org/multipage/scripting.html#selector-read-only.
Comment 32•8 years ago
|
||
bug 237964 added support for the :-moz-read-{only,write} pseudos for contenteditable bug 612128 added support for the :-moz-read-{only,write} pseudos for textfields need to figure out what else we need to do in order to be done and unprefix
Comment 33•8 years ago
|
||
thanks for the fixes. but apparently this css selector still does not work on the latest firefox: input[type="email"]:not(:-read-only), input[type="email"]:not(:-moz-read-only) { ... } they already do work fine on chrome ... let me know, thanks
![]() |
||
Comment 34•8 years ago
|
||
data:text/html,<style>input[type="email"]:not(:-moz-read-only) { color: purple }</style><input type="email" value="something"> works just fine for me. The selector you listed in comment 33 would cause the entire rule to be discarded, because ":-read-only" is not recognized and causes the whole selector to be invalid.
Comment 35•8 years ago
|
||
i see - will this ever be fixed?
![]() |
||
Comment 36•8 years ago
|
||
See comment 32.
Updated•7 years ago
|
Comment 37•6 years ago
|
||
Note that there is a spec bug trying to remove this (mis)feature, which would make unprefixing moot: https://github.com/w3c/csswg-drafts/issues/127
Updated•6 years ago
|
![]() |
||
Updated•5 years ago
|
![]() |
||
Comment 38•5 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Updated•5 years ago
|
Comment 39•4 years ago
|
||
I just came across this when working on bug 1577457, I assumed we supported this since all other browsers now support the unprefixed version.
Is there still a blocker to do this ?
Assignee | ||
Comment 40•4 years ago
|
||
Assuming we match the spec and the issues raised here don't affect our implementation we could give that a shot, IMO, but somebody needs to do the work of reviewing the implementation against the spec and fix any issue that comes up.
The change of unprefixing itself is trivial of course.
![]() |
||
Comment 41•4 years ago
|
||
Also, note that this bug definitely has open "depends on" bugs that would presumably need to be resolved.
But yes, the main problem is sorting out the spec-compliance angle.
Updated•4 years ago
|
![]() |
||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 42•3 years ago
|
||
And remove some duplicated tests from WPT.
Depends on D75230
Updated•3 years ago
|
Comment 43•3 years ago
|
||
Emilio, could you update https://github.com/whatwg/html/issues/3501 and https://github.com/w3c/csswg-drafts/issues/127 as appropriate? I'm guessing they would be WONTFIX and we file a bug against Chrome? Assuming the information there isn't dated.
There's also a form-associated custom elements angle here, but this should probably not block on resolving that, see https://github.com/whatwg/html/issues/5016#issuecomment-544027904 if you want to read more on that.
Assignee | ||
Comment 44•3 years ago
|
||
(In reply to Anne (:annevk) from comment #43)
Done!
Comment 45•3 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c2658687ac23 Unprefix -moz-read-write / -moz-read-only. r=edgar
Updated•3 years ago
|
![]() |
||
Comment 46•3 years ago
|
||
bugherder |
Comment 47•3 years ago
|
||
Is there / should there be a bug for removing support of the prefixed version in some future?
Comment 48•3 years ago
•
|
||
Posted a site compatibility note for this. Also updated our compatibility checker to inform the deprecation.
Assignee | ||
Comment 49•3 years ago
|
||
(In reply to j.j. from comment #47)
Is there / should there be a bug for removing support of the prefixed version in some future?
Yes, there should be.
Comment 50•3 years ago
|
||
I've updated the documentation to cover this; see https://github.com/mdn/sprints/issues/3282#issuecomment-638970670 for the details.
Let me know if you need anything else. Thanks!
Description
•