Re: Conclusion for :read-only and :read-write?

Allan Beaufour wrote:
> Is there a conclusion for what :read-only and :read-write should match for 
> (X)HTML?

   The W3C may have come to a conclusion, but certainly not one that
meets with my satisfaction.

   The trouble is that, as defined in CSS3-UI right now, user agent
states have more influence over whether :read-only or :read-write match
an element than the actual markup does. For instance, if you're in an
editor, <input readonly> could theoretically match :read-write.

   So, generally, it's like this:

   :read-write == user_editable
   :read-only == !user_editable

   (This can actually be contradictory to XForms 1.0 Appendix F in
situations where you're editing XForms content. It's similar to the
<input readonly> situation mentioned above.)

   Therefore, in a classic browser context, unless you're using
designMode or contentEditable, active read-write form controls match
:read-write, and _EVERYTHING ELSE_ matches :read-only. With
contentEditable, everything within an element set with |contenteditable|
as true is editable.

   This is contrary to the way :enabled and :disabled are defined.
Although it's been recently pointed out that their definition is flawed
(as the result of dependence on focusability), they're both generally
defined as matching elements that have semantic enabled and disabled
states. Therefore, if you can't define an element as one or the other in
markup, then the element doesn't match either selector.

   So, in my opinion, the CSS3-UI versions of :read-only and :read-write
are total disasters.

   It's been my suggestion that a new :editable pseudo-class be
introduced that would address editable content. Such a pseudo-class
could even be expanded to refer to specific types of editability:

| :editable { /* Style anything that's editable. */ }
| :editable(control) { /* Style for enabled, read-write controls. */ }
| :editable(editor) { /* Style for elements in an HTML editor. */ }
| :editable(in-page) { /* Style for contentEditable-type elements. */ }

   This would allow styling based on different editing states without
doing idiotic stuff like out-right contradicting the markup regarding
what "readonly" means.

   Media types for editors are another way to go, but I see them as a
bad solution, since you may be editing in a aural media type, for instance.

   With regards to Daniel Glazman's weblog post:

http://glazman.org/weblog/dotclear/index.php?2005/08/04/1148-read-write-and-read-only

   I guess I'm for Solution 3, with some Solution 1 mixed in. A way to
style stuff in various editing contexts is nice, but it shouldn't have
anything to do with semantic read-only/read-write states.

> There seems to be some sort of consensus about form controls, but how about 
> "plain" HTML elements (ie. everything else than form controls).

   Under the current definition, they'd match :read-only in a
non-editable context, and :read-write in an editable context.

> It's 
> questionable whether they should match the selectors at all, given the 
> current challenges with editable content (see Daniel's blog post). Is there 
> an official clarification on this? We need to take a decision for the Mozilla 
> implementation now...

   I don't think there's an official clarification on this, other than
that the CSS3-UI spec most certainly DOES say that non-control elements
match :read-only in non-editing cases.

   You could implement :read-only and :read-write as only applying to
elements where you can specifically set the read-only/read-write state
in markup, which is definitely what I'd prefer, but the problem is that
changing it later to the CSS3-UI definition would result in styles being
applied to elements unintentionally.

   If you have to make a decision now, I'd say go with something like
":-moz-read-only" and ":-moz-read-write" until this gets figured out.
Either that or just break with the W3C and implement something more in
line with the XForms 1.0 definitions.

Received on Wednesday, 10 August 2005 19:46:53 UTC