User Interface for CSS3

W3C Working Draft 16 Sep 1999

This version:
Latest version:
Previous version:
Tantek Çelik (tantekc@microsoft.com)
Tantek Çelik (tantekc@microsoft.com)
Peter Linss (peterl@netscape.com)
Sho Kuwamoto (sho@macromedia.com)
16 December 1999


This proposal 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. This is the first working draft for these proposals.

Feedback is very much welcomed. Comments can be sent directly to the editor, but the mailing list www-style@w3.org (see instructions) is also open 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.


1. Introduction

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 make an arbitrary structural element take on the dynamic presentation of the system default look and feel of various standard user interface widgets.

1.1 Purpose

Specifically, 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 three HTML4 attributes could be deprecated:

1.4 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 FRAMESET and FRAME?
  2. How do we specify the precise behavior of radio button elements (INPUT TYPE="radio") which only allow one element to be :checked among each group of radio button elements that has the same NAME attribute? Or OPTION elements of a SELECT menu which only allow one element to be :checked in the entire SELECT? One possible solution is to create two new properties: 'toggle-group' and 'toggle-group-reset'. These properties would work similar to 'counter-increment' and 'counter-reset'. 'toggle-group' would accept a string value, which essentially is a named toggle group, just like the value for the 'counter-increment' property is a named counter. Also similarly, the 'toggle-group-reset' for a toggle-group X, creates a fresh toggle-group X, the scope of which is the element, its preceding siblings, and all the descendants of the element and its preceding siblings.
  3. 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?
  4. :root and :viewport pseudo-classes
  5. 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?
  6. There needs to be a way to distinguish between an element acquiring :focus by the user clicking on it, and by the user tabbing into it. A typical preference is that in the tab-in case, the entire contents of the element are selected, whereas in the click-in case, an insertion point is placed at the click location and nothing is selected initially. One solution would be to add two specific properties to override the user-focus property: 'key-focus' and 'pointer-focus' that would take the same values as the 'user-focus' property.
  7. 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.
  8. Should we add the notion of indeterminate checkboxes and radio buttons? E.g. an :indeterminate pseudo-class, and indeterminate versions of the various glyphs for the content property for checkbox and radio button.
  9. Should we distinguish system colors of elements in the front-most window versus non-front-most windows?
  10. Should we add a system color window subtype to represent palettes or floating windows (or both)?

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

The :menu pseudo-element is automatically generated for an element whose user-focus property is set to select-menu. 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

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)

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


Indicates something is to be copied. Often rendered as an arrow with a small plus sign next to it.
Indicates an alias of/shortcut to something is to be created. Often rendered as an arrow with a small curved arrow next to it.
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.
Indicates that a cell or set of cells may be selected. Often rendered as a thick plus-sign with a dot in the middle.
Indicates something is to be grabbed. Often rendered as an open hand.
Indicates that the user has grabbed something. Often rendered as a closed hand.
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.
Indicates that the program is performing a counting up operation.
Indicates that the program is performing a count down operation.
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.

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

	EnabledButton, DisabledButton, ActiveButton, HoverButton

Summary of fallback handling for system colors

The 40 state independent colors and their respective 160 state specific colors make a total of potentially 200 separate system colors for the UA to support. Not all UAs or platforms may be able to support all 200 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

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)

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


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

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. The menu value should be considered "inline-level" similar to how display:list-item is considered "block-level", and formatted accordingly.

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

New Values:<uri> |
check | diamond | menu-check |
radio-on | radio-off | disabled-radio-on | disabled-radio-off | active-radio-off | active-radio-on |
checkbox-on | checkbox-off | disabled-checkbox-on | disabled-checkbox-off | active-checkbox-on | active-checkbox-off
Initial:see CSS2
Applies to:see CSS2
Inherited:see CSS2
Percentages:see CSS2
Media:see CSS2
Replace the contents of the element with the contents of the URI specified.
A check mark.
A filled diamond. Like 'square' but rotated 45 degrees.
The system standard check-mark to indicate a 'checked' menu item.
The system standard renderings of a radio button in its various states.
The system standard renderings of a checkbox button in its various 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.

New Values: check | diamond | menu-check |
radio-on | radio-off | disabled-radio-on | disabled-radio-off | active-radio-off | active-radio-on |
checkbox-on | checkbox-off | disabled-checkbox-on | disabled-checkbox-off | active-checkbox-on | active-checkbox-off
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

Values: auto | both | horizontal | vertical | none | inherit
Applies to:all elements

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.

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


       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

Values: none | (<key-press-combination> )+ | inherit
Applies to:all enabled elements

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.

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.


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}
INPUT.forcequit { key-equivalent: ctrl-alt-del cmd-opt-esc }

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

5.3 Dynamic presentation

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

Values:auto | none | enabled | disabled | inherit
Applies to:all elements

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.

The UA determines the user-input permissions value to use based on the current context and platform.
The element is not an element that responds to user input. It is considered neither enabled nor disabled. It does not become :active.
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.
The element is functionally disabled and does not respond to user input. Any applicable :disabled pseudo-class selectors are also applied.

Note: 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 for example.


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

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

Values:read-only | read-write | write-only | inherit
Applies to:all elements

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.

The user can view, select (if applicable) and copy information out of the element, but cannot modify the contents of the element.
The user can view, select (if applicable), and edit the contents of the element.
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

Values:none | text | toggle | element | elements | all | inherit
Applies to:all elements (including 'empty') except replaced elements

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 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.
The element's contents follow a standard text content selection model.
The element's contents follow a standard toggling content model.
One element at a time may be selected.
One or more elements at a time may be selected.
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

Values:auto | normal | select-all | select-before | select-after | select-same | select-menu | inherit
Applies to:all elements

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.

The default user agent behavior.
The element simply acquires focus when activated. Nothing else.
The element's entire contents are selected.
Nothing is selected, and the insertion-point is placed immediately inside the element, but before the contents of the element.
Nothing is selected, and the insertion-point is placed immediately inside the element, but after the contents of the element.
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.
A :menu pseudo-element is generated which can be separately styled and is selected when the element is focussed.

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 }

/* 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;

/* content and formatting of text in HTML4 input buttons */
 content: attr(value);

/* appearance of a default button */
 border: DefaultButtonBorder;


/* appearance of HTML4 text fields */
 color: FieldText;
 background: Field;
 border: FieldBorder;
 font: field;
 display: inline-block;
 white-space: nowrap;
/* user interface */
 cursor: text;
 user-modify: read-write;
 user-select: text;
 user-focus: select-all;

/* appearance of the HTML4 hidden text field in particular */
 display: none;

/* appearance of the HTML4 password text field in particular */
/* user interface of the HTML4 password text field in particular */
 user-modify: write-only;

/* appearance of BUTTON and TEXTAREA tags in particular */

 content: url(attr(src));
 border: none;
 user-select: none;
 user-focus: normal;

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

/* SELECT tags with no size attribute, or size=1 - popup-menu SELECT */
 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;

/* active SELECT tags with size>1 - appearance of active list SELECT */
 display: inline-block;

 display: block;

 display: block;
 white-space: nowrap;
 user-input: enabled;

 user-focus: select-menu;
 user-select: element;

 content: attr(label);

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

*[noresize] { resizer:none }

BUTTON[disabled], INPUT[disabled], OPTGROUP[disabled], OPTION[disabled], SELECT[disabled], TEXTAREA[disabled] { user-input:disabled }