Re: Request for returning CSS3-UI to Working Draft status

Anne van Kesteren wrote:
> Quoting Matthew Raymond <mattraymond@earthlink.net>:
>>* CSS3-UI is self-contradictory regarding its dependence on XForms.
> 
> It is the other way around. XForms depends on CSS3-UI for styling. Also,
> everything XForms says is non-normative and therefore does not have to be
> followed.

   You are mistaken. CSS3-UI claims to depend on XForms explicitly.

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

| All other features are either defined in a normative reference [...],
| or _DEPENDENCIES FOR ANOTHER SPECIFICATION_ (e.g. XForms [XFORMS10])
| [...] more implementations (perhaps experimental), and thus will not
| be dropped without returning to last call.

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

   (Emphasis added in the above quotes.)

   CSS3-UI clearly claims to depend on XForms 1.0 state definitions, but
then proceeds with contradicting them. This is according to the language
of the spec. You would have a point if the spec itself DIDN'T claim that
it was using the XForms state definitions, but that's not the case.

>>* CSS3-UI conflicts with the XForms 1.0 Appendix F definitions it is
>> supposed to depend on.
> 
> Again, it is the other way around. It is also unclear to me how you could
> possible think that normative content depends on a non normative appendix.

   Look again. It specifically says that it's using the "respective
states as defined in XForms". It's true that normative portions of
specifications take priority over the non-normative parts of other
specs, but by creating a normative dependency on the non-normative
material in XForms, the material upon which you depend becomes
normative. It would have to in order for normative material to "depend"
on it in the first place.

>>* 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.
> 
> This is exactly why people ask for clarification with reflect to editing
> contexts. (There is no conflict with the definition in general, only in a
> specific case. If you want to make points, please be careful what you acuse a
> spec of.) And I believe people have been asking for clarification on that now
> and several sensible suggestions have been made by people from the WYSIWYG
> editor "area".

   The conflict between the definition of "read-only" in CSS3-UI and
HTML goes beyond editing contexts. Let's look at the HTML 4.01 spec again...

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

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

   In the above, "read-only elements" are defined as being able to
receive focus but being unmodifiable by the user, being included in
tabbing navigation and being successful in form submission. What
elements meet these criteria in HTML other than <input> and <textarea>,
which are also clearly defined as the only element that support
|readonly| (thus implying that the are the only elements that can be
"read-only elements" in HTML)?

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

| An element whose contents are not user-alterable is :read-only.

   Right off the bat, CSS3-UI is defining "read-only" in a manner much
broader that HTML, because it does not restrict read-only elements in
any way other than that they can't be altered by the user.

| In typical documents, most elements are :read-only.

   In a typical _HTML_ document, most elements are NOT "read-only",
because only <input> and <textarea> elements can be read-only as it is
defined in HTML. An HTML document without these two elements doesn't
have read-only elements.

   Even if you were to assume that "read-only elements" and elements
with the |readonly| attribute are not the same in the HTML 4.01 spec
(which is a huge stretch given the context in which the term "read-only
element" is used), "read-only" elements may still be successful (as in
successful for forms submission), which means it has to be a form
control in HTML.

   Granted, if I were to talk about editing contexts, the conflicts
become more apparent...

| However it may be possible (e.g. in the context of an editor) for any
| element to become :read-write.

   Here, the semantics of HTML are contradicted simply because the
content is being edited, since it's fairly obvious that elements with
|readonly| attributes are "read-only" under the HTML specification.

   Yet, as shown above, you don't need editing contexts at all to show a
conflict of definitions. Editing contexts only make it easier to show
how different those definitions are.

Received on Sunday, 14 August 2005 02:00:48 UTC