Last Comment Bug 312971 - Support :read-only and :read-write pseudoclasses
: Support :read-only and :read-write pseudoclasses
Status: NEW
[parity-webkit][parity-blink][parity...
: css3, dev-doc-needed, html5
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: -- normal with 31 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors: Boris Zbarsky [:bz] (still a bit busy)
http://www.w3.org/TR/css3-ui/#pseudo-...
Depends on: 888884 contenteditable 612128
Blocks: 313111 html5forms html5test
  Show dependency treegraph
 
Reported: 2005-10-19 00:37 PDT by Allan Beaufour
Modified: 2016-11-21 23:01 PST (History)
39 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
?


Attachments
Testing :read-write and :read-only on contenteditable and a textarea (714 bytes, text/html)
2009-11-20 13:51 PST, d
no flags Details
Test for :read-only and :read-write (20.56 KB, text/html)
2014-11-27 21:37 PST, Giovanni Sferro [:agi]
no flags Details

Description Allan Beaufour 2005-10-19 00:37:17 PDT
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?
Comment 1 d 2009-11-20 07:48:57 PST
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.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 09:00:27 PST
Sounds good.  Is comment 1 you volunteering to do the looking at?
Comment 3 d 2009-11-20 09:17:47 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 09:40:53 PST
designMode.
Comment 5 d 2009-11-20 11:45:55 PST
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."
Comment 6 d 2009-11-20 11:51:04 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 12:03:33 PST
> I just realized that it's another name for contenteditable (correct?)

Yes, exactly.
Comment 8 d 2009-11-20 12:19:37 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 12:22:49 PST
Maybe.  Depends on whether that part of the spec is stable, for example.
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 12:23:33 PST
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 d 2009-11-20 12:26:49 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 12:38:33 PST
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 d 2009-11-20 12:57:03 PST
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 d 2009-11-20 13:51:36 PST
Created attachment 413698 [details]
Testing :read-write and :read-only on contenteditable and a textarea

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 d 2009-11-20 13:59:47 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 19:53:53 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 20:08:12 PST
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 David Baron :dbaron: ⌚️UTC-8 2009-11-20 20:21:19 PST
(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 David Baron :dbaron: ⌚️UTC-8 2009-11-20 20:22:15 PST
That said, the relevant spec doesn't really say how they're supposed to work.
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 20:24:08 PST
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 David Baron :dbaron: ⌚️UTC-8 2009-11-20 20:26:57 PST
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 d 2009-11-21 02:17:17 PST
(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 d 2009-11-21 05:57:38 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-21 09:42:56 PST
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 David Baron :dbaron: ⌚️UTC-8 2009-11-21 09:48:49 PST
I agree with comment 17; this also needs a good test suite testing all the relevant cases, not just contenteditable and textarea.
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2009-11-21 09:54:49 PST
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 d 2009-11-21 11:03:57 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2009-11-22 20:16:57 PST
> 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...
Comment 29 Josh Matthews [:jdm] (on vacation until Dec 5) 2014-11-21 12:21:11 PST
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 Boris Zbarsky [:bz] (still a bit busy) 2014-11-21 12:26:40 PST
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 Giovanni Sferro [:agi] 2014-11-27 21:37:49 PST
Created attachment 8530080 [details]
Test for :read-only and :read-write

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 David Baron :dbaron: ⌚️UTC-8 2015-08-27 07:54:07 PDT
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 michael.heuberger 2015-10-18 14:23:19 PDT
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 Boris Zbarsky [:bz] (still a bit busy) 2015-10-18 18:38:23 PDT
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 michael.heuberger 2015-10-18 23:22:23 PDT
i see - will this ever be fixed?
Comment 36 Boris Zbarsky [:bz] (still a bit busy) 2015-10-19 04:33:01 PDT
See comment 32.

Note You need to log in before you can comment on or make changes to this bug.