W3C

User Interface for CSS3

W3C Working Draft 16 Feb 2000

This version:
http://www.w3.org/TR/2000/WD-css3-userint-20000216
Latest version:
http://www.w3.org/TR/css3-userint
Previous version:
http://www.w3.org/TR/1999/WD-css3-userint-19990916
Editor:
Tantek Çelik (Microsoft Corporation) <[email protected]>
Authors:
Tantek Çelik (Microsoft Corporation) <[email protected]>
Peter Linss (formerly of Netscape Communications), <[email protected]>
Sho Kuwamoto (Macromedia) <[email protected]>

Copyright ©2000 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

This working draft contains:

Status of this document

This document is a working draft of the CSS & FP working group which is part of the Style activity. It contains a proposal for features to be included in CSS level 3.

Feedback is very much welcomed. Comments can be sent directly to the editor, but the mailing list [email protected] (see instructions) is also open and is preferred for discussion of this and other drafts in the Style area.

This working draft may be updated, replaced or rendered obsolete by other W3C documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". Its publication does not imply endorsement by the W3C membership or the CSS & FP Working Group (members only).

To find the latest version of this working draft, please follow the "Latest version" link above, or visit the list of W3C Technical Reports.

Contents

1. Introduction

Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. This proposal extends them to provide the ability, through CSS, to style elements based upon their various user interface related states, and to make an arbitrary structural element take on the dynamic presentation, or system default look and feel, of various standard user interface widgets.

1.1 Purpose

The purpose of this proposal is to achieve the following objectives:

1.2 Scope

This proposal intends only to specify the look and feel of various elements, and specifically does not address the meaning behind what a specific look and feel may imply. For example, with the additions in the proposal, an author can make any element look and even feel like a submit button. Yet, that arbitrary element has no meaning, so pushing it does nothing by default, and certainly doesn't imply that it submits a form.

Similarly, the SELECT element for example, provides a list or menu of choices to the user. The meaning of the SELECT element is that it allows the user to make a choice, to choose something among several alternatives. This says nothing about its look and feel, and in fact, the "concept" of a SELECT could be visually implemented as a list-box, a popup-menu, or a group of radio-buttons. Each visual instantiation has a different look and feel, but maintains its original meaning, a choice among several alternatives. This proposal addresses only the former (look and feel), not the latter (meaning).

Since this proposal serves to simulate various user interface and forms elements in HTML4, it is perhaps useful to call out what specifically is believed to be outside the scope of CSS, or better suited to document structure rather than style and therefore not addressed by this proposal:

1.3 Summary of Additions

The proposal can be briefly summed up by the following additions to CSS:

As a result, the rendering behaviors of the following fourteen HTML4 tags and four HTML4 attributes could be deprecated:

1.4 Dependencies

The following work has dependencies on the CSS UI working draft.

1.5 Issues

This is a work in progress, and as such, has not yet addressed all issues that have been raised with respect to creating user interface elements using CSS. The following issues remain to be resolved:

  1. Should this proposal attempt to address more of the behavior of FRAMESET and FRAME, specifically the ability to "share" resizability when elements share a border (i.e. with border-collapse for example)?
  2. Using "attr()" outside of the content property. In the default style sheet additions at the end of this document, one of the rules is: SELECT[size] { height: attr(size)em; } in order to attempt to have a SELECT element that has a size attribute be vertically sized as a multiple of its font-size. Should we discuss additional usages of the attr() expression in this proposal?
  3. key-equivalent conflicts. what happens when two or more elements have the same key-equivalent? what happens when an element has the same key-equivalent as some portion of the UAs intrinsic user interface?
  4. Should we add additional pseudo-classes to be able to style an element based upon it's modifiability? E.g. :read-only, :read-write, :write-only.
  5. Should we distinguish system colors of elements in the front-most window versus non-front-most windows? Not at this point - it doesn't make sense to address without also addressing system window layering functionality.
  6. Should we add a system color window subtype to represent palettes or floating windows (or both)? Not at this point - it doesn't make sense to address without also addressing system window layering functionality.
  7. Do we need to allow more control for the author to distinguish between what happens when a user interface element is focussed by the user, and when a user interface element is activated by the user? Currently the 'user-focus' property dictates the behavior of an element when it acquires focus, but there is no such parallel property for when an element is activated (e.g. 'user-activate'). For example, in some implementations, tabbing in an element focusses it and then pressing the enter, return and sometimes spacebar key activates it. For checkboxes and radio buttons, some implementations focus the element when the user clicks on the label or non-content portion of the element, whereas if the user clicks on the radio or check portion of the element, the element is activated. Any property solutions to this issue should resolve what the default value of the property is for the SELECT and OPTGROUP elements in order to correctly reproduce typical behavior for those elements in HTML4 user agents - something like "user-active:select-menu;".
  8. Should we include a :hot-key (or similarly named) pseudo-element selector which selects the character or characters in an element which are the same as any key-equivalents on the element? E.g. you could style the hot-key for any enabled user interface element with the following: :enabled:hot-key{text-decoration:underline}
  9. Should we add selectors for scrollbars? E.g. :horizontal-scrollbar, :vertical-scrollbar ?

2. Selectors: UI element states and fragments

2.1 Pseudo-classes: UI element states

2.1.1 :active and :focus - addition to the CSS2 definitions

The CSS2 definition of :active and :focus states:

This proposal adds the following:

Only elements whose 'user-input' property has the value of "enabled" can become :active or acquire :focus.

2.1.2 The :enabled pseudo-class

The purpose of the :enabled pseudo-class is to allow authors to customize the look of user interface elements which are enabled - which the user can select/activate in some fashion (e.g. clicking on a button with a mouse). There is a need for such a pseudo-class because as of yet there is no way to programmatically specify the default appearance of say, an enabled INPUT element without also specifying what it would look like when it was disabled.

2.1.3 The :disabled pseudo-class

Similar to :enabled, :disabled allows the author to specify precisely how a disabled or inactive user interface element should look.

It should be noted that most elements will be neither enabled nor disabled. An element is enabled if the user can either activate it or transfer the focus to it. An element is disabled if it could be enabled, but the user cannot presently activate it or transfer focus to it.

2.1.4 The :checked pseudo-class

The :checked pseudo-class only applies to elements which are user-input:enabled or disabled. Radio and checkbox elements can be toggled by the user. Some menu items are "checked" when the user selects them. When such elements are toggled "on" the :checked pseudo-class applies. The :checked pseudo-class initially applies to such elements that have the HTML4 SELECTED or CHECKED attribute as described in Section 17.2.1 of HTML4, but of course the user can toggle "off" such elements in which case the :checked pseudo-class would no longer apply. While the :checked pseudo-class is dynamic in nature, and is altered by user action, since it can also be based on the presence of the semantic HTML4 SELECTED and CHECKED attribute, it applies to all media.

2.1.5 The :indeterminate pseudo-class

The :indeterminate pseudo-class only applies to elements which are user-input:enabled or disabled. Radio and checkbox elements can be toggled by the user, but are sometimes in an indeterminate state, neither checked nor unchecked. This can be due to an element attribute, or DOM manipulation. The :indeterminate pseudo-class applies to such elements. While the :indeterminate pseudo-class is dynamic in nature, and is altered by user action, since it can also be based on the presence of an element attribute, it applies to all media.

2.2 Pseudo-elements: UI element fragments

2.2.1 The :selection pseudo-element

The :selection pseudo-element applies to the portion of a document that has been highlighted by the user. This also applies, for example, to selected text within an editable text field. Only elements that have a user-select other than 'none' can have a :selection. This pseudo-element should not be confused with the :checked pseudo-class (which used to be named :selected) or the :selected pseudo-class in the Selectors Proposal.

Although the :selection pseudo-element is dynamic in nature, and is altered by user action, it is reasonable to expect that when a UA rerenders to a static medium (such as a printed page) which was originally rendered to a dynamic medium (like screen), the UA may wish to transfer the current :selection state to that other medium, and have all the appropriate formatting and rendering take effect as well. This is not required - UAs may omit the :selection pseudo-element for static media.

2.2.2 The :menu pseudo-element.

Authors can specify the style and location of a generated menu with the :menu pseudo-element. It is treated as a child of the element (and therefore inherits all styling by default - similar to :before and :after), and absolutely positioned at 0,0 with respect to the content top left corner of the element. It is made "visibility:visible" when the element itself is :active, and is "visibility:hidden" otherwise. It contains a copy of all the contents of the element itself.

3. Media Types and Preferences

3.1 Media type 'presentation'

@media presentation
The medium "screen" typically implies a window on a graphic display on perhaps a personal computer. Such devices typically also have high fidelity stereo audio capabilities, and the ability to display content covering the entire graphic display, instead of just within a window. There is significant demand to be able to author content specifically for this "mode" of interaction which can best be described as another medium - presentation. Presentation is different from projection, in that it does not imply that it is rendered on a significantly larger screen (projection typically does). On the contrary, presentation implies a similar sort of (perhaps the same) device as screen, but just in a different mode.

3.2 @preference

@preference
CSS @media rules permit content authors to specify different appearances for content based upon what medium it is rendered to, or what kind of device it is used on. Many devices support rendering on multiple mediums - a typical desktop computer has a printer attached and can therefore support both "screen" and "print" media. These desktop computers typically also have audio capabilities, and therefore can support "aural" as well. The @preference rule allows the content author to indicate which medium is preferred for rendering the content. It does this with the "media" property. For example, content which was designed to be rendered as a presentation, but is also suitable for screen rendering, and finally print, could have the following @preference rule in its style sheet: 
@preference {
 media: presentation, screen, print;
}
This @ rule instructs the UA to attempt to render the content as a presentation by default, and if unable to, render to the screen, and finally, at least provide the option of rendering to print. Essentially, the "preference" @ rule gives hints to the UA as to how the content author believes the content is best delivered. The only property currently defined for the @preference rule is "media", which gives an ordered list of the media that the content was intended for. If a UA supports more than one medium in the list, it should by default use the first medium in the list which it supports.

4. Addition(s) To CSS2 Properties

4.1 cursor (extensions to CSS2 18.1)

'cursor'
New Values:copy | alias | context-menu | cell | grab | grabbing | spinning | count-up | count-down | count-up-down
Initial:see CSS2
Applies to:see CSS2
Inherited:see CSS2
Percentages:see CSS2
Media:see CSS2

Description

copy
Indicates something is to be copied. Often rendered as an arrow with a small plus sign next to it.
alias
Indicates an alias of/shortcut to something is to be created. Often rendered as an arrow with a small curved arrow next to it.
context-menu
A context menu is available for the object under the cursor. Often rendered as an arrow with a small menu-like graphic next to it.
cell
Indicates that a cell or set of cells may be selected. Often rendered as a thick plus-sign with a dot in the middle.
grab
Indicates something is to be grabbed. Often rendered as an open hand.
grabbing
Indicates that the user has grabbed something. Often rendered as a closed hand.
spinning
Indicates that the program is performing some processing, but is different from 'wait' in that the user may still interact with the program. Often rendered as a spinning beach ball.
count-up
Indicates that the program is performing a counting up operation.
count-down
Indicates that the program is performing a count down operation.
count-up-down
Indicates that the program is alternately counting up and then counting down.

4.2 color (including background and border, extensions to CSS2 18.2)

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.

This proposal extends that set of colors to allow authors to specify the specific colors for the subcomponents of a number of standard user interface elements in several states. The proposal also recognizes that there may be other, platform specific system colors which UAs may implement in order to permit authors to take full advantage of the capabilities of that particular platform.

In addition, when the appropriate values are specified on the 'background' or 'border' shortcut properties, they behave similar to the System Font values, in that, the value indicates not only the color of the shortcut property but all other aspects (width, style, etc.) that are determined by the look of standard user interface elements on the system. When the values are set on the shortcut 'background' or 'border' property, the individual properties such as 'background-color' or 'border-style' are still given values taken from the system, which can be independently varied. Authors are encouraged to use the shortcut properties 'background' and 'border' rather than the properties 'background-color' and 'border-color' in order to allow the UA the flexibility to render as close to the standard look and feel of the platform.

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:

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).

Each of these user interface elements has a number of subcomponents, each of which is typically a different color in today's modern desktop graphical user interfaces: background, text, and border which correspond precisely to the CSS properties 'background', 'color', and 'border'.

The following combinations of user interface element with subcomponent are required to abstractly construct the background, text color and border of each of the user interface elements respectively:

The CSS UI proposal defines a number of pseudo-classes or states for user interface elements: enabled, disabled, active, and hover.

Today's richest platform graphical user interfaces typically render differently for the first three states. There are already applications which render their user interface elements differently even when the user is simply hovering over them, as such, it is not too great a leap to infer that future system standard user interface elements may also render differently in the hover state.

The above list of 42 system colors are expected to be rendered differently depending on the user interface state of the element. This provides the author a simple and straight-forward mechanism for building user interface elements without having to construct rules for each possible state.

However, to enable the author to define their own rules for the look of specific states, for each of the above state independent colors, there are four state specific colors which are constructed by simply taking the given color and prepending the name of the state. E.g.

Button
	EnabledButton, DisabledButton, ActiveButton, HoverButton

Summary of fallback handling for system colors

The 42 state independent colors and their respective 168 state specific colors make a total of potentially 210 separate system colors for the UA to support. Not all UAs or platforms may be able to support all 210 colors, so we explicitly specify a series of fallback steps:

  1. The color of the specific element as specified, e.g. ActiveDefaultButtonBorder
  2. The color of the generic element, e.g. ActiveButtonBorder
  3. The state independent version, e.g. ButtonBorder

An example of a very simple UA on a 1-bit video (black & white only) platform might for example, map all enabled border and text colors to black, and all background colors to white. The disabled border and text colors could be rendered as a dithered 50% grey pattern, and the active text and background inverted. Finally, the hover versions of the colors could simply be rendered the same as the enabled versions.

4.3 font (extensions to CSS2 18.3)

System Font addition(s): The system font in standard user interface widgets

'font'
New Values:window | document | workspace | desktop | info | dialog | button | pull-down-menu | list | field
Initial:see CSS2
Applies to:see CSS2
Inherited:see CSS2
Percentages:see CSS2
Media:see CSS2

These additional values for 'font' symbolically specify that an element has the default font for that specific user interface element. This is just an extension of the system font values in CSS2. As with the other system font values, the values must be set on the shorthand property.

As with the extended system colors documented above, there is a specific fall back mechanism for UAs or platforms which do not support all the specific user interface elements.

  1. The font of the specific element, e.g. dialog
  2. The font of the generic element, e.g. window

Just as with the system colors, UAs are expected to support rendering at a minimum the five generic system fonts: icon, window, button, menu and field, with proper fallback treatment for the specific system fonts.

4.4 box-sizing (interpetation of width and height)

'box-sizing'
Values:content-box | border-box | inherit
Initial:content-box
Applies to:all elements that accept width or height
Inherited:no
Media:same as width and height

Description

content-box
This is the behavior of width and height as specified by CSS2. The specified width and height apply to the width and height respectively of the content box of the element. The padding and border of the element are laid out and drawn outside the specified width and height.
border-box
The specified width and height on this element determine the border box of the element. That is, any padding or border specified on the element is laid out and drawn inside this specified width and height. The content width and height is computed by subtracting the border and padding widths of the respective sides from the specified width and height. This is the behavior of width and height as commonly implemented by legacy HTML user agents for replaced elements and input elements.

4.5 display

The formatting model of the BUTTON tag, the TEXTAREA tag and other elements.

'display'
New Values:inline-block
Initial:see CSS2
Applies to:see CSS2
Inherited:see CSS2
Percentages:see CSS2
Media:see CSS2

The 'inline-block' value for 'display' specifies that an element is to be formatted as a block, but that this block can sit on a line with other elements, similar to the way replaced/empty elements such as IMG and OBJECT and the containers TEXTAREA and BUTTON do.

inline-block
The element is formatted as a block, and adjacent inline elements are formatted on the same line space permitting.

Example: a multi-line text field (similar to TEXTAREA): 

div.field {
 color: fieldText;
 background: field;
 border: fieldBorder;
 font: field;
 display: inline-block;
 user-modify: read-write;
 user-select: text;
}

4.6 content

Symbolic additions to the 'content' property

'content'
New Values:normal | <uri> |
check | diamond | menu-check | menu-diamond |
radio | radio-on | radio-off | radio-ind |
enabled-radio-on | enabled-radio-off | enabled-radio-ind |
disabled-radio-on | disabled-radio-off | disabled-radio-ind |
active-radio-off | active-radio-on | active-radio-ind |
hover-radio-off | hover-radio-on | hover-radio-ind |
checkbox | checkbox-on | checkbox-off | checkbox-ind |
enabled-checkbox-on | enabled-checkbox-off | enabled-checkbox-ind |
disabled-checkbox-on | disabled-checkbox-off | disabled-checkbox-ind |
active-checkbox-on | active-checkbox-off | active-checkbox-ind |
hover-checkbox-on | hover-checkbox-off | hover-checkbox-ind
Initial:normal
Applies to:all elements
Inherited:see CSS2
Percentages:see CSS2
Media:see CSS2
normal
The contents of the element are determined by the document source. Since the :before and :after generated content pseudo-elements have no document source to begin with, their initial content property value is effectively an empty string, as defined in CSS2.
<uri>
Replace the contents of the element with the contents of the URI specified.
check
A check mark.
diamond
A filled diamond. Like 'square' but rotated 45 degrees.
menu-check
The system standard check-mark to indicate a 'checked' menu item.
menu-diamond
The system standard diamond used to annotate menu items.
radio
State dependent system standard rendering of a radio button. The specific rendering of the radio button depends on its specific user interaction states (enabled vs. disabled vs. hover vs. active) and its specific user setting states, unchecked vs. checked vs. indeterminate).
radio-on
radio-off
radio-ind
User interaction state dependent system standard rendering of a radio button. The specific rendering of the radio button depends on its specific user interface states (enabled vs. disabled vs. hover vs. active).
enabled-radio-on
enabled-radio-off
enabled-radio-ind
disabled-radio-on
disabled-radio-off
disabled-radio-ind
active-radio-on
active-radio-off
active-radio-ind
hover-radio-on
hover-radio-off
hover-radio-ind
State specific radio buttons. The system standard renderings of a radio button in its various user interface related states.
checkbox
State dependent system standard rendering of a checkbox. The specific rendering of the checkbox depends on its specific user interaction states (enabled vs. disabled vs. hover vs. active) and its specific user setting states, unchecked vs. checked vs. indeterminate).
checkbox-on
checkbox-off
checkbox-ind
User interaction state dependent system standard rendering of a checkbox. The specific rendering of the checkbox depends on its specific user interface states (enabled vs. disabled vs. hover vs. active).
enabled-checkbox-on
enabled-checkbox-off
enabled-checkbox-ind
disabled-checkbox-on
disabled-checkbox-off
disabled-checkbox-ind
active-checkbox-on
active-checkbox-off
active-checkbox-ind
hover-checkbox-on
hover-checkbox-off
hover-checkbox-ind
State specific checkboxes. The system standard renderings of a checkbox in its various user interface related states.

These additional values for 'content' symbolically specify list annotations and menu annotations that were previously only available respectively through list-style-type and hardcoded for OPTION elements that were SELECTED. In addition, symbolic names for the various states of a radio button and checkbox are introduced. The rendering of disc, circle, and square is identical to what is described for list-style-type. The exact rendering of check and diamond depends on the user agent, but it is suggested that the same glyph which is used on the platform to render a "checked" menu item be used for "check", and similarly for those platforms which support rendering of a "diamond" next to a menu item. Conformant user agents may render 'diamond' the same as 'check'. The radio- and checkbox- values are rendered as they are by default on the platform.

4.7 list-style-type

Parallel symbolic additions to the list-style-type property. This is simply here to keep the list-style-type property in synch with the content property.

'list-style-type'
New Values: check | diamond | menu-check |
radio | radio-on | radio-off | radio-ind |
enabled-radio-on | enabled-radio-off | enabled-radio-ind |
disabled-radio-on | disabled-radio-off | disabled-radio-ind |
active-radio-off | active-radio-on | active-radio-ind |
hover-radio-off | hover-radio-on | hover-radio-ind |
checkbox | checkbox-on | checkbox-off | checkbox-ind |
enabled-checkbox-on | enabled-checkbox-off | enabled-checkbox-ind |
disabled-checkbox-on | disabled-checkbox-off | disabled-checkbox-ind |
active-checkbox-on | active-checkbox-off | active-checkbox-ind |
hover-checkbox-on | hover-checkbox-off | hover-checkbox-ind
Initial:see CSS2
Applies to:see CSS2
Inherited:see CSS2
Percentages:see CSS2
Media:see CSS2

See the 'content' property above for definitions of the values.

5. Interactivity Additions

5.1 resizer - counterpart to overflow: scroll

Specifying resizing capabilities: the 'resizer' property

'resizer'
Values: auto | both | horizontal | vertical | none | inherit
Initial:auto
Applies to:all elements
Inherited:no
Percentages:n/a
Media:interactive

Currently it is possible to control the appearance of the scrolling mechanism (if any) on a window using the overflow property (overflow: hidden) on the HTML (root) element. The purpose of the resizer property is to also allow control over the appearance and function of the resize box (or other appropriate resizing mechanism) on the window.

Note: the resize box is NOT the same as the scrolling mechanism. The scrolling mechanism allows the user to determine which portion of the canvas the viewport shows. The resizing mechanism allows the user to determine the size of the viewport.

This property is meant to primarily apply to the HTML (root) element, yet it makes sense on any element which has scrollbars (overflow: scroll). If the element does not have scrollbars (either through overflow: clip or default behavior of the user agent), then this property is ignored. The appearance of the specific resizer is whatever is default for the user interface of the platform.

When the user manipulates the resizer, the actual width and height of the element are altered accordingly. It is recommended that the resizer be placed in accordance with how the UA places the scrollbars. Some implementations place the scrollbars between the padding and the border. The precise direction of resizing (i.e. altering the top left of the element or altering the bottom right) may depend on a number of factors including whether the element is absolutely positioned, whether it is positioned using the 'right' and 'bottom' properties, whether the language of the element is right-to-left etc. The precise direction of resizing is left to the UA to properly determine for the platform.

auto
Whatever is the default for the UA and platform.
both
A bi-directional resizer is present on the element, and allows the user to adjust both the height and the width of the element.
horizontal
A unidirectional horizontal resizer is present on the element, and allows the user to adjust only the width of the element.
vertical
A unidirectional vertical resizer is present on the element, and allows the user to adjust only the height of the element.
none
No resizer is present, and the user is given no direct manipulation mechanism to resize the element.

Example:

html {
       width: 100px; 
       height: 100px;
       overflow: clip;
       resizer: none 
     } /* display content in a non-resizable 100px by 100px window */

5.2 Keyboard control

5.2.1 Key equivalents: the 'key-equivalent' property

'key-equivalent'
Values: none | (<key-press-combination> )+ | <system-key-equivalent> | inherit
Initial:none
Applies to:all enabled elements
Inherited:no
Percentages:n/a
Media:interactive

The purpose of this property is to be able to specify what key or combination of keys being simultaneously pressed activates/triggers a particular element. This is typically used to alter the command or control key shortcut used for menu items and form buttons. Key-equivalents are active in a document only if an element inside the document has the focus (this can include BODY). 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. There may be platform and user agent limitations to key-equivalents which conflict with those inherent in the user agent and operating system.

none
No key-equivalent is defined for the element
(<key-press-combination> )+

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.

A <key-press-combination> is one or more characters with one or more modifier keys separated by dashes ('-'). The characters must be specified in uppercase or as entities - 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 actual list of supported special or modifier keys and characters is platform dependent. For the modifier keys of which there are typically two, the right and the left, the author can either specify both, e.g. cmd, or only the right: rcmd, or only the left: lcmd.

Note. Should we include "standard" keys from other consumer computing devices?

<key-press-combination> = <key> ('-' <key>)*
<key> = space | <character[CN]> | <special-key> | attr(<attribute>)
<special-key> = <modifier-key> | <function-key> | <navigation-key> | <edit-key> | <misc-key>
<modifier-key> = accesskey | <cmd-key> | <opt-key> | <ctrl-key> | <shift-key> | <alt-key> | <win-key> | <meta-key> | fn | fcn | caps
<cmd-key> = cmd | rcmd | lcmd
<opt-key> = opt | ropt | lopt
<ctrl-key> = ctrl | rctrl | lctrl
<shift-key> = shift | rshift | lshift
<alt-key> = alt | ralt | lalt
<win-key> = win | rwin | lwin
<meta-key> = meta | rmeta | lmeta
<function-key> = f1 | f2 | f3 | f4 | f5 | f6 | f7 | f8 | f9 | f10 | f11 | f12 | f13 | f14 | f15
<navigation-key> = tab | esc | enter | return | menu | help | namemenu | rcl | snd | <arrow-key> | <page-key>
<arrow-key> = up | down | left | right
<page-key> = home | end | pgup | pgdn
<edit-key> = bs | del | ins | undo | cut | copy | paste | clr | sto
<misc-key> = prtsc | sysrq | scrlock | pause | brk | numlock | pwr

'accesskey' is a symbolic value which represents the default "shortcut" or "keyboard accelerator" modifier key for the platform. This value can be used essentially the same way that the ACCESSKEY attribute in HTML4 is used, to specify a single character to be pressed in conjunction with the default shortcut modifier key on the platform.

Examples:

input.cancel { key-equivalent: esc cmd-. N }
input.ok     { key-equivalent: return enter Y }
input.open   { key-equivalent: ctrl-O cmd-O accesskey-O}
input.close  { key-equivalent: alt-f4 cmd-W}
input.copy   { key-equivalent: ctrl-C cmd-C copy accesskey-C}
<system-key-equivalent>

The author can also specify the system key-equivalent for a particular command on that platform. System key-equivalents are all named with the system-* prefix, and refer to the command in their name.

Examples:

input.cancel { key-equivalent: system-cancel }
input.ok     { key-equivalent: system-ok }
input.open   { key-equivalent: system-open }
input.close  { key-equivalent: system-close }
input.copy   { key-equivalent: system-copy }

Note. Other values may be permitted in future levels of CSS.

5.2.2 Tabbing order: the 'tab-index' property

'tab-index'
Values: auto | <number> | inherit
Initial:auto
Applies to:all enabled elements
Inherited:no
Percentages:n/a
Media:interactive

This property is a replacement for the HTML4 attribute TABINDEX. Borrowed and slightly rephrased from the HTML4 recommendation:

This property specifies the position of the current element in the tabbing order for the current document.

The tabbing order defines the order in which elements will receive focus when navigated by the user via the keyboard. The tabbing order may include elements nested within other elements.

Elements that may receive focus should be navigated by user agents according to the following rules:

  1. Those elements that support the tab-index property and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest tab-index value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical tab-index values should be navigated in the order they appear in the character stream.
  2. Those elements that do not support the tab-index property or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream.
  3. Elements that are disabled do not participate in the tabbing order.

Tabbing keys. The actual key sequence that causes tabbing navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).

User agents may also define key sequences to navigate the tabbing order in reverse. When the end (or beginning) of the tabbing order is reached, user agents may circle back to the beginning (or end)

5.3 Dynamic presentation

5.3.1 Enabling user interface elements: the 'user-input' property

'user-input'
Values:none | enabled | disabled | inherit
Initial:none*
Applies to:all elements
Inherited:yes
Percentages:n/a
Media:all

The purpose of this property is to allow the author to specify whether or not a user interface element will currently accept user input. Typically this will be used to enable or disable specific input elements in a form. UAs may interpret none as disabled for user interface related elements.

none
The element is not an element that responds to user input. It is considered neither enabled nor disabled. It does not become :active.
enabled
The element is functionally enabled and responds to user input. Any applicable :enabled pseudo-class selectors are also applied. The element can now become :active.
disabled
The element is functionally disabled and does not respond to user input. Any applicable :disabled pseudo-class selectors are also applied.

*Note that although the initial value for this property is "none", user agents will typically set this value in their user agent style sheet. Certainly, for HTML4 form elements, the user agent style sheet will have a value of "enabled" for the user-input property.

Any settings for the user-input property are ignored when inside a style declaration selected by either the :enabled or :disabled pseudo-classes. This is to avoid the obvious infinite loop of setting user-input:disabled on a :enabled pseudo-class.

Example:

textarea { user-input: disabled } /* prevent access to contents of TEXTAREA */

5.3.2 Modifiability of an element: the 'user-modify' property

'user-modify'
Values:read-only | read-write | write-only | inherit
Initial:read-only
Applies to:all elements
Inherited:yes
Percentages:n/a
Media:interactive

The purpose of this property is to allow finer control over which user interface elements are user modifiable. Input elements can be pre-filled in, with the user-modify property set to read-only so that the user cannot change them. This is useful for templates, or for update forms. The user can still activate a read-only element and copy content out of it, if that is appropriate for the content model of the element. This is different from making the element "user-input:disabled" because that would prevent the user from activating the element.

Note that user agents may have a different initial value for the 'user-modify' property for some elements such as TEXTAREA which is typically user-modify:read-write.

read-only
The user can view, select (if applicable) and copy information out of the element, but cannot modify the contents of the element.
read-write
The user can view, select (if applicable), and edit the contents of the element.
write-only
The user can select and edit the contents of the element, but is unable to view the actual contents, nor copy them out. The rendering of the "unreadable" content is user agent dependent (perhaps rendered as nothing, a sequence of bullets or some other form of text-greeking.)

5.3.3 Content selection granularity: the 'user-select' property

'user-select'
Values:none | text | toggle | element | elements | all | inherit
Initial:text
Applies to:all elements (including 'empty') except replaced elements
Inherited:no
Percentages:n/a
Media:interactive

This property controls the selection model and granularity of an element. Additional selection models may be added in the future.

Note that although the initial value of 'user-select' is 'text', rules in the user agent's default style sheet may override this value. For example, user agents typically do not allow selection of the contents of a BUTTON element. E.g. BUTTON { user-select: none }

For the same reason, user-select: none is a typical default on the 'empty' INPUT elements. For replaced elements the content which replaces the element determines the user-select, which is why this property does not apply. For example, the user-select of an IFRAME is determined by the selection style of the HTML document inside.

This property is not inherited, but it does affect children in the same way that display: none does, it limits it. That is if an element is user-select: none, it doesn't matter what the user-select value is of its children, the element's contents or it's childrens contents cannot be selected.

none
None of the element's content can be selected. This is a very important value of user-select for user interface elements in particular. This value is one of the aspects of how a button behaves. The user cannot select any of the content inside the button. If for example, a user uses a pointing device to click on an element with user-select: none, what happens when the pointing device button is "down" is addressed by the user-input property, whereas when that pointing device button is "released", this property ensures that no selection of the contents of the element may remain. Another way to explain this is that user-select: none is what gives a button its "push-button-springy" feel. The value of 'none' is also useful for static text labels in a user interface which are not meant to be selected. For example, in the header of an email message window, the portion that says "Name:" cannot be selected, whereas the content following it can be. Such a static text label would also have user-input: none.
text
The element's contents follow a standard text content selection model.
toggle
The element's contents follow a standard toggling content model.
element
One element at a time may be selected.
elements
One or more elements at a time may be selected.
all
Only the entire contents as a whole can be selected.

5.3.4 Focus selection behavior of the contents of an element: the 'user-focus' property

'user-focus'
Values:auto | normal | select-all | select-before | select-after | select-same | select-menu | inherit
Initial:auto
Applies to:all elements
Inherited:yes
Percentages:n/a
Media:interactive

The purpose of this property is to determine what happens to an element when the user focusses it either by "tabbing" into it or clicking on it with a pointing device. This property serves as both a shortcut property that sets the values of the individual user-focus-key and user-focus-pointer properties, and also serves to determine what happens for any other input methods not covered by user-focus-key and user-focus-pointer.

auto
The default user agent behavior.
normal
The element simply acquires focus when activated. Nothing else.
select-all
The element's entire contents are selected.
select-before
Nothing is selected, and the insertion-point is placed immediately inside the element, but before the contents of the element.
select-after
Nothing is selected, and the insertion-point is placed immediately inside the element, but after the contents of the element.
select-same
The selection returns to precisely what was selected last time the element had focus. If this is the first time the element is being activated, the selection is whatever (if anything) was specified in the document markup. If nothing was specified, nothing is initially selected - similar to the 'normal' value.
select-menu
The generated :menu pseudo-element is selected when the element is focussed.
5.3.4.1 Focus selection behavior of the contents of an element via keyboard input: the 'user-focus-key' property
'user-focus-key'
Values:auto | normal | select-all | select-before | select-after | select-same | select-menu | inherit
Initial:auto
Applies to:all elements
Inherited:yes
Percentages:n/a
Media:interactive

The purpose of this property is to determine what happens to an element when the user focusses it specifically by clicking on it with a pointing device.

See 'user-focus' for definitions of the values.

5.3.4.2 Focus selection behavior of the contents of an element via pointing device: the 'user-focus-pointer' property
'user-focus-pointer'
Values:auto | normal | select-all | select-before | select-after | select-same | select-menu | inherit
Initial:auto
Applies to:all elements
Inherited:yes
Percentages:n/a
Media:interactive

The purpose of this property is to determine what happens to an element when the user focusses it specifically by "tabbing" into it.

See 'user-focus' for definitions of the values.

5.4 Toggle Groups - mutually exclusively toggled sets of elements

Mutually exclusively toggled user interface elements are controlled with two properties, 'toggle-group' and 'group-reset'. The groups defined by the group-reset property are used as values for the toggle-group property. These properties interact and cascade similarly to the 'counter-reset' and 'counter-increment' properties defined in CSS2.

5.4.1 Specifying a toggle group: the 'toggle-group' property

'toggle-group'
Values:<identifier> | none | inherit
Initial:none
Applies to:all elements
Inherited:no
Percentages:n/a
Media:all

The 'toggle-group' property accepts the name of a group (identifier). The property indicates which toggle group that the element is a member of. Only one element belonging to any given toggle group can be :checked.

If 'toggle-group' refers to a group that is not in the scope (see below) of any 'group-reset', the group is assumed to have been reset by the root element.

5.4.2 Resetting a group: the 'group-reset' property

'group-reset'
Values:<identifier>+ | none | inherit
Initial:none
Applies to:all elements
Inherited:no
Percentages:n/a
Media:all

The 'group-reset' property contains a list of one or more names of groups.

The 'group-reset' for a group X, creates a fresh group X, the scope of which is the element, its preceding siblings, and all the descendants of the element and its preceding siblings.

This example shows a way to create a group of three mutually exclusive radio buttons. 

.radiogroup1 { group-reset: group1 }
.radiobutton { 
    toggle-group: group1;
    display: inline-block;
    color: ButtonText;
    background: Button;
    border: ButtonBorder;
    font: button;
    white-space: nowrap;
    cursor: arrow;
    user-input: enabled;
    user-modify: read-only;
    user-select: toggle;
    user-focus: normal;
}
.radiobutton:before { content: radio }

<div class="radiogroup1">
    <div class="radiobutton">Win</div>
    <div class="radiobutton">Lose</div>
    <div class="radiobutton">Draw</div>
</div>

The 'group-reset' property follows the cascading rules. Thus, due to cascading, the following style sheet: 

div { group-reset: result }
div { group-reset: choice }

will only reset 'choice'. To reset both groups, they have to be specified together: 

div { group-reset: result choice }
Nested groups and scope

Groups are "self-nesting", in the sense that re-using a group in a child element automatically creates a new instance of the group. This is important for situations like dependent choices and sub-choices in HTML, where elements can be nested inside themselves to arbitrary depth. It would be impossible to define uniquely named groups for each level.

The self-nesting is based on the principle that every element that has a 'group-reset' for a group X, creates a fresh group X, the scope of which is the element, its preceding siblings, and all the descendants of the element and its preceding siblings.

Groups in elements with 'display: none'

An element that is not displayed ('display' set to 'none') cannot reset a group.

For example, with the following style sheet, H2s with class "secret" do not reset 'group2'. 

h2.secret {group-reset: count2; display: none}

Elements with 'visibility' set to 'hidden', on the other hand, do reset groups.

Appendix A. Additions to the Base Style Sheet for HTML4

Potential additions to the base style sheet to express HTML4 form elements:


a[href] { user-input: enabled }

button,
input[type=button],
input[type=reset],
input[type=submit],
input[type=checkbox],
input[type=radio],
textarea,
input,
input[type=text],
input[type=hidden],
input[type=password],
input[type=image]
{
/* appearance of the various types of HTML4 buttons */
 display: inline-block;
 color: ButtonText;
 background: Button;
 border: ButtonBorder;
 font: button;
 white-space: nowrap;
/* dynamic interface */
 cursor: arrow;
 user-input: enabled;
 user-modify: read-only;
 user-select: none;
 user-focus: normal;
}

input[type=button],
input[type=reset],
input[type=submit]
{
/* content and formatting of text in HTML4 input buttons */
 content: attr(value);
}

input[type=submit]
{
/* appearance of a default button */
 color: DefaultButtonText;
 background: DefaultButton;
 border: DefaultButtonBorder;
}

input[type=checkbox],
input[type=radio]
{
 user-select: toggle;
}

input[type=checkbox][name],
input[type=radio][name]
{
 toggle-group: attr(name);
}

input[type=checkbox]:before { content: checkbox }

input[type=radio]:before { content: radio }

textarea,
input[type=text],
input[type=hidden],
input[type=password]
{
/* appearance of HTML4 text fields */
 color: FieldText;
 background: Field;
 border: FieldBorder;
 font: field;
 white-space: nowrap;
/* user interface */
 cursor: text;
 user-modify: read-write;
 user-select: text;
 user-focus: select-all;
}

input[type=hidden] 
{
/* appearance of the HTML4 hidden text field in particular */
 display: none;
}

input[type=password] 
{
/* appearance of the HTML4 password text field in particular */
/* user interface of the HTML4 password text field in particular */
 user-modify: write-only;
}

textarea,
button
{
/* appearance of BUTTON and TEXTAREA tags in particular */
 white-space:normal;
}

input[type=image]
{
 content: url(attr(src));
 border: none;
 user-select: none;
 user-focus: normal;
}

select[size]
{
/* SELECT with size>1 - appearance of list */
 color: ListText;
 background: List;
 border: ListBorder;
 font: List;
 display: inline-block;
 height: attr(size)em;
 user-focus: select-same;
 user-select: elements;
}

select,select[size=1]
{
/* SELECT with no size attribute, or size=1 - popup-menu */
 color: PopupMenuText;
 background: PopupMenu;
 border: PopupMenuBorder;
 font: PopupMenu;
 display: inline-block;
 height: 1em;
 overflow: clip;
 user-input: enabled;
 user-focus: select-menu;
 user-select: element;
 user-modify: read-only;
}

select[size]:active
{
/* active SELECT with size>1 - appearance of active list */
 display: inline-block;
}

select:menu,select[size=1]:menu
{
 display: block;
}

optgroup,option
{
 display: block;
 white-space: nowrap;
 user-input: enabled;
}

optgroup
{
 user-focus: select-menu;
 user-select: element;
}

optgroup[label],option[label] 
{
 content: attr(label);
}

option[selected]:before 
{ 
 content: menu-check; display: marker;
}

*[accesskey]:enabled 
{ 
 key-equivalent:accesskey-attr(accesskey);
}

*[noresize] { resizer:none }

*[tabindex] { tab-index:attr(tabindex) }

button[disabled], input[disabled], 
optgroup[disabled], option[disabled],
select[disabled], textarea[disabled] 
{
 user-input:disabled;
}

/* other inline-block elements in HTML4 */
img, object, applet, embed, iframe, frame, frameset 
{ 
 display:inline-block; 
}