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

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
12 years ago
8 days ago

People

(Reporter: Allan Beaufour, Unassigned, Mentored)

Tracking

(Depends on: 1 bug, Blocks: 4 bugs, 4 keywords)

Trunk
css3, dev-doc-needed, html5, site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(b2g-v1.3?)

Details

(Whiteboard: [parity-webkit][parity-blink][parity-opera][parity-edge][lang=c++], URL)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
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?
(Reporter)

Updated

12 years ago
Blocks: 313111
(Reporter)

Updated

12 years ago
No longer blocks: 271720
Assignee: dbaron → nobody
QA Contact: ian → style-system

Comment 1

8 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.
Sounds good.  Is comment 1 you volunteering to do the looking at?

Comment 3

8 years ago
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.

Comment 5

8 years ago
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

8 years ago
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.

Comment 8

8 years ago
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.

Comment 11

8 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?
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

8 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

8 years ago
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

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

8 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

8 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?
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.

Comment 27

8 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?
> 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

7 years ago
Blocks: 344614
Keywords: html5
Blocks: 802882

Updated

4 years ago
Keywords: dev-doc-needed

Updated

4 years ago
tracking-b2g-v1.3: --- → ?

Updated

3 years ago
Whiteboard: [parity-webkit][parity-blink][parity-opera]
Mentor: bzbarsky@mit.edu
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.
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.
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, 237964

Comment 33

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

2 years ago
i see - will this ever be fixed?
See comment 32.

Updated

2 years ago
Depends on: 888884
Whiteboard: [parity-webkit][parity-blink][parity-opera][lang=c++] → [parity-webkit][parity-blink][parity-opera][parity-edge][lang=c++]
Blocks: 1337166

Updated

3 months ago
Blocks: 775235
Summary: Support :read-only and :read-write pseudoclasses → Support :read-only and :read-write pseudoclasses (unprefix)

Comment 37

3 months 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

a month ago
Keywords: site-compat
No longer blocks: 1337166
You need to log in before you can comment on or make changes to this bug.