- From: Micah Dubinko <MDubinko@cardiff.com>
- Date: Wed, 23 Jul 2003 18:01:58 -0400 (EDT)
- To: "'www-style@w3.org'" <www-style@w3.org>
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? Are there any limits or guidelines on what can make up a "group" for purposes of :default? 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. 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. 3.2.4 ::repeat-index k) Reportedly, this is difficult to implement as a pseudo-element. Should it perhaps be a pseudo-class instead? 4.1 The 'appearance' property l) please add the following possible values (listed under respective broader categories) * button - submit - signature - tab (as in tabbed dialog, etc.) * field - static-text (like <xforms:output>) - multiline (like <xforms:textarea>) - password (like <xforms:secret>) - styled-text 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. 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". 4.2 System fonts n) This property has the same values as the 'appearance' property. See comments l) and m). 5.2 'box-sizing' property o) This property is confusing, and doesn't add any new functionality. Please remove it from CSS3 Basic UI. Normative References p) Please update your reference to XForms 1.0 to the latest that's available at publication time. Thank you, Micah Dubinko
Received on Thursday, 24 July 2003 06:04:36 UTC