Request for returning CSS3-UI to Working Draft status

Daniel Glazman wrote:
> Anne van Kesteren wrote:
>>I have seen at least one e-mail to this list from a Mozilla developer 
>>asking for
>>clarification because they are planning to implement it for the next 
>>release.
>>(And branching will happen soon, so there is pressure.)
>>
>>That, and the CSS3 Basic User Interface Module is a W3C Candidate 
>>Recommendation
>>and therefore should be followed by browsers. Because some browsers also
>>implement methods for editing they want clarification on how the CSS3 
>>module
>>maps to that. Pretty simple.
> 
> Exactly. It's not time for comments on the contents themselves of
> CSS3-UI. There was plenty of time when the spec was only a draft.
> Thanks, Anne.

   Candidate Recommendations can be returned to Working Draft status if
the Working Group decides to make serious changes to the technical report...

[http://www.w3.org/2004/02/Process-20040205/tr.html#cfi]

| If the Working Group makes other substantive changes to the technical
| report, the Director MUST return it to the Working Group for further
| work.

| Possible next steps:
|     * Forward: Call for Review of a Proposed Recommendation
|     * Otherwise: return to Working Group or end work

[http://www.w3.org/2004/02/Process-20040205/tr.html#return-to-wg]

| The Working Group makes substantive changes to the technical report at
| any time after a Last Call announcement and prior to Publication as a
| Recommendation, except when the changes involve the removal of
| features at risk identified in a Call for Implementations. In the case
| of substantive changes, the Working Group MUST republish the technical
| report as a Working Draft.

   The specification "CSS3 Basic User Interface Module" has serious
flaws in that it is both self-contradictory and that it contradicts the
definition of what "read-only" is in HTML. It also redefines :read-only
and :read-write in a way that, instead of making them supersets of their
counterparts in XForms 1.0 Appendix F, makes them outright conflicting
with the XForms 1.0 versions of the pseudo-classes under some circumstances.

   With regard to the self-contradiction, CSS3-UI clearly establishes a
pretext of standardizing pseudo-classes in the non-normative XForms 1.0
Appendix F:

[http://www.w3.org/TR/2004/CR-css3-ui-20040511/#atrisk]

| All other features are either defined in a normative reference (e.g.
| CSS 2.1 [CSS21] or Selectors [SELECT]), or dependencies for another
| specification (e.g. XForms [XFORMS10]) or are believed to have one or
| more implementations (perhaps experimental), and thus will not be
| dropped without returning to last call.

   Note that XForms-related features are specifically cited as not being
at risk because of "dependencies" on XForms.

[http://www.w3.org/TR/2004/CR-css3-ui-20040511/#new-user]

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

   So above we see that the spec purports to honor the states as defined
in the XForms 1.0 spec...

[http://www.w3.org/TR/xforms/sliceF.html#id2644859]

| Selects any form control bound to a node with the model item property
| readonly evaluating to true or false (respectively).

   Note that the above refers to the "model item property readonly", and
not to whether or not the element is editable. However, CSS3-UI later
completely ignores the XForms definitions of the :read-only and
:read-write states...

[http://www.w3.org/TR/2004/CR-css3-ui-20040511/#pseudo-ro-rw]

| An element whose contents are not user-alterable is :read-only.
| However, elements whose contents are user-alterable (such as text
| input fields) are considered to be in a :read-write state. In typical
| documents, most elements are :read-only. However it may be possible
| (e.g. in the context of an editor) for any element to become
| :read-write.

   So, in spite of claiming _IN THE SPEC_ that it is dependent on the
XForms 1.0 state definitions, CSS3-UI turns right around and defines
read-only as being "user-alterable" rather than having a "readonly"
property assigned to it.

   The self-contradiction alone should be enough to bump it back to Last
Call, but one must also consider that the reason given for not making
features like :read-only and :read-write "at risk" is because they
supposedly depend on XForms. Well they don't! The definitions of
:read-only and :read-write have been fundamentally rewritten so that
they can even be contradictory to XForms 1.0 Appendix F in the context
of an editor. Therefore, the justification for leaving :read-only and
:read-write off the "at risk" list is completely flawed. Such major
editing errors within the spec itself alone should be cause enough to
return to Last Call Working Draft.

   But furthermore, the CSS3-UI pseudo-class definitions also create
situation where you have conflicting and competing definitions of what
"readonly" is. Remember that read-only elements in XForms are supposed
to have a "readonly" property? Well, HTML has a similar situation...

[http://www.w3.org/TR/html4/interact/forms.html#adef-readonly]

| The readonly attribute specifies whether the control may be modified
| by the user.
|
| When set, the readonly attribute has the following effects on an
| element:
|
|    * Read-only elements receive focus but cannot be modified by the
|      user.
|    * Read-only elements are included in tabbing navigation.
|    * Read-only elements may be successful.
|
| The following elements support the readonly attribute: INPUT and
| TEXTAREA.
|
| How read-only elements are rendered depends on the user agent.

   Note that elements with the "readonly" attribute are referred to as
"read-only elements". But we know from the definition of :read-write in
CSS3-UI that an HTML read-only element will be styled as a read-write
element when in a editing context. Therefore, the definitions of
"read-only" in the two specifications is contradictory, in spite of the
fact that these two technologies are supposed to be used _TOGETHER_.

   To sum up:

* CSS3-UI can be returned to working draft status.
* CSS3-UI is self-contradictory regarding its dependence on XForms.
* CSS3-UI gives flawed reasoning for :read-only and :read-write not
  being "at risk".
* CSS3-UI conflicts with the XForms 1.0 Appendix F definitions it is
  supposed to depend on.
* CSS3-UI creates a definition of the term "read-only" that conflicts
  with the definition in the HTML 4.01 Recommendation, a spec that it's
  supposed to interoperate with and that predates it by over four years.

   That seems like a pretty solid case for returning CSS3-UI to Working
Draft status to me. I don't understand your compulsion to use the terms
"read-only" and "read-write" when what you mean is "user-alterable". We
could always introduce pseudo-classes with different names that do the
exact same things as the CSS3-UI versions of :read-only and :read-write
if you feel such pseudo-classes are so vital. We could also devise a
much better system that's more flexible, in my opinion. I have yet to
understand why you don't wish to consider those possibilities and
instead defend pseudo-class definitions based solely on the fact that
those definitions made it into a candidate recommendation.

Received on Friday, 12 August 2005 19:43:31 UTC