- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Sat, 10 Apr 2004 23:48:22 -0700
- To: Micah Dubinko <MDubinko@cardiff.com>
- Cc: <www-style@w3.org>
On 7/23/03 3:01 PM, "Micah Dubinko" <MDubinko@cardiff.com> 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. Agreed. > 3.1.1 :default > > b) Please clarify: can the default pseudo-class simultaneously apply to more > than one element in a group? Yes. > 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". Agreed. > 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. Agreed. > 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." Agreed. > 3.2.1 ::value > > g) Please add a graphical illustration of what part of a form control is > styled by ::value. Agreed. > 3.2.2 ::choices > > h) Minor editorial. "pseudo." -> "pseudo-element." Agreed. > 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? Agreed. > 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.) Accepted. > * 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>) Accepted. > - 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. Agreed. > 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