312971 - Support :read-only and :read-write pseudoclasses (unprefix)

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect)

Description

[Allan Beaufour]

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]

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 [:bzbarsky]]

Sounds good.  Is comment 1 you volunteering to do the looking at?

Comment 3

[d]

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 [:bzbarsky]]

designMode.

Comment 5

[d]

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]

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 [:bzbarsky]]

> I just realized that it's another name for contenteditable (correct?)

Yes, exactly.

Comment 8

[d]

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 [:bzbarsky]]

Maybe.  Depends on whether that part of the spec is stable, for example.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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]

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 [:bzbarsky]]

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]

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]

Attachment: 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]

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 [:bzbarsky]]

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 [:bzbarsky]]

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:]

(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:]

That said, the relevant spec doesn't really say how they're supposed to work.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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:]

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]

(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]

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 [:bzbarsky]]

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:]

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 [:bzbarsky]]

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]

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 [:bzbarsky]]

> 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]]

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 [:bzbarsky]]

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

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: 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:]

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]

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 [:bzbarsky]]

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]

i see - will this ever be fixed?

Comment 36

[Boris Zbarsky [:bzbarsky]]

See comment 32.

Comment 37

[Chris Rebert]

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

Comment 38

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 39

[Tim Nguyen :ntim]

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 ?

Comment 40

[Emilio Cobos Álvarez (:emilio)]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 42

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 312971 - Unprefix -moz-read-write / -moz-read-only. r=edgar

And remove some duplicated tests from WPT.

Depends on D75230

Comment 43

[Anne (:annevk)]

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.

Comment 44

[Emilio Cobos Álvarez (:emilio)]

(In reply to Anne (:annevk) from comment #43)
Done!

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c2658687ac23
Unprefix -moz-read-write / -moz-read-only. r=edgar

Comment 46

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/c2658687ac23

Comment 47

[j.j.]

Is there / should there be a bug for removing support of the prefixed version in some future?

Comment 48

[Kohei Yoshino]

Posted a site compatibility note for this. Also updated our compatibility checker to inform the deprecation.

Comment 49

[Emilio Cobos Álvarez (:emilio)]

(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

[Chris Mills [:cmills]]

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!