Closed Bug 312971 Opened 19 years ago Closed 4 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
b2g-v1.3 ? ---
firefox78 --- fixed

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?
Blocks: 313111
No longer blocks: 271720
Assignee: dbaron → nobody
QA Contact: ian → style-system
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.
Sounds good.  Is comment 1 you volunteering to do the looking at?
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?
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.
> 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?
Maybe.  Depends on whether that part of the spec is stable, for example.
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.
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?
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.
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.
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.
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.
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.
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.
(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
That said, the relevant spec doesn't really say how they're supposed to work.
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.
(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.
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?
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.
I agree with comment 17; this also needs a good test suite testing all the relevant cases, not just contenteditable and textarea.
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.
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?
> 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...
Blocks: 344614
Keywords: html5
Keywords: dev-doc-needed
Whiteboard: [parity-webkit][parity-blink][parity-opera]
Mentor: bzbarsky
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")
Whiteboard: [parity-webkit][parity-blink][parity-opera] → [parity-webkit][parity-blink][parity-opera][lang=c++]
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.
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.
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
Depends on: 612128, contenteditable
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
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.
i see - will this ever be fixed?
Depends on: 888884
Whiteboard: [parity-webkit][parity-blink][parity-opera][lang=c++] → [parity-webkit][parity-blink][parity-opera][parity-edge][lang=c++]
Blocks: unprefix
Summary: Support :read-only and :read-write pseudoclasses → Support :read-only and :read-write pseudoclasses (unprefix)
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
Keywords: site-compat
No longer blocks: 1337166
Whiteboard: [parity-webkit][parity-blink][parity-opera][parity-edge][lang=c++] → [parity-webkit][parity-blink][parity-presto opera][parity-edge][lang=c++]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-webkit][parity-blink][parity-presto opera][parity-edge][lang=c++] → [lang=c++]
Blocks: html-forms

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 ?

Flags: needinfo?(emilio)
Flags: needinfo?(bzbarsky)

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.

Flags: needinfo?(emilio)

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.

Depends on: 715484
Flags: needinfo?(bzbarsky)
Whiteboard: [lang=c++] → [lang=c++][wpt-triaged]
Mentor: bzbarsky

And remove some duplicated tests from WPT.

Depends on D75230

Assignee: nobody → emilio
Status: NEW → ASSIGNED

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.

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

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c2658687ac23
Unprefix -moz-read-write / -moz-read-only. r=edgar
Attachment #9148212 - Attachment description: Bug 312971 - Unprefix -moz-read-write / -moz-read-only. r=smaug → Bug 312971 - Unprefix -moz-read-write / -moz-read-only. r=edgar
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Blocks: 1577457

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

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

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

Blocks: 1638507
Regressions: 1641382

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!

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