-

CSS Transitions Level 1 +

CSS Transitions [[CSS-TRANSITIONS-1]] and CSS Animations Level 1 [[CSS-ANIMATIONS-1]].

Introduces mechanisms for transitioning the computed values of CSS properties over time. -

CSS Will Change Level 1 +

CSS Will Change Module Level 1 [[CSS-WILL-CHANGE-1]]

Introduces a performance hint property called 'will-change'. @@ -520,7 +522,7 @@ Modules with Rough Interoperability

Introduces events and interfaces used for dynamically loading font resources. -

CSS Box Sizing Level 3 +

CSS Box Sizing Module Level 3 [[CSS-SIZING-3]]

Overlays and extends CSS§10., @@ -530,7 +532,7 @@ Modules with Rough Interoperability various automatic sizing concepts only vaguely defined in CSS2. -

CSS Transforms Level 2 +

CSS Transforms Module Level 2 [[CSS-TRANSFORMS-2]]

Builds upon [[CSS-TRANSFORMS-1]] diff --git a/css-2025/Overview.bs b/css-2025/Overview.bs new file mode 100644 index 00000000000..e8ab2dd6ca1 --- /dev/null +++ b/css-2025/Overview.bs @@ -0,0 +1,1178 @@ +

+Title: CSS Snapshot 2025
+Shortname: css-2025
+Level: none
+Status: NOTE
+Prepare for TR: no
+Group: CSSWG
+Work Status: revising
+URL: https://drafts.csswg.org/css-2025/
+Editor: Tab Atkins Jr., Google, http://xanthir.com/, w3cid 42199
+Editor: Elika J. Etemad / fantasai, Apple, http://fantasai.inkedblade.net/contact, w3cid 35400
+Editor: Florian Rivoal, Invited Expert, https://florian.rivoal.net, w3cid 43241
+Editor: Chris Lilley, W3C, https://svgees.us/, w3cid 1438
+Editor: Sebastian Zartner, Invited Expert, sebastianzartner@gmail.com, w3cid 64937
+Abstract: This document collects together into one definition all the specs that
+	together form the current state of Cascading Style Sheets (CSS) as of 2025.
+	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 represents the state of CSS as of 2025.
+	
+Boilerplate: index no
+

+

+spec:selectors-4; type:dfn; text:document language
+spec:css-ui-3; type:property; text:cursor
+spec:css-ui-3; type:property; text:outline
+spec:css-display-3; type:property; text:display
+

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

+What is CSS?

+ +

+

Cascading Style Sheets (CSS) +

+ CSS is a language for writing [=style sheets=], + and is designed to describe the rendering of structured documents + (such as HTML and XML) + on a variety of media. + CSS is used to describe the presentation of a [=source document=], + and usually does not change the underlying semantics + expressed by its [=document language=]. + +

Style sheet +

+ A set of rules that specify the presentation of a document. + Style sheets are written by an [=Author=], + and interpreted by a [=User Agent=], + to present the document to the [=User=]. + +

Source document +

+ The document to which one or more style sheets apply. + A source document’s structure and semantics are encoded + using a [=document language=] (e.g., HTML, XHTML, or SVG). + +

Author +

+ An author is a person who writes documents and associated style sheets. + An authoring tool is a [=User Agent=] that generates style sheets. + +

User +

+ A user is a person who interacts with a user agent + to view, hear, or otherwise use the document. + +

User Agent (UA) +

+ A user agent is any program that interprets a document + and its associated [=style sheets=] + on behalf of a [=user=]. + A [=user agent=] may display a document, read it aloud, + cause it to be printed, convert it to another format, etc. + For the purposes of the CSS specifications, + a [=User Agent=] is one that supports and interprets [=Cascading Style Sheets=] + as defined in these specifications. +

+ +

+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 2025, + 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 Module 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 Module 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 Module Level 3 + [[!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 Module 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 Module Level 3 + [[!CSS-BOX-3]] +

+ Replaces CSS2§8.1, §8.2, §8.3 (but not §8.3.1), and §8.4. + +

CSS Color Module Level 4 + [[!CSS-COLOR-4]] +

+ Extends and supersedes CSS2§4.3.6, CSS2§14.1, and CSS2§18.2, + also extends and supersedes [[CSS-COLOR-3]], + introducing an extended range of color spaces beyond sRGB, + extended color values, + and CSS Object Model extensions for color. + Also defines the 'opacity' property. + +

CSS Backgrounds and Borders Module 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 Module 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 Module 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 Module Level 1 + [[!CSS-MULTICOL-1]] +

+ Introduces multi-column flows to CSS layout. + +

CSS Flexible Box Layout Module Level 1 + [[!CSS-FLEXBOX-1]] +

+ Introduces a flexible linear layout model for CSS. + +

CSS Basic 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 Module Level 1 + [[!CSS-TRANSFORMS-1]] +

+ Introduces coordinate-based graphical transformations to 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. + +

+Reliable Candidate Recommendations

+ +The following specifications are considered to be in a reliable state, meaning they have largely stable implementations and specifications, but are not yet at the Recommendation level due to minor issues or the need for additional implementation reports. + +

+

Media Queries Level 4 + [[MEDIAQUERIES-4]] +

+ Extends and supersedes [[CSS3-MEDIAQUERIES]], + expanding the syntax, + deprecating most media types, + and introducing new media features. + +

CSS Scroll Snap Module Level 1 + [[CSS-SCROLL-SNAP-1]] +

+ Contains features to control panning and scrolling behavior with “snap positions”. + +

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

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

+ +

+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|official definition of CSS]] in a future snapshot. + +

+ +

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.3, + 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 Module 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 Module Level 1 + [[CSS-MASKING-1]] +

+ Replaces CSS2§11.1.2 + and introduces more powerful ways of clipping and masking content. + +

CSS Speech Module Level 1 + [[CSS-SPEECH-1]] +

+ Replaces CSS2§A, + overhauling the (non-normative) speech rendering chapter. + +

CSS View Transitions Module Level 1 + [[CSS-VIEW-TRANSITIONS-1]]

+

+ Defines the View Transition API, along with associated properties and pseudo-elements, + which allows developers to create animated visual transitions representing + changes in the document state. +

+

+ +

+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|official definition of CSS]] in a future snapshot. + +

+

CSS Transitions + [[CSS-TRANSITIONS-1]] + and CSS Animations Level 1 + [[CSS-ANIMATIONS-1]]. +

+ Introduces mechanisms for transitioning the computed values of CSS properties over time. + +

CSS Will Change Module 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 Module 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 Module 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 Conditional Rules Module Level 4 + [[CSS-CONDITIONAL-4]] +

+ Extends CSS Conditional 3 to allow testing for supported selectors.

+ +

CSS Cascading and Inheritance Level 5 + [[CSS-CASCADE-5]] +

+ Extends CSS Cascade 4 to add cascade layers.

+ +

Motion Path Module Level 1 + [[MOTION-1]] +

+ This module allows authors to position any graphical object and animate it along an author specified path. + +

CSS Scroll Anchoring Module Level 1 + [[CSS-SCROLL-ANCHORING-1]] +

+ This module aims to minimize content shifts + by locking the scroll position of a scroll container to a particular anchor element. + +

CSS Object Model (CSSOM) + [[CSSOM-1]] +

+ This module defines APIs for parsing, serializing, + and manipulating CSS, Media Queries, and Selectors. + +

CSS Color Module Level 5 + [[CSS-COLOR-5]] +

+ Extends CSS Color 4 to add color spaces and color modification functions. + +

Selectors Level 4 + [[SELECTORS-4]] +

+ Extends Selectors Level 3 by introducing new pseudo-classes, + pseudo-elements, and combinators, + enhancing the ability to select elements + based on more complex criteria and states. +

+ +

+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 color-mix() function. [[!CSS-COLOR-5]] + +
• The <>, defined in [[!CSS-COLOR-4]] and used for interpolation of linear, radial and conic gradients. [[!CSS-IMAGES-4]] + +
• The [=relative color=] syntax, defined in [[!CSS-COLOR-5]]
+

+ + The following features have been explicitly and retroactively cleared + by the CSS Working Group for broad release + prior to the spec reaching Candidate Recommendation: +

+
• Everything in + CSS Animations Level 1 + and + CSS Transitions Level 1. +

+ +

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. diff --git a/css-align-3/Overview.bs b/css-align-3/Overview.bs index 56aea26bda2..80fa29d9666 100644 --- a/css-align-3/Overview.bs +++ b/css-align-3/Overview.bs @@ -897,11 +897,10 @@ Content Distribution for Scroll Containers

Self-Alignment for Absolutely Positioned Boxes

- For [=absolutely positioned=] [=alignment subjects=] + For [=absolutely positioned=] [=alignment subjects=] whose relevant [=self-alignment property=] is not ''justify-self/normal'', the default [=overflow alignment=] behavior is as follows: -

1. Let the |default overflow rect| be the bounding rectangle of the [=alignment subject's=] [=inset-modified containing block=] @@ -1172,30 +1171,24 @@ Content-Distribution Shorthand: the 'place-content' property in which case it is defaulted to ''start''.

-Overflow and Scroll Positions

+Alignment Overflow and Scroll Containers When the content-distribution properties are set on a scroll container with an overflowing alignment subject, - rather than shifting the layout positions of its content, - they instead change its initial scroll position - so that the initially-visible content - of the scroll container - satisfies the [[#alignment-values|expected alignment]] - of the alignment subject and alignment container. - However, the [[css-scroll-snap-2#scroll-initial-target-with-place-content|scroll-initial-target]] - property, when present, overrides the content-distribution properties - in determining the initial scroll position. - - Note: The presence of scrollbars can change the size of the [=scroll container’s=] content box, - and thus the size of the [=alignment container=] - and/or [=alignment subject=]. + they reduce the clipping of the [=negative scrollable overflow region=] + just enough to ensure that alignment subject can be scrolled + into its ''align-content/start''-aligned position.

For example, if a scrollable flex container is set to ''justify-content: flex-end'' (or ''justify-content: flex-start'' with ''flex-flow: row-reverse''), - it will be initially displayed scrolled all the way to the main-end edge of its content, + its [=in-flow=] content will be initially positioned + to align the main-end edge of its content to the main-end edge of the flex container, and its content will appear to overflow its main-start edge. + However, the viewer will be able to scroll up + to view the overflowing [=in-flow=] content, + just as if ''justify-content: flex-start'' had been specified.

@@ -1205,17 +1198,16 @@ Overflow and Scroll Positions

- None of this changes how scroll coordinates are assigned: - the origin is still where it would be in a ''align-content/start''-aligned container, - it just might be initially positioned outside the scrollport. - Note: The alignment subject is not necessarily identical to the scrollable overflow area: - content overflowing the alignment subject, - such as an absolutely-positioned or out-of-flow element, - grows the scrollable overflow area but not the alignment subject, - thus an ''align-content/end''-aligned scroll container - might not be initially scrolled all the way to the bottom. + content overflowing the alignment subject-- + such as an [=out-of-flow=] box-- + grows the scrollable overflow area but not the alignment subject. + Thus an ''align-content/end''-aligned scroll container + might not be initially scrolled all the way to the bottom, + and positioned content can still be clipped + if it is further into the [=negative scrollable overflow region=] + than the [=in-flow=] content forming the [=alignment subject=].

@@ -1227,6 +1219,10 @@ Overflow and Scroll Positions

+ Note: The presence of scrollbars can change + the size of the [=scroll container’s=] [=content box=]-- + and thus the size of the [=alignment container=] + and/or [=alignment subject=].

Baseline Content-Alignment

@@ -1357,7 +1353,7 @@ Self-Alignment: Aligning the Box Within Its Parent

-Inline-Axis (or Main-Axis) Alignment: the 'justify-self' property

+Inline-Axis (or Main-Axis) Self-Alignment: the 'justify-self' property

 	Name: justify-self
@@ -1457,7 +1453,7 @@ Inline-Axis (or Main-Axis) Alignment: the 'justify-self' property
 			''justify-self/normal'' Behavior
 			
 				The box lays out according to the default rules for block layout
-				(see [[CSS2/visudet#Computing_widths_and_margins]]).
+				(see CSS2.1§10.3).
 		
 			Other Details
 			
@@ -1507,15 +1503,9 @@ Inline-Axis (or Main-Axis) Alignment: the 'justify-self' property
 		
 			''justify-self/normal'' Behavior
 			
-				* For replaced absolutely-positioned boxes, the ''justify-self/normal'' keyword behaves as ''start''.
-				* For all other absolutely-positioned boxes, ''justify-self/normal'' behaves as stretch.
-					Additionally, if neither inset in this axis is ''top/auto'',
-					but 'width' ('height', for vertical writing modes) is ''width/auto'',
-					''margin/auto'' margins are treated as zero.
-
-					(In non-''justify-self/normal'' cases, ''margin/auto'' margins are prioritized over the self-alignment properties, as usual.)
-
-				Note: This somewhat bizarre behavior is required for compatibility with the behavior specified in CSS 2.1.
+				Behaves as ''justify-self/stretch'' or ''justify-self/start'',
+				depending on the type of box.
+				See [[css-position-3#abspos-layout]].
 		
 			Other Details
 			
@@ -1583,7 +1573,7 @@ Inline-Axis (or Main-Axis) Alignment: the 'justify-self' property
 	See [[!CSS-GRID-1]] for details.
 
 

-Block-Axis (or Cross-Axis) Alignment: the 'align-self' property
+Block-Axis (or Cross-Axis) Self-Alignment: the 'align-self' property
 
 	
 	Name: align-self
@@ -1677,15 +1667,9 @@ Block-Axis (or Cross-Axis) Alignment: the 'align-self' property
 		
 			''align-self/normal'' Behavior
 			
-				* For replaced absolutely-positioned boxes, the ''align-self/normal'' keyword behaves as ''start''.
-				* For all other absolutely-positioned boxes, ''align-self/normal'' behaves as stretch.
-					Additionally, if neither inset in this axis is ''top/auto'',
-					but 'width' ('height', for vertical writing modes) is ''width/auto'',
-					''margin/auto'' margins are treated as zero.
-
-					(In non-''align-self/normal'' cases, ''margin/auto'' margins are prioritized over the self-alignment properties, as usual.)
-
-				Note: This somewhat bizarre behavior is required for compatibility with the behavior specified in CSS 2.1.
+				Behaves as ''align-self/stretch'' or ''align-self/start'',
+				depending on the type of box.
+				See [[css-position-3#abspos-layout]].
 		
 			Other Details
 			
@@ -1935,7 +1919,7 @@ Default Alignment
 	
 
 

-Inline-Axis (or Main-Axis) Alignment: the 'justify-items' property
+Inline-Axis (or Main-Axis) Default Alignment: the 'justify-items' property
 
 	
 	Name: justify-items
@@ -1972,7 +1956,7 @@ Inline-Axis (or Main-Axis) Alignment: the 'justify-items' property
 	Other values have no special handling and are merely referenced by 'justify-self'.
 
 

-Block-Axis (or Cross-Axis) Alignment: the 'align-items' property
+Block-Axis (or Cross-Axis) Default Alignment: the 'align-items' property
 
 	
 	Name: align-items
@@ -1992,7 +1976,7 @@ Block-Axis (or Cross-Axis) Alignment: the 'align-items' property
 	Values have no special handling and are merely referenced by 'align-self'.
 
 

-Self-Alignment Shorthand: the 'place-items' property
+Default Alignment Shorthand: the 'place-items' property
 
 	
 	Name: place-items
@@ -2026,18 +2010,18 @@ Self-Alignment Shorthand: the 'place-items' property
 

 Gaps Between Boxes
 
-While 'margin' and 'padding' can be used to specify visual spacing around individual boxes,
-it's sometimes more convenient to globally specify spacing between adjacent boxes
-within a given layout context,
-particularly when the spacing is different between boxes
-as opposed to between the first/last box and the container's edge.
+	While 'margin' and 'padding' can be used to specify visual spacing around individual boxes,
+	it's sometimes more convenient to globally specify spacing
+	between adjacent boxes within a given layout context,
+	particularly when the spacing is different between sibling boxes
+	as opposed to between the first/last box and the container's edge.
 
-The 'gap' property,
-and its 'row-gap' and 'column-gap' sub-properties,
-provide this functionality for
-multi-column,
-flex,
-and grid layout.
+	The 'gap' property,
+	and its 'row-gap' and 'column-gap' sub-properties,
+	provide this functionality for
+	multi-column,
+	flex,
+	and grid layout.
 
 

 Row and Column Gutters: the 'row-gap' and 'column-gap' properties
@@ -2093,9 +2077,10 @@ Row and Column Gutters: the 'row-gap' and 'column-gap' properties
 	

 		
multi-column containers
 		

-			'column-gap' specifies the [=gutter=] between adjacent column boxes.
-			See [[CSS-MULTICOL-1]] for details on how this affects the layout of multicol elements.
-			'row-gap' does not currently apply.
+			'column-gap' specifies the [=gutter=] between adjacent column boxes,
+			see [[CSS-MULTICOL-1]].
+			'row-gap' specifies the [=gutter=] between the rows of [=column boxes=] established by 'column-height',
+			see [[CSS-MULTICOL-2]].
 
 		
flex containers
 		

@@ -2119,6 +2104,9 @@ Row and Column Gutters: the 'row-gap' and 'column-gap' properties
 			See [[css-grid-1#gutters]] for precise details.
 	
 
+	In all cases, the [=gutter=] disappears when it coincides with
+	a [=fragmentation break=]. [[CSS-BREAK-3]]
+
 	Note: Table boxes do not use the 'gap' properties
 	to specify separation between their cells.
 	Instead, they use the 'border-spacing' property,
@@ -2235,7 +2223,7 @@ Baseline Alignment Details
 	for more information on baselines and writing modes.
 
 

-Determining the Baselines of a Box
+Determining the Baselines of a Box
 
 	Each box,
 	for a given axis,
@@ -2312,6 +2300,9 @@ Determining the Baselines of a Box
 			is synthesized from the lowest and highest content edges of the cells in the row.
 			[[!CSS2]]
 
+			Spanning cells participate only in the first/last row that they span
+			for the purpose of ''first baseline''/''last baseline''.
+
 		
flex containers
 		

 			See Flex Baselines in [[!CSS-FLEXBOX-1]].
@@ -2461,7 +2452,7 @@ Appendix A: Static Position Terminology
 	on an absolutely positioned box,
 	CSS2 uses its static position
 	to resolve its size and position.
-	See [[css2/visudet#abs-non-replaced-width]].
+	See CSS2.1§10.3.7.
 	The box alignment properties modify these calculations,
 	just as they do the sizing and positioning calculations in other layout modes.
 	These modifications refer to a static-position rectangle,
@@ -2524,15 +2515,53 @@ Changes
 
 	Changes since the 17 February 2023 Working Draft include:
 	

+		
Made [=block containers=] default to ''safe'' alignment.
+			See [[#auto-safety-default]].
+			(Issue 8992)
+		
Made [=absolutely positioned boxes=] default to using a “smart” safe alignment
+			that allows unsafe overflow of the [=inset-modified containing block=]
+			while maintaining safety within the [=original containing block=].
+			See [[#auto-safety-position]].
+			(Issue 10316,
+			 Issue 9960)
 		
Make all the ''space-*'' keywords fallback to ''safe'' overflow.
 			(Issue 10154)
+		
Clearly define the interaction of overflowing [=content distribution=] and [=scroll containers=]
+			to not impact layout, but to only affect the extent of the [=scrollable overflow area=].
+			(Issue 4957)
 		
Only apply the special margin-edge baseline rule for [=scroll container=] [=block containers=]
 			when 'baseline-source' is its [=initial value=].
 			(Issue 8214)
-		
Made [=block containers=] default to ''safe'' alignment.
-			(Issue 8992)
+		
When synthesizing the baseline of an orthogonal-flow box,
+			make the assumed parallel [=writing mode=] sensitive to 'direction'.
+			(Issue 7775)
+			

+				
Otherwise,
+					assume either ''horizontal-tb'' or ''vertical-lr'' 'writing-mode',
+					whichever is orthogonal to the box’s own 'writing-mode'.
+				
Otherwise:
+					

+						
If the box’s own [=writing mode=] is vertical,
+							assume ''horizontal-tb''.
+						
If the box’s own [=writing mode=] is horizontal,
+							assume ''vertical-lr'' if 'direction' is ''ltr''
+							and ''vertical-rl'' if 'direction' is ''rtl''.
+					
+				
+			
+		
Clarify that spanning cells only participate in the first/last row they span
+			when participating in first/last baseline alignment.
+			(Issue 7655)
 		
Define the 'grid-gap' properties as [=legacy name aliases=] of the 'gap' properties.
 			(Issue 8014)
+		
Defer definition of ''align-self/normal'' alignment for [=absolutely positioned boxes=] to [[css-position-3]].
+			(Issue 11215,
+			 Issue 11285)
+		
Changed sentence about applicability of 'row-gap' to [=multi-column containers=]
+			to indicate that it applies in [[CSS-MULTICOL-2]].
+			(Issue 11539)
+		
Defined that [=gutters=] dissappear at [=fragmentation breaks=].
+			(Issue 11520)
 	
 
 	Changes since the 24 December 2021 Working Draft include:
diff --git a/css-anchor-position-1/Overview.bs b/css-anchor-position-1/Overview.bs
index 65b24fa15e1..20763c7f4b0 100644
--- a/css-anchor-position-1/Overview.bs
+++ b/css-anchor-position-1/Overview.bs
@@ -1372,49 +1372,6 @@ were ''visibility: hidden'',
 regardless of what their actual 'visibility' value is.
 
 
-Accessibility Implications {#accessibility}
---------------------------
-
-It's important to remember that Anchor Positioning
-does not automatically establish any semantic relationship
-between a positioned box
-and any of its anchors,
-because it can be used in many different ways.
-Authors must not rely solely on a visual connection
-implied by the positioning
-to link elements together semantically;
-without additional help,
-the elements often have no meaningful DOM relationship,
-making them difficult or impossible to use in non-visual user agents,
-like screen readers.
-
-Many features on the web platform,
-both existing and upcoming,
-allow establishing such connections explicitly,
-so that non-visual user agents can also benefit.
-
-For example, the Popover API in HTML
-automatically links the invoker button
-to the popover element,
-including automatically adjusting tabbing order;
-it also establishes the invoker button
-as the [=implicit anchor element=] for the popover,
-making it easy to use Anchor Positioning as well.
-
-In more general cases,
-ARIA features such as
-the aria-details
-or aria-describedby attributes
-on an anchor element
-can provide this information
-in a slightly more manual fashion;
-in concert with the <{html-global/role}> attribute on the positioned element,
-non-visual user agents
-can tell their users about the relationship between the elements
-and let them automatically navigate between them.
-
-
-
 
 
 
+
+
+Accessibility Implications {#accessibility}
+==========
+
+It's important to remember that Anchor Positioning
+does not automatically establish any semantic relationship
+between a positioned box
+and any of its anchors,
+because it can be used in many different ways.
+Authors must not rely solely on a visual connection
+implied by the positioning
+to link elements together semantically;
+without additional help,
+the elements often have no meaningful DOM relationship,
+making them difficult or impossible to use in non-visual user agents,
+like screen readers.
+
+Many features on the web platform,
+both existing and upcoming,
+allow establishing such connections explicitly,
+so that non-visual user agents can also benefit.
+
+For example, the Popover API in HTML
+automatically links the invoker button
+to the popover element,
+including automatically adjusting tabbing order;
+it also establishes the invoker button
+as the [=implicit anchor element=] for the popover,
+making it easy to use Anchor Positioning as well.
+
+In more general cases,
+ARIA features such as
+the aria-details
+or aria-describedby attributes
+on an anchor element
+can provide this information
+in a slightly more manual fashion;
+in concert with the <{html-global/role}> attribute on the positioned element,
+non-visual user agents
+can tell their users about the relationship between the elements
+and let them automatically navigate between them.
+
+
+
 
-
 Abstract: This CSS module describes a way for authors to animate the values of CSS properties over time, using keyframes. The behavior of these keyframe animations can be controlled by specifying their duration, number of repeats, and repeating behavior.
 
 Link Defaults: css-values-3 (type) , cssom-1 (interface) cssstyledeclaration, dom-core-ls (interface) event, webidl (type) SyntaxError
 Ignored Terms: domstring, animationeventinit, event, eventinit, eventtarget, document
 
+
 
 url: https://dom.spec.whatwg.org/#constructing-events; type: dfn; text: event constructor;
 urlPrefix: https://html.spec.whatwg.org/multipage/webappapis.html; type: dfn; spec: html
@@ -1387,25 +1385,25 @@ Working Group Resolutions that are pending editing
 			

 			
Issue(7335): Detail how/when keyframe values are computed; using G.beta in dbaron's mail
 			
Agreed that both transitions and animations animate all properties. css-transitions to define animation of non-interoperable/discrete values. They take their starting values below 50% timing function progress, and end values above
-			
Dynamic changes to animation properties/keyframes. Tab to propose resolution. (Bug 14713)
-			
Negative animation-delay values apply against the active duration of the animation i.e. (animation-duration*animation-iteration-count). The delay can thus swallow iterations for which no iteration event will be fired. The start/end events are still fired. Even when delay == (-1*active_duration)
-			
Fire animation start/end events when animation-duration is zero, with 0 elapsedTime
-			
If animation-iteration-count is infinite and duration is 0, treat the iteration-count as if it was finite and run a 0s second (option A in Brian's mail)
-			
If an animation with a negative animation delay is initially paused, the start event still fires
+			
Dynamic changes to animation properties/keyframes. Tab to propose resolution. (Bug 14713)
+			
Negative animation-delay values apply against the active duration of the animation i.e. (animation-duration*animation-iteration-count). The delay can thus swallow iterations for which no iteration event will be fired. The start/end events are still fired. Even when delay == (-1*active_duration)
+			
Fire animation start/end events when animation-duration is zero, with 0 elapsedTime
+			
If animation-iteration-count is infinite and duration is 0, treat the iteration-count as if it was finite and run a 0s second (option A in Brian's mail)
+			
If an animation with a negative animation delay is initially paused, the start event still fires
 			
 
 		
2012-10-29 minutes
 			

-			
Change the animation properties to be dynamically changeable
-			
@keyframes can be dynamically changed
+			
Change the animation properties to be dynamically changeable
+			
@keyframes can be dynamically changed
 			
When you encounter duplicate animations names, last one wins.
 			
Make *animations* transition *all* properties. Unless otherwise specified, discrete properties take their starting values below 50% timing function progress, and end values above 50% timing function progress.
 			
 		
2012-12-12 minutes and intermediate comments and 2012-12-19 minutes
 			

-			
Animations only run if they contain at least one valid keyframe rule (Bug)
+			
Animations only run if they contain at least one valid keyframe rule (Bug)
 			
When an element changes from display:none to display: non-none, animations start immediately (Bug)
-			
An initially-paused animation is still started (fires start events etc.) (Bug)
+			
An initially-paused animation is still started (fires start events etc.) (Bug)
 			
Animations can be paused during their delay phase, which freezes the remaining delay to be applied after it unpauses (Bug)
 			
animation-play-state has the same list behavior as the other animation properties, matching the length of animation-name (Bug)
 			
diff --git a/css-animations-2/Overview.bs b/css-animations-2/Overview.bs
index b3a30e7ddb5..c0e84664b34 100644
--- a/css-animations-2/Overview.bs
+++ b/css-animations-2/Overview.bs
@@ -27,11 +27,11 @@ ED: https://drafts.csswg.org/css-animations-2/
 TR: https://www.w3.org/TR/css-animations-2/
 Editor: L. David Baron, Google https://www.google.com/, https://dbaron.org/, w3cid 15393
 Editor: Brian Birtles, Invited Expert, brian@birchill.co.jp, w3cid 43194
-
-
+!Issues List: https://github.com/w3c/csswg-drafts/labels/css-animations-2
 Abstract: This CSS module describes a way for authors to animate the values of CSS properties over time, using keyframes. The behavior of these keyframe animations can be controlled by specifying their duration, number of repeats, and repeating behavior.
 Ignored Vars: auto-rewind
 
+
 
 urlPrefix: https://dom.spec.whatwg.org/; type: dfn; spec: dom
     text: event target
@@ -68,6 +68,13 @@ spec:web-animations-1; type:dfn;
     text:start delay
     text:target element
     text:unresolved
+spec:web-animations-2; type:dfn;
+    text:active interval; for:animation trigger
+    text:default range
+    text:exit range
+spec:scroll-animations-1; type:dfn;
+	text:animation-range-start
+	text:animation-range-end
 
 
 
Delta specification
@@ -135,7 +142,7 @@ the changes from the programming interface take precedence as follows:
     to null
     or some {{AnimationEffect}} other than the original {{KeyframeEffect}},
     all subsequent changes to animation properties other than
-    'animation-name' or 'animation-play-state'
+    'animation-name', 'animation-play-state', or 'animation-timeline'
     will not be reflected in that animation.
     Similarly, any change to matching ''@keyframes'' rules will not be reflected
     in that animation.
@@ -702,7 +709,282 @@ The 'animation' shorthand property syntax is as follows:
 
 <single-animation> = <<'animation-duration'>> || <> || <<'animation-delay'>> || <> || <> || <> || <> || [ none | <> ] || <>
 
+

+Declaring Animation Triggers
+
+    Animation Triggers are defined using the 'animation-trigger-*' properties.
+    These list-valued properties,
+    which are all [=longhands=] of the 'animation-trigger' [=shorthand=],
+    form a [=coordinating list property group=]
+    with 'animation-name' as the [=coordinating list base property=]
+    and each item in the [=coordinated value list=]
+    defining the properties of a single animation trigger.
+
+    The 'animation-trigger' properties
+    are [=reset-only sub-properties=] of the 'animation' [=shorthand=].
+
+## The 'animation-trigger-type' property ## {#animation-trigger-type}
+
+The 'animation-trigger-type' property specifies the [=animation trigger type=]
+of the [=animation trigger=].
+
+
+Name: animation-trigger-type
+Value: <>#
+Initial: once
+Applies to: all elements
+Inherited: no
+Percentages: N/A
+Computed value: list, each item a keyword as specified
+Animation type: not animatable
+Canonical order: per grammar
+
+
+<single-animation-trigger-type> = once | repeat | alternate | state
+
+The values of 'animation-trigger-type' have the following meaning
+for an [=animation trigger=] that enters its [=animation trigger/active interval|active interval=]:
+
+

+	
once
+	

+		The animation is triggered and played once and only once.
+
+	
repeat
+	

+		The animation is played from the beginning each time it is triggered.
+		When the trigger’s [=animation trigger/active interval=] is exited the animation is reset.
+
+	
alternate
+	

+		The animation is played forwards, according to its [=playback direction=], each time it is triggered.
+		When the trigger’s [=animation trigger/active interval=] is exited the animation is reversed.
+
+	
state
+	

+		The animation is triggered and played once.
+		When the trigger’s [=animation trigger/active interval=] is exited the animation is paused.
+		When the trigger’s [=animation trigger/active interval=] is re-entered the animation is resumed.
+
+
+The behavior of each value is defined in [[web-animations-2#trigger-types]].
+
+## The 'animation-trigger-timeline' property ## {#animation-trigger-timeline}
+
+The 'animation-trigger-timeline' property specifies the timeline
+of the animation’s associated [=animation trigger=].
+
+
+Name: animation-trigger-timeline
+Value: <>#
+Initial: auto
+Applies to: all elements
+Inherited: no
+Percentages: N/A
+Computed value: list, each item either
+  the keyword ''single-animation-timeline/none'',
+  the keyword ''single-animation-timeline/auto'',
+  a case-sensitive [=css identifier=],
+  a computed ''scroll()'' function,
+  or
+  a computed ''view()'' function
+Canonical order: per grammar
+Animation Type: not animatable
+
+
+The values of 'animation-trigger-timeline' have the same meaning as those of 'animation-timeline'.
+
+Issue: Probably a trigger with timeline "none" is under-specified here. Need to clarify what it means.
+
+## The 'animation-trigger-range' property ## {#animation-trigger-range}
+
+
+  Name: animation-trigger-range
+  Value: [ <<'animation-trigger-range-start'>> <<'animation-trigger-range-end'>>? ]#
+
+
+The 'animation-trigger-range' property is a [=shorthand property|shorthand=]
+that sets 'animation-trigger-range-start' and 'animation-trigger-range-end'
+together in a single declaration,
+specifying the [=animation trigger=]’s associated [=default range=].
+It has the same syntax as the 'animation-range' property.
+
+The behavior of 'animation-trigger-range' is defined in [[web-animations-2#trigger-ranges]].
 
+## The 'animation-trigger-range-start' property ## {#animation-trigger-range-start}
+
+
+  Name: animation-trigger-range-start
+  Value: [ normal | <> | <> <>? ]#
+  Initial: normal
+  Applies to: all elements
+  Inherited: no
+  Percentages: relative to the specified [=named timeline range=] if one was specified, else to the entire timeline
+  Computed value: list, each item either the keyword ''animation-trigger-range-start/normal'' or a timeline range and progress percentage
+  Animation type: not animatable
+
+
+The 'animation-trigger-range-start' property specifies the start of the [=animation trigger=]’s
+associated [=default range=].
+
+The values of 'animation-trigger-range-start' have the same meaning as those of 'animation-range-start'.
+
+## The 'animation-trigger-range-end' property ## {#animation-trigger-range-end}
+
+
+  Name: animation-trigger-range-end
+  Value: [ normal | <> | <> <>? ]#
+  Initial: normal
+  Applies to: all elements
+  Inherited: no
+  Percentages: relative to the specified [=named timeline range=] if one was specified, else to the entire timeline
+  Computed value: list, each item either the keyword ''animation-trigger-range-end/normal'' or a timeline range and progress percentage
+  Animation type: not animatable
+
+
+The 'animation-trigger-range-end' property specifies the end of the [=animation trigger=]’s
+associated [=default range=].
+
+The values of 'animation-trigger-range-end' have the same meaning as those of 'animation-range-end'.
+
+## The 'animation-trigger-exit-range' property ## {#animation-trigger-exit-range}
+
+
+  Name: animation-trigger-exit-range
+  Value: [ <<'animation-trigger-exit-range-start'>> <<'animation-trigger-exit-range-end'>>? ]#
+
+
+The 'animation-trigger-exit-range' property is a [=shorthand property|shorthand=]
+that sets 'animation-trigger-exit-range-start' and 'animation-trigger-exit-range-end'
+together in a single declaration,
+specifying the [=animation trigger=]’s associated [=exit range=].
+It has the same syntax as the 'animation-range' property, with the addition of the ''auto'' keyword.
+
+The [=exit range=] replaces the [=default range=] once the [=animation trigger=]’s
+[=animation trigger/active interval|active interval=] is entered,
+and redefines the extent of the [=animation trigger=]’s [=animation trigger/active interval|active interval=].
+It is used to extend the [=default range=], for example,
+in cases where exiting the [=animation trigger/active interval|active interval=]
+may create a visual jump that needs to be avoided.
+
+The behavior of 'animation-trigger-exit-range' is further defined in [[web-animations-2#trigger-ranges]].
+
+## The 'animation-trigger-exit-range-start' property ## {#animation-trigger-exit-range-start}
+
+
+  Name: animation-trigger-exit-range-start
+  Value: [ auto | normal | <> | <> <>? ]#
+  Initial: auto
+  Applies to: all elements
+  Inherited: no
+  Percentages: relative to the specified [=named timeline range=] if one was specified, else to the entire timeline
+  Computed value: list, each item either the keyword ''animation-trigger-exit-range-start/normal'' or a timeline range and progress percentage
+  Animation type: not animatable
+
+
+The 'animation-trigger-exit-range-start' property specifies the start of the [=animation trigger=]’s
+associated [=exit range=].
+
+The values of 'animation-trigger-exit-range-start' have the following meaning:
+
+

+	
auto
+	

+		The start of the trigger’s [=exit range=]
+		is equal to the start of its [=default range=].
+
+	
normal
+	

+		The start of the trigger’s [=exit range=]
+		is the start of its associated [=timeline=];
+		the start of the trigger’s [=animation trigger/active interval|active interval=]
+		is determined as normal.
+
+	
<>
+	

+		The [=exit range=] starts
+		at the specified point on the [=timeline=]
+		measuring from the start of the timeline.
+
+	
<> <>?
+	

+		The [=exit range=] starts
+		at the specified point on the [=timeline=]
+		measuring from the start of the specified [=named timeline range=].
+		If the <> is omitted,
+		it defaults to 0%.
+
+
+## The 'animation-trigger-exit-range-end' property ## {#animation-trigger-exit-range-end}
+
+
+  Name: animation-trigger-exit-range-end
+  Value: [ auto | normal | <> | <> <>? ]#
+  Initial: auto
+  Applies to: all elements
+  Inherited: no
+  Percentages: relative to the specified [=named timeline range=] if one was specified, else to the entire timeline
+  Computed value: list, each item either the keyword ''animation-trigger-exit-range-end/normal'' or a timeline range and progress percentage
+  Animation type: not animatable
+
+
+The 'animation-trigger-exit-range-end' property specifies the end of the [=animation trigger=]’s
+associated [=exit range=].
+
+The values of 'animation-trigger-exit-range-start' have the following meaning:
+
+

+	
auto
+	

+		The end of the trigger’s [=exit range=]
+		is equal to the end of its [=default range=].
+
+	
normal
+		

+			The end of the trigger’s [=exit range=]
+			is the end of its associated [=timeline=];
+			the end of the trigger’s [=animation trigger/active interval|active interval=]
+			is determined as normal.
+
+		
<>
+		

+			The [=exit range=] ends
+			at the specified point on the [=timeline=]
+			measuring from the start of the timeline.
+
+		
<> <>?
+		

+			The [=exit range=] ends
+			at the specified point on the [=timeline=]
+			measuring from the start of the specified [=named timeline range=].
+			If the <> is omitted,
+			it defaults to 100%.
+
+
+## The 'animation-trigger' property ## {#animation-trigger}
+
+The 'animation-trigger' property is a [=shorthand property|shorthand=]
+that sets 'animation-trigger-type', 'animation-trigger-timeline',
+'animation-trigger-range-start', 'animation-trigger-range-end',
+'animation-trigger-exit-range-start', and 'animation-trigger-exit-range-end'
+together in a single declaration,
+specifying the [=animation trigger=] for an animation.
+
+
+Name: animation-trigger
+Value: <>#
+Initial: see individual properties
+Applies to: all elements
+Inherited: no
+Percentages: N/A
+Computed value: see individual properties
+Canonical order: per grammar
+Animation Type: not animatable
+
+
+
+<single-animation-trigger> = <> || [ none | auto | [ [ <> | <> | <> ] [ normal | <> | <> <>? ]{0,4} ] ]
+
 
 # Animation Events # {#events}
 
diff --git a/css-backgrounds-3/Overview.bs b/css-backgrounds-3/Overview.bs
index 47f86a0b23f..10cee759b0a 100644
--- a/css-backgrounds-3/Overview.bs
+++ b/css-backgrounds-3/Overview.bs
@@ -28,7 +28,7 @@ spec:css2; type:value; text:table
 spec:css2; type:value; text:inline-table
 spec:css2; type:value; text:table-cell
 spec:css2; type:property; text:overflow
-spec:css2; type:value; text:visible
+spec:css2; type:value; for:overflow; text:visible
 spec:css2; type:dfn; text:viewport
 spec:css-break-4; type:dfn; text:fragment
 spec:css-color-4; type:property; text:color
@@ -832,7 +832,7 @@ Affixing Images: the 'background-attachment' property
 					
-				
+				
 			
 
 		
<>
@@ -2602,7 +2602,7 @@ Overlapping Curves
 
 			
 		
diff --git a/css-backgrounds-4/Overview.bs b/css-backgrounds-4/Overview.bs
index c194cb67699..55f4bb87c55 100644
--- a/css-backgrounds-4/Overview.bs
+++ b/css-backgrounds-4/Overview.bs
@@ -48,6 +48,7 @@ Tiling Images: the 'background-repeat-x', 'background-repeat-y', 'background-rep
 		Percentages: N/A
 		Computed value: as specified
 		Animation type: discrete
+		Logical property group: background-repeat
 	
 
 	
diff --git a/css-borders-4/Overview.bs b/css-borders-4/Overview.bs
index 2b0051e5569..ce22115d48e 100644
--- a/css-borders-4/Overview.bs
+++ b/css-borders-4/Overview.bs
@@ -19,6 +19,7 @@ Warning: Not Ready
 
 spec:css-text-4; type:value; text:collapse
 spec:css-shapes-2; type:function; text:path()
+spec:css-shapes-2; type:property; text:shape-inside
 
 
 
@@ -336,29 +337,165 @@ The 'border-radius' shorthand
 	See [[CSS3BG]].
 
 

-Corner Shaping: the 'corner-shape' property
+Corner Shaping
+
+By default, non-zero border-radii define a quarter-ellipse that rounds the affected corners.
+However in some cases, other corner shapes are desired.
+The 'corner-shape' property group specifies a reinterpretation of the radii to define other corner shapes.
+
+The different shapes applicable to 'corner-shape' can be expressed as different parameters to a superellipse.
+A superellipse is a closed curve resembling an ellipse, and based on its `k` parameter can express all the shapes between a square, an ellipse, and a notch.
+
+To allow full expression as well as interpolation, the 'corner-shape' properties can provide its own superellipse parameter using the 'superellipse()' function,
+or use one of the supplied keywords which represent commonly used parameters. See the <> definition for details.
+
+

+Rendering 'corner-shape'
+'corner-shape' works alongside 'border-radius', and does not have any visual effect with a 'border-radius' of 0.
+It acts as an alteration on top of the default round 'border-radius', and thus can be used as progressive enhancement.
+
+Like 'border-radius', 'corner-shape' clips elements according to the [=overflow=] rules, and applies to the rendering of the border.
+Since stroking a superellipse accurately may be computationally intensive, user agents may approximate the path using bezier curves,
+as well as account for sharp edges and overlaps.
+
+Issue: 'border-radius' already handles *adjacent* corners overlapping by shrinking the radiuses proportionally.
+A negative ''superellipse()'' parameter allows for *opposite* corners to sometimes overlap, and needs additional restrictions defined.
+
+Issue #11610: check if we need additional rendering restrictions.
+
+

+'corner-shape' values
+
+	
+		<> = ''round'' | ''scoop'' | ''bevel'' | ''notch'' | ''straight'' | ''squircle'' | superellipse(<> | infinity)
+	
+
+	

+		
round
+		

+			Border radii define a convex elliptical curve at the corner. Equivalent to superellipse(2).
+
+			Note: this is the initial value of 'corner-shape' properties, as elements with 'border-radius' would be rounded.
+
+		
scoop
+		
Border radii define a concave elliptical curve at the corner. Equivalent to superellipse(0.5).
+		
bevel
+		
Border radii define a diagonal slice at the corner. Equivalent to superellipse(1).
+		
notch
+		
Border radii define a concave 90deg angle at the corner. Equivalent to superellipse(0).
+		
straight
+		
Border radii define a convex 90deg angle at the corner.
+			This would have the same visual effect as a 'border-radius' of 0. This is different from having a 'border-radius' of 0 when animating.
+			Equivalent to superellipse(infinity).
+		
squircle
+		
Border radii define a convex curve between an ellipse and an convex angle, equivalent to superellipse(4).
+	
+
+	Issue #11607: resolve on ''straight'' vs none.
+
+	The superellipse( <> | infinity ) function describes the curvature of the corner.
+	It accepts a superellipse exponent, which defines the curvature of the corner, or the exponent of the formula.
+	The [=superellipse exponent=] accepts values between 0 (a straight concave angle) and infinity (a straight convex angle),
+	with the values in between representing the curvatures in between.
+
+	The ''superellipse()'' formula can be described in cartesian coordinates, as follows,
+	where a is the horizontal ''border-radius''
+	b is the vertical ''border-radius'', and k is the [=superellipse exponent=]:
+
+	
+		|x/a|^k + |y/b|^k = 1
+	
+
+

+Corner Shaping: the 'corner-shape' and 'corner-*-shape' properties
 
 	
 		Name: corner-shape
-		Value: [ round | angle ]{1,4}
+		Value: <>{1,4}
 		Initial: round
-		Applies to: all elements, except table element when 'border-collapse' is ''collapse''
+		Applies to: all elements where 'border-radius' can apply
 		Inherited: no
-		Animation type: discrete
+		Animation type: see individual properties
 	
 
-	By default, non-zero border-radii define
-	a quarter-ellipse that rounds the affected corners.
-	However in some cases, other corner shapes are desired.
-	The 'corner-shape' property specifies a reinterpretation of the radii
-	to define other corner shapes.
-
-	

-		
''round''
-		
Border radii define a convex elliptical curve at the corner.
-		
''angle''
-		
Border radii define a diagonal slice at the corner.
-	
+	Applies the shape to all corners, following the same rules as ''border-radius''.
+
+	
+	Name: corner-top-left-shape, corner-top-right-shape, corner-bottom-right-shape, corner-bottom-left-shape, corner-start-start-shape, corner-start-end-shape, corner-end-start-shape, corner-end-end-shape
+	Value: <>
+	Initial: round
+	Applies to: all elements where 'border-radius' can apply
+	Inherited: no
+	Logical property group: corner-shape
+	Computed value: the corresponding ''superellipse()'' value
+	Animation Type: see [=superellipse interpolation=]
+	
+
+	The [=flow-relative=] properties
+	'corner-start-start-shape',
+	'corner-start-end-shape',
+	'corner-end-start-shape',
+	and 'corner-end-end-shape'
+	correspond to the [=physical=] properties
+	'corner-top-left-shape',
+	'corner-bottom-left-shape',
+	'corner-top-right-shape',
+	and 'corner-bottom-right-shape'.
+	The mapping depends on the element’s 'writing-mode', 'direction', and 'text-orientation',
+	with the first start/end giving the block axis side,
+	and the second the inline-axis side
+	(i.e. patterned as 'corner-block-inline-shape').
+
+	
+		Name: corner-top-shape, corner-right-shape, corner-bottom-shape, corner-left-shape,
+			corner-block-start-shape, corner-block-end-shape, corner-inline-start-shape, corner-inline-end-shape
+		Value: <>
+		Initial: round
+		Applies to: all elements where 'border-radius' can apply
+		Inherited: no
+		Computed value: see individual properties
+		Animation type: see individual properties
+	
+
+	
The 'corner-*-shape' shorthands set the two 'corner-*-*-shape'
+	properties of the related side.
+	The two values for the shapes are given in the order
+	top-left, top-right for 'corner-top-shape',
+	top-right, bottom-right for 'corner-right-shape',
+	bottom-left, bottom-right for 'corner-bottom-shape',
+	top-left, bottom-left for 'corner-left-shape',
+	start-start, start-end for 'corner-block-start-shape',
+	end-start, end-end for 'corner-block-end-shape'
+	start-start, end-start for 'corner-inline-start-shape',
+	and start-end, end-end for 'corner-inline-end-shape'.
+	If the second value is omitted it is copied from the first.
+
+
+

+Interpolating corner shapes
+
+Since a <> can always be expressed by a ''superellipse()'' with an [=superellipse exponent=] variable, interpolating between two
+<>s is done by interpolating the [=superellipse exponent=] itself.
+Since it's an exponent, interpolating it linearly would result in an effect where concave corners interpolate at a much higher velocity than convex corners.
+To balance that, the superellipse interpolation formula describes how a [=superellipse exponent=] is converted to a value between 0 and 1, and vice versa:
+
+

+To interpolate a <> |exponent| to an interpolation value between 0 and 1:
+	1. If |exponent| is 0, return 0.
+	1. If |exponent| is ∞, return 1.
+	1. Return 1/(2^(1/|exponent|)).
+
+To convert a <> |interpolationValue| back to a [=superellipse exponent=]:
+	1. If |interpolationValue| is 0, return 0.
+	1. If |interpolationValue| is 1, return ∞.
+	1. Return ln(0.5)/ln(|interpolationValue|).
+
+
+Issue #11608: resolve on this or another interpolation formula.
+
+
+
+
 
 	

 		For example, the following declarations create a right-pointing next button.
@@ -398,33 +535,6 @@ Corner Shaping: the 'corner-shape' property
 		How to allow custom corners? Perhaps a ''path()'' function? Or a ''cubic-bezier()''?
 		Something else?
 
-

-Corner Shape and Size: the 'corners' shorthand
-
-	
-		Name: corners
-		Value: <<'corner-shape'>> || <<'border-radius'>>
-	
-
-	The 'corners' shorthand sets 'corner-shape' and 'border-radius' in the same declaration.
-	If either is omitted, it is reset to its initial value.
-
-	

-		For example, the following declaration creates a diamond shape.
-		
corners: angle 50%;
-		In UAs that don't support 'corner-shape', the declaration is ignored
-		(falls back to a rectangle).
-	
-
-	

-		In this example, the first declaration creates tabs with vertical sides and rounded corners using 'border-radius',
-		while the second example makes them trapezoid-shaped in UAs that support 'corners'.
-		
-			border-radius: 0.25em 0.25em 0 0;
-			corners: angle 0.25em 0.25em 0 0 / 50% 50% 0 0;
-		
-	
-
 

 Partial borders
 
@@ -975,6 +1085,59 @@ Layering, Layout, and Other Details
 	or an inner shadow on a rowspanning table cell that adjoins cells with different border thicknesses),
 	the exact position and rendering of its shadows are undefined.
 
+

+Border Shaping
+
+While 'corner-shape' and 'border-radius' allow some expressiveness to styling a border,
+they still work with the assumption that the border is rectangular.
+
+The 'border-shape' function augments these capabilities,
+by enabling the author to use any [=basic shape=] to specify the path of the border.
+
+

+The 'border-shape' property
+
+	
+		Name: border-shape
+		Value: none | [ <> <>?]{1,2}
+		Initial: none
+		Applies to: all elements
+		Inherited: no
+		Percentages: relative to the given <>, or to [=border box=] if not given.
+		Computed value: list, each item a computed color
+		Animation type: by computed value
+	
+
+The 'border-shape' property is provided with either a single <> or two <>s,
+resulting in one or two paths, respectively.
+The single-path border shape varint uses the existing ''border'' properties of the element to stroke the
+path that the given <> resolves to,
+while the double-path border shape variant fills the area between the two paths as if it were the border.
+
+The 'border-shape' property is not compatible with 'border-radius' and 'corner-shape'.
+When an element's [=computed value=] of 'border-shape' is not none,
+its 'border-radius' is ignored, as if it was set to 0.
+'corner-shape' is implicitly ignored, as it can only work in tandem with 'border-radius'.
+
+A 'box-shadow' follows both the inner and outer border paths.
+
+'border-shape' does not affect geometry or layout,
+which is still computed using the existing 'border-width' properties.
+
+'border-shape' does not affect the flow of content inside the box.
+Note: An author can use 'border-shape' in tandem with 'shape-inside' to create effects that decorate the box and control its text flow at the same time.
+
+The inner 'border-shape' clips the [=overflow=] content of the element, in the same manner as 'border-radius',
+as described in corner clipping.
+
+Issue: how should this affect clipping replaced elements?
+
+The fill and stroke color, as well as the stroke width, are taken from the respective 'border-color' and 'border-width' properties.
+
+Issue: define this in detail. Perhaps it should be overridable somehow?
+
+Issue: what do we do about 'border-style'? It can't exactly work for every arbitrary shape.
+
 

 Changes
 
diff --git a/css-box-4/Overview.bs b/css-box-4/Overview.bs
index bbd7a343e5c..1434c803b76 100644
--- a/css-box-4/Overview.bs
+++ b/css-box-4/Overview.bs
@@ -402,7 +402,7 @@ Margins at Container Edges: the 'margin-trim' property {#margin-trim}
 		
block-start
 		
block-end
 		

-			For in-flow boxes contained by this box,
+			For [=in-flow=] boxes contained by this box,
 			margins adjacent to the box’s specified edges
 			are truncated to zero.
 			It also truncates any descendant margins collapsed with such a margin
@@ -410,7 +410,7 @@ Margins at Container Edges: the 'margin-trim' property {#margin-trim}
 
 		
inline-start
 		
inline-end
-			For in-flow boxes contained by this box,
+			For [=in-flow=] boxes contained by this box,
 			margins adjacent to the box’s specified edges
 			are truncated to zero.
 			(However, these values do not apply to [=block containers=])
diff --git a/css-cascade-6/Overview.bs b/css-cascade-6/Overview.bs
index 26c2bfa2d2f..76b2207a3e9 100644
--- a/css-cascade-6/Overview.bs
+++ b/css-cascade-6/Overview.bs
@@ -147,9 +147,12 @@ Cascade Sorting Order
 
 		
Specificity
 		

-			The Selectors module [[!SELECT]] describes how to compute the specificity of a selector.
-			Each declaration has the same specificity as the style rule it appears in.
-			The declaration with the highest specificity wins.
+			The Selectors module [[!SELECT]]
+			describes how to compute the specificity of a selector.
+
+			When comparing declarations from two style rules,
+			the declaration belonging to
+			the style rule with the highest specificity wins.
 
 		
Scope Proximity
 		

diff --git a/css-color-4/Overview.bs b/css-color-4/Overview.bs
index ae03c3dbca3..5add776dc2f 100644
--- a/css-color-4/Overview.bs
+++ b/css-color-4/Overview.bs
@@ -100,6 +100,11 @@ spec: css-backgrounds-3; type: property; text: border-right-color
 			"title": "ROMM RGB",
 			"publisher": "ICC",
 			"href": "https://www.color.org/chardata/rgb/rommrgb.xalter"
+		},
+		"Understanding_CCT": {
+			"title": "What is CCT? A Guide to Choosing Correlated Color Temperature for Your Lighting",
+			"date": "2024-08-14",
+			"href": "https://litomatic.com/blog/what-is-cct-in-lighting/"
 		}
 	}
 
@@ -352,7 +357,8 @@ Value Definitions
 
 	Most color spaces use one of a few
 	daylight-simulating [=white points=],
-	which are named by the color temperature
+	which are named by the correlated color temperature (CCT)
+	[[Understanding_CCT]]
 	of the corresponding black-body radiator.
 	For example, [=D65=] is a daylight whitepoint
 	corresponding to a correlated color temperature
@@ -413,7 +419,7 @@ Value Definitions
 	like those found in a rainbow.
 
 	

-		

+		

 		
 		

 		<color-space> = <rectangular-color-space> | <polar-color-space>
-		<rectangular-color-space> = ''srgb'' | ''srgb-linear'' | ''display-p3'' | ''a98-rgb'' | ''prophoto-rgb'' | ''rec2020'' | ''lab'' | ''oklab'' | ''xyz'' | ''xyz-d50'' | ''xyz-d65''
-		<polar-color-space> = ''hsl'' | ''hwb'' | ''lch'' | ''oklch''
+		<rectangular-color-space> = ''srgb'' | ''srgb-linear'' | ''display-p3'' | ''a98-rgb'' | ''prophoto-rgb'' | ''rec2020'' | ''lab'' | ''oklab'' | ''xyz'' | ''xyz-d50'' | ''xyz-d65''
+		<polar-color-space> = ''hsl'' | ''hwb'' | ''lch'' | ''oklch''
 		<hue-interpolation-method> = [ shorter | longer | increasing | decreasing ] hue
 		<color-interpolation-method> = in [ <> | <> <>? ]
 	

-			 lch(50% 0.02 none)
-			 color(display-p3 0.7 0.5 none)
+			 lch(50% 0.02 none)
+			 color(display-p3 0.7 0.5 none)
 		

-			 oklch(56.897% 0.0001 0)
-			 oklch(63.612% 0.1522 78.748)
+			 oklch(56.897% 0.0001 0)
+			 oklch(63.612% 0.1522 78.748)
 		

-			 oklch(56.897% 0.0001 none)
-			 oklch(63.612% 0.1522 78.748)
+			 oklch(56.897% 0.0001 none)
+			 oklch(63.612% 0.1522 78.748)
 		

- +