W3C home > Mailing lists > Public > www-style@w3.org > July 2011

[css3-ui] Inconsistencies in the definition of :read-only and :read-write

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Fri, 15 Jul 2011 00:01:05 -0400
Message-ID: <4E1FBB81.5050909@earthlink.net>
To: W3C CSS <www-style@w3.org>
   The current Editor's Draft states that all pseudo-classes are
supposedly provided for forms styling:

| Specifically, these new states (except for :default) are provided as
| a way to style elements which are in the respective states as defined
| by XForms [XFORMS10].
- http://dev.w3.org/csswg/css3-ui/#pseudo-classes

   Now, lets look at four pairs of pseudo-classes that are found in
Section G.1 of the XForms 1.1 specification:

:enabled & :disabled

| What constitutes an enabled state, a disabled state, and a user
| interface element is language-dependent. In a typical document most
| elements will be neither :enabled nor :disabled.
- http://www.w3.org/TR/css3-selectors/#enableddisabled

:required & :optional

| A form element is :required or :optional if a value for it is,
| respectively, required or optional before the form it belongs to is
| submitted. Elements that are not form elements are neither required
| nor optional.
- http://dev.w3.org/csswg/css3-ui/#pseudo-required-value

:valid & :invalid

| An element is :valid or :invalid when it is, respectively, valid or
| invalid with respect to data validity semantics defined by a
| different specification (e.g. [XFORMS10]). An element which lacks data
| validity semantics is neither :valid nor :invalid.
- http://dev.w3.org/csswg/css3-ui/#pseudo-validity

:out-of-range & :in-range

| The :in-range and :out-of-range pseudo-classes apply only to
| elements that have range limitations. [...] An element that lacks
| data range limits or is not a form control is neither :in-range nor
| :out-of-range.
- http://dev.w3.org/csswg/css3-ui/#pseudo-range

   So here we have four separate pairs of XForms-inspired pseudo-classes
that have the following in common:

1) They are all limited to specific elements that are defined as
supporting specific states by their respective languages.

2) They all explicitly state that elements that lack the necessary
semantics do not match either state.

3) All of these pseudo-classes are compatible with their non-normative
definitions under Section G.1 of the XForms 1.1 spec.

   By contrast, :read-only and :read-write break all theses conditions:

1) They disregard any explicit, language-defined read-write state
semantics. (In fact, the whole idea that read-only and read-write may
have semantic meanings beyond user-alterability is ignored.)

2) By definition, there are no elements that wouldn't fall under one of
the two pseudo-classes.

3) The would style XForms and other elements that did not have a
read-only property, contrary to their G.1 definitions.

   Now, let's say we decided later to add pseudo-classes for controls
that are defined like the G.1 versions of :read-only and :read-write.
Those names are take, so we'd have to use something like
:control-read-write or :control-read-only. Developers using CSS may
confuse the two with unfortunate results.

   I would recommend the text of the CSS3-UI specification be changed to
the following:

| The :read-write pseudo-class represents user interface elements that
| are in a read-write state; such elements have a corresponding
| read-only state.
| Conversely, the :read-only pseudo-class represents user interface
| elements that are in a read-only state; such elements have a
| corresponding read-write state.
| What constitutes a read-write state, a read-only state, and a user
| interface element is language-dependent. In a typical document most
| elements will be neither :read-write nor :read-only.

   The above is consistent with the definition of :enabled and :disabled
in the Selectors Level 3 specification.

   I would also like to see the addition of a new :editable pseudo-class
should be added for elements that are user-alterable regardless of their
language semantics.

| An element whose contents are not user-alterable 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 would allow developers to define styles for elements that are
generally editable, but do not have a read-write state specified in the

   If a developer needs to style elements that are not user-alterable,
he/she could just use :not(:editable).
Received on Friday, 15 July 2011 04:01:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:28:29 UTC