W3C home > Mailing lists > Public > www-archive@w3.org > July 2003

[css3-ui] Last Call Comments on 3 July 2003 draft

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 01 Aug 2003 04:52:50 +0200
To: tantekc@microsoft.com
Cc: www-archive@w3.org
Message-ID: <3f37d57c.816245539@smtp.bjoern.hoehrmann.de>


  These are my last call comments on the CSS3 Basic Unter Interface
Module <http://www.w3.org/TR/2003/WD-css3-ui-20030703>. I got the
strange feeling that I am not a member of the target audience or I am
just clueless. On the other hand, I expect less clueful people than me
to read the draft. The most important thing for a second last call
working draft or a candidate recommendation would be examples, at least
one for each new selector and each new property. I would have proposed
new text and new examples if I knew better how to interpret the draft.
I hope these comments are notheless useful and help to improve the

Please note that questions and "I do not understand"s are requests for
clarification in the draft. Sometimes a satisfactory clarification could
be as simple as stating that the specification does not define

* Abstract

  http://www.w3.org/2001/06/manual/#Abstract says that the abstract
  should be written for a non-technical audience. The current abstract
  is however extremly technical.

* Status of this document

  See http://www.w3.org/mid/a0600182fbb3b692c9c4e@%5B10.0.1.2%5D

* Changes

  If this section is kept in the next version of this document this
  should be a non-normative appendix.

* 3. User Interface Selectors

  None of the 13 new selectors have an example. Each selector should at
  least have one example. It would be neat to have a more complex
  example at the end of the section that demonstrates how various
  selectors could be used together.

* 3.1. User interface states: pseudo-classes

  The draft uses SELECT to mean the <select> element in HTML and
  [SELECT] to mean a reference to the css3-selectors candidate
  recommendation. This is rather confusing. A better name for the
  reference would be [CSS3SELECTORS] or something similar.

    Specifically, these new states (except for :default) are provided as
    a way to style elements which are in the respective states as
    defined by XForms [XFORMS10].

  Up to this point XForms were not mentioned, the draft merely talks
  about HTML 4. Is the draft meant to provide properties to style
  XForms? Then it should say so in the abstract/status/introduction.

* 3.1.2. :valid and :invalid

    An element is :valid or :invalid when it is, respectively, valid or
    invalid with respect to the bound instance data constraints. An
    element which lacks data validity semantics is neither :valid nor
    :invalid. This is different from an element which otherwise has no
    constraints. Such an element would always be :valid. 

  I don't understand the difference between lack of data validity
  semantics and an element "which otherwise has no constraints". The
  term "data validity semantics" is already confusing as neither css3-ui
  nor XForms define a term close to it. Logically, an element either has
  a notion of validity in which case the element can be either :valid or
  :invalid depending on whether it matches the constraints or it does
  not have a notion of validity in which case it either neither :valid
  nor :invalid or always :valid. The draft says it's neither then. So
  what's this about? There should be examples which demonstrate each

3.1.3. :in-range and :out-of-range

    The :in-range and :out-of-range pseudo-classes apply only to
    elements that have range limitations. An element is :in-range or
    :out-of-range when the value that the element is bound to is in
    range or out of range of the visual representation of the element
    respectively. E.g. a

  Range of the visual representation? So this does not apply to aural
  media or what?

    slider element with a value of 11 on a slider that only represents
    the values from 1-10 is :out-of-range. In summary: an element is
    :out-of-range when it does not accurately reflect the state of the

  What model?

  Is an element :out-of-range :invalid?

* 3.1.4. :required and :optional

    A form element is :required or :optional if a value for it is,
    respectively, required or optional before the form it belongs to is
    submitted. Elements that are not form elements are neither required
    nor optional. This spec does not defined what is a form element. 


  I do not understand "before the form it belongs to is submitted". Are
  elements :required or :optional before I hit the submit button? While
  I press the submit button? After I've pressed the submit button? If
  there are two forms in the document do :required and :optional apply
  to form elements of both forms?

* 3.2. User interface element fragments: pseudo-elements

  Are any of these pseudo-elements meant to be used in combination with
  other pseudo-elements in this module or in other modules?

* 3.2.1. ::value

    A form element may contain both a label for its data value, and the
    data value itself. For such elements, the ::value pseudo-element
    selects the representation of just the data value itself, in order
    to style its appearance.

  What if the markup language does not allow labeling form elements?
  What if it does but the author did not specify a label? How is this
  pseudo-element different from

    xf|value { ... }


* 3.2.2. ::choices

  I do not understand the need for this pseudo-element. In XForms you 

      <label />
          <label />
          <value />
          <label />
          <value />

  To select the choices one can easily use the element type name

    xf|choices { ... }

  or probably

    xf|choices > xf|item { ... }


    xf|choices > xf|item::before { ... }

  depending on what this pseudo-element is about.

    A list of radio buttons can also be selected with the ::choices
    pseudo, and the currently chosen radio button can be selected with
    the ::value pseudo. 


  I am lost here. ::value is said to select the representation of the
  data value of some form element but nothing is said about the
  currently chosen form element. Does ::value only apply to selected
  data value representation?

* 3.2.3. ::repeat-item

    The ::repeat-item pseudo-element represents a single item from a
    repeating sequence. Its position is as a parent to all the elements
    in a single repeating item. Each ::repeat-item is associated with a
    particular instance data node, and is affected by the model item
    properties (e.g. 'relevant') found there, as the related style
    properties will cascade to the child elements. 

  I guess there is a missing reference to XForms in section 3.2.,
  otherwise this model item property speak does not make much sense.

  I do not understand what this pseudo-element selects. I would expect


  to select all foo element's repeat-item part but what is the
  repeat-item part of an element? The prose says ::repeat-item selects a
  single item from a repeating sequence. Which item? The first? The

3.2.4. ::repeat-index

    The ::repeat-index pseudo-element represents the current item of a
    repeating sequence. Its position is as a parent of all the elements
    in the index repeating item (and as a child to the ::repeat-item
    pseudo-element), thus any style declarations applying to this
    pseudo-element override those on the parent ::repeat-item. 

  I understand "current item" better than the "single item" of
  ::repeat-item and I understand the part on overriding declarations,
  but I do not understand much more of this pseudo-element, especially
  the term "index repeating item". What's this "index" about?

* 4.1. The 'appearance' property

  I do not understand why this property does not apply to static media,
  I think it is quite common to print forms with checkboxes and text

    CSS2 introduced the concept of system colors, which is a set of
    values that allows authors to specify colors in a manner that
    integrates them into the user's graphic environment. However, color
    is not the only property for which native form elements have a


    This document introduces the 'appearance' property. The 'appearance'
    property simultaneously affects color, font, background, padding,
    border, and margin (note: and perhaps others). 

    When the appearance property is specified, the value indicates not
    only color, but all other aspects (font, background, padding,
    border, and margin, etc.) that are determined by the look of
    standard user interface elements on the system. Individual
    properties such as 'background-color' or 'border-style' are still
    given values taken from the system, which can be independently

  s/and margin (note: and perhaps others)/margin and perhaps others/
  It's odd that the various affected aspects are mentioned twice here.

  I do not understand the last sentence. I understand that it is
  intended that I can use

    button { appearance: button }
    button { border-color: green }

  to get a button with green borders but I have trouble to understand
  what "are still given values taken from the system" means. Does this
  mean that setting appearance also sets color for example? That is, if
  my system button color is green and 

    button { appearance: button }

  is applied, the computed value for 'color' would be some green just if
  I had specified 

     button {
       color:      green;
       background: ...;
       margin:     ...;
       padding:    ...;

  ? If that's the case appearance has a major security issue, since I
  would expect

    foo { appearance: desktop }

  to set

    foo { background-image: url(file:///e:/winnt/...desktop-image.bmp) }

  and it'd be much easier for an attacker to crack my system or steal
  files if he knows the location of my system directory.

    The list of CSS2 System Colors, the list of HTML4 form elements, and
    the concept of a dialog window and an icon give us the following
    grouped by category list of user interface elements:

  The draft neither restates any of those lists nor are they referenced.
  In fact, HTML does not have a list of "form elements" but rather has
  "form controls". I do not understand how these lists and concepts
  yield in the following that list of user interface elements.

  Surprisingly none of those keywords is explained. I have for various
  keywords no idea how those could render or are different from each
  other. I also have trouble to understand the grouping. In Windows GUI
  design almost anything is a window including buttons, menubars, menus,

  I have no idea how appearance:hyperlink would look like on my system,
  hyperlinks on the desktop have a different style than hyperlinks in
  the Explorer and those are still different from hyperlinks in my
  browser which are again different from the hyperlink styles used in 
  the Windows help system. I'd claim there is no system default style
  for hyperlinks. Is it then the user agent default? My user agent
  defaults for hyperlinks have colors but no background colors,

    hyperlink-container { background-color: blue; color: black }
    hyperlink           { appearance: hyperlink }

  is likely to get unreadable. How does css3-ui deal with this
  situation? What are user agents or authors supposed to do to prevent

  The prose for appearance does not state whether it only
  affects properties for the element or also pseudo-classes,
  pseudo-elements, etc. What's inside scope, what is outside? Does it
  affect child elements? In which way?

  Why are "info" and "message-box" "renamed"?

  What is an "outline-tree"? Is this like Tree View Controls in Windows
  GUI? Does it render lines linking the elements? Does the author have
  control over it? Collapsed? Expanded? Are there CSS modules providing
  useful properties?

  What is a "list-menu"? Is this like List View Controls in Windows GUI?
  Those ain't menus to me.

  What is the difference between a pull-down-menu and a pop-up-menu?

  What is 'field'? Is this more like <textarea> or more like <input> or
  what? The sample style sheet implies it's like both but their
  appearance is not even similar to me.

  What color would I get if

    element { color: green; appearance: normal }

  is specified?

  I am sorry but the description of the cursor property which has rather
  small impact on rendering is twice as long as the description of the
  appearance property which is said to have major impact on rendering.
  There should be more definitions, more descriptions, some examples and
  some sample renderings.

    All UAs are expected to support rendering the appearance of the five
    generic user interface elements: icon, window, button, menu and
    field. If a UA or platform does not support a specific user
    interface element (e.g. dialog), it may apply the values for the
    respective generic user interface element (e.g. window).

  s/UA/user agent/

  Wrt conformance, what does "are expected" mean? What's the alternative
  to the "may" in the last sentence? Ignore the property? Why is this
  not a MUST or at least a SHOULD? How may a user agent not support
  specific user interface elements if the operating system does? Is
  appearance than optional for css3-ui conformance even if appearance
  would be implementable on the user agents target platform?

  How would I use this property to style a typical context menu like

    | Undo            |
    | Redo            |
    | Cut             |
    | Copy            |
    | Paste           |
    | Find            |
    | Find next       |

  How to style the separators for example? If I assign "key-equivalent"s
  to all the entries, how would I make the user agent to highlight e.g. 
  the 'u' in 'undo'?

* 4.2. System fonts

  This font property is confusing. In CSS Level 2.0, 2.1 and css3-fonts

    font: status-bar

  is inherited and applies to e.g. the print media type, in css3-ui it
  is not inherited and does not apply to print. If this is intentional,
  there should be a description how a user agent is supposed to 
  implement both, css3-ui and css3-fonts.

  In css3-ui the initial value is 'normal' which is not a legal value
  according to the value grammar. The prose says all appearance keywords
  are added, appearance:normal however is not. If this is intentional
  the prose should say that it is omitted and either css3-fonts is added
  as normative reference or the initial value must be changed.

    The computed values for system font values are simply the value
    keywords themselves. 

  Change "computed values" to "... value" or replace all with "specified
  value". It's never been obvious to me that the computed value of

    font: status-bar

  is "status-bar" while the computed value of

    font: normal

  is undefined but I guess that's the intention and should be clarified
  in css3-fonts.

  I wonder why it doesn't just say

    New values: foo | bar | baz

  adds css3-fonts to the normative dependencies and keeps other fields
  of the property database just as in css3-fonts. It'd be much less

  I do not think that all these new keywords for font add much value to
  CSS. Using Windows 2000, all fonts I am able to configure are
  typically set to either Tahoma or Microsoft Sans Serif (8pt) depending
  on your theme preferences. Under my preferences all keywords would be
  equivalent to

    font-size: 8pt;
    font-family: Microsoft Sans Serif;

  Even if they were different, I can hardly think of a situation where I
  would like to style something with the font settings of a button that
  is no button. If there are great and important use cases, I would like
  to read about them in the specification.

    CSS2 introduced system font values as values for the shorthand
    'font' property which have the effect of setting all the elemental
    'font-*' properties.

  Change "system font values" to "system font keywords" or "system

  Why is the "icon" keyword a link to the "icon" property?

  The draft says, 'message-box' is included for compatbility with CSS
  Level 2.0, the css3-fonts module doesn't. What does "for
  compatibility" mean? Is this keyword deprecated and may be removed
  from future specifications?

      The specific font used in forms text fields (input or output).

  s/forms/form/, no?

  I do not understand why it is

    font: status-bar


    font: menubar

  'menubar' should rather be 'menu-bar'. 'message-box' vs. 'checkbox' is
  also odd.

* 8.1. 'cursor' property

    Computed value:

      If there are one or more <uri> values specified, and the UA finds
      a <uri> that it is able to support (due to format, resource
      availability etc.), then the computed value is that URI, fully
      qualified, with optional <x> and <y> coordinates. If no such
      supported <uri> value is found, or if none were specified, then
      the computed value is the specified keyword value, or 'auto' if no
      keyword value is specified.

  Per the current grammar it is not possible to specify no keyword


      The user agent retrieves the cursor from the resource designated
      by the URI. If the user agent cannot handle the first cursor of a

  With respect to conformance, what does "retrieves" mean? For example,
  if the user agent performs a HTTP HEAD for the specified resource and
  the server answers with a Content-Type the user agent does not
  support, must the user agent still retrieve the resource? If the URI
  ends in .png and the user agent does not support image/png resources,
  may it ignore the resource even if it really is a image/svg+xml cursor
  which the user agent supports? what steps must be performed to
  determine whether a cursor resource can be handled? What if the
  resource cannot be retrieved (unsupported protocol, offline browsing,
  404, etc.)? It's probably up to the Values module to specify the
  details here, currently however it only says "User agents may vary in
  how they handle URIs that designate unavailable or inapplicable
  resources" which would strictly speaking allow the user agent to
  display a "broken cursor" cursor rather than choosing the next
  specified cursor... Further, the term "URI" is inaccurate as e.g.
  <http://www.example.org/cursor.svg#cursor> is a URI *reference* but no
  URI in RFC 2396 terminology although the intention is to support such

      list of cursors, it should attempt to handle the second, etc. If
      the user agent cannot handle any user-defined cursor, it must use
      the generic cursor at the end of the list. The optional <x> and

  There isn't necessarily a generic cursor at the end of the list,
  "auto" is also permitted. I am actually a bit surprised "auto" is
  allowed there, it'd make more sense to me if the value grammar was
  something like "... | auto | inherit" and the generic cursor is
  optional and if ommited and none of the url() cursors are supported,
  auto is assumed. This would allow to specify

    cursor: url(l33t.png);

  and the user agent would choose what fits best in the current context
  if l33t.png is unavailable. If authors are required to specify a
  generic cursor they will likely choose a less appropriate one,
  probably "default". It's rather unlikely that authors want to specify
  a different cursor than "auto" (or what the user agent would choose
  for "auto"), isn't it? It would of course be incompatible with CSS

  Why is using the first url() a MUST but the second/third/etc. url()
  only a SHOULD? This seems to be inconsistent.

  The value grammar requires <x> and <y>, if those are optional (as the
  prose indicates) the grammar must be changed.

    <dt>ns-resize | ew-resize | nesw-resize | nwse-resize

  Missing <strong />.


      The platform-dependent default cursor. Often rendered as an arrow.

  Is there no better name for this keyword? To me, the default cursor
  for a :link element is a 'pointer' not some kind of an arrow.


      Indicates that a cell or set of cells may be selected. Often
      rendered as a thick plus-sign with a dot in the middle. 

  I've never seen this cursor with a dot in the middle. And if I did,
  I'd probably mixed it up with something similar to 'all-scroll'...


      Indicates vertical-text that may be selected. Often rendered as a
      horizontal I-beam 

  s/beam/bar/? add a full-stop.

  I miss a keyword to specify no cursor at all, i.e. "none" or "hidden",
  I've seen some requests for the ability to hide the cursor for example
  in presentation scenarios. The typical advise is to create an invisble
  cursor image which shoudn't be necessary. Users or user agents that
  like to avoid rendering invisible cursors can more easily ignore

    cursor: none

  than testing whether the external resource might yield in an invisible
  cursor (consider an animated cursor with a long lasting invisible
  second frame).

  Please sort the <dl> in alphabetic order (except "auto" which should
  precede the generic cusor keywords).

    The UA may treat inapplicable values as 'auto'. E.g. on platforms
    that do not have a concept of a 'context-menu' cursor, the UA may
    render 'default' or whatever is appropriate. 

  With respect to conformance, what does "inapplicable" mean? If a user
  agent supports PNG cursors with abitrary dimensions, may it treat a
  1600x1200px PNG cursor as "inapplicable"? May it treat

    a[href] { cursor: wait }

  as "inapplicable"? Is "inapplicable" any different from "unsupported"?

* 8.2.1. Keyboard equivalents: the 'key-equivalent' property

  That's IMHO a very bad name, common terminology would be "hotkey" or
  "shortcut", this sounds more like "key aspect" and one wonders how an
  element can be equivalent to a key. One gets used to the name after
  some time but I think it's name is not obvious to casual authors.
  Alternatives could go along


    Value:  none | (<key-press-combination> )+ |
      <system-key-equivalent> | list-item-marker | inherit

  Round brackets are not allowed in the value grammar definition in CSS
  Level 2.0.

    Key-equivalents are active in a document only if an element inside
    the document has the focus (e.g. this can include the <body>
    element). This also applies to documents inside frames. The frame
    must first acquire the focus before key-equivalents for any of the
    elements of its document can be active.

  Giving focus to a frame does not automatically give focus to an
  element inside the document contained in the frame. I'd prefer to
  omit frame discussion and describe this in terms of *:focus.

  I do not understand the need for accesskey-attr(<attribute>), there is
  attr() isn't it? Where is <attribute> defined and how does <attribute>
  cope with namespaces?

    One or more <key-press-combination>s separated by spaces. The user
    agent is supposed to use all <key-press-combination>s which it finds
    in the list which it and the platform is capable of supporting. In
    some ways this is similar to the list of font families in the
    font-family property.

  Please avoid using symbols as words, "<key-press-combination>s" is
  hard to translate into other languages.

    A <key-press-combination> is one or more characters with one or more

  "characters" is a link to HTML 4.01, this makes HTML 4.01 a normative
  reference to the specification but it is not even listed as an
  informative reference. I disagree that <key-press-combination> is a
  character according to the definition in HTML 4.01. Please take care
  that if this specification uses the term "character" it uses it in
  accordance with the specification requirements in 

    modifier keys separated by dashes ('-'). Each character must be
    specified in uppercase or as an escaped character (character entity)

  Character Entity? &ouml; and such? I do not understand why
  "characters" must be specified in uppercase if it's case-insensitive.
  May I use lowercase characters when using escapes?

    - the actual user input for the key-equivalency is case insensitive.
    In addition to characters (representing keys), special or modifier
    keys can also be specified. These are specified in all lowercase so
    as to be distinguished from the characters representing keys. The

  And who needs that? Maybe authors should accept this as some
  convention but I do not see a specific reason for user agent
  requirements here.

  I have trouble to understand various keys, for example fcn, rcl, snd,
  bs, clr, sto, sysrq, and namemenu. Has this particular part of the
  specification been reviewed by I18N and/or DI Activity?

  All these key symbols should really be inside an additional <dl>.

  I would prefer if various shortcuts are separated by commas just as in
  cursor or font-family.

  I whish I could use in my user style sheet to allow some shortcuts but
  disallow others. All I can do to prevent unexpected user agent
  behaivour is to disallow any change to "key-equivalent".

* 5.2. 'icon' property

  Does this property not have an "inherit" value? It's odd that all
  properties but icon list inherit as a value.

  Why is the comma opertator not used to list multiple <uri> values just
  like in e.g. the cursor property?


  Why are these '(' ')'?

  I think that p { display:icon } is a rather bad example, especially
  for user style sheets.

* 5.3. 'box-sizing' property

  I remember some discussion about adding margin-box and/or padding-box.
  Has this been considered?

* 8.2.3. Directional focus navigation: the 'nav-up', 'nav-right',
  'nav-down', 'nav-left' properties

  This is more about expressing relationships between resources than
  about presentation of or interaction with content. It seems like this
  is reinventing <a rel=next ...> and <a rel=prev ...>, something like

  <div id=prev><p>...</p><p><a rel=next href='#next'>next</a></p></div>
  <div id=next><p>...</p><p><a rel=prev href='#prev'>prev</a></p></div>

  #prev:focus a { key-equivalent: down }
  #next:focus a { key-equivalent: up }

  or whatever. 

      The user agent automatically determines which element to navigate
      the focus to in response to directional navigational input. 

  I have no idea how this should or could be implemented.

      The <target-name> parameter indicates the target frame for the
      focus navigation. It is a string and it cannot start with the
      underscore "_" character. If the specified target frame does not
      exist, the parameter will be treated as an empty string. The
      keyword 'root' indicates that the user agent should target the
      full window.

  A string? Why not an identifier?

    User agents for devices with keyboards with arrow keys may respond
    to the four directional arrow keys (up arrow, right arrow, down
    arrow, left arrow) by navigating the focus according to four
    respective nav-* directional navigation properties (nav-up,
    nav-right, nav-down, nav-left). 

  They may, so this is an optional feature? I don't want web site
  authors to break keyboard scrolling in my browser. This property
  is open to all kinds of abuse not to mention WAI issues. The draft
  does not say anything about the purpose of the property or potential
  use cases so what problem is this meant to solve? If there is no
  compelling need for this property I suggest to remove it.

* Appendix A. Additions to the Base Style Sheet for HTML4

     white-space: nowrap;

  What user agent uses white-space: normal for <textarea>? I am pretty
  sure that white-space:pre is much closer to current user agent

* Normative References

  Reference to css3-color and XForms 1.0 were already outdated on
  publication of this working draft.

* misc

  * missing reference to RFC 2119
  * some notes are "Note. ..." in green color, some are "Note: " in
    black color. If there is no semantic difference between these kinds
    of notes there should be a difference in style
  * examples!
  * examples!
  * examples!

Received on Thursday, 31 July 2003 22:53:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:26 UTC