> in its prelude.
For example, the following rule
@supports ( display: flex ) {
body, #navigation, #content { display: flex; }
#navigation { background: blue; color: white; }
#article { background: white; color: black; }
}
applies the rules inside the ''@supports'' rule only when
''display: flex'' is supported.
The following example shows an additional ''@supports'' rule that can
be used to provide an alternative for when ''display: flex'' is not
supported:
@supports not ( display: flex ) {
body { width: 100%; height: 100%; background: white; color: black; }
#navigation { width: 25%; }
#article { width: 75%; }
}
Note that the 'width' declarations may be harmful to the
flex-based layout, so it is important that they be present only in
the non-flex styles.
The following example checks for support for the 'box-shadow'
property, including checking for support for vendor-prefixed versions of
it. When the support is present, it specifies both 'box-shadow' (with
the prefixed versions) and 'border' in a way what would cause the box to
become invisible were 'box-shadow' not supported.
.noticebox {
border: 1px solid black;
padding: 1px;
}
@supports ( box-shadow: 0 0 2px black inset ) or
( -moz-box-shadow: 0 0 2px black inset ) or
( -webkit-box-shadow: 0 0 2px black inset ) or
( -o-box-shadow: 0 0 2px black inset ) {
.noticebox {
-moz-box-shadow: 0 0 2px black inset;
-webkit-box-shadow: 0 0 2px black inset;
-o-box-shadow: 0 0 2px black inset;
box-shadow: 0 0 2px black inset; /* unprefixed last */
/* override the rule above the @supports rule */
border: none;
padding: 2px;
}
}
To avoid confusion between and and or, the syntax requires
that both and and or be specified explicitly (rather than, say,
using commas or spaces for one of them). Likewise, to avoid confusion
caused by precedence rules, the syntax does not allow and, or,
and not operators to be mixed without a layer of parentheses.
For example, the following rule is not valid:
@supports (transition-property: color) or
(animation-name: foo) and
(transform: rotate(10deg)) {
// ...
}
Instead, authors must write one of the following:
@supports ((transition-property: color) or
(animation-name: foo)) and
(transform: rotate(10deg)) {
// ...
}
@supports (transition-property: color) or
((animation-name: foo) and
(transform: rotate(10deg))) {
// ...
}
The declaration being tested must always occur within parentheses,
when it is the only thing in the expression.
For example, the following rule is not valid:
@supports display: flex {
// ...
}
Instead, authors must write:
@supports (display: flex) {
// ...
}
The syntax allows extra parentheses when they are not needed. This
flexibility is sometimes useful for authors (for example, when
commenting out parts of an expression) and may also be useful for
authoring tools.
For example, authors may write:
@supports ((display: flex)) {
// ...
}
A trailing ''!important'' on a declaration being tested is allowed,
though it won't change the validity of the declaration.
For example, the following rule is valid:
@supports (display: flex !important) {
// ...
}
Definition of support
For forward-compatibility,
section 4.1.8
(Declarations and properties) of [[!CSS21]]
defines rules for handling invalid properties and values.
CSS processors that
do not implement or partially implement a specification
must treat any part of a value that they
do not implement, or
do not have a usable level of support for,
as invalid according to this rule
for handling invalid properties and values,
and therefore must discard the declaration as a parse error.
A CSS processor is considered to support
a declaration (consisting of a property and value) if it accepts that
declaration (rather than discarding it as a parse error).
If a processor does not implement, with a usable level of support,
the value given,
then it must not
accept the declaration or claim support for it.
Note: Note that properties or values
whose support is effectively disabled by user preferences
are still considered as supported by this definition.
For example, if a user has enabled a high-contrast mode
that causes colors to be overridden,
the CSS processor is still considered to support the 'color' property
even though declarations of the 'color' property may have no effect.
On the other hand, a developer-facing preference
whose purpose is to enable or disable support for an experimental CSS feature
does affect this definition of support.
These rules (and the equivalence between them) allow
authors to use fallback (either in the [[CSS1]] sense of declarations
that are overridden by later declarations or with the new capabilities
provided by the ''@supports'' rule in this specification) that works
correctly for the features implemented. This applies especially to
compound values; implementations must implement all parts of the value
in order to consider the declaration supported, either inside a style rule
or in the declaration condition of an ''@supports'' rule.
APIs
Extensions to the CSSRule interface
The CSSRule interface is extended as follows:
partial interface CSSRule {
const unsigned short SUPPORTS_RULE = 12;
};
The CSSGroupingRule interface
The {{CSSGroupingRule}} interface represents an at-rule that contains other rules nested inside itself.
[Exposed=Window]
interface CSSGroupingRule : CSSRule {
readonly attribute CSSRuleList cssRules;
unsigned long insertRule (CSSOMString rule, unsigned long index);
void deleteRule (unsigned long index);
};
cssRules of type CSSRuleList, readonly
- The
cssRules attribute must return a CSSRuleList
object for the list of CSS rules nested inside the grouping rule.
insertRule(CSSOMString rule, unsigned long index), returns
unsigned long
-
The
insertRule operation must
insert a CSS rule rule
into the CSS rule list returned by cssRules,
such that the inserted rule will be at position index,
and any rules previously at index or higher
will increase their index by one.
It must throw INDEX_SIZE_ERR
if index is greater than cssRules.length.
It must throw SYNTAX_ERR
if rule has a syntax error and is unparseable;
this does not include syntax errors handled by error handling rules
for constructs inside of the rule,
but this does include cases where the string given
does not parse into a single CSS rule (such as when the string is empty)
or where there is anything other than whitespace or comments
after that single CSS rule.
It must throw HIERARCHY_REQUEST_ERR
if the rule cannot be inserted at the location specified,
for example, if an ''@import'' rule is inserted inside a group rule.
The return value is the index parameter.
deleteRule (unsigned long index), return void
-
The
deleteRule operation must
remove a CSS rule from
the CSS rule list returned by cssRules at index.
It must throw INDEX_SIZE_ERR
if index is greater than or equal to cssRules.length.
The CSSConditionRule interface
The {{CSSConditionRule}} interface represents
all the “conditional” at-rules,
which consist of a condition and a statement block.
[Exposed=Window]
interface CSSConditionRule : CSSGroupingRule {
attribute CSSOMString conditionText;
};
conditionText of type CSSOMString
-
The
conditionText attribute represents
the condition of the rule.
Since what this condition does
varies between the derived interfaces of CSSConditionRule,
those derived interfaces
may specify different behavior for this attribute
(see, for example, CSSMediaRule below).
In the absence of such rule-specific behavior,
the following rules apply:
The conditionText attribute, on getting, must return
the result of serializing the associated condition.
On setting the conditionText attribute these steps
must be run:
- Trim the given value of white space.
- If the given value matches the grammar of the
appropriate condition production for the given rule,
replace the associated CSS condition with the given value.
- Otherwise, do nothing.
The {{CSSMediaRule}} interface represents a ''@media'' at-rule:
[Exposed=Window]
interface CSSMediaRule : CSSConditionRule {
[SameObject, PutForwards=mediaText] readonly attribute MediaList media;
};
media of type {{MediaList}}, readonly
- The
media attribute must return a {{MediaList}} object
for the list of media queries specified with the ''@media'' at-rule.
conditionText of type CSSOMString (CSSMediaRule-specific definition for attribute on CSSConditionRule)
- The
conditionText attribute (defined on the CSSConditionRule parent rule),
on getting, must return the value of media.mediaText on the rule.
Setting the conditionText attribute
must set the media.mediaText attribute on the rule.
The CSSSupportsRule interface
The {{CSSSupportsRule}} interface represents a ''@supports'' rule.
[Exposed=Window]
interface CSSSupportsRule : CSSConditionRule {
};
conditionText of type CSSOMString (CSSSupportsRule-specific definition for attribute on CSSConditionRule)
- The
conditionText attribute (defined on the CSSConditionRule parent rule),
on getting, must return the condition that was specified,
without any logical simplifications,
so that the returned condition will evaluate to the same result
as the specified condition
in any conformant implementation of this specification
(including implementations that implement future extensions
allowed by the <> exensibility mechanism in this specification).
In other words,
token stream simplifications are allowed
(such as reducing whitespace to a single space
or omitting it in cases where it is known to be optional),
but logical simplifications (such as removal of unneeded parentheses,
or simplification based on evaluating results) are not allowed.
The CSS namespace, and the supports() function
The {{CSS}} namespace holds useful CSS-related functions that do not belong elsewhere.
partial namespace CSS {
boolean supports(CSSOMString property, CSSOMString value);
boolean supports(CSSOMString conditionText);
};
supports(CSSOMString property, CSSOMString value), returns boolean
supports(CSSOMString conditionText), returns boolean
-
When the {{supports(property, value)}} method is invoked
with two arguments property and value,
it must return
true if property is a literal match for the name of a CSS property that the UA supports,
and value would be successfully parsed as a supported value for that property.
(Literal match means that no CSS escape processing is performed,
and leading and trailing whitespace are not stripped,
so any leading whitespace, trailing whitespace,
or CSS escapes equivalent to the name of a property
would cause the method to return false.)
Otherwise, it must return false.
When {{supports(conditionText)}} invoked with a single conditionText argument,
it must return true if conditionText,
when either parsed and evaluated as a <>
or parsed as a <>,
wrapped in implied parentheses,
and evaluated as a <>,
would return true.
Otherwise, it must return false.
Privacy and Security Considerations
This spec introduces no new security considerations.
Various features in this specification,
associated mainly with the ''@media'' rule
but also to some degree with the ''@supports'' rule,
provide information to Web content about
the user's hardware and software and their configuration and state.
Most of the information is provided through the features in [[MEDIAQUERIES-4]]
rather than through the features in this specification.
However, the ''@supports'' rule may provide some additional details about the user's software
and whether it is running with non-default settings that may enable or disable certain features.
Most of this information can also be determined through other APIs.
However, the features in this specification are one of the ways this information
is exposed on the Web.
This information can also, in aggregate, be used to improve the accuracy of
fingerprinting of the user.
Changes
The following (non-editorial) changes were made to this specification since the
4 April 2013 Candidate Recommendation:
- Drop requirement for spaces around ''and'', ''or'', and ''not'' keywords
for consistency with Media Queries
(which are themselves constrained by compatibility with the output of some CSS minimizers
that rely on some of the more arcane aspects of CSS tokenization).
Note that white space--or a comment--is still required after these keywords,
since without it they and the ensuing opening parenthesis will be tokenized as a function opening token.
- Allow the
supports() method
to imply parentheses for simple declarations,
for consistency with the ''@import'' rule’s ''supports()'' function.
- Fixed missing semicolons in IDL code.
- Updated links, terminology, and example code in response to changes to other modules.
- Added section on privacy and security considerations.
Acknowledgments
Thanks to the ideas and feedback from
Tab Atkins,
Arthur Barstow,
Ben Callahan,
Tantek Çelik,
Alex Danilo,
Elika Etemad,
Pascal Germroth,
Björn Höhrmann,
Paul Irish,
Brad Kemper,
Anne van Kesteren,
Vitor Menezes,
Alex Mogilevsky,
Chris Moschini,
James Nurthen,
Simon Pieters,
Florian Rivoal,
Simon Sapin,
Nicholas Shanks,
Ben Ward,
Zack Weinberg,
Estelle Weyl,
Boris Zbarsky,
and all the rest of the www-style community.