diff --git a/css-2022/Overview.bs b/css-2022/Overview.bs
new file mode 100644
index 00000000000..21afd2e4ed8
--- /dev/null
+++ b/css-2022/Overview.bs
@@ -0,0 +1,1064 @@
+
+Title: CSS Snapshot 2022
+Shortname: css-2022
+Level: none
+Status: ED
+Group: CSSWG
+Work Status: revising
+URL: https://drafts.csswg.org/css-2022/
+Editor: Tab Atkins Jr., Google, http://xanthir.com/, w3cid 42199
+Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact, w3cid 35400
+Editor: Florian Rivoal, Invited Expert, https://florian.rivoal.net, w3cid 43241
+Abstract: This document collects together into one definition all the specs that
+ together form the current state of Cascading Style Sheets (CSS) as of 2022.
+ The primary audience is CSS implementers, not CSS authors, as this definition
+ includes modules by specification stability, not Web browser adoption rate.
+Status Text:
+ This document is a work in progress,
+ aimed at representing the state of CSS as of 2022.
+ It should become a Working Group Note when completed.
+
+
+Boilerplate: index no
+
+
+spec:selectors-4; type:selector; text::lang()
+
+
+
+
+
+
+
+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 2022.
+
+
+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 maintenance 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.)
+
+
+
+Classification of CSS Specifications
+
+ Advisement:
+ A list of all CSS modules, stable and in-progress,
+ and their statuses
+ can be found at the CSS Current Work page.
+
+
+Cascading Style Sheets (CSS) — The Official Definition
+
+ 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.
+
+ As of 2022,
+ Cascading Style Sheets (CSS) is defined by the following
+ specifications.
+
+
+ - CSS Level 2, latest revision (including errata)
+ [[!CSS2]]
+
-
+ 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
+ [[!CSS-SYNTAX-3]]
+
-
+ Replaces CSS2§4.1, CSS2§4.2, CSS2§4.4, and CSS2§G,
+ redefining how CSS is parsed.
+
+
- CSS Style Attributes
+ [[!CSS-STYLE-ATTR]]
+
-
+ Defines how CSS declarations can be embedded in markup attributes.
+
+
- Media Queries Level 3
+ [[!CSS3-MEDIAQUERIES]]
+
-
+ Replaces CSS2§7.3 and expands on the syntax for media-specific styles.
+
+
- CSS Conditional Rules Level 3
+ [[!CSS-CONDITIONAL-3]]
+
-
+ Extends and supersedes CSS2§7.2,
+ updating the definition of ''@media'' rules to allow nesting
+ and introducing the ''@supports'' rule for feature-support queries.
+
+
- Selectors Level 3
+ [[!SELECTORS-3]]
+
-
+ Replaces CSS2§5 and CSS2§6.4.3, defining an extended range of selectors.
+
+
- CSS Namespaces
+ [[!CSS3-NAMESPACE]]
+
-
+ Introduces an ''@namespace'' rule to allow namespace-prefixed selectors.
+
+
- CSS Cascading and Inheritance Level 4
+ [[!CSS-CASCADE-4]]
+
-
+ Extends and supersedes CSS2§1.4.3 and CSS2§6, as well as [[CSS-CASCADE-3]].
+ Describes how to collate style rules and assign values to all properties on all elements.
+ By way of cascading and inheritance, values are propagated for all properties on all elements.
+
+
- CSS Values and Units Level 3
+ [[!CSS-VALUES-3]]
+
-
+ Extends and supersedes 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 Custom Properties for Cascading Variables Module Level 1
+ [[!CSS-VARIABLES-1]]
+
-
+ Introduces cascading variables as a new primitive value type that is accepted by all CSS properties,
+ and custom properties for defining them.
+
+
- CSS Box Model Level 3
+ [[!CSS-BOX-3]]
+
-
+ Replaces CSS2§8.1, §8.2, §8.3 (but not §8.3.1), and §8.4.
+
+
- CSS Color Level 3
+ [[!CSS-COLOR-3]]
+
-
+ Extends and supersedes CSS2§4.3.6, CSS2§14.1, and CSS2§18.2,
+ introducing an extended range of color values.
+ Also introduces the 'opacity' property.
+
+
- CSS Backgrounds and Borders Level 3
+ [[!CSS-BACKGROUNDS-3]]
+
-
+ Extends and supersedes CSS2§8.5 and CSS2§14.2,
+ providing more control of backgrounds and borders,
+ including layered background images,
+ image borders,
+ and drop shadows.
+
+
- CSS Images Level 3
+ [[!CSS-IMAGES-3]]
+
-
+ Redefines and incorporates the external 2D image value type,
+ introduces native 2D gradients,
+ and adds additional controls for replaced element sizing and rendering.
+
+
- CSS Fonts Level 3
+ [[!CSS-FONTS-3]]
+
-
+ Extends and supersedes CSS2§15
+ and provides more control over font choice and feature selection.
+
+
- CSS Writing Modes Level 3
+ [[!CSS-WRITING-MODES-3]]
+
-
+ Defines CSS support for various international writing modes,
+ such as left-to-right (e.g. Latin or Indic),
+ right-to-left (e.g. Hebrew or Arabic),
+ bidirectional (e.g. mixed Latin and Arabic) and vertical (e.g. Asian scripts).
+ Replaces and extends CSS2§8.6 and §9.10.
+
+
- CSS Multi-column Layout Level 1
+ [[!CSS-MULTICOL-1]]
+
-
+ Introduces multi-column flows to CSS layout.
+
+
- CSS Flexible Box Module Level 1
+ [[!CSS-FLEXBOX-1]]
+
-
+ Introduces a flexible linear layout model for CSS.
+
+
- CSS User Interface Module Level 3
+ [[!CSS-UI-3]]
+
-
+ Extends and supersedes CSS2§18.1 and CSS2§18.4,
+ defining 'cursor', 'outline', and several new CSS features that also enhance the user interface.
+
+
- CSS Containment Module Level 1
+ [[!CSS-CONTAIN-1]]
+
-
+ Introduces the 'contain' property,
+ which enforces the independent CSS processing of an element’s subtree
+ in order to enable heavy optimizations by user agents when used well.
+
+
- CSS Transforms Level 1
+ [[!CSS-TRANSFORMS-1]]
+
-
+ Introduces coordinate-based graphical transformations to CSS.
+
+
- CSS Compositing and Blending Level 1
+ [[!COMPOSITING]]
+
-
+ Defines the compositing and blending of overlaid content
+ and introduces features to control their modes.
+
+
- CSS Easing Functions Level 1
+ [[!CSS-EASING-1]].
+
-
+ Describes a way for authors to define a transformation
+ that controls the rate of change of some value.
+ Applied to animations,
+ such transformations can be used to produce animations
+ that mimic physical phenomena such as momentum
+ or to cause the animation to move in discrete steps producing robot-like movement.
+
+
- CSS Counter Styles Level 3
+ [[!CSS-COUNTER-STYLES-3]]
+
-
+ Introduces the ''@counter-style'' rule,
+ which allows authors to define their own custom counter styles
+ for use with CSS list-marker and generated-content counters [[CSS-LISTS-3]].
+ It also predefines a set of common counter styles,
+ including the ones present in CSS2 and CSS2.1.
+
+
+ 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.
+
+
+Fairly Stable Modules with limited implementation experience
+
+ The following modules have completed design work,
+ and are fairly stable,
+ but have not received much testing and implementation experience yet.
+ We hope to incorporate them into the [[#css|official definition of CSS]] in a future snapshot.
+
+
+ - Media Queries Level 4
+ [[MEDIAQUERIES-4]]
+
-
+ Extends and supersedes [[CSS3-MEDIAQUERIES]],
+ expanding the syntax, deprecating most media types,
+ and introducing new media features.
+
+
- CSS Color Level 4
+ [[!CSS-COLOR-4]]
+
-
+ Extends and supersedes [[CSS-COLOR-3]],
+ further expanding the range of colors expressible in CSS.
+
+
- CSS Display Module Level 3
+ [[CSS-DISPLAY-3]]
+
-
+ Replaces CSS2§9.1.2, §9.2.1 (but not §9.2.1.1), §9.2.2 (but not §9.2.2.1), §9.2.3, and §9.2.4 (and lays the foundations for replacing §9.7),
+ defining how the CSS formatting box tree is generated
+ from the document element tree
+ and defining the 'display' property that controls it.
+
+
- CSS Writing Modes Level 4
+ [[CSS-WRITING-MODES-4]]
+
-
+ Extends and supersedes [[CSS-WRITING-MODES-3]],
+ adding more options for vertical writing.
+
+
- CSS Fragmentation Module Level 3
+ [[CSS-BREAK-3]]
+
-
+ Describes the fragmentation model that partitions a flow into pages, columns, or regions
+ and defines properties that control it.
+ Extends and supersedes CSS2§13.3.
+
+
- CSS Box Alignment Module Level 3
+ [[CSS-ALIGN-3]]
+
-
+ Introduces properties to control the alignment of boxes
+ within their containers in the various CSS box layout models:
+ block layout, table layout, flex layout, and grid layout.
+
+
- CSS Shapes Module Level 1
+ [[CSS-SHAPES-1]]
+
-
+ Extends floats (CSS2§9.5) to effect non-rectangular wrapping shapes.
+
+
- CSS Text Module Level 3
+ [[CSS-TEXT-3]]
+
-
+ Extends and supersedes CSS2§16 excepting §16.2,
+ defining properties for text manipulation and specifying their processing model.
+ It covers line breaking, justification and alignment, white space handling, and text transformation.
+
+
- CSS Text Decoration Level 3
+ [[CSS-TEXT-DECOR-3]]
+
-
+ Extends and supersedes CSS2§16.3,
+ providing more control over text decoration lines
+ and adding the ability to specify text emphasis marks
+ and text shadows.
+
+
- CSS Masking Level 1
+ [[CSS-MASKING-1]]
+
-
+ Replaces CSS2§11.1.2
+ and introduces more powerful ways of clipping and masking content.
+
+
- CSS Scroll Snap Module Level 1
+ [[CSS-SCROLL-SNAP-1]]
+
-
+ Contains features to control panning and scrolling behavior with “snap positions”.
+
+
- CSS Speech Module Level 1
+ [[CSS-SPEECH-1]]
+
-
+ Replaces CSS2§A,
+ overhauling the (non-normative) speech rendering chapter.
+
+
- CSS Scrollbars Styling Module Level 1
+ [[CSS-SCROLLBARS-1]]
+
-
+ Defines properties to influence the visual styling of scrollbars,
+ introducing controls for their color and width.
+
+
+
+Modules with Rough Interoperability
+
+ Although the following modules have been widely deployed with rough interoperability,
+ their details are not fully worked out or sufficiently well-specified
+ and they need more testing and bugfixing.
+ We hope to incorporate them into the [[#css|official definition of CSS]] in a future snapshot.
+
+
+ - CSS Transitions Level 1
+ [[CSS-TRANSITIONS-1]]
+ and CSS Animations Level 1
+ [[CSS-ANIMATIONS-1]].
+
-
+ Introduces mechanisms for transitioning the computed values of CSS properties over time.
+
+
- CSS Grid Layout Module Level 1
+ [[!CSS-GRID-1]]
+
-
+ Introduces a two-dimensional grid-based layout system,
+ optimized for user interface design.
+ In the grid layout model, the children of a grid container
+ can be positioned into arbitrary slots in a predefined flexible or fixed-size layout grid.
+
+
- CSS Grid Layout Module Level 2
+ [[!CSS-GRID-2]]
+
-
+ Extends and supersedes [[CSS-GRID-1]],
+ introducing “subgrids” for managing nested markup in a shared grid framework.
+
+
- CSS Will Change Level 1
+ [[CSS-WILL-CHANGE-1]]
+
-
+ Introduces a performance hint property called 'will-change'.
+
+
- Filter Effects Module Level 1
+ [[FILTER-EFFECTS-1]]
+
-
+ Introduces filter effects as a way of processing an element’s rendering before it is displayed in the document.
+
+
- CSS Font Loading Module Level 3
+ [[CSS-FONT-LOADING-3]]
+
-
+ Introduces events and interfaces used for dynamically loading font resources.
+
+
- CSS Box Sizing Level 3
+ [[!CSS-SIZING-3]]
+
-
+ Overlays and extends CSS§10.,
+ expanding the value set of the sizing properties,
+ introducing more precise sizing terminology,
+ and defining with more precision and detail
+ various automatic sizing concepts only vaguely defined in CSS2.
+
+
+
- CSS Transforms Level 2
+ [[!CSS-TRANSFORMS-2]]
+
-
+ Builds upon [[CSS-TRANSFORMS-1]]
+ to add new transform functions and properties for three-dimensional transforms,
+ and convenience functions for simple transforms.
+
+
- CSS Lists and Counters Module Level 3
+ [[!CSS-LISTS-3]]
+
-
+ Contains CSS features related to list counters:
+ styling them,
+ positioning them,
+ and manipulating their value.
+
+
- CSS Logical Properties and Values Level 1
+ [[!CSS-LOGICAL-1]]
+
-
+ Introduces logical properties and values
+ that provide the author with the ability to control layout through logical,
+ rather than physical,
+ direction and dimension mappings.
+ Also defines logical properties and values for the features defined in [[CSS2]].
+ These properties are writing-mode relative equivalents
+ of their corresponding physical properties.
+
+
- CSS Positioned Layout Module Level 3
+ [[!CSS-POSITION-3]]
+
-
+ Contains defines coordinate-based positioning and offsetting schemes of CSS:
+ [=relative positioning=],
+ [=sticky positioning=],
+ [=absolute positioning=],
+ and [=fixed positioning=].
+
+
- Resize Observer
+ [[!RESIZE-OBSERVER-1]]
+
-
+ This specification describes an API for observing changes to element’s principal box's size.
+
+
- Web Animations
+ [[!WEB-ANIMATIONS-1]]
+
-
+ Defines a model for synchronization and timing of changes to the presentation of a Web page.
+ Also defines an application programming interface for interacting with this model.
+
+
- CSS Fonts Module Level 4
+ [[!CSS-FONTS-4]]
+
-
+ Extends and supersedes CSS Fonts 3
+ and provides more control over font choice and feature selection,
+ including support for OpenType variations.
+
+
- CSS Color Adjustment Module Level 1
+ [[!CSS-COLOR-ADJUST-1]]
+
-
+ This module introduces a model and controls over automatic color adjustment by the user agent to handle user preferences and device output optimizations.
+
+
+
+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.
+
+ In the past, the Working Group published a few Profiles,
+ which were meant to define the minimal subset of CSS
+ that various classes of user agents were expected to support.
+
+ This effort has been discontinued,
+ as the Working Group was not finding it effective or useful,
+ and the profiles previously defined are now unmaintained.
+
+ 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
+
+ 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.
+ See [[#CR-exceptions]].
+
+ 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
+
+ To avoid clashes with future CSS features,
+ the CSS2.1 specification reserves a
+ prefixed syntax [[!CSS2]]
+ for proprietary and experimental extensions to CSS.
+ 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
+
+ If a feature is unstable (i.e. the spec has not yet stabilized), but
+
+ * 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.
+
+ Note that the CSSWG must still be consulted to ensure coordination across vendors
+ and to ensure coherency 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.
+
+
+ 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.
+
+
+
+Vendor-prefixing Unstable Features
+
+ When exposing such a standards-track unstable feature to the Web in a production release,
+ implementations should support both vendor-prefixed and unprefixed syntaxes
+ for the feature.
+ Once the feature has stabilized and the implementation is updated to match interoperable behavior,
+ support for the vendor-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.
+
+ The lack of a phase
+ where only the prefixed syntax is supported
+ greatly reduces the risk of stylesheets
+ being written with only the vendor-prefixed syntax.
+ This in turn allows UA vendors to retire
+ their prefixed syntax once the feature is stable,
+ with a lower risk of breaking existing content.
+ It also reduces the need occasionally felt by some vendors
+ to support a feature with the prefix of another vendor,
+ due to content depending on that syntax.
+
+
+ Anyone promoting unstable features to authors
+ should document them using their standard unprefixed syntax,
+ and avoid encouraging the use of the vendor-prefixed syntax
+ for any purpose other than working around implementation differences.
+
+
+Preserving the Openness of CSS
+
+ 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.
+
+
+Safe to Release pre-CR Exceptions
+
+ The following features have been explicitly and proactively cleared
+ by the CSS Working Group for broad release
+ prior to the spec reaching Candidate Recommendation.
+ See [[#experimental]].
+
+
+ - The flow-relative equivalents of
+ the sizing properties ('width', 'height', etc.),
+ the border properties,
+ the margin and padding properties.
+ See explanation
+ and specification.
+
+
- The ''width/min-content'' and ''width/max-content'' keywords of the sizing properties.
+ See decision
+ and specification.
+
- The ''conic-gradient()'' gradient notation. See decision.
+
+
- The aspect-ratio property. [[!CSS-SIZING-4]]
+
+
- The 'translate', 'rotate', and 'scale' properties. [[!CSS-TRANSFORMS-2]]
+
+
- The 'hyphenate-character' property. [[!CSS-TEXT-4]]
+
+
+ The following features have been explicitly and retroactively cleared
+ by the CSS Working Group for broad release
+ prior to the spec reaching Candidate Recommendation:
+
+
+Indices
+
+These sections are non-normative.
+
+Terms Index
+
+
+
+Selector Index
+
+
+
+
+At-Rule Index
+
+
+
+Property Index
+
+
+
+Values Index
+
+
+
+Acknowledgements {#acks}
+========================
+
+Special thanks to Florian Rivoal for creating the initial draft of the [[#experimental]] recommendations.