Re: Request for specific changes to CSS3-UI

Bert Bos wrote:
> But don't expect a definite answer soon. Not only is half the WG on 
> holiday, the first thing on the agenda is the CSS 2.1 comments, then we 
> have to review some drafts by other WGs and it is probably only after 
> that will we have time to discuss the UI draft again.
> 
> But be assured that the request is on our agenda.

   Okay, nearly two years later and nothing's happened. The CSS3-UI spec
still says Tantek works at Microsoft. Now that CSS 2.1 has reached CR, I
think it's time we revisit this issue. Here are the major problems:

1) The definition of a "readonly" element differs between HTML 4.01 and
CSS3-UI.

   In HTML 4.01, a "readonly" element can only be a control with a
"readonly" attribute. The CSS3-UI :readonly pseudo-class, as defined,
would match not only these elements but all non-control elements as well
(with the exception of markup in a |contenteditable| container).

2) As defined, :readonly undermines its original purpose for XForms.

   If XForms markup is editable, the current definition of :readonly
would not match any XForm control, even if the "readonly" property of
that control is true. Note that this is contradictory with the
non-normative information in the XForms 1.1 specification:

http://www.w3.org/TR/2007/WD-xforms11-20070222/#style

   Thus, read-only control styling for XForms would be unusable in
situations where markup is user-editable in any way.

3) The current definition of :readonly confuses widget contents with
markup editability.

   CSS3-UI gives no distinction between the editability of the control
contents and the editability of the markup. Thus, :readonly is useless
for selecting read-only controls. Conversely, you can't select markup
that is editable using :readwrite without selecting read-write controls
who's markup is not editable.

4) The :disabled pseudo-class is always a subset of :readonly in CSS3-UI.

   Because a disabled control cannot be edited by the user, it always
matches :readonly. Thus, you cannot use :disabled:readonly to select a
control that is both disabled and read-only, since :readonly will always
match.

5) The :readwrite pseudo-class is a logical NOT of :readonly.

   As currently defined in CSS3-UI, ":readwrite" is the same thing as
":not(:readonly)", so one of them is clearly redundant in its definition.

6) The :readwrite pseudo-class matches password input controls.

   You can't technically "read" the passwords you input, so how are they
read-write?

7) Selectors content is in a CSS spec.

   Why do we have selectors, which are now supposed to be separate from
CSS, inside a CSS module?

8) What are the status of the "Features at Risk"?

   We should really know by now if the at-risk features have been
dropped or not...


   Here are the changes I'd like to see to address the problems with
CSS3-UI:

1) Drop CSS3-UI back to WD status. (Last Call would be fine if all
issues are addressed.)
2) Make :readonly match read-only controls exclusively.
3) Make :readwrite match read-write controls exclusively.
3) Add :writeonly back in to handle things such as password input styling.
4) Add a new :editable pseudo-class to handle situations where the
markup is user-editable.
5) Move the entire "User Interface Selectors" section of CSS3-UI to
Selectors Level 3.
6) Resolve conflicts for the :active pseudo-class after the move to
Selectors Level 3.
7) Remove at-risk features that didn't survive.

Received on Thursday, 26 July 2007 01:25:12 UTC