<pre class='metadata'>

Title: CSS Cascading and Inheritance Level 6

Shortname: css-cascade

Level: 6

Status: ED

Prepare for TR: no

Work Status: Revising

Group: csswg

ED: https://drafts.csswg.org/css-cascade-6/

TR: https://www.w3.org/TR/css-cascade-6/

Previous Version: https://www.w3.org/TR/2021/WD-css-cascade-6-20211221/

Editor: Elika J. Etemad / fantasai, Apple, http://fantasai.inkedblade.net/contact, w3cid 35400

Editor: Miriam E. Suzanne, Invited Expert, http://miriamsuzanne.com/contact, w3cid 117151

Editor: Tab Atkins Jr., Google, http://xanthir.com/contact/, w3cid 42199

Abstract: This CSS module 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.

Abstract:

Abstract: New in this level is [[#scoped-styles]].

Ignored Terms: auto, flex items, <supports-condition>

Informative Classes: ex

</pre>

<pre class=link-defaults>

spec:dom; type:dfn; text:shadow tree

spec:dom; type:dfn; for:tree; text:root

spec:css-color-4; type:property; text:color

spec:css-values-3; type: value; text:ex

spec:css-conditional-3; type:at-rule; text:@media

spec:mediaqueries-4; type:type; for:@media; text:all

spec:mediaqueries-4; type:type; text:<media-query>

spec:selectors-4; type:dfn; text:subject

spec:html; type:element; text:style

spec:css-scoping-1; type:dfn; text:shadow host

</pre>

<pre class=ignored-specs>

spec:mediaqueries-5

spec:css-values-4

spec:css-fonts-4

</pre>

<h2 id="intro" oldids='filtering,fragments,stages-examples,actual,used,computed,cascaded,declared,specified,value-stages,all-shorthand,aliasing,shorthand,content-type,import-processing,conditional-import,at-import,defaulting,initial-values,inheriting,defaulting-keywords,initial,inherit,inherit-initial,default'>

Introduction and Missing Sections</h2>

Issue: This is a diff spec over <a href="https://www.w3.org/TR/css-cascade-5/">CSS Cascading and Inheritance Level 5</a>.

It is currently an Exploratory Working Draft:

if you are implementing anything, please use Level 5 as a reference.

We will merge the Level 5 text into this draft once it reaches CR.

<!--

██████ ███ ██████ ██████ ███ ████████ ████████

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██████ ██ ██ ██ ██ ██ ██████

██ █████████ ██ ██ █████████ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██████ ██ ██ ██████ ██████ ██ ██ ████████ ████████

-->

<h2 id='cascading'>

Cascading</h2>

The <dfn export>cascade</dfn>

takes an unordered list of <a>declared values</a>

for a given property on a given element,

sorts them by their [=declaration’s=] precedence as determined below,

and outputs a single <a>cascaded value</a>.

<h3 id="cascade-sort">

Cascade Sorting Order</h3>

The cascade sorts [=declarations=] according to the following criteria,

in descending order of precedence:

<dl>

<dt id='cascade-origin'>Origin and Importance

<dd>

The <a>origin</a> of a [=declaration=] is based on where it comes from

and its <a lt="important">importance</a> is

whether or not it is declared with ''!important''

(see [[#importance|below]]).

The precedence of the various <a>origins</a> is, in descending order:

<ol>

<li>Transition declarations [[!css-transitions-1]]

<li>[=Important=] [=user-agent origin|user agent=] declarations

<li>[=Important=] [=user origin|user=] declarations

<li>[=Important=] [=author origin|author=] declarations

<li>Animation declarations [[!css-animations-1]]

<li>[=Normal=] [=author origin|author=] declarations

<li>[=Normal=] [=user origin|user=] declarations

<li>[=Normal=] [=user-agent origin|user agent=] declarations

</ol>

Declarations from <a>origins</a> earlier in this list win over declarations from later <a>origins</a>.

<dt id='cascade-context'>Context

<dd>

A document language can provide for blending [=declarations=] sourced

from different <dfn local-lt="context">encapsulation contexts</dfn>,

such as the nested [=tree contexts=] of [=shadow trees=] in the [[!DOM]].

When comparing two declarations

that are sourced from different [=encapsulation contexts=],

then for [=normal=] rules

the declaration from the outer context wins,

and for [=important=] rules

the declaration from the inner context wins.

For this purpose,

[[DOM]] [=tree contexts=] are considered to be nested

in [=shadow-including tree order=].

Note: This effectively means that

[=normal=] declarations belonging to an [=encapsulation context=]

can set defaults that are easily overridden by the outer context,

while [=important=] declarations belonging to an [=encapsulation context=]

can enforce requirements that cannot be overridden by the outer context.

<dt id='style-attr'>The Style Attribute

<dd>

Separately for [=normal=] and [=important=] [=declarations=],

declarations that are attached directly to an element

(such as the <a href="https://www.w3.org/TR/css-style-attr/#interpret">contents of a style attribute</a>)

rather than indirectly mapped by means of a style rule selector

take precedence over declarations the same [=importance=]

that are mapped via style rule.

<dt id='cascade-layering'>Layers

<dd>

[=Declarations=] within each [=origin=] and [=context=]

can be explicitly assigned to a [=cascade layer=].

For the purpose of this step,

any declaration not assigned to an explicit layer is added to an implicit final layer.

Cascade layers (like declarations) are sorted by order of appearance,

see [[#layer-ordering]].

When comparing declarations that belong to different layers,

then for [=normal=] rules the declaration whose [=cascade layer=] is latest in the layer order wins,

and for [=important=] rules the declaration whose [=cascade layer=] is earliest wins.

Note: This follows the same logic used for precedence of [=normal=] and [=important=] [=origins=],

thus the ''!important'' flag maintains the same “override” purpose in both settings.

<dt id='cascade-specificity'>Specificity

<dd>

The <a href="https://www.w3.org/TR/selectors/#specificity">Selectors module</a> [[!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.

<dt id='cascade-proximity'><dfn>Scope Proximity</dfn>

<dd>

When comparing declarations that appear in style rules

with different [=scoping roots=],

then the declaration with the fewest

generational or sibling-element hops

between the [=scoping root=] and the

[=scoped style rule=] [=subject=] wins.

For this purpose,

style rules without a [=scoping root=]

are considered to have infinite proximity hops.

<dt id='cascade-order'>Order of Appearance

<dd>

The last declaration in document order wins.

For this purpose:

<ul>

<li>Style sheets are ordered as in <a href="https://drafts.csswg.org/cssom/#documentorshadowroot-final-css-style-sheets">final CSS style sheets</a>.

<li>Declarations from <a at-rule lt="@import">imported style sheets</a>

are ordered as if their style sheets were substituted in place of the ''@import'' rule.

<li>Declarations from style sheets independently linked by the originating document

are treated as if they were concatenated in linking order,

as determined by the host document language.

<li>Declarations from style attributes

are ordered according to the document order of the element the style attribute appears on,

and are all placed after any style sheets.

[[!CSSSTYLEATTR]]

</ul>

</dl>

The <dfn export>output of the cascade</dfn>

is a (potentially empty) sorted list of <a>declared values</a> for each property on each element.

<h3 id='cascading-origins'>

Cascading Origins</h3>

Issue: [[css-cascade-5#cascading-origins]]

<dfn id=origin export local-lt="origin">cascade origin</dfn>

<h3 id='importance'>

Important Declarations: the ''!important'' annotation</h3>

Issue: [[css-cascade-5#importance]]

<dfn export local-lt="importance">important</dfn>

<dfn>normal</dfn>

<h3 id='layering'>

Cascade Layers</h3>

Issue: [[css-cascade-5#layering]]

<h4 id="layer-ordering">

Layer Ordering</h4>

Issue: [[css-cascade-5#layer-ordering]]

<!--

██████ ██████ ███████ ████████ ████ ██ ██ ██████

██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ████ ██ ██

██████ ██ ██ ██ ████████ ██ ██ ██ ██ ██ ████

██ ██ ██ ██ ██ ██ ██ ████ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ███ ██ ██

██████ ██████ ███████ ██ ████ ██ ██ ██████

-->

<h3 id='scoped-styles' oldids="scope-atrule">

Scoping Styles: the ''@scope'' rule</h3>

A <dfn>scope</dfn> is a subtree or fragment of a document,

which can be used by selectors for more targeted matching.

A [=scope=] is formed by determining:

* The [=scoping root=] [=node=],

which acts as the upper bound of the scope,

and optionally:

* The <dfn>scoping limit</dfn> elements,

which act as the lower bounds.

An element is <dfn>in scope</dfn> if:

* It is an [=inclusive descendant=] of the [=scoping root=], and

* It is not an [=inclusive descendant=] of a [=scoping limit=].

Note: In contrast to [[CSS-SCOPING-1#shadow-dom|Shadow Encapsulation]],

which describes a persistent one-to-one relationship in the DOM

between a [=shadow host=] and its nested [=shadow tree=],

multiple overlapping [=scopes=] can be defined in relation to the same elements.

Scoped styles are described in CSS using

the <dfn>@scope</dfn> [=block at-rule=],

which declares a [=scoping root=] and optional [=scoping limits=]

associated with a set of [=style rules=].

<div class=example>

For example,

an author might have wide-reaching color-scheme scopes,

which overlap more narrowly-scoped design patterns

such as a media object.

The selectors in the ''@scope'' rule

establish [=scoping root=] and optional [=scoping limit=] elements,

while the nested selectors only match elements

that are [=in scope|in a resulting scope=]:

<pre highlight=css>

@scope (.light-scheme) {

/* Only match links inside a light-scheme */

a { color: darkmagenta; }

}

@scope (.dark-scheme) {

/* Only match links inside a dark-scheme */

a { color: plum; }

}

@scope (.media-object) {

/* Only match author images inside a media-object */

.author-image { border-radius: 50%; }

}

</pre>

</div>

<div class=example>

By providing [=scoping limits=],

an author can limit matching more deeply nested descendants.

For example:

<pre highlight=css>

@scope (.media-object) to (.content > *) {

img { border-radius: 50%; }

.content { padding: 1em; }

}

</pre>

The ''img'' selector will only match image tags that are in a DOM fragment

starting with any ''.media-object'',

and including all descendants up to

any intervening children of the ''.content'' class.

</div>

Issue: Should scoping limits be added to the definition of [=scoped selectors=]?

<h4 id="scope-effects">

Effects of ''@scope''</h4>

The ''@scope'' [=at-rule=] has three primary effects

on the [=style rules=] it contains:

* The [=style rules=] in an ''@scope'' <<rule-list>>

are [=scoped style rules=].

* The '':scope'' selector is defined to match

the ''@scope'' rule’s [=scoping root=].

The ''&'' selector is defined to represent

the selector representing the [=scoping root=]

(the <<scope-start>> selector),

or else '':scope'' if no selector was specified.

* The [=cascade=] prioritizes declarations

with a [=scope proximity|more proximate=] [=scoping root=],

regardless of specificity or order of appearance

by applying [=scope proximity=]

between the [=scoping root=] and the [=subject=]

of each [=scoped style rule=].

Note: Unlike <a href="https://www.w3.org/TR/css-nesting/">Nesting</a>,

selectors within an ''@scope'' rule

do not acquire the specificity of any parent selector(s) in the ''@scope'' prelude.

<div class=example>

The following selectors have the same specificity (0,0,1):

<pre highlight=css>

@scope (#hero) {

img { border-radius: 50%; }

}

:where(#hero) img { border-radius: 50%; }

</pre>

The additional specificity of the ''#hero'' selector

is not applied to the specificity of the scoped selector.

However, since one <{img}> selector is scoped,

that selector is weighted more strongly in the cascade

with the application of [=scope proximity=].

</div>

<div class=example>

Many existing tools implement "scoped styles"

by applying a unique class or attribute

to every element in a given scope

or "single file component."

In this example there are two scopes

(<code>main-component</code> and <code>sub-component</code>)

and every element is marked as part of one or both scopes

using the <code>data-scope</code> attribute:

<pre class=lang-html>

&lt;section data-scope="main-component">

&lt;p data-scope="main-component">...&lt;p>

&lt;!-- sub-component root is in both scopes -->

&lt;section data-scope="main-component sub-component">

&lt;!-- children are only in the inner scope -->

&lt;p data-scope="sub-component">...&lt;p>

&lt;/section>

&lt;/section>

</pre>

Those custom scope attributes are then

appended to every single selector in CSS:

<pre highlight=css>

p[data-scope~='main-component'] { color: red; }

p[data-scope~='sub-component'] { color: blue; }

/* both sections are part of the outer scope */

section[data-scope~='main-component'] { background: snow; }

/* the inner section is also part of the inner scope */

section[data-scope~='sub-component'] { color: ghostwhite; }

</pre>

Using the ''@scope'' rule,

authors and tools can replicate similar behavior

with the unique attribute or class

applied only to the [=scoping roots=]:

<pre class=lang-html>

&lt;section data-scope="main-component">

&lt;p>...&lt;p>

&lt;section data-scope="sub-component">

&lt;p>...&lt;p>

&lt;/section>

&lt;/section>

</pre>

Then the class or attribute can be used

for establishing both upper and lower boundaries.

Elements matched by a lower boundary selector

are excluded from the resulting scope,

which allows authors to create non-overlapping scopes by default:

<pre highlight=css>

@scope ([data-scope='main-component']) to ([data-scope]) {

p { color: red; }

/* only the outer section is part of the outer scope */

section { background: snow; }

}

@scope ([data-scope='sub-component']) to ([data-scope]) {

p { color: blue; }

/* the inner section is only part of the inner scope */

section { color: ghostwhite; }

}

</pre>

However, authors can use the child combinator

and universal selector to create scope boundaries that overlap,

such that the inner scope root is part of both scopes:

<pre highlight=css>

@scope ([data-scope='main-component']) to ([data-scope] > *) {

p { color: red; }

/* both sections are part of the outer scope */

section { background: snow; }

}

</pre>

</div>

<h4 id="scope-syntax">

Syntax of ''@scope''</h4>

The syntax of the ''@scope'' rule is:

<pre class="prod def">

@scope [(<<scope-start>>)]? [to (<<scope-end>>)]? {

<<rule-list>>

}

</pre>

where:

* <dfn><<scope-start>></dfn> is a <<forgiving-selector-list>> [=selector=]

used to identify the [=scoping root=](s).

* <dfn><<scope-end>></dfn> is a <<forgiving-selector-list>> [=selector=]

used to identify any [=scoping limits=].

* the <<rule-list>> represents the [=scoped style rules=].

[=Pseudo-elements=] cannot be [=scoping roots=] or [=scoping limits=];

they are invalid both within <<scope-start>> and <<scope-end>>.

<h4 id="scoped-rules">

Scoped Style Rules</h4>

<dfn>Scoped style rules</dfn> differ from non-scoped rules

in the following ways:

* Their selectors can only match elements that are [=in scope=].

(This only applies to the [=subject=];

the rest of the selector can match unrestricted.)

* They accept a <<relative-selector-list>> as their prelude

(rather than just a <<selector-list>>).

Such [=relative selectors=]

are relative to '':scope''.

* Any selector in the <<relative-selector-list>>

that does not start with a [=combinator=]

but does [=contain the nesting selector=] or the '':scope'' selector,

is interpreted as a non-[=relative selector=]

(but the [=subject=] must still be [=in scope=] to match).

<div class="example">

By default, selectors in a [=scoped style rule=]

are [=relative selectors=],

with the [=scoping root=] and [=descendant combinator=]

implied at the start.

The following selectors will match the same elements:

<pre highlight=css>

@scope (#my-component) {

p { color: green; }

:scope p { color: green; }

}

</pre>

Authors can adjust the implied relationship

by adding an explicit combinator:

<pre highlight=css>

@scope (#my-component) {

> p { color: green; }

:scope > p { color: green; }

}

</pre>

Authors can also target or explicitly position

the [=scoping root=] in a selector

by including either '':scope'' or ''&'' in a given selector:

<pre highlight=css>

@scope (#my-component) {

:scope { border: thin solid; }

& { border: thin solid; }

main :scope p { color: green; }

main & p { color: green; }

}

</pre>

While the '':scope'' or ''&'' selectors

can both refer to the [=scoping root=],

they have otherwise different meanings in this context:

: Differences in selector matching

:: The '':scope'' selector will only match the [=scoping root=] itself,

while the ''&'' selector is able to match any element

that is matched by the <<scope-start>> selector list.

: Differences in selector specificity

:: The '':scope'' selector has a specificity

equal to other pseudo-classes,

while the ''&'' selector has the specificity

equal to the most specific selector in <<scope-start>>.

</div>

<h4 id="scope-limits">

Identifying Scoping Roots and Limits</h4>

A ''@scope'' rule produces one or more [=scopes=] as follows:

: Finding the [=scoping root=](s)

:: For each element matched by <<scope-start>>,

create a [=scope=] using that element as the [=scoping root=].

If no <<scope-start>> is specified,

the [=scoping root=] is the [=parent element=] of the [=owner node=]

of the stylesheet where the ''@scope'' rule is defined.

(If no such element exists,

then the [=scoping root=] is the [=root=] of the containing [=node tree=].)

Any '':scope'' or ''&'' selectors in <<scope-start>>

are interpreted as defined for its outer context.

: Finding any [=scoping limits=]

:: For each [=scope=] created by a [=scoping root=],

its [=scoping limits=] are set to all elements

that are [=in scope=] and that match <<scope-end>>,

interpreting '':scope'' and ''&''

exactly as in [=scoped style rules=].

<div class=example>

Authors can establish local scoping

for <{style}> elements by leaving out the <<scope-start>> selector.

For example:

<pre class=lang-html>

&lt;div>

&lt;style>

@scope {

p { color: red; }

}

&lt;/style>

&lt;p>this is red&lt;/p>

&lt;/div>

&lt;p>not red&lt;/p>

</pre>

That would be equivalent to:

<pre class=lang-html>

&lt;div id="foo">

&lt;style>

@scope (#foo) {

p { color: red; }

}

&lt;/style>

&lt;p>this is red&lt;/p>

&lt;/div>

&lt;p>not red&lt;/p>

</pre>

</div>

<div class=example>

[=Scoping limits=] can use the '':scope'' pseudo-class

to require a specific relationship to the [=scoping root=]:

<pre highlight=css>

/* .content is only a limit when it is a direct child of the :scope */

@scope (.media-object) to (:scope > .content) { ... }

</pre>

[=Scoping limits=] can also reference elements outside their [=scoping root=]

by using '':scope''.

For example:

<pre highlight=css>

/* .content is only a limit when the :scope is inside .sidebar */

@scope (.media-object) to (.sidebar :scope .content) { ... }

</pre>

</div>

<h4 id="scope-scope">

Scope Nesting</h4>

''@scope'' rules can be nested.

In this case, just as with the nested style rules,

the prelude selectors of the inner ''@scope''

(those defining its [=scope=])

are [=scoped selectors|scoped by=]

the selectors of the outer one.

Note: The resulting [=scope=]

for further nested [=scoped style rules=]

is practically constrained by both

the outer and inner ''@scope'' rules,

but the [=scoping root=] is defined

by the innermost ''@scope''.

Since [=scope proximity=] is measured

between a [=scoped style rule=] [=subject=]

and [=scoping root=],

only the innermost ''@scope'' matters

for determining [=scope proximity=] of [[#scope-scope|nested @scope rules]].

<div class=example>

When nesting ''@scope'' rules inside other ''@scope'' rules,

or inside other selectors,

the <<scope-start>> selector is

[=relative selector|relative to=] the nesting context,

while the <<scope-end>> and any [=scoped style rules=]

are [=relative selector|relative to=] the [=scoping root=]

For example, the following code:

<pre highlight=css>

@scope (.parent-scope) {

@scope (:scope > .child-scope) to (:scope .limit) {

:scope .content {

color: red;

}

}

}

</pre>

is equivalent to:

<pre highlight=css>

@scope (.parent-scope > .child-scope) to (.parent-scope > .child-scope .limit) {

.parent-scope > .child-scope .content {

color: red;

}

}

</pre>

</div>

Global name-defining [=at-rules=]

such as ''@keyframes'' or ''@font-face'' or ''@layer''

that are defined inside ''@scope'' are valid,

but are not scoped or otherwise affected

by the enclosing ''@scope'' rule.

However, any [=style rules=] contained by such rules

(e.g. within ''@layer'')

are [=scoped style rules|scoped=].

<h3 id="preshint">

Precedence of Non-CSS Presentational Hints</h3>

Issue: [[css-cascade-5#layering]]

<!--

██████ ██████ ██████ ███████ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ███ ███

██ ██ ██ ██ ██ ████ ████

██ ██████ ██████ ██ ██ ██ ███ ██

██ ██ ██ ██ ██ ██ ██

██ ██ ██ ██ ██ ██ ██ ██ ██ ██

██████ ██████ ██████ ███████ ██ ██

-->

CSSOM {#cssom}

==============

<h3 id="the-cssscoperule-interface">

The <code>CSSScopeRule</code> interface</h3>

The {{CSSScopeRule}} interface represents the ''@scope'' rule:

<pre class='idl' export>

[Exposed=Window]

interface CSSScopeRule : CSSGroupingRule {

readonly attribute CSSOMString? start;

readonly attribute CSSOMString? end;

};

</pre>

<dl class='idl-attributes'>

<dt><code>start</code> of type <code>CSSOMString</code>

<dd>The <code>start</code> attribute

returns the result of serializing the <<scope-start>> of the rule

(without the enclosing parentheses),

or null if there is no <<scope-start>>.

<dt><code>end</code> of type <code>CSSOMString</code>

<dd>The <code>end</code> attribute

returns the result of serializing the <<scope-end>> of the rule

(without the enclosing parentheses),

or null if there is no <<scope-end>>.

</dl>

<!--

████████ ████████ ██████

██ ██ ██ ██

██ ██ ██

██████ ██ ██

██ ██ ██

██ ██ ██ ██

████████ ██ ██████

-->

<h2 id="changes">

Changes</h2>

This appendix is <em>informative</em>.

<h3 id="changes-2022-08">

Changes since the 21 March 2023 Working Draft</h3>

Significant changes since the

<a href="https://www.w3.org/TR/2023/WD-css-cascade-6-20230321/">21 March 2023 Working Draft</a> include:

* Clarified that [=scope proximity=] is a single measurement of the steps

between a single [=scoping root=] and [=scoped style rule=] [=subject=].

* Removed strong scope proximity.

(<a href="https://github.com/w3c/csswg-drafts/issues/6790">Issue 6790</a>)

* Removed the scoped descendant combinator (deferred).

(<a href="https://github.com/w3c/csswg-drafts/issues/8628">Issue 8628</a>)

* Added the {{CSSScopeRule}} interface.

(<a href="https://github.com/w3c/csswg-drafts/issues/8626">Issue 8626</a>)

<h3 id="changes-2022-08">

Changes since the 21 December 2021 First Public Working Draft</h3>

Significant changes since the

<a href="https://www.w3.org/TR/2021/WD-css-cascade-6-20211221/">21 December 2021 First Public Working Draft</a> include:

* Clarified ''@scope'' effects on nested '':scope'' and ''&'' selectors.

(<a href="https://github.com/w3c/csswg-drafts/issues/8377">Issue 8377</a>)

* Removed ''@scope'' prelude from specificity calculation.

(<a href="https://github.com/w3c/csswg-drafts/issues/8500">Issue 8500</a>)

* Specified how name-defining [=at-rules=] behave in ''@scope''.

(<a href="https://github.com/w3c/csswg-drafts/issues/6895">Issue 6895</a>)

* Added implicit scopes by making ''<<scope-start>>'' optional.

(<a href="https://github.com/w3c/csswg-drafts/issues/6606">Issue 6606</a>)

* Disallowed [=pseudo-elements=] in the ''@scope'' prelude.

(<a href="https://github.com/w3c/csswg-drafts/issues/7382">Issue 7382</a>)

* Removed selector scoping notation.

(<a href="https://github.com/w3c/csswg-drafts/issues/7709">Issue 7709</a>)

* [=Scoping limit=] elements are excluded from the resulting [=scope=].

(<a href="https://github.com/w3c/csswg-drafts/issues/6577">Issue 6577</a>)

<h3 id="additions-l5">

Additions Since Level 5</h3>

The following features have been added since

<a href="https://www.w3.org/TR/css-cascade-5/">Level 5</a>:

* The definition of a [=scope=],

as described by a combination of <<scope-start>> and <<scope-end>> selectors.

* The in-scope ('':in()'') pseudo-class for selecting with lower-boundaries

* The ''@scope'' rule for creating scoped stylesheets

* The definition of [=scope proximity=] in the cascade

<h3 id="additions-l4">

Additions Since Level 4</h3>

The following features have been added since

<a href="https://www.w3.org/TR/css-cascade-4/">Level 4</a>:

* Added [=cascade layers=] to the [=cascade=] sort criteria

(and defined style attributes as a distinct step of the [=cascade=] sort criteria

so that they interact appropriately).

* Introduced the ''@layer'' rule for defining cascade layers.

* Added ''layer''/''layer()'' option to ''@import'' definition.

* Introduced the ''revert-layer'' keyword for rolling back values to previous layers.

<h3 id="additions-l3">

Additions Since Level 3</h3>

The following features have been added since

<a href="https://www.w3.org/TR/css-cascade-3/">Level 3</a>:

* Introduced ''revert'' keyword, for rolling back the cascade.

* Introduced ''supports()'' syntax for supports-conditional ''@import'' rules.

* Added [=encapsulation context=] to the [=cascade=] sort criteria

to accommodate Shadow DOM. [[DOM]]

* Defined the property two aliasing mechanisms CSS uses to support legacy syntaxes. See [[css-cascade-4#aliasing]].

<!--

* Added definition of how scoped styles would cascade

(deferred from Level 3)

-->

<h3 id="changes-2">

Additions Since Level 2</h3>

The following features have been added since

<a href="http://www.w3.org/TR/CSS2/cascade.html">Level 2</a>:

<ul>

<li>The 'all' shorthand

<li>The ''initial'' keyword

<li>The ''unset'' keyword

<li>Incorporation of animations and transitions into the <a>cascade</a>.

</ul>

<h2 class="no-num" id="acknowledgments">Acknowledgments</h2>

David Baron,

Tantek Çelik,

Keith Grant,

Giuseppe Gurgone,

Theresa O'Connor,

Florian Rivoal,

Noam Rosenthal,

Simon Sapin,

Jen Simmons,

Nicole Sullivan,

Lea Verou,

and Boris Zbarsky

contributed to this specification.

<h2 id="privacy">

Privacy Considerations</h2>

* User preferences and UA defaults expressed via application of style rules

are exposed by the cascade process,

and can be inferred from the computed styles they apply to a document.

<h2 id="security">

Security Considerations</h2>

* The cascade process does not distinguish between same-origin and cross-origin stylesheets,

enabling the content of cross-origin stylesheets to be inferred

from the computed styles they apply to a document.

* The ''@import'' rule does not apply the [=CORS protocol=] to loading cross-origin stylesheets,

instead allowing them to be freely imported and applied.

* The ''@import'' rule assumes that resources without <a href="https://html.spec.whatwg.org/multipage/urls-and-fetching.html#content-type"><code>Content-Type</code> metadata</a>

(or any same-origin file if the host document is in quirks mode)

are <code>text/css</code>,

potentially allowing arbitrary files to be imported into the page

and interpreted as CSS,

potentially allowing sensitive data to be inferred from the computed styles they apply to a document.