1. Introduction
CSS defines a finite set of parameters, called properties, that direct the rendering of a document. Each property has a name (e.g., color, font-size, or border-style), a value space (e.g., <color>, <length-percentage>, [ solid | dashed | dotted | … ]), and a defined behavior on the rendering of the document. Properties values are assigned to various parts of the document via property declarations, which assign the property a value (e.g. red, 12pt, dotted) for the associated element or box.
One of the fundamental design principles of CSS is cascading, which allows several style sheets to influence the presentation of a document. When different declarations try to set a value for the same element/property combination, the conflicts must somehow be resolved.
The opposite problem arises when no declarations try to set a the value for an element/property combination. In this case, a value is be found by way of inheritance or by looking at the property’s initial value.
The cascading and defaulting process takes a set of declarations as input, and outputs a specified value for each property on each element.
The rules for finding the specified value for all properties on all elements in the document are described in this specification. The rules for finding the specified values in the page context and its margin boxes are described in [css-page-3].
1.1. Module Interactions
This section is normative.
This module replaces and extends the rules for assigning property values, cascading, and inheritance defined in [CSS2] chapter 6.
Other CSS modules may expand the definitions of some of the syntax and features defined here. For example, the Media Queries Level 4 specification, when combined with this module, expands the definition of the <media-query> value type as used in this specification.
For the purpose of this specification, text nodes are treated as element children of their associated element, and possess the full set of properties; since they cannot be targetted by selectors all of their computed values are assigned by defaulting.
2. Importing Style Sheets: the @import rule
The @import rule allows users to import style rules from other style sheets. If an @import rule refers to a valid stylesheet, user agents must treat the contents of the stylesheet as if they were written in place of the @import rule, with two exceptions:
-
If a feature (such as the @namespace rule) explicitly defines that it only applies to a particular stylesheet, and not any imported ones, then it doesn’t apply to the imported stylesheet.
-
If a feature relies on the relative ordering of two or more constructs in a stylesheet (such as the requirement that @namespace rules must not have any other rules other than @import preceding it), it only applies between constructs in the same stylesheet.
For example, declarations in style rules from imported stylesheets interact with the cascade as if they were written literally into the stylesheet at the point of the @import.
Any @import rules must precede all other valid at-rules and style rules in a style sheet (ignoring @charset), or else the @import rule is invalid. The syntax of @import is:
@import [ <url> | <string> ] [ supports( [ <supports-condition> | <declaration> ] ) ]? <media-query-list>? ;
where the <url> or <string> gives the URL of the style sheet to be imported, and the optional [<supports-condition>|<declaration>] and <media-query-list> (collectively, the import conditions) state the conditions under which it applies.
@import url("narrow.css") supports(display: flex) handheld and (max-width: 400px);
If a <string> is provided, it must be interpreted as a <url> with the same value.
@import "mystyle.css" ; @import url ( "mystyle.css" );
2.1. Conditional @import Rules
The import conditions allow the import to be media– or feature-support–dependent. In the absence of any import conditions, the import is unconditional. (Specifying all for the <media-query-list> has the same effect.) If the import conditions do not match, the rules in the imported stylesheet do not apply, exactly as if the imported stylesheet were wrapped in @media and/or @supports blocks with the given conditions.
@import url ( "fineprint.css" ) print; @import url ( "bluish.css" ) projection, tv; @import url ( "narrow.css" ) handheld and( max-width:400 px );
User agents may therefore avoid fetching a conditional import as long as the import conditions do not match. Additionally, if a <supports-condition> blocks the application of the imported style sheet, the UA must not fetch the style sheet (unless it is loaded through some other link) and must return null for the import rule’s CSSImportRule.styleSheet value (even if it is loaded through some other link).
@import url ( "fallback-layout.css" ) supports ( not( display: flex)); @supports ( display: flex) { ...}
A <media-query> corresponds to the media_query_list
production
and is interpreted as a media query,
and a <supports-condition> corresponds to a supports_condition
production
and is interpreted as an @supports condition.
If a <declaration> (a declaration
production) is given in place of a <supports-condition>,
it must be interpreted as a supports_declaration_condition
production
(i.e. the extra set of parentheses is implied)
and treated as a <supports-condition>.
@import "mystyle.css" supports ( display: flex); @import "mystyle.css" supports (( display: flex));
The evaluation and full syntax of the import conditions are defined by the Media Queries [MEDIAQ] and CSS Conditional Rules [CSS-CONDITIONAL-3] specifications.
2.2. Processing Stylesheet Imports
When the same style sheet is imported or linked to a document in multiple places, user agents must process (or act as though they do) each link as though the link were to an independent style sheet.
Note: This does not place any requirements on resource fetching, only how the style sheet is reflected in the CSSOM and used in specs such as this one. Assuming appropriate caching, it is perfectly appropriate for a UA to fetch a style sheet only once, even though it’s linked or imported multiple times.
The origin of an imported style sheet is the origin of the style sheet that imported it.
The environment encoding of an imported style sheet is the encoding of the style sheet that imported it. [css-syntax-3]
2.3. Content-Type of CSS Style Sheets
The processing of imported style sheets depends on the actual type of the linked resource:
-
If the resource does not have Content-Type metadata, the type is treated as
text/css
. -
If the host document is in quirks mode, and the host document’s origin is same origin with the linked resource response’s URL’s origin, the type is treated as
text/css
. -
Otherwise, the type is determined from its Content-Type metadata.
If the linked resource’s type is text/css
,
it must be interpreted as a CSS style sheet.
Otherwise, it must be interpreted as a network error.
3. Shorthand Properties
Some properties are shorthand properties, meaning that they allow authors to specify the values of several properties with a single property. A shorthand property sets all of its longhand sub-properties, exactly as if expanded in place.
When values are omitted from a shorthand form, unless otherwise defined, each “missing” sub-property is assigned its initial value.
For example, writing background: green rather than background-color: green ensures that the background color overrides any earlier declarations that might have set the background to an image with background-image.
h1{ font-weight : bold; font-size : 12 pt ; line-height : 14 pt ; font-family : Helvetica; font-variant : normal; font-style : normal; }
can therefore be rewritten as
h1{ font : bold12 pt /14 pt Helvetica}
As more font sub-properties are introduced into CSS, the shorthand declaration resets those to their initial values as well.
In some cases, a shorthand might have different syntax or special keywords that don’t directly correspond to values of its sub-properties. (In such cases, the shorthand will explicitly define the expansion of its values.)
In other cases, a property might be a reset-only sub-property of the shorthand: Like other sub-properties, it is reset to its initial value by the shorthand when unspecified, but the shorthand might not include syntax to set the sub-property to any of its other values. For example, the border shorthand resets border-image to its initial value of none, but has no syntax to set it to anything else. [css-backgrounds-3]
If a shorthand is specified as one of the CSS-wide keywords [css-values-3], it sets all of its sub-properties to that keyword, including any that are reset-only sub-properties. (Note that these keywords cannot be combined with other values in a single declaration, not even in a shorthand.)
Declaring a shorthand property to be !important is equivalent to declaring all of its sub-properties to be !important.
3.1. Aliasing
Properties sometimes change names after being supported for a while, such as vendor-prefixed properties being standardized. The original name still needs to be supported for compatibility reasons, but the new name is preferred. To accomplish this, CSS defines two different ways of “aliasing” old syntax to new syntax.
- legacy name aliases
-
When the old property’s syntax is identical to
or a subset of the value space of the new property’s syntax,
the two names are aliased with an operation on par with case-mapping:
at parse time, the old property is converted into the new property.
This conversion also applies in the CSSOM,
both for string arguments and property accessors:
requests for the old property name
transparently transfer to the new property name instead.
For example, if old-name is a legacy name alias for new-name,
getComputedStyle
will return the computed style of the( el). oldNamenewName
property, andel
will set the new-name property to. style. setPropertyValue( "old-name" , "value" )
."value" - legacy shorthands
-
When the old property has a distinct syntax from the new property,
the two names are aliased using the shorthand mechanism.
These shorthands are defined to be legacy shorthands,
and their use is deprecated.
They otherwise behave exactly as regular shorthands,
except that the CSSOM will not use them
when serializing declarations. [CSSOM]
For example, the page-break-* properties are legacy shorthands for the break-* properties (see CSS Fragmentation 3 §3.4 Page Break Aliases: the page-break-before, page-break-after, and page-break-inside properties).
Setting page-break-before: always expands to break-before: page at parse time, like other shorthands do. Similarly, if break-before: page is set, calling
getComputedStyle
will return( el). pageBreakBefore
. However, when serializing a style block (see CSSOM 1 §5.7.2 Serializing CSS Values), the page-break-before property will never be chosen as the shorthand to serialize to, regardless of whether it or break-before was specified; instead, break-before will always be chosen."always"
3.2. Resetting All Properties: the all property
Name: | all |
---|---|
Value: | initial | inherit | unset | revert |
Initial: | see individual properties |
Applies to: | see individual properties |
Inherited: | see individual properties |
Percentages: | see individual properties |
Computed value: | see individual properties |
Animation type: | see individual properties |
Canonical order: | per grammar |
The all property is a shorthand that resets all CSS properties except direction and unicode-bidi. It only accepts the CSS-wide keywords. It does not reset custom properties [css-variables-1].
Note: The excepted CSS properties direction and unicode-bidi are actually markup-level features,
and should not be set in the author’s style sheet.
(They exist as CSS properties only to style document languages not supported by the UA.)
Authors should use the appropriate markup, such as HTML’s dir
attribute, instead. [css-writing-modes-3]
This can be useful for the root element of a "widget" included in a page,
which does not wish to inherit the styles of the outer page.
Note, however, that any "default" style applied to that element
(such as, e.g. display: block from the UA style sheet on block elements such as <div>
)
will also be blown away.
4. Value Processing
Once a user agent has parsed a document and constructed a document tree, it must assign, to every element in the tree, and correspondingly to every box in the formatting structure, a value to every property that applies to the target media type.
The final value of a CSS property for a given element or box is the result of a multi-step calculation:
- First, all the declared values applied to an element are collected, for each property on each element. There may be zero or many declared values applied to the element.
- Cascading yields the cascaded value. There is at most one cascaded value per property per element.
- Defaulting yields the specified value. Every element has exactly one specified value per property.
- Resolving value dependencies yields the computed value. Every element has exactly one computed value per property.
- Formatting the document yields the used value. An element only has a used value for a given property if that property applies to the element.
- Finally, the used value is transformed to the actual value based on constraints of the display environment. As with the used value, there may or may not be an actual value for a given property on an element.
Elements that are not connected or are not part of the document’s flattened element tree do not participate in CSS value processing,
and do not have declared, cascaded, specified, computed, used, or actual values,
even if they potentially have style declarations assigned to them
(for example, by a style
attribute).
4.1. Declared Values
Each property declaration applied to an element contributes a declared value for that property associated with the element. See Filtering Declarations for details.
These values are then processed by the cascade to choose a single “winning value”.
4.2. Cascaded Values
The cascaded value represents the result of the cascade: it is the declared value that wins the cascade (is sorted first in the output of the cascade). If the output of the cascade is an empty list, there is no cascaded value.
4.3. Specified Values
The specified value is the value of a given property that the style sheet authors intended for that element. It is the result of putting the cascaded value through the defaulting processes, guaranteeing that a specified value exists for every property on every element.
In many cases, the specified value is the cascaded value. However, if there is no cascaded value at all, the specified value is defaulted. The CSS-wide keywords are handled specially when they are the cascaded value of a property, setting the specified value as required by that keyword, see § 7.3 Explicit Defaulting.
4.4. Computed Values
The computed value is the result of resolving the specified value as defined in the “Computed Value” line of the property definition table, generally absolutizing it in preparation for inheritance.
Note: The computed value is the value that is transferred from parent to child during inheritance.
For historical reasons,
it is not necessarily the value returned by the getComputedStyle()
function,
which sometimes returns used values. [CSSOM] Furthermore, the computed value is an abstract data representation:
their definitions reflect that data representation,
not how that data is serialized.
For example, serialization rules often allow omitting certain values which are implied during parsing;
but those values are nonetheless part of the computed value.
- values with relative units (em, ex, vh, vw) must be made absolute by multiplying with the appropriate reference size
- certain keywords (e.g., smaller, bolder) must be replaced according to their definitions
- percentages on some properties must be multiplied by a reference value (defined by the property)
- valid relative URLs must be resolved to become absolute.
See examples (f), (g) and (h) in the table below.
Note: In general, the computed value resolves the specified value as far as possible without laying out the document or performing other expensive or hard-to-parallelize operations, such as resolving network requests or retrieving values other than from the element and its parent.
The computed value exists even when the property does not apply. However, some properties may change how they determine the computed value based on whether the property applies to the element.
4.5. Used Values
The used value is the result of taking the computed value and completing any remaining calculations to make it the absolute theoretical value used in the formatting of the document.
For example, a declaration of width: auto can’t be resolved into a length without knowing the layout of the element’s ancestors, so the computed value is auto, while the used value is an absolute length, such as 100px. [CSS2]
As another example, a <div>
might have a computed break-before value of auto,
but acquire a used break-before value of page by propagation from its first child. [css-break-3]
If a property does not apply to this element or box type—
For example, the flex property has no used value on elements that aren’t flex items.
Note: A property defined to apply to “all elements” applies to all elements and display types, but not necessarily to all pseudo-element types, since pseudo-elements often have their own specific rendering models or other restrictions. The ::before and ::after pseudo-elements, however, are defined to generate boxes almost exactly like normal elements and are therefore defined accept all properties that apply to “all elements”. See [CSS-PSEUDO-4] for more information about pseudo-elements.
4.6. Actual Values
A used value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the used width. Also, the font size of an element may need adjustment based on the availability of fonts or the value of the font-size-adjust property. The actual value is the used value after any such adjustments have been made.
Note: By probing the actual values of elements, much can be learned about how the document is laid out. However, not all information is recorded in the actual values. For example, the actual value of the page-break-after property does not reflect whether there is a page break or not after the element. Similarly, the actual value of orphans does not reflect how many orphan lines there is in a certain element. See examples (j) and (k) in the table below.
4.7. Examples
Property | Winning declaration | Cascaded value | Specified value | Computed value | Used value | Actual value | |
---|---|---|---|---|---|---|---|
(a) | text-align | text-align: left
| left | left | left | left | left |
(b) | border-top-width, border-right-width, border-bottom-width, border-left-width | border-width: inherit
| inherit | 4.2px | 4.2px | 4.2px | 4px |
(c) | width | (none) | (none) | auto (initial value) | auto | 120px | 120px |
(d) | list-style-position | list-style-position: inherit
| inherit | inside | inside | inside | inside |
(e) | list-style-position | list-style-position: initial
| initial | outside (initial value) | outside | outside | outside |
(f) | font-size | font-size: 1.2em
| 1.2em | 1.2em | 14.1px | 14.1px | 14px |
(g) | width | width: 80%
| 80% | 80% | 80% | 354.2px | 354px |
(h) | width | width: auto
| auto | auto | auto | 134px | 134px |
(i) | height | height: auto
| auto | auto | auto | 176px | 176px |
(j) | page-break-after | (none) | (none) | auto (initial value) | auto | auto | auto |
(k) | orphans | orphans: 3
| 3 | 3 | 3 | 3 | 3 |
5. Filtering
In order to find the declared values, implementations must first identify all declarations that apply to each element. A declaration applies to an element if:
- It belongs to a style sheet that currently applies to this document.
- It is not qualified by a conditional rule [CSS-CONDITIONAL-3] with a false condition.
- It belongs to a style rule whose selector matches the element. [SELECT]
- It is syntactically valid: the declaration’s property is a known property name, and the declaration’s value matches the syntax for that property.
The values of the declarations that apply form, for each property on each element, a list of declared values. The next section, the cascade, prioritizes these lists.
6. Cascading
The cascade takes an unordered list of declared values for a given property on a given element, sorts them by their declaration’s precedence as determined below, and outputs a single cascaded value.
6.1. Cascade Sorting Order
The cascade sorts declarations according to the following criteria, in descending order of priority:
- Origin and Importance
-
The origin of a declaration is based on where it comes from
and its importance is
whether or not it is declared with !important (see below).
The precedence of the various origins is, in descending order:
- Transition declarations [css-transitions-1]
- Important user agent declarations
- Important user declarations
- Important author declarations
- Animation declarations [css-animations-1]
- Normal author declarations
- Normal user declarations
- Normal user agent declarations
Declarations from origins earlier in this list win over declarations from later origins.
- Context
-
A document language can provide for blending declarations sourced
from different encapsulation contexts,
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.
- The Style Attribute
- Separately for normal and important declarations, declarations that are attached directly to an element (such as the contents of a style attribute) rather than indirectly mapped by means of a style rule selector take precedence over declarations the same importance that are mapped via style rule.
- Layers
-
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 ordered by order of appearance. When comparing declarations that belong to different layers, then for normal rules the declaration whose cascade layer is last wins, and for important rules the declaration whose cascade layer is first wins.
Note: This follows the same logic used for layering normal and important origins, so that the !important flag maintains the same “override” purpose in both settings.
- 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.
- Order of Appearance
-
The last declaration in document order wins.
For this purpose:
- Declarations from imported style sheets are ordered as if their style sheets were substituted in place of the @import rule.
- 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.
- 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.
The output of the cascade is a (potentially empty) sorted list of declared values for each property on each element.
6.2. Cascading Origins
Each style rule has a cascade origin, which determines where it enters the cascade. CSS defines three core origins:
- Author Origin
- The author specifies style sheets for a source document according to the conventions of the document language. For instance, in HTML, style sheets may be included in the document or linked externally.
- User Origin
- The user may be able to specify style information for a particular document. For example, the user may specify a file that contains a style sheet or the user agent may provide an interface that generates a user style sheet (or behaves as if it did).
- User-Agent Origin
- Conforming user agents must apply a default style sheet (or behave as if they did). A user agent’s default style sheet should present the elements of the document language in ways that satisfy general presentation expectations for the document language (e.g., for visual browsers, the EM element in HTML is presented using an italic font). See e.g. the HTML user agent style sheet. [HTML]
Extensions to CSS define the following additional origins:
- Animation Origin
- CSS Animations [css-animations-1] generate “virtual” rules representing their effects when running.
- Transition Origin
- Like CSS Animations, CSS Transitions [css-transitions-1] generate “virtual” rules representing their effects when running.
6.3. Important Declarations: the !important annotation
CSS attempts to create a balance of power between author and user style sheets. By default, rules in an author’s style sheet override those in a user’s style sheet, which override those in the user-agent’s default style sheet. To balance this, a declaration can be marked important, which increases its weight in the cascade and inverts the order of precedence.
A declaration is important if it has a !important annotation as defined by [css-syntax-3], i.e. if the last two (non-whitespace, non-comment) tokens in its value are the delimiter token ! followed by the identifier token important. All other declarations are normal (non-important).
An important declaration takes precedence over a normal declaration. Author and user style sheets may contain important declarations, with user-origin important declarations overriding author-origin important declarations. This CSS feature improves accessibility of documents by giving users with special requirements (large fonts, color combinations, etc.) control over presentation.
Important declarations from all origins take precedence over animations. This allows authors to override animated values in important cases. (Animated values normally override all other rules.) [css-animations-1]
User-agent style sheets may also contain important declarations. These override all author and user declarations.
/* From the user’s style sheet */ p{ text-indent : 1 em !important} p{ font-style : italic !important} p{ font-size : 18 pt } /* From the author’s style sheet */ p{ text-indent : 1.5 em !important} p{ font : normal12 pt sans-serif !important} p{ font-size : 24 pt }
Property | Winning value |
---|---|
text-indent | 1em |
font-style | italic |
font-size | 12pt |
font-family | sans-serif |
6.4. Cascade Layers
In the same way that cascade origins provide a balance of power
between user and author styles, cascade layers provide a structured way
to organize and balance concerns within a single origin.
Authors can create layers to represent element defaults,
third-party libraries, themes, components,
overrides, and other styling concerns—
audio{ /* specificity of 0,0,1 - implicit (final) layer */ display: flex; } @layer defaults{ audio[ controls] { /* specificity of 0,1,1 - explicit "defaults" layer */ display: block; } }
The un-layered declarations on the audio
element take precedence
over the explicitly layered declarations on audio[controls] —
Do we need a keyword similar to `revert`, but for cascade layers? <https://github.com/w3c/csswg-drafts/issues/5793>
6.4.1. Declaring Cascade Layers: the @layer rule
The @layer rule defines an explicit cascade layer, with the option to assign style rules as either a block or an import.
The import syntax is:
@layer <layer-ident>? <url>;
Such @layer import rules have the same restrictions and processing as @import (see § 2 Importing Style Sheets: the @import rule), except that the imported rules are assigned to the indicated layer.
Is @layer the proper way to handle layered url imports? <https://github.com/w3c/csswg-drafts/issues/5681>
The block syntax is:
@layer <layer-ident>? { <stylesheet> }
Such @layer block rules have the same restrictions and processing as a conditional rule [CSS-CONDITIONAL-3] with a true condition.
In both cases the optional <layer-ident> is a CSS identifier (<ident>) that represents its layer name. If the layer name matches that of a cascade layer already defined within this origin and context (and same layer scope, see § 6.4.1.1 Nested Layers), then its style rules are assigned to that same cascade layer. Otherwise, or if no <layer-ident> is provided, a new cascade layer is created.
Note: Layer name matching does not cross the shadow DOM boundary, so the ordering of layers in the light DOM has no impact on the order of identically-named layers in the shadow DOM.
Provide a syntax for re-using cascade layers across encapsulation context? <https://github.com/w3c/csswg-drafts/issues/5854>
The @layer rule can also be used to define new layers without assigning any style rules, by providing only a layer name:
@layer <layer-ident>#;
Such empty @layer are allowed anywhere either import @layer or block @layer rules are allowed.
Provide an attribute for assigning link or style elements to cascade layers <https://github.com/w3c/csswg-drafts/issues/5853>
headings.css
and links.css
are cascaded within the same layer as the audio[controls]
rule:
@layer defaulturl ( headings.css ); @layer defaulturl ( links.css ); @layer default{ audio[ controls] { display : block; } }
In this example,
the imported theme.css
style rules will override
any rules added in the later default block
since the order of layers has already been established.
@layer default; @layer theme; @layer components; @layer themeurl ( theme.css ); @layer default{ audio[ controls] { display : block; } }
It can also be written with the comma-separated syntax as:
@layer default, theme, components; @layer themeurl ( theme.css ); @layer default{ audio[ controls] { display : block; } }
6.4.1.1. Nested Layers
When @layer rules are nested, layer names are scoped to their parent layer.
@layer default{ p{ max-width : 70 ch ; } } @layer framework{ @layer default{ p{ margin-block : 0.75 em ; } } @layer theme{ p{ color : #222; } } }
The resulting layers can be represented as a tree:
-
default
-
framework
-
default
-
theme
-
or as a flat list with nested identifiers:
-
default
-
framework default
-
framework theme
It is not possible for nested layers to reference a layer name in an outer layer’s scope, but it is possible to reference nested layers from an outer scope, by combining identifiers with a full stop (. U+002E) character.
@layer framework{ @layer default{ p{ margin-block : 0.75 em ; } } @layer theme{ p{ color : #222; } } } @layer framework.theme{ /* These styles will be added to the theme layer inside the framework layer */ blockquote{ color : rebeccapurple; } }
This syntax is provided as a shorthand for defining nested layers, and has the same effect as declaring each layer name inside nested @layer rules.
The following example defines framework.theme before framework.default:
@layer framework.theme{ blockquote{ color : rebeccapurple; } } @layer framework{ @layer default{ p{ margin-block : 0.75 em ; } } @layer theme{ p{ color : #222; } } }
The framework.theme shorthand is purely syntax sugar for the following longhand:
@layer framework{ @layer theme{ blockquote{ color : rebeccapurple; } } }
What is the appropriate syntax for appending to nested layers? <https://github.com/w3c/csswg-drafts/issues/5791>
6.4.1.2. Un-Named Layers
In most use-cases this would only be syntax-sugar for brevity —
/* bootstrap-base.css */ /* unnamed wrapper layers around each sub-file */ @layer url ( base-forms.css ); @layer url ( base-links.css ); @layer url ( base-headings.css ); /* bootstrap.css */ /* the intrnal names are hidden from access, subsumed in "base" */ @layer baseurl ( bootstrap-base.css ); /* author.css */ /* author has access to bootstrap.base layer, but not into unnamed layers */ @layer bootstrapurl ( bootstrap.css );
Should unnamed cascade layers be allowed? <https://github.com/w3c/csswg-drafts/issues/5792>
6.5. Precedence of Non-CSS Presentational Hints
The UA may choose to honor presentational hints in a source document’s markup,
for example the bgcolor
attribute or s
element in [HTML].
All document language-based styling must be translated to corresponding CSS rules
and either enter the cascade as UA-origin rules or
be treated as author-origin rules with a specificity of zero
placed at the start of the .
A document language may define whether such a presentational hint
enters the cascade as UA-origin or ;
if so, the UA must behave accordingly.
For example, [SVG11] maps its presentation attributes into the author level.
Note: Presentational hints entering the cascade as UA-origin rules can be overridden by author-origin or user-origin styles. Presentational hints entering the cascade as rules can be overridden by styles, but not by non-important user-origin styles. Host languages should choose the appropriate origin for presentational hints with these considerations in mind.
7. Defaulting
When the cascade does not result in a value, the specified value must be found some other way. Inherited properties draw their defaults from their parent element through inheritance; all other properties take their initial value. Authors can explicitly request inheritance or initialization via the inherit and initial keywords.
7.1. Initial Values
Each property has an initial value, defined in the property’s definition table. If the property is not an inherited property, and the cascade does not result in a value, then the specified value of the property is its initial value.
7.2. Inheritance
Inheritance propagates property values from parent elements to their children. The inherited value of a property on an element is the computed value of the property on the element’s parent element. For the root element, which has no parent element, the inherited value is the initial value of the property.
For a [DOM] tree with shadows,
inheritance operates on the flattened element tree. This means that slotted elements inherit from the slot
they’re assigned to,
rather than directly from their light tree parent. Pseudo-elements inherit according to the fictional tag sequence
described for each pseudo-element. [CSS-PSEUDO-4]
Some properties are inherited properties, as defined in their property definition table. This means that, unless the cascade results in a value, the value will be determined by inheritance.
A property can also be explicitly inherited. See the inherit keyword.
Note: Inheritance follows the document tree and is not intercepted by anonymous boxes, or otherwise affected by manipulations of the box tree.
7.3. Explicit Defaulting
Several CSS-wide property values are defined below; declaring a property to have these values explicitly specifies a particular defaulting behavior. As specified in CSS Values and Units Level 3 [css-values-3], all CSS properties can accept these values.
7.3.1. Resetting a Property: the initial keyword
If the cascaded value of a property is the initial keyword, the property’s specified value is its initial value.
7.3.2. Explicit Inheritance: the inherit keyword
If the cascaded value of a property is the inherit keyword, the property’s specified and computed values are the inherited value.
7.3.3. Erasing All Declarations: the unset keyword
If the cascaded value of a property is the unset keyword, then if it is an inherited property, this is treated as inherit, and if it is not, this is treated as initial. This keyword effectively erases all declared values occurring earlier in the cascade, correctly inheriting or not as appropriate for the property (or all longhands of a shorthand).
7.3.4. Rolling Back The Cascade: the revert keyword
If the cascaded value of a property is the revert keyword, the behavior depends on the cascade origin to which the declaration belongs:
- user-agent origin
- Equivalent to unset.
- user origin
- Rolls back the cascaded value to the user-agent level, so that the specified value is calculated as if no author-origin or user-origin rules were specified for this property on this element.
- author origin
- Rolls back the cascaded value to the user level, so that the specified value is calculated as if no author-origin rules were specified for this property on this element. For the purpose of revert, this origin includes the Animation origin.
8. Changes
8.1. Additions Since Level 4
The following features have been added since Level 4:
-
Added cascade layers to the cascade sort criteria.
-
Defined style attributes as a distinct step of the cascade sort criteria.
-
Introduced the @layer rule for defining cascade layers
-
Introduced the @layers rule for defining and re-ordering multiple layers
8.2. Additions Since Level 3
The following features have been added since Level 3:
-
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 See § 3.1 Aliasing.
8.3. Additions Since Level 2
The following features have been added since Level 2:
- The all shorthand
- The initial keyword
- The unset keyword
- Incorporation of animations and transitions into the cascade.
Acknowledgments
David Baron, Tantek Çelik, Florian Rivoal, Simon Sapin, Jen Simmons, and Boris Zbarsky contributed to this specification.
Privacy and Security Considerations
-
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.
-
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.
-
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
Content-Type
metadata (or any same-origin file if the host document is in quirks mode) aretext/css
, 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.