Title: CSS Snapshot 2015
Shortname: css-2015
Level: 1
Status: NOTE
Group: CSSWG
Work Status: Exploring
URL: https://drafts.csswg.org/css-2015/
TR: https://www.w3.org/TR/CSS
Editor: Tab Atkins Jr., Google, http://xanthir.com/
Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact
Abstract: This document collects together into one definition all the specs that
	together form the current state of Cascading Style Sheets (CSS) as of 2015.
	The primary audience is CSS implementers, not CSS authors, as this definition
	includes modules by specification stability, not Web browser adoption rate.

This document represents the state of CSS as of 2015. The CSS Working Group does not expect any further changes to this document: new snapshots will be published at http://www.w3.org/TR/CSS/ as CSS advances.

* Plan to incorporate intro material from CSS2.1 in next update * Plan to incorporate property indices/glossaries/etc. once we can generate them for an entire snapshot

Introduction {#intro} ===================== When the first CSS specification was published, all of CSS was contained in one document that defined CSS Level 1. CSS Level 2 was defined also by a single, multi-chapter document. However for CSS beyond Level 2, the CSS Working Group chose to adopt a modular approach, where each module defines a part of CSS, rather than to define a single monolithic specification. This breaks the specification into more manageable chunks and allows more immediate, incremental improvement to CSS. Since different CSS modules are at different levels of stability, the CSS Working Group has chosen to publish this profile to define the current scope and state of Cascading Style Sheets as of late 2015. This profile includes only specifications that we consider stable and for which we have enough implementation experience that we are sure of that stability. Note: This is not intended to be a CSS Desktop Browser Profile: inclusion in this profile is based on feature stability only and not on expected use or Web browser adoption. This profile defines CSS in its most complete form. Note: Although we don't anticipate significant changes to the specifications that form this snapshot, their inclusion does not mean they are frozen. The Working Group will continue to address problems as they are found in these specs. Implementers should monitor www-style and/or the CSS Working Group Blog for any resulting changes, corrections, or clarifications.

Background: The W3C Process and CSS

This section is non-normative. In the W3C Process, a Recommendation-track document passes through three levels of stability, summarized below:

Working Draft (WD): This is the design phase of a W3C spec. The WG iterates the spec in response to internal and external feedback. The first official Working Draft is designated the “First Public Working Draft” (FPWD). In the CSSWG, publishing FPWD indicates that the Working Group as a whole has agreed to work on the module, roughly as scoped out and proposed in the editor's draft. The transition to the next stage is sometimes called “Last Call Working Draft” (LCWD) phase. The CSSWG transitions Working Drafts once we have resolved all known issues, and can make no further progress without feedback from building tests and implementations. This ”Last Call for Comments” sets a deadline for reporting any outstanding issues, and requires the WG to specially track and address incoming feedback. The comment-tracking document is the Disposition of Comments (DoC). It is submitted along with an updated draft for the Director's approval, to demonstrate wide review and acceptance.
Candidate Recommendation (CR): This is the testing phase of a W3C spec. Notably, this phase is about using tests and implementations to test the specification: it is not about testing the implementations. This process often reveals more problems with the spec, and so a Candidate Recommendation will morph over time in response to implementation and testing feedback, though usually less so than during the design phase (WD). Demonstration of two correct, independent implementations of each feature is required to exit CR, so in this phase the WG builds a test suite and generates implementation reports. The transition to the next stage is “Proposed Recommendation” (PR). During this phase the W3C Advisory Committee must approve the transition to REC.
Recommendation (REC): This is the completed state of a W3C spec and represents a maintainance phase. At this point the WG only maintains an errata document and occasionally publishes an updated edition that incorporates the errata back into the spec.

An Editor's Draft is effectively a live copy of the editors’ own working copy. It may or may not reflect Working Group consensus, and can at times be in a self-inconsistent state. (Because the publishing process at W3C is time-consuming and onerous, the Editor's Draft is usually the best (most up-to-date) reference for a spec. Efforts are currently underway to reduce the friction of publishing, so that official drafts will be regularly up-to-date and Editor's Drafts can return to their original function as scratch space.)

Cascading Style Sheets (CSS) — The Official Definition

As of 2015, Cascading Style Sheets (CSS) is defined by the following specifications.

CSS Level 2, latest revision (including errata): This defines the core of CSS, parts of which are overridden by later specifications. We recommend in particular reading Chapter 2, which introduces some of the basic concepts of CSS and its design principles.
CSS Syntax Level 3: Replaces CSS2§4.1, CSS2§4.1, CSS2§4.2, CSS2§4.4, and CSS2§G, defining how CSS is parsed.
CSS Style Attributes: Defines how CSS declarations can be embedded in markup attributes.
Media Queries Level 3: Replaces CSS2§7.3 and expands on the syntax for media-specific styles.
CSS Conditional Rules Level 3: Replaces CSS2§7.2, updating the definition of ''@media'' rules to allow nesting, and introduces ''@supports'' rules for feature-support queries.
CSS Namespaces: Introduces an ''@namespace'' rule to allow namespace-prefixed selectors.
Selectors Level 3: Replaces CSS2§5 and CSS2§6.4.3, defining an extended range of selectors.
CSS Cascading and Inheritance Level 3: Replaces CSS2§1.4.3 and CSS2§6
CSS Transitions Level 1 and CSS Animations Level 1: Define mechanisms for transitioning the computed values of CSS properties over time. ISSUE: IIRC, these specs have some fairly significant out-of-dateness atm... Should they move to the note below? Or a different note?
CSS Values and Units Level 3: Replaces CSS2§1.4.2.1, CSS2§4.3, and CSS2§A.2.1–3, defining CSS's property definition syntax and expanding its set of units.
CSS Color Level 3: Replaces CSS2§4.3.6, CSS2§14.1, and CSS2§18.2, defining an extended range of color values. Also introduces the 'opacity' property.
CSS Backgrounds and Borders Level 3: Replaces CSS2§8.5 and CSS2§14.2, providing more control of backgrounds and borders, including layered background images, image borders, and drop shadows.
CSS Image Values and Replaced Content Level 3: Provides a new foundation text for the sizing of replaced elements (such as images), adds additional controls to their sizing and orientation, and introduces syntax for gradients as images in CSS.
CSS Fonts Level 3: Replaces CSS2§15 and provides more control over font choice and feature selection.
CSS Multi-column Layout Level 1: Introduces multi-column flows to CSS layout.
CSS Flexible Box Module Level 1: Introduces a flexible linear layout model for CSS. ISSUE: This spec isn't very stable yet... (We all wish it was though.) Should it move to the note below?
CSS User Interface Module Level 3: Replaces CSS2§18.1 and CSS2§18.4, defining 'cursor', 'outline', and several new CSS features that also enhance the user interface.
CSS Transforms Level 1: Introduces graphical transformations to CSS. ISSUE: Is this thing actually up-to-date and referenceable?
CSS Compositing and Blending Level 1: Defines the compositing and blending of overlaid content and introduces features to control their modes.

Issue: Add will-change once it's pushed to CR

The following modules have completed design work, and are fairly stable, but have not received much testing and implementation experience yet:

CSS Counter Styles Level 3: Expands the possible values of <> and provides an ''@counter-style'' syntax for customized counter styles.
CSS Masking Level 1: Replaces CSS2§11.1.2 and introduces more powerful ways of clipping and masking content.
CSS Shapes Module Level 1: Extends floats to effect non-rectangular wrapping shapes.
CSS Text Decoration Level 3: Replaces CSS2§16.3, providing more control over text decoration lines and adding the ability to specify text emphasis marks and text shadows.
CSS Speech Module Level 1: Replaces CSS2§A, overhauling the (non-normative) speech rendering chapter.

We hope to incorporate them into a future snapshot.

ISSUE: Should we have a section for "These specifications are widely implemented, but their specifications are out-of-sync with reality" for Transitions/Transforms/Animations/Flexbox? Advisement: A list of all CSS modules, stable and in-progress, and their statuses can be found at the CSS Current Work page.

CSS Levels

Cascading Style Sheets does not have versions in the traditional sense; instead it has levels. Each level of CSS builds on the previous, refining definitions and adding features. The feature set of each higher level is a superset of any lower level, and the behavior allowed for a given feature in a higher level is a subset of that allowed in the lower levels. A user agent conforming to a higher level of CSS is thus also conformant to all lower levels.

CSS Level 1: The CSS Working Group considers the CSS1 specification to be obsolete. CSS Level 1 is defined as all the features defined in the CSS1 specification (properties, values, at-rules, etc), but using the syntax and definitions in the CSS2.1 specification. CSS Style Attributes defines its inclusion in element-specific style attributes.
CSS Level 2: Although the CSS2 specification is technically a W3C Recommendation, it passed into the Recommendation stage before the W3C had defined the Candidate Recommendation stage. Over time implementation experience and further review has brought to light many problems in the CSS2 specification, so instead of expanding an already unwieldy errata list, the CSS Working Group chose to define CSS Level 2 Revision 1 (CSS2.1). In case of any conflict between the two specs CSS2.1 contains the definitive definition. Once CSS2.1 became Candidate Recommendation—effectively though not officially the same level of stability as CSS2—obsoleted the CSS2 Recommendation. Features in CSS2 that were dropped from CSS2.1 should be considered to be at the Candidate Recommendation stage, but note that many of these have been or will be pulled into a CSS Level 3 working draft, in which case that specification will, once it reaches CR, obsolete the definitions in CSS2. The CSS2.1 specification defines CSS Level 2 and the CSS Style Attributes specification defines its inclusion in element-specific style attributes.
CSS Level 3: CSS Level 3 builds on CSS Level 2 module by module, using the CSS2.1 specification as its core. Each module adds functionality and/or replaces part of the CSS2.1 specification. The CSS Working Group intends that the new CSS modules will not contradict the CSS2.1 specification: only that they will add functionality and refine definitions. As each module is completed, it will be plugged in to the existing system of CSS2.1 plus previously-completed modules. From this level on modules are levelled independently: for example Selectors Level 4 may well be completed before CSS Line Module Level 3. Modules with no CSS Level 2 equivalent start at Level 1; modules that update features that existed in CSS Level 2 start at Level 3.
CSS Level 4 and beyond: There is no CSS Level 4. Independent modules can reach level 4 or beyond, but CSS the language no longer has levels. ("CSS Level 3" as a term is used only to differentiate it from the previous monolithic versions.)

CSS Profiles

Not all implementations will implement all functionality defined in CSS. For example, an implementation may choose to implement only the functionality required by a CSS Profile. Profiles define a subset of CSS considered fundamental for a specific class of CSS implementations. The W3C CSS Working Group defines the following CSS profiles:

Note: Partial implementations of CSS, even if that subset is an official profile, must follow the forward-compatible parsing rules for partial implementations.

Requirements for Responsible Implementation of CSS

The following sections define several conformance requirements for implementing CSS responsibly, in a way that promotes interoperability in the present and future.

Partial Implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported property values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

Implementations of Unstable and Proprietary Features

To avoid clashes with future stable CSS features, the CSSWG recommends the following best practices for the implementation of unstable features and proprietary extensions to CSS:

Experimentation and Unstable Features

Issue: Rewritten per gregwhitworth's feedback. Implementations of unstable features that are described in W3C specifications but are not interoperable should not be released broadly for general use; but may be released for limited, experimental use in controlled environments.

Why?

We want to allow both authors and implementors to experiment with the feature and give feedback, but prevent authors from relying on them in production websites and thereby accidentally "locking in" (through content dependence) certain syntax or behavior that might change later.

For example, a UA could release an unstable features for experimentation through beta or other testing-stage builds; behind a hidden configuration flag; behind a switch enabled only for specific testing partners; or through some other means of limiting dependent use.

A CSS feature is considered unstable until its specification has reached the Candidate Recommendation (CR) stage in the W3C process. In exceptional cases, the CSSWG may additionally, by an officially-recorded resolution, add pre-CR features to the set that are considered safe to release for broad use. Note: Vendors should consult the WG explicitly and not make assumptions on this point, as a pre-CR spec that hasn't changed in awhile is usually more out-of-date than stable.

Proprietary and Non-standardized Features

Issue: Rewritten as open vs. closed systems instead of Web vs. non-Web, per szilles' request. A CSS feature is a proprietary extension if it is meant for use in a closed environment accessible only to a single vendor's user agent(s). A UA should support such proprietary extensions only through a vendor-prefixed syntax and not expose them to open (multi-UA) environments such as the World Wide Web.

Why?

The prefixing requirement allows shipping specialized features in closed environments without conflicting with future additions to standard CSS. The restriction on exposure to open systems is to prevent accidentally causing the public CSS environment to depend on an unstandardized proprietary extensions.

For example, Firefox's XUL-based UI, Apple's iTunes UI, and Microsoft's Universal Windows Platform app use extensions to CSS implemented by their respective UAs. So long as these UAs do not allow Web content to access these features, they do not provide an opportunity for such content to become dependent on their proprietary extensions.

Even if a feature is intended to eventually be used in the Web, if it hasn't yet been standardized it should still not be exposed to the Web.

Market Pressure and De Facto Standards

Issue: Added "should not" against encumbered features, per dbaron's request. If a feature is unstable, yet * at least three UAs implement the feature (or a UA has broken the other rules and shipped for broad use an unstable or otherwise non-standard feature in a production release), * and the implementations have rough interoperability, * and the CSS Working Group has recorded consensus that this feature should exist and be released, implementers may ship that feature unprefixed in broad-release builds. Rough interoperability is satisfied by a subjective judgment that even though there may be differences, the implementations are sufficiently similar to be used in production websites for a substantial number of use cases.

Why?

If a feature is sufficiently popular that three or more browsers have implemented it before it's finished standardization, this clause allows releasing the pressure to ship. Also, if a feature has already escaped into the wild and sites have started depending on it, pretending it's still "experimental" doesn't help anyone. Allowing others to ship unprefixed recognizes that the feature is now de facto standardized and encourages authors to write cross-platform code.

Note, though, that the CSSWG must still be consulted to ensure coordination across vendors and to ensure sanity review by the CSS experts from each vendor. Note also that rough interoperability still usually means painful lack of interop in edge (or not-so-edge) cases, particularly because details have not been ironed out through the standards review process.

When exposing such an unstable feature to the Web in a production release, implementations should support both prefixed and unprefixed syntaxes for the feature. Once the feature has stabilized and the implementation is updated to match interoperable behavior, support for the prefixed syntax should be removed.

Why?

This is recommended so that authors can use the unprefixed syntax to target all implementations, but when necessary, can target specific implementations to work around incompatibilities among implementations as they get ironed out through the standards/bugfixing process.

In order to preserve the open nature of CSS as a technology, vendors should make it possible for other implementors to freely implement any features that they do ship. To this end, they should provide spec-editing and testing resources to complete standardization of such features, and avoid other obstacles (e.g., platform dependency, licensing restrictions) to their competitors shipping the feature.

Implementations of CR-level Features

Once a specification reaches the Candidate Recommendation stage, implementers should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec, and should avoid exposing a prefixed variant of that feature. To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group. Further information on submitting testcases and implementation reports can be found from on the CSS Working Group's website at http://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

Indices

These sections are non-normative.

Terms Index

Issue: Export terms from animations, backgrounds, selectors, style-attr, conditional, namespaces, ui, css21, and color.

Selector Index

Pattern	Meaning	Described in section	First defined in level
*	any element	Universal selector	2
E	an element of type E	Type selector	1
E[foo]	an E element with a "foo" attribute	Attribute selectors	2
E[foo="bar"]	an E element whose "foo" attribute value is exactly equal to "bar"	Attribute selectors	2
E[foo~="bar"]	an E element whose "foo" attribute value is a list of whitespace-separated values, one of which is exactly equal to "bar"	Attribute selectors	2
E[foo^="bar"]	an E element whose "foo" attribute value begins exactly with the string "bar"	Attribute selectors	3
E[foo$="bar"]	an E element whose "foo" attribute value ends exactly with the string "bar"	Attribute selectors	3
E[foo*="bar"]	an E element whose "foo" attribute value contains the substring "bar"	Attribute selectors	3
E[foo\|="en"]	an E element whose "foo" attribute has a hyphen-separated list of values beginning (from the left) with "en"	Attribute selectors	2
E:root	an E element, root of the document	Structural pseudo-classes	3
E:nth-child(n)	an E element, the n-th child of its parent	Structural pseudo-classes	3
E:nth-last-child(n)	an E element, the n-th child of its parent, counting from the last one	Structural pseudo-classes	3
E:nth-of-type(n)	an E element, the n-th sibling of its type	Structural pseudo-classes	3
E:nth-last-of-type(n)	an E element, the n-th sibling of its type, counting from the last one	Structural pseudo-classes	3
E:first-child	an E element, first child of its parent	Structural pseudo-classes	2
E:last-child	an E element, last child of its parent	Structural pseudo-classes	3
E:first-of-type	an E element, first sibling of its type	Structural pseudo-classes	3
E:last-of-type	an E element, last sibling of its type	Structural pseudo-classes	3
E:only-child	an E element, only child of its parent	Structural pseudo-classes	3
E:only-of-type	an E element, only sibling of its type	Structural pseudo-classes	3
E:empty	an E element that has no children (including text nodes)	Structural pseudo-classes	3
E:link E:visited	an E element being the source anchor of a hyperlink of which the target is not yet visited (:link) or already visited (:visited)	The link pseudo-classes	1
E:active E:hover E:focus	an E element during certain user actions	The user action pseudo-classes	1 and 2
E:target	an E element being the target of the referring URI	The target pseudo-class	3
E:lang(fr)	an element of type E in language "fr" (the document language specifies how language is determined)	The :lang() pseudo-class	2
E:enabled E:disabled	a user interface element E which is enabled or disabled	The UI element states pseudo-classes	3
E:checked	a user interface element E which is checked (for instance a radio-button or checkbox)	The UI element states pseudo-classes	3
E::first-line	the first formatted line of an E element	The ::first-line pseudo-element	1
E::first-letter	the first formatted letter of an E element	The ::first-letter pseudo-element	1
E::before	generated content before an E element	The ::before pseudo-element	2
E::after	generated content after an E element	The ::after pseudo-element	2
E.warning	an E element whose class is "warning" (the document language specifies how class is determined).	Class selectors	1
E#myid	an E element with ID equal to "myid".	ID selectors	1
E:not(s)	an E element that does not match simple selector s	Negation pseudo-class	3
E F	an F element descendant of an E element	Descendant combinator	1
E > F	an F element child of an E element	Child combinator	2
E + F	an F element immediately preceded by an E element	Adjacent sibling combinator	2
E ~ F	an F element preceded by an E element	General sibling combinator	3

At-Rule Index

Property Index

ISSUE: Incorporate all the rest of the specs into this index. (These only include the 2010 snapshot content.)

Name	Values	Initial value	Applies to	Inherited?	Percentages	Media
`background-attachment`	scroll \| fixed \| inherit	scroll		no		visual
`background-color`	<color> \| inherit	transparent		no		visual
`background-image`	<uri> \| none \| inherit	none		no		visual
`background-position`	[ [ <percentage> \| <length> \| left \| center \| right ] [ <percentage> \| <length> \| top \| center \| bottom ]? ] \| [ [ left \| center \| right ] \|\| [ top \| center \| bottom ] ] \| inherit	0% 0%		no	refer to the size of the box itself	visual
`background-repeat`	repeat \| repeat-x \| repeat-y \| no-repeat \| inherit	repeat		no		visual
`background`	['background-color' \|\| 'background-image' \|\| 'background-repeat' \|\| 'background-attachment' \|\| `background-position`] \| inherit	see individual properties		no	allowed on 'background-position'	visual
`border-collapse`	collapse \| separate \| inherit	separate	''table'' and ''inline-table'' elements	yes		visual
`border-color`	[ <color> ]{1,4} \| inherit	see individual properties		no		visual
`border-spacing`	<length> <length>? \| inherit	0	''table'' and ''inline-table'' elements	yes		visual
`border-style`	<border-style>{1,4} \| inherit	see individual properties		no		visual
`border-top` `border-right` `border-bottom` `border-left`	[ <border-width> \|\| <border-style> \|\| `border-top-color` ] \| inherit	see individual properties		no		visual
`border-top-color` `border-right-color` `border-bottom-color` `border-left-color`	<color> \| inherit	the value of the 'color' property		no		visual
`border-top-style` `border-right-style` `border-bottom-style` `border-left-style`	<border-style> \| inherit	none		no		visual
`border-top-width` `border-right-width` `border-bottom-width` `border-left-width`	<border-width> \| inherit	medium		no		visual
`border-width`	<border-width>{1,4} \| inherit	see individual properties		no		visual
`border`	[ <border-width> \|\| <border-style> \|\| `border-top-color` ] \| inherit	see individual properties		no		visual
`bottom`	<length> \| <percentage> \| auto \| inherit	auto	positioned elements	no	refer to height of containing block	visual
`caption-side`	top \| bottom \| inherit	top	''table-caption'' elements	yes		visual
`clear`	none \| left \| right \| both \| inherit	none	block-level elements	no		visual
`clip`	<shape> \| auto \| inherit	auto	absolutely positioned elements	no		visual
`color`	<color> \| inherit	depends on user agent		yes		visual
`content`	normal \| none \| [ <string> \| <uri> \| <counter> \| attr(<identifier>) \| open-quote \| close-quote \| no-open-quote \| no-close-quote ]+ \| inherit	normal	:before and :after pseudo-elements	no		all
`counter-increment`	[ <identifier> <integer>? ]+ \| none \| inherit	none		no		all
`counter-reset`	[ <identifier> <integer>? ]+ \| none \| inherit	none		no		all
`cursor`	[ [<uri> ,]* [ auto \| crosshair \| default \| pointer \| move \| e-resize \| ne-resize \| nw-resize \| n-resize \| se-resize \| sw-resize \| s-resize \| w-resize \| text \| wait \| help \| progress ] ] \| inherit	auto		yes		visual, interactive
`direction`	ltr \| rtl \| inherit	ltr	all elements, but see prose	yes		visual
`display`	inline \| block \| list-item \| inline-block \| table \| inline-table \| table-row-group \| table-header-group \| table-footer-group \| table-row \| table-column-group \| table-column \| table-cell \| table-caption \| none \| inherit	inline		no		all
`empty-cells`	show \| hide \| inherit	show	''table-cell'' elements	yes		visual
`float`	left \| right \| none \| inherit	none	all, but see 9.7	no		visual
`font-family`	[ [ <family-name> \| <generic-family> ] [, <family-name>\| <generic-family> ]* ] \| inherit	depends on user agent		yes		visual
`font-size`	<absolute-size> \| <relative-size> \| <length> \| <percentage> \| inherit	medium		yes	refer to inherited font size	visual
`font-style`	normal \| italic \| oblique \| inherit	normal		yes		visual
`font-variant`	normal \| small-caps \| inherit	normal		yes		visual
`font-weight`	normal \| bold \| bolder \| lighter \| 100 \| 200 \| 300 \| 400 \| 500 \| 600 \| 700 \| 800 \| 900 \| inherit	normal		yes		visual
`font`	[ [ 'font-style' \|\| 'font-variant' \|\| 'font-weight' ]? 'font-size' [ / 'line-height' ]? `font-family` ] \| caption \| icon \| menu \| message-box \| small-caption \| status-bar \| inherit	see individual properties		yes	see individual properties	visual
`height`	<length> \| <percentage> \| auto \| inherit	auto	all elements but non-replaced inline elements, table columns, and column groups	no	see prose	visual
`left`	<length> \| <percentage> \| auto \| inherit	auto	positioned elements	no	refer to width of containing block	visual
`letter-spacing`	normal \| <length> \| inherit	normal		yes		visual
`line-height`	normal \| <number> \| <length> \| <percentage> \| inherit	normal		yes	refer to the font size of the element itself	visual
`list-style-image`	<uri> \| none \| inherit	none	elements with 'display: list-item'	yes		visual
`list-style-position`	inside \| outside \| inherit	outside	elements with 'display: list-item'	yes		visual
`list-style-type`	disc \| circle \| square \| decimal \| decimal-leading-zero \| lower-roman \| upper-roman \| lower-greek \| lower-latin \| upper-latin \| armenian \| georgian \| lower-alpha \| upper-alpha \| none \| inherit	disc	elements with 'display: list-item'	yes		visual
`list-style`	[ 'list-style-type' \|\| 'list-style-position' \|\| `list-style-image` ] \| inherit	see individual properties	elements with 'display: list-item'	yes		visual
`margin-right` `margin-left`	<margin-width> \| inherit	0	all elements except elements with table display types other than table-caption, table and inline-table	no	refer to width of containing block	visual
`margin-top` `margin-bottom`	<margin-width> \| inherit	0	all elements except elements with table display types other than table-caption, table and inline-table	no	refer to width of containing block	visual
`margin`	<margin-width>{1,4} \| inherit	see individual properties	all elements except elements with table display types other than table-caption, table and inline-table	no	refer to width of containing block	visual
`max-height`	<length> \| <percentage> \| none \| inherit	none	all elements but non-replaced inline elements, table columns, and column groups	no	see prose	visual
`max-width`	<length> \| <percentage> \| none \| inherit	none	all elements but non-replaced inline elements, table rows, and row groups	no	refer to width of containing block	visual
`min-height`	<length> \| <percentage> \| inherit	0	all elements but non-replaced inline elements, table columns, and column groups	no	see prose	visual
`min-width`	<length> \| <percentage> \| inherit	0	all elements but non-replaced inline elements, table rows, and row groups	no	refer to width of containing block	visual
`opacity`	<number> \| inherit	1	all	no		visual
`orphans`	<integer> \| inherit	2	block container elements	yes		visual, paged
`outline-color`	<color> \| invert \| inherit	invert		no		visual, interactive
`outline-style`	<border-style> \| inherit	none		no		visual, interactive
`outline-width`	<border-width> \| inherit	medium		no		visual, interactive
`outline`	[ 'outline-color' \|\| 'outline-style' \|\| `outline-width` ] \| inherit	see individual properties		no		visual, interactive
`overflow`	visible \| hidden \| scroll \| auto \| inherit	visible	block containers	no		visual
`padding-top` `padding-right` `padding-bottom` `padding-left`	<padding-width> \| inherit	0	all elements except table-row-group, table-header-group, table-footer-group, table-row, table-column-group and table-column	no	refer to width of containing block	visual
`padding`	<padding-width>{1,4} \| inherit	see individual properties	all elements except table-row-group, table-header-group, table-footer-group, table-row, table-column-group and table-column	no	refer to width of containing block	visual
`page-break-after`	auto \| always \| avoid \| left \| right \| inherit	auto	block-level elements (but see text)	no		visual, paged
`page-break-before`	auto \| always \| avoid \| left \| right \| inherit	auto	block-level elements (but see text)	no		visual, paged
`page-break-inside`	avoid \| auto \| inherit	auto	block-level elements (but see text)	no		visual, paged
`position`	static \| relative \| absolute \| fixed \| inherit	static		no		visual
`quotes`	[<string> <string>]+ \| none \| inherit	depends on user agent		yes		visual
`right`	<length> \| <percentage> \| auto \| inherit	auto	positioned elements	no	refer to width of containing block	visual
`table-layout`	auto \| fixed \| inherit	auto	''table'' and ''inline-table'' elements	no		visual
`text-align`	left \| right \| center \| justify \| inherit	a nameless value that acts as ''text-align/left'' if 'direction' is ''ltr'', ''text-align/right'' if 'direction' is ''rtl''	block containers	yes		visual
`text-decoration`	none \| [ underline \|\| overline \|\| line-through \|\| blink ] \| inherit	none		no (see prose)		visual
`text-indent`	<length> \| <percentage> \| inherit	0	block containers	yes	refer to width of containing block	visual
`text-transform`	capitalize \| uppercase \| lowercase \| none \| inherit	none		yes		visual
`top`	<length> \| <percentage> \| auto \| inherit	auto	positioned elements	no	refer to height of containing block	visual
`unicode-bidi`	normal \| embed \| bidi-override \| inherit	normal	all elements, but see prose	no		visual
`vertical-align`	baseline \| sub \| super \| top \| text-top \| middle \| bottom \| text-bottom \| <percentage> \| <length> \| inherit	baseline	inline-level and ''table-cell'' elements	no	refer to the 'line-height' of the element itself	visual
`visibility`	visible \| hidden \| collapse \| inherit	visible		yes		visual
`white-space`	normal \| pre \| nowrap \| pre-wrap \| pre-line \| inherit	normal		yes		visual
`widows`	<integer> \| inherit	2	block container elements	yes		visual, paged
`width`	<length> \| <percentage> \| auto \| inherit	auto	all elements but non-replaced inline elements, table rows, and row groups	no	refer to width of containing block	visual
`word-spacing`	normal \| <length> \| inherit	normal		yes		visual
`z-index`	auto \| <integer> \| inherit	auto	positioned elements	no		visual

Values Index

Acknowledgements {#acks} ======================== Special thanks to Florian Rivoal for creating the initial draft of the [[#experimental]] recommendations.