CSS3-UI revisited

   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:

   http://lists.w3.org/Archives/Public/www-style/2005Aug/0099.html

*** 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 <input> and <textarea> elements 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 readonly> and <input disabled>.

6) It is unclear if <select> is 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"
disabled> map 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.

*** Other 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? (Of course, you could make a similar argument for the
WHATWG specs regarding HTML/DOM/JS...)

Received on Tuesday, 25 October 2005 18:54:56 UTC