Comments from CSS WG on XForms 1.0

As promised, the comments of the CSS WG on the XForms 1.0 draft
(http://www.w3.org/TR/2002/WD-xforms-20020118):



a) The criteria to exit from CR are too weak.

We suggest the criteria of the Selectors CR[1], with the addition
(which we unfortunately forgot to add to the Selectors criteria) that
features *may* be dropped in order to exit CR status. ("May" indicates 
that this is a case by case decision for each feature: sometimes it is 
better to drop the feature, sometimes to extend the CR period.)

[1] http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current



b) The "selectMany" element should have attributes for specifying the
minimum and maximum number of items to select.

Selections like "select between 1 and 5 of these 30" appear frequently
in practice. We realize that this makes "selectOne" redundant, but
that element can be kept as a convenience for authors.



c) The choice between "radiobutton" and "checkbox" should be made
automatically based on the number of items to select.

How the controls actually looks is a style question, but the semantics
of "radio" is that there is exactly one item selected from the set,
while "checkbox" means each item can be on or off independently. We
ask to drop "radiobutton" and "checkbox" and instead introduce a
single keyword, that means either, depending on whether min = max = 1
or not. Some suggestions: "togglebutton", "toggle", "togglebox",
"toggler".



d) HTTP GET should not be deprecated.

The semantics of GET and POST are different. As the HTTP spec says,
GET is idempotent, POST is not.



e) We suggest changing "should" to "may" in section 8.1, where it says 
that the UA "should" select the best UI widget for each data type.

The type is insufficient to really do a good job with picking an
appropriate widget. A derived type doesn't necessarily require the
same interface as its superclass. And even a Date may require
different interfaces, based on whether, e.g., the expected date is in
this month (a calendar might work), or long in the past (a text field
might be easier), or part of a set of similar dates (a set of text
fields with autocompletion).



f) We think there are problems with the inputMode attribute, but we
defer to the I18N group.



g) All elements that are intended to be displayed should have a
"style" attribute.

For various reasons (cut & paste of elements, experiments, local
overrides, consistency with SVG and HTML...), the "style" attribute is
a good thing. The fact that the "ideal" style sheet is an external
style sheet is not enough reason to disallow the attribute.



h) The "caption" element should be called "label" (8.12.4.1)

A caption is typically something associated with a table or a figure
and it is usually displayed below the thing it describes. The right
name for the element in XForms seems to be "label", which is also what 
HTML calls it.



i) The "cursor" (7.4.3.5) should be called something else.

A "cursor" will be understood by most people as the mouse pointer or
the insertion point in a text editor. Indeed, CSS uses 'cursor' as a
property to set the shape of the mouse pointer. To avoid confusion, we 
suggest a name such as "currentElement".



j) We suggest an informative section describing a "pseudo-element" to
allow a style sheet to address the actual input widget.

When styling the "input" element, one can select the caption (label),
the hint and the container that holds all of those, but not the actual
input widget. To allow styling of that input field, we suggest that
the XForms draft adds an informative section that introduces a
"pseudo-element" (a CSS term) that represents that object, which
exists on the screen but not in the source document. The name could be
'::input-value'.

The section should explain that the '::input-value' is a part of the
"input" element that conceptually comes at the end of the element. In
CSS, we typically use a "fictional tag sequence" to describe the tree
as it is seen by a renderer:

    <input><caption>...</caption><input::input-value/></input>

An example of its use would be the following, which creates (a row in)
a table with two columns and puts the label in the first column and
the input field in the second:

    input { display: table-row }
    input label { display: table-cell }
    input::input-value { display: table-cell }

It can be further styled with colors, backgrounds, borders, margins,
etc.


For the CSS WG,
Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 27 February 2002 06:24:14 UTC