CSS Properties and Values API Level 1

1. Introduction

CSS defines a comprehensive set of properties that can be manipulated in order to modify the layout, paint, or behaviour of a web document. However, web authors frequently wish to extend this set with additional properties.

[css-variables] provides primitive means for defining user-controlled properties, however these properties always take token lists as values, must always inherit, and can only impact document layout or paint by being re-incorporated into the value of other properties via a var() reference.

This specification extends [css-variables], allowing the registration of properties that have a value type, an initial value, and a defined inheritance behaviour.

This specification is complementary to [css-paint-api] and [css-layout-api], which allow custom properties to directly impact paint and layout behaviours respectively.

2. Registering custom properties

dictionary PropertyDescriptor {
  required DOMString name;
           DOMString syntax       = "*";
           boolean   inherits     = false;
           DOMString initialValue;
};

partial interface CSS {
  void registerProperty(PropertyDescriptor descriptor);
  void unregisterProperty(DOMString name);
};

2.1. The PropertyDescriptor dictionary

A PropertyDescriptor dictionary represents author-specified configuration options for a custom property. PropertyDescriptor dictionaries contain the following members:

name, of type DOMString

The name of the custom property being defined.

syntax, of type DOMString, defaulting to "*"

A string representing how this custom property is parsed.

inherits, of type boolean, defaulting to false

True if this custom property should inherit down the DOM tree; False otherwise.

initialValue, of type DOMString

The initial value of this custom property.

2.2. The registerProperty() function

The registerProperty(PropertyDescriptor descriptor) method registers a custom property according the to configuration options provided in descriptor.

Attempting to register properties with a name that doesn’t correspond to the production must cause registerProperty() to throw a SyntaxError.

The list of types supported in the syntax member are listed in §2.3 Supported syntax strings. Currently, only simple type references are supported. Attempting to register properties with a syntax that is not supported must cause registerProperty() to throw a SyntaxError.

Note: for example, the syntax string could be "" or "".

Note: in future levels we anticipate supporting more sophisticated parse strings, e.g. " || "

Attempting to call registerProperty() with an initialValue that is not parseable using the provided syntax must cause it to throw a SyntaxError. If no initialValue is provided and the syntax is *, then a special initial value used. This initial value must be considered parseable by registerProperty() but invalid at computed value time. Initial values that are not computationally idempotent must also cause registerProperty() to throw a SyntaxError.

define computational idempotency.

Is computational idempotency the right thing to do here? We could also just resolve any relative values once (against all the other initial values) and use that. OR! We could allow specified values and just fix our engines...

When a custom property is registered with a given type, the process via which specified values for that property are turned into computed values is defined fully by the type selected, as described in §2.4 Calculation of Computed Values.

If registerProperty() is called with a descriptor name that matches an already registered property, then an InvalidModificationError is thrown and the re-registration fails.

Properties can be unregistered using unregisterProperty(DOMString name). If this function is called with a name that doesn’t match an existing property then a NotFoundError is thrown.

Successful calls to both registerProperty() and unregisterProperty() change the set of registered properties. When the set of registered properties changes, previously syntactically invalid property values can become valid and vice versa. This can change the set of declared values which requires the cascade to be recomputed.

.thing {
  --my-color: green;
  --my-color: url("not-a-color");
  color: var(--my-color);
}

registerProperty({
name: "--my-color",
syntax: ""
});

2.3. Supported syntax strings

The following syntax strings are supported:

""

Any valid value

""

values

""

Any valid value

""

Any valid or value, any valid expression combining and components.

""

Any valid value

""

Any valid value

""

Any valid value

""

Any valid value

""

Any valid value

""

Any valid value

""

Any valid value

""

Any valie value

""

Any valid value

Any string, the contents of which matches the production

That identifier

Any one of the preceding strings, followed by '+'

A list of values of the type specified by the string

Any combination of the preceding, separated by '|'

Any value that matches one of the items in the combination, matched in specified order.

"*"

Any valid token stream

Note: [css3-values] maintains a distinction between properties that accept only a length, and properties that accept both a length and a percentage, however the distinction doesn’t currently cleanly line up with the productions. Accordingly, this specification introduces the length-percentage production for the purpose of cleanly specifying this distinction.

Regardless of the syntax specified, all custom properties will accept CSS-wide keywords as well as revert, and process these values appropriately.

Note: This does not apply to the initialValue member of the PropertyDescriptor dictionary.

2.4. Calculation of Computed Values

The syntax of a custom property fully determines how computed values are generated from specified values for that property.

The CSS-wide keywords and revert generate computed values as described in [css3-values] and [css-cascade-4] respectively. Otherwise:

For values, the computed value is the absolute length expressed in pixels.

For values, the computed value is one of the following:

• if the specified value contains only length units, the computed value is the absolute length expressed in pixels.

• if the specified value contains only percentages, the computed value is a simple percentage.

• otherwise, the computed value is a calc expression containing an absolute length expressed in pixels, and a percentage value.

For , ident, , , , , , , , or "*" values, the computed value is identical to the specified value.

For and values which are not calc expressions, the computed value is identical to the specified value. Calc expressions that are and values get reduced during computation to simple numbers and percentages respectively.

For values specified by a syntax string that include "|" clauses, the computed value is given by applying the calculation rules for the first clause that matches to the specified value.

For list values, the computed value is a list of the computed values of the primitives in the list.

3. Behavior of Custom Properties

3.1. Animation Behavior of Custom Properties

Note: As defined by [css3-animations] and [css3-transitions], it is possible to specify animations and transitions that reference custom properties.

When referenced by animations and transitions, custom properties interpolate in a manner defined by their types. If the start and end of an interpolation have matching types, then they will interpolate as specified in [css3-animations]. Otherwise, the interpolation falls back to the default 50% flip described in [css3-animations].

Intermediate interpolated results of animations on custom properties must be able to generate a token stream representing their value. We should ensure that this is standard across implementations to avoid interop issues.

3.2. Conditional Rules

@supports rules and the supports(conditionText) method behave as specified in [css-variables].

Note: In other words, for the purpose of determining whether a value is supported by a given custom property, the type registered for the custom property is ignored and any value consisting of at least one token is considered valid.

should @supports pay attention to type when considering custom properties?

4. Examples

4.1. Example 1: Using custom properties to add animation behavior

<script>
CSS.registerProperty({
  name: "--stop-color",
  syntax: "",
  inherits: false,
  initialValue: "rgba(0,0,0,0)"
});
script>

<style>

.button {
  --stop-color: red;
  background: linear-gradient(var(--stop-color), black);
  transition: --stop-color 1s;
}

.button:hover {
  --stop-color: green;
}

style>

5. Security Considerations

There are no known security issues introduced by these features.

6. Privacy Considerations

There are no known privacy issues introduced by these features.