I haven't noticed any discussion on this issue lately on the mailing
list, and I've heard nothing about any decisions regarding
:read-only/:read-write, so I'm posting a quick recap of issues regarding
the CSS3-UI specification.
Problems with the CSS3-UI Specification
I explain the problems with the spec in detail in the following URL:
User-Alterability (or Editability)
The term "read-only" is not a synonym for "user-alterable". It has UI
and form submission implications that are unrelated to one's ability to
edit element contents. While the styling of user-alterable elements has
merit, tying user-alterability to and element's read-only property does
not. If we are to have selectors for user-alterability specifically, we
need to separate them from the concept of read-only.
Problems with existing definitions of :read-only and :read-write
1) Form controls in XForms 1.0 that are set as "readonly" are not given
this value via a direct attribute, so you have to use :read-only in
order to style them. However, in an editing context, they will never
match :read-only because the pseudo-class is defined in terms of
user-alterability, and in a editor everything is user-alterable.
Therefore, read-only controls in XForms become impossible to style in an
editing context without referencing classes or specific IDs.
2) Because the HTML 4.01 specification clearly implies that "read-only
elements" in HTML consist only of <inputand <textareaelements that
have the |readonly| attribute, the definition of :read-only in CSS3-UI
is counterintuitive for someone coming from an HTML background who has
no prior knowledge of CSS3-UI. When they see "read-only", they will
think it refers to form controls with the |readonly| attribute. (Note
that :enabled and :disabled don't have this kind of counterintuitive
problem.)
3) Compounding the above problem, using :read-write under HTML 4.01
behaves exactly as one might anticipate, applying only to form controls
without the attribute |readonly|.
4) Because :read-only styles nearly all elements in a standard HTML
document in most browsers, it is useless for styling HTML read-only
elements. Selectors like "textarea[readonly]" and "input[readonly]"
would be the only selectors that select HTML read-only controls in both
browsing and editing contexts. However, if scripting is used to change
whether a control is read-only, the control may be styled incorrectly.
Therefore, if you toggle the read-only state of an HTML form control,
there's no way to ensure that the control will be styled properly in all
contexts.
5) Using the current definition, :disabled is a subset of :read-only
under typical browsing conditions. Therefore, a selector
"input:read-only" styles both <input readonlyand <input disabled>.
6) It is unclear if <selectis selected by :read-only. While you can
select a value, you cannot actually alter content. Rather, they select
from existing, unchangeable content. Therefore, under the current
definition, one might implement :read-only as applying to <select>.
7) Because :read-write is effectively defined as :not(:read-only), it
provides no additional functionality to CSS. By contrast,
:not(:disabled) selects far more elements than :enabled would.
8) What selectors do <input type="password"and <input type="password"
disabledmap to? In the current specification, they'd map to
:read-write and :read-only respectively, yet they clearly aren't
human-readable.
Requested Changes
I hereby request the following changes to CSS3-UI:
1) Replace the ":read-only and :read-write" section with the following:
| :read-only and :read-write
|
| The purpose of the :read-only and :read-write pseudo-classes is to
| allow authors to customize the look of elements which have a
| read-only property or attribute, or are otherwise bound to a node
| with a read-only model item property, that can be set in the
| markup. An element is :read-only if its associated "read-only"
| property or attribute is set to true. An element is :read-write if its
| associated "read-only" property or attribute is set to false.
|
| While the actual property or attribute name does not have to be
| "read-only", it must be defined as having read-only semantics. For
| instance, the HTML attribute "disabled" would not satisfy :read-only.
|
| It should be noted that most elements will be neither read-write nor
| read-only. Elements must be capable of having markup-explicit
| read-only/read-write states. Elements that have no means of setting
| the state will not be selected by either pseudo-class.
2) Insert the following section after ":active details":
| :enabled and :disabled details
|
| If focus is required to allow complete viewing of an element's
| content, the ability to receive focus may be ignored when determining
| if an element is :enabled or :disabled.
Possible Changes
We can also make additional changes to provide a selector
specifically for user-alterable markup:
1) Append the following to "New user interface state pseudo-classes":
| This specification also introduces a new :editable pseudo-class for
| the purpose of styling a greater range of user-alterable content.
2) Add the following section after ":read-only and :read-write":
| :editable
|
| An element whose contents are user-alterable (such as text input
| fields or non-control user-alterable content) is :editable. In typical
| documents, most elements are not :editable. However it may be possible
| (e.g. in the context of an editor) for any element to become
| :editable.
This is only a suggestion. You may choose to deal with user-alterable
content in a different manner.
Further Questions Related to the CSS3-UI Specification
1) Is there a reason :write-only was eliminated? It maps nicely to
<input type="password"in HTML. The only reason I can think of is that
it didn't fit the "user-alterable" definition of :read-only and
:read-write. If :read-only and :read-write are changed as I suggest, we
should probably take a second look at :write-only.
2) If selectors are their own language, why are selectors grouped here
with CSS properties in the same specification? Shouldn't these selectors
be separated out into a separate specification updates the Selectors
specification? ( course, you could make a similar argument for the
WHATWG specs regarding HTML/DM/JS)

dolphinling wrote:
Matthew Raymond wrote:

Problems with the CSS3-UI Specification

Without having read the CSS3-UI spec (I will (when should I get to it
by?)), how about the following change?

| CSS3-UI applies only to form elements.

If you mean that the /selectors/ in CSS3-UI only apply to form
elements, that would solve some problems but not all of them. For
instance, it wouldn't solve the problem of an <input readonlyelement
matching :read-write in an editor. It also wouldn't solve the problem of
disabled controls matching :read-only. Remember that :read-only and
:read-write are defined with regards to "user-alterability" and not by
any definition of read-only or read-write in XForms or HTML.

There's a big split between forms (the "Application" part of a web page)
and non-forms (the "Document" part of a web page). This split is in
meaning, use, their entire reason for existing. Shouldn't there be a way
to style one and not the other?

I recall someone suggesting a :control selector or something similar,
if that's what you mean. While this could be useful in some cases, it
doesn't solve specific problems I'm trying to address.

dolphinling wrote:
Matthew Raymond wrote:
>>dolphinling wrote:
Without having read the CSS3-UI spec (I will (when should I get to it
by?)), how about the following change?

| CSS3-UI applies only to form elements.
>>
>If you mean that the /selectors/ in CSS3-UI only apply to form
>>elements, that would solve some problems but not all of them. For
>>instance, it wouldn't solve the problem of an <input readonlyelement
>>matching :read-write in an editor. It also wouldn't solve the problem of
>>disabled controls matching :read-only. Remember that :read-only and
>>:read-write are defined with regards to "user-alterability" and not by
>>any definition of read-only or read-write in XForms or HTML.

So then my stance is that CSS3-UI should only apply to form
elements _and_ those things should be fixed. ;)

The way I redefine :read-only and :read-write, an element must be
defined in the markup language as being capable of supporting semantic
read-only or read-write states, and it must be possible to set those
states in markup. With that kind of definition, I'm not sure the
limitation to form controls is useful. For example, in the cases of
:in-range and :out-of-range, it may prevent things like an element being
styled differently if it's inside or outside of the bounds of its parent
element. Unnecessary restrictions are not desirable.