Copyright © 2003 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This working draft contains:
This document is a draft of one of the "modules" for the upcoming CSS3 specification. It not only describes the user interface related properties and values that already exist in CSS1 and CSS2.1, but also proposes new properties and values for CSS3 as well. The Working Group doesn't expect that all implementations of CSS3 will implement all properties or values. Instead, there will probably be a small number of variants of CSS3, so-called "profiles".
The current draft is the result of the merging of relevant parts of the following Recommendations and Working Drafts, and the addition of some new features.
This document is a working draft of the CSS working group which is part of the style activity (see summary). This is a W3C Last Call Working Draft. Last call means that the working group believes that this specification is ready and therefore wishes this to be the last call for comments. If the feedback is positive, the working group plans to submit it for consideration as a W3C Candidate Recommendation. Comments can be sent until 31 July 2003.
Comments on, and discussions of this draft can be sent to the (archived) public mailing list www-style@w3.org (see instructions). W3C Members can also send comments directly to the CSS working group.
Patent disclosures relevant to CSS may be found on the Working Group's public patent disclosure page.
To find the latest version of this working draft, please follow the "Latest version" link above, or visit the list of W3C Technical Reports.
This section describes major changes from the previous draft of 2 August 2002.
CSS3 is a set of modules, divided up and profiled in order to simplify the specification, and to allow implementors the flexibility of supporting the particular modules appropriate for their implementations.
This module describes selectors and CSS properties which enable authors to style user interface related states, element fragments, properties and values.
Section 2.1 of CSS1 and Chapter 18 of CSS2 introduced several user interface related pseudo-classes, properties and values. Section 6.6.4 of Selectors also describes several additional user interface related pseudo-classes (and one pseudo-element).
This working draft extends them to provide the ability, through CSS, to style elements based upon additional user interface states, to style fragments of user interface elements, and to alter the dynamic presentation of elements in ways previously only available through specific HTML4 elements and attributes.
The purpose of this proposal is to achieve the following objectives:
This proposal specifies how to alter 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 is not afforded any additional meaning, so pushing it does nothing by default, and certainly does not submit 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 the appearance of 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:
In addition, this document does not attempt to solve all user interface related issues / features that can be found in modern user interfaces. Perhaps future versions may attempt to solve these. For example:
This CSS3 module depends on the following other CSS3 modules:
It has non-normative (informative) references to the following other CSS3 modules:
The following work is related to the CSS3 Module Basic User Interface working draft.
Selectors [SELECT] defines several user interface selectors which represent user interface states:
These pseudo-classes as defined by [SELECT] are included in this specification by reference.
In addition to the above-mentioned pseudo-classes, this specification introduces several new pseudo-classes to define additional user interface states.
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].
The :default selector applies to a UI element that is the default among a set of similar elements. Typically applies to context menu items and buttons. One example is the default submit button among a set of buttons.
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.
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 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 model.
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.
An element whose contents are not user-alterable is :read-only. However, elements whose contents are user-alterable (such as text input fields) are considered to be in a :read-write state. In typical documents, most elements are :read-only. However it may be possible (e.g. in the context of an editor) for any element to become :read-write.
Selectors [SELECT] also defines one user interface element fragment selector:
This pseudo-element is included in this specification as defined by [SELECT] by reference.
In addition to the above-mentioned pseudo-element, this specification introduces four new pseudo-elements to provide access to additional user interface element fragments.
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.
Similarly, a form element which represents a list of options may contain both a label for the list, and the list of choices itself. For such elements, the ::choices pseudo-element selects the representation of just the list of choices themselves, in order to style their appearance.
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.
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.
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.
Name: | appearance |
Value: | normal | icon | window | document | workspace | desktop | tooltip | dialog | button | push-button | hyperlink | radio-button | checkbox | menu | menubar | pull-down-menu | pop-up-menu | list-menu | radio-group | checkbox-group | outline-tree | field | inherit |
Initial: | normal |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | interactive |
Computed value: | specified value |
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 default.
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 varied.
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).
CSS2 introduced system font values as values for the shorthand 'font' property which have the effect of setting all the elemental 'font-*' properties. This specification adds the list of 'appearance' control values to the set of system fonts to allow styling text the same as such system controls.
Name: | font |
System values: | icon | window | status-bar | document | workspace | desktop | tooltip | message-box | dialog | button | caption | small-caption | push-button | hyperlink | radio-button | checkbox | menu | menubar | pull-down-menu | pop-up-menu | list-menu | radio-group | checkbox-group | outline-tree | field | inherit |
Initial: | normal |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | interactive |
Computed value: | The computed values for system font values are simply the value keywords themselves. |
Name: | display |
New Value(s): | icon |
Initial: | inline |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | all |
Computed value: | specified value |
Name: | icon |
Value: | auto | <uri>+ |
Initial: | auto |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | all |
Computed value: | The computed value for 'auto' is 'auto'. The computed value for the <uri>+ value is either the fully qualified URI value for the referenced icon that the UA is able to render, or 'auto' if the UA did not find any referenced icons that it could render. |
The 'icon' property provides the author the ability to style any arbitrary element with an iconic equivalent. An element's icon is not used/rendered unless the 'display' property is set to the value 'icon' (see above). Documents whose elements have icons assigned to them can be more easily viewed by users who find too much text distracting.
A user could simply add a rule such as:
p { display:icon }
which would then render an icon in place of each paragraph.
Name: | box-sizing |
Value: | content-box | border-box | inherit |
Initial: | content-box |
Applies to: | all elements that accept width or height |
Inherited: | no |
Percentages: | N/A |
Media: | same as width and height |
Computed value: | specified value |
Description
At times, style sheet authors may want to create outlines around visual objects such as buttons, active form fields, image maps, etc., to make them stand out. Outlines differ from borders in the following ways:
The outline properties control the style of these dynamic outlines.
Name: | outline |
Value: | [ <'outline-color'> || <'outline-style'> || <'outline-width'> ] | inherit |
Initial: | see individual properties |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | undefined for shorthand properties |
Name: | outline-width |
Value: | <border-width> | inherit |
Initial: | medium |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | <length> value in absolute units (px or physical). |
Name: | outline-style |
Value: | <border-style> | inherit |
Initial: | none |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | specified value |
Name: | outline-color |
Value: | <color> | invert | inherit |
Initial: | invert |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | The computed value for 'invert' is 'invert'. For <color> values, the computed value is as defined for the [CSS3COLOR] 'color' property. |
The outline created with the outline properties is drawn "over" a box, i.e., the outline is always on top, and doesn't influence the position or size of the box, or of any other boxes. Therefore, displaying or suppressing outlines does not cause reflow.
Outlines may be non-rectangular. For example, if the element is broken across several lines, the outline should be an outline or minimum set of outlines that encloses all the element's boxes. Each part of the outline should be fully connected rather than open on some sides (as borders on inline elements are when lines are broken). The parts of the outline are not required to be rectangular. The position of the outline may be affected by descendant boxes. User agents should use an algorithm for determining the outline that encloses a region appropriate for conveying the concept of focus to the user.
The 'outline-width' property accepts the same values as 'border-width'.
The 'outline-style' property accepts the same values as 'border-style', except that 'hidden' is not a legal outline style.
The 'outline-color' accepts all colors, as well as the keyword 'invert'. 'Invert' is expected to perform a color inversion on the pixels on the screen. This is a common trick to ensure the focus border is visible, regardless of color background.
Conformant UAs may ignore the 'invert' value on platforms that do not support color inversion of the pixels on the screen. If the UA does not support the 'invert' value then the initial value of the 'outline-color' property is the 'currentColor' [CSS3COLOR] keyword.
The 'outline' property is a shorthand property, and sets all three of 'outline-style', 'outline-width', and 'outline-color'.
Note. The outline is the same on all sides. In contrast to borders, there are no 'outline-top' or 'outline-left' etc. properties.
This specification does not define how multiple overlapping outlines are drawn, or how outlines are drawn for boxes that are partially obscured behind other elements.
Note. Since the focus outline does not affect formatting (i.e., no space is left for it in the box model), it may well overlap other elements on the page.
By default, the outline is drawn starting just outside the border edge. However, it is possible to offset the outline and draw it beyond the border edge.
Name: | outline-offset |
Value: | <length> | inherit |
Initial: | 0 |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | visual |
Computed value: | <length> value in absolute units (px or physical). |
If the computed value of 'outline-offset' is anything other than 0, then the outline is outset from the border edge by that amount.
Here's an example of drawing a thick outline around a BUTTON element:
button { outline: thick solid }
Scripts may be used to dynamically change the width of the outline, without provoking reflow.
Graphical user interfaces may use outlines around elements to tell the user which element on the page has the focus. These outlines are in addition to any borders, and switching outlines on and off should not cause the document to reflow. The focus is the subject of user interaction in a document (e.g., for entering text, selecting a button, etc.).
For example, to draw a thick black line around an element when it has the focus, and a thick red line when it is active, the following rules can be used:
:focus { outline: thick solid black } :active { outline: thick solid red }
CSS2 provides a mechanism for controlling the appearance of a scrolling mechanism (e.g. scrollbars), and this specification adds to that a mechanism for controlling user resizability of elements.
The 'resize' property allows the author to specify whether or not an element is resizable by the user, and if so, along which axis/axes.
Name: | resize |
Value: | auto | both | horizontal | vertical | none | inherit |
Initial: | auto |
Applies to: | all elements |
Inherited: | no |
Percentages: | N/A |
Media: | interactive |
Computed value: | specified value. |
Currently it is possible to control the appearance of the scrolling mechanism (if any) on an element using the overflow property (e.g. 'overflow: scroll' vs. 'overflow: hidden' etc.). The purpose of the resize property is to also allow control over the appearance and function of the resizing mechanism (e.g. a resize box or widget) on the element.
Note: the resizing mechanism is NOT the same as the scrolling mechanism. The scrolling mechanism allows the user to determine which portion of a the contents of an element is shown. The resizing mechanism allows the user to determine the size of the element. The user agent may restrict the resizing range to something suitable, such as between the formatted size of the element, and large enough to encompass all the elements contents.
The 'resize' property applies to elements whose computed overflow value is something other than 'visible'. If overflow is different in a particular axis (i.e. overflow-x vs. overflow-y), then this property applies to the dimension(s) which do not have the value 'visible'.
When the user manipulates the resizing mechanism, the actual width and height of the element are altered accordingly. 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.
Example:
html { width: 100px; height: 100px; overflow: hidden; resize: none } /* display content in a non-resizable 100px by 100px window */
Name: | cursor |
Value: | [ [<uri> [<x> <y>],]* [ auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize | w-resize | ns-resize | ew-resize | nesw-resize | nwse-resize | text | wait | help | progress | copy | alias | context-menu | cell | all-scroll | col-resize | row-resize | no-drop | not-allowed | vertical-text ] ] | inherit |
Initial: | auto |
Applies to: | all elements |
Inherited: | yes |
Percentages: | N/A |
Media: | visual and interactive |
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. |
Description
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.
Name: | key-equivalent |
Value: | none | (<key-press-combination> )+ | <system-key-equivalent> | list-item-marker | inherit |
Initial: | none |
Applies to: | all enabled elements |
Inherited: | no |
Percentages: | n/a |
Media: | interactive |
Computed value: | specified value. |
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 (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.
There may be platform and user agent limitations to key-equivalents which conflict with those inherent in the user agent and operating system.
If two or more elements in the same document are given the same key-equivalent, the first (in document order) of such elements is activated by the key-equivalent first. Implementations may then activate each of the remaining elements with the same key equivalent in document order when that key equivalent is activated.
Pressing an key-equivalent assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a hyperlink, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.
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 ('-'). Each character must be specified in uppercase or as an escaped character (character entity) - 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.
If the specified value for key-equivalent contains a key which is unavailable on the system (for whatever reason), then that specified value is ignored as it would be if the value was an unrecognized value.
Note. Should we include "standard" keys from other consumer computing devices?
<key-press-combination> = <key> ('-'
<key>)*
<key> = space | <character[CN]> | <special-key> |
accesskey-attr(<attribute>)
<special-key> = <modifier-key> | <function-key> |
<navigation-key> | <edit-key> | <misc-key> |
<volume-control-key> | <phone-key> | <application-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
<volume-control-key> = volumeup | volumedown
<phone-key> = phoneend | phonesend | phoneaccept
<application-key> = memo | todo | calendar | mail | address
'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-\2E N } /* cmd-\2E = cmd-. */ /* non-nmstart characters must be escaped to comply with the CSS grammar */ 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}
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 }
Use the computed list item marker as the key equivalent.
This enables authors to construct a list of elements with key-equivalents that are determined automatically according to their list numbering (and style).
For example, in a document containing this style sheet:
/* style sheet */ div.navmenu { list-style:decimal } div.navmenu a { display:list-item; key-equivalent: list-item-marker; text-decoration:none }
The following markup:
<div class='navmenu'> <a href='#chocolate'>Chocolate</a> <a href='#vanilla'>Vanilla</a> <a href='#strawberry'>Strawberry</a> </div>
Renders as follows:
Where the items are automatically given the key-equivalents \31, \32, \33 respectively without the author having to manually specify them. Similarly, if the author specified 'list-style:upper-latin' on the div.navmenu, then the hyperlinks would have the key-equivalents A, B, C - again, the same as their list item markers.
Note. Other values may be permitted in future levels of CSS.
Previously known as 'tab-index', this property has been renamed, and redefined in terms of an input-method-neutral definition, that is, in terms of a sequential navigation order rather than tabbing order.
Name: | nav-index |
Value: | auto | <number> | inherit |
Initial: | auto |
Applies to: | all enabled elements |
Inherited: | no |
Percentages: | n/a |
Media: | interactive |
Computed value: | specified value. |
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 sequential navigation order for the current document.
The sequential navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The sequential navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
The actual key sequence that causes sequential navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is often used for sequential navigation, and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the sequential navigation order in reverse. When the end (or beginning) of the tabbing order is reached, user agents may circle back to the beginning (or end). "shift-tab" is often used for reverse sequential navigation.
Names: | nav-up, nav-right, nav-down, nav-left |
Value: | auto | <uri> [ <target-name> | root ]? | inherit |
Initial: | auto |
Applies to: | all enabled elements |
Inherited: | no |
Percentages: | N/A |
Media: | interactive |
Computed value: | Fully qualified <uri> with optional <target-name>. |
The <uri> should indicate (through the use of a fragment identifier) the element to which the focus is to be navigated to in response to directional navigation input respective to the specific property.
If the <uri> is a fragment identifier that refers to the currently focused element, the directional navigation input respective to the nav- property is ignored — there is no need to refocus the same element.
If the <uri> is not a local fragment identifier, user agent should navigate to the page specified by the external <uri> in response to the directional navigation input. If the external <uri> contains a fragment identifier, the element specified by the fragment identifier should receive focus. Note that after user agent has navigated to another page, there is no way to navigate back to the original page via directional focus navigation unless there is an element on the destination page with a nav-* property set to the original page's URI.
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).
Potential additions to the base style sheet to express HTML4 form elements and a few HTML4 dynamic presentation attributes:
a[href] { appearance: hyperlink; /* set color, font, background, padding, border, etc.*/ cursor: pointer; } a[href]:focus { outline: 2px inset inverse; } 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: button; display: inline-block; white-space: nowrap; cursor: default; } button, input[type=button], input[type=reset][value], input[type=submit][value] { /* appearance of HTML4 push buttons */ appearance: push-button; } input[type=reset] { /* default content of HTML4 input type=reset button */ content: "Reset"; } input[type=submit] { /* default content of HTML4 input type=submit button */ content: "Submit"; } input[type=button], input[type=reset][value], input[type=submit][value] { /* text content/labels of HTML4 "input" buttons */ content: attr(value); } textarea, input, input[type=text], input[type=hidden], input[type=password] { appearance: field; white-space: nowrap; /* user interface */ cursor: text; } input[type=hidden] { /* appearance of the HTML4 hidden text field in particular */ display: none; } textarea, button { /* appearance of BUTTON and TEXTAREA tags in particular */ white-space:normal; } input[type=image] { display: inline-block; content: attr(src,url); border: none; } select[size] { /* SELECT with size>1 - appearance of list */ appearance: list-menu; display: inline-block; height: attr(size,em); } select,select[size=1] { /* SELECT with no size attribute, or size=1 - popup-menu */ appearance: popup-menu; display: inline-block; height: 1em; overflow: hidden; } select[size]:active { /* active SELECT with size>1 - appearance of active list */ display: inline-block; } optgroup,option { display: block; white-space: nowrap; } optgroup[label],option[label] { content: attr(label); } option[selected]:before { content: check; display: inline; } *[accesskey]:enabled { key-equivalent:accesskey-attr(accesskey); } *[noresize] { resize:none } *[tabindex] { nav-index:attr(tabindex) } /* other inline-block elements in HTML4 */ img, object, applet, embed, iframe, frame, frameset { display:inline-block; }
[acknowledgments]
Property | Values | Initial | Applies to | Inh. | Percentages | Media |
---|---|---|---|---|---|---|
appearance | normal | icon | window | document | workspace | desktop | tooltip | dialog | button | push-button | hyperlink | radio-button | checkbox | menu | menubar | pull-down-menu | pop-up-menu | list-menu | radio-group | checkbox-group | outline-tree | field | inherit | normal | all elements | no | N/A | interactive |
box-sizing | content-box | border-box | inherit | content-box | all elements that accept width or height | no | N/A | same as width and height |
cursor | [ [<uri> [<x> <y>],]* [ auto | crosshair | default | pointer | move | e-resize | ne-resize | nw-resize | n-resize | se-resize | sw-resize | s-resize | w-resize | ns-resize | ew-resize | nesw-resize | nwse-resize | text | wait | help | progress | copy | alias | context-menu | cell | all-scroll | col-resize | row-resize | no-drop | not-allowed | vertical-text ] ] | inherit | auto | all elements | yes | N/A | visual and interactive |
display | icon | inline | all elements | no | N/A | all |
font | icon | window | status-bar | document | workspace | desktop | tooltip | message-box | dialog | button | caption | small-caption | push-button | hyperlink | radio-button | checkbox | menu | menubar | pull-down-menu | pop-up-menu | list-menu | radio-group | checkbox-group | outline-tree | field | inherit | normal | all elements | no | N/A | interactive |
icon | auto | <uri>+ | auto | all elements | no | N/A | all |
key-equivalent | none | (<key-press-combination> )+ | <system-key-equivalent> | list-item-marker | inherit | none | all enabled elements | no | n/a | interactive |
nav-index | auto | <number> | inherit | auto | all enabled elements | no | n/a | interactive |
nav-up, nav-right, nav-down, nav-left | auto | <uri> [ <target-name> | root ]? | inherit | auto | all enabled elements | no | N/A | interactive |
outline | [ <'outline-color'> || <'outline-style'> || <'outline-width'> ] | inherit | see individual properties | all elements | no | N/A | visual |
outline-color | <color> | invert | inherit | invert | all elements | no | N/A | visual |
outline-offset | <length> | inherit | 0 | all elements | no | N/A | visual |
outline-style | <border-style> | inherit | none | all elements | no | N/A | visual |
outline-width | <border-width> | inherit | medium | all elements | no | N/A | visual |
resize | auto | both | horizontal | vertical | none | inherit | auto | all elements | no | N/A | interactive |