Re: Last Call comments for css3-ui

On 7/23/03 3:01 PM, "Micah Dubinko" <> wrote:

> Greetings,
> The following are Last Call comments on behalf of Cardiff Software. They are
> individually lettered for easy reference, and arranged by heading in the
> specification.
> 2 Dependencies on other modules
> a) Section 3.1.4 contains the statement "This spec[ification] does not
> define what is a form element". This statement applies to multiple sections,
> and should be moved to a more central place, such as section 2 which deals
> with dependencies.


> 3.1.1 :default
> b) Please clarify: can the default pseudo-class simultaneously apply to more
> than one element in a group?


> For example, in a set of buttons, if two of
> them had the same function, could they both be considered :default?

Agreed. That sounds right.  Also, consider a <selectmany> where multiple
items can be simultaneously selected (like pizza toppings).

> Are
> there any limits or guidelines on what can make up a "group" for purposes of
> :default?

Not at the moment.

> 3.1.2 :valid and :invalid
> c) Please change "the bound instance data constraints" to "data validity
> semantics defined by a different specification".


> 3.1.3 :in-range and :out-of-range
> d) This section speaks of "in range or out of range of the *visual*
> representation of the element" (emphasis added). Is it the intent that this
> applies only to visual media? Please change it to apply to any media. For
> example, an audio browser should still be able to do something useful with
> the :out-of-range class.


> e) The text currently says "In summary: an element is :out-of-range when it
> does not accurately reflect the state of the model." Please change "does
> not" to "cannot". For example, if a form control didn't accurately reflect
> the state of the model just because it needed to be refreshed, etc., it
> would not be :out-of-range. Only when some kind of logical contradiction is
> present, is a form control :out-of-range.

Agreed with your correction of the concept.  The "in summary" sentence was
problematic and will be dropped.  The rest of the section will be revised as
you requested.

> f) Please add a sentence along the lines of "An element that lacks data
> range limits or is not a form control is neither :in-range nor
> :out-of-range."


> 3.2.1 ::value
> g) Please add a graphical illustration of what part of a form control is
> styled by ::value.


> 3.2.2 ::choices
> h) Minor editorial. "pseudo." -> "pseudo-element."


> 3.2.3 ::repeat-item
> i) Current text: "Its position is as a parent to all the elements in a
> single repeating item." We believe this is technically correct, but awkward
> to read. Could the sentence be improved?


> j) Please add a textual example showing where the pseudo-element appears.

Agreed.  As discussed during the recent W3C plenary, a fictional tag
sequence will be added.

> 3.2.4 ::repeat-index
> k) Reportedly, this is difficult to implement as a pseudo-element. Should it
> perhaps be a pseudo-class instead?

Disagreed.  As discussed during the recent W3C plenary, It must be a
pseudo-element because pseudo-classes which are used to indicate a state,
may only be placed on real element rather than pseudo-elements.  Thus a
pseudo-element in a particular state can only be represented by another
pseudo-element, named specifically to reflect that state, which is precisely
what ::repeat-index is.

> 4.1 The 'appearance' property
> l) please add the following possible values (listed under respective broader
> categories)
> * button
> - submit

Disagreed.  As discussed during the recent W3C plenary, 'submit' buttons
have the same presentation as 'push-buttons' in today's UIs.

> - signature

Accepted, but, As discussed during the recent W3C plenary: a field makes
more sense, typical use is a signature field where you have to type in a
specific string (like first last name precisely).

> - tab            (as in tabbed dialog, etc.)


> * field
> - static-text    (like <xforms:output>)

Disagreed because, as discussed during the recent W3C plenary, elements by
default are unstyled like spans.  No need for an appearance value.

> - multiline      (like <xforms:textarea>)

Disagreed because, as discussed during the recent W3C plenary, multiline is
just a field that has a height greater than one line.

> - password       (like <xforms:secret>)


> - styled-text

Disagreed. As discussed during the recent W3C plenary, how/when is this ever
different from just 'field'?

> We would also like some kind of appearance value to represent a "combo box"
> affordance, or a control that allows either selecting from a list or manual
> data entry.

Agreed. As discussed during the recent W3C plenary, 'combo-box' will be
added as a special field.

> m) "field" is a confusing choice of terminology, as some users might
> consider several of the controls listed under "menu" also as a "field".
> Please use a different term, such as "data-entry".

Disagreed.  'field' is a more user-friendly term.

> 4.2 System fonts
> n) This property has the same values as the 'appearance' property. See
> comments l) and m).

Agreed that any values added to the 'appearance' property should be added as
values for the shorthand 'font' property.

> 5.2 'box-sizing' property
> o) This property is confusing, and doesn't add any new functionality. Please
> remove it from CSS3 Basic UI.

Disagreed. As discussed during the recent W3C plenary, authors want this
property, and it adds the ability to do width 50%-20px etc.

> Normative References
> p) Please update your reference to XForms 1.0 to the latest that's available
> at publication time.


> Thank you,
> Micah Dubinko

Thank you for taking the time to review the CSS3 UI module last call draft
and provide your detailed and valuable feedback.  Your input has improved
the specification.

Tantek «elik
editor, CSS3 Basic UI module

Received on Sunday, 11 April 2004 02:48:33 UTC