W3C

Motion Path Module Level 1

W3C First Public Working Draft,

This version:
http://www.w3.org/TR/2015/WD-motion-1-20150409/
Latest version:
http://www.w3.org/TR/motion-1/
Editor's Draft:
http://dev.w3.org/fxtf/motion-1/
Feedback:
public-fx@w3.org with subject line “[motion] … message topic …” (archives)
Issue Tracking:
Inline In Spec
Editors:
(Adobe Systems Inc.)
(Google)

Abstract

Motion paths allow authors to animate any graphical object along an author specified path.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a First Public Working Draft.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The (archived) public mailing list public-fx@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “motion” in the subject, preferably like this: “[motion] …summary of comment…

This document was produced by the CSS Working Group (part of the Style Activity) and the SVG Working Group (part of the Graphics Activity).

This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures (CSS) and a public list of any patent disclosures (SVG) made in connection with the deliverables of each group; these pages also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 August 2014 W3C Process Document.

Table of Contents

1. Introduction

This section is not normative.

Authors have possibilities to position objects like elements, boxes or containers relative to each other or absolutely in their own coordinate system. CSS Transforms extends these possibilities with a set of transform functions allowing authors to mutate the object’s local coordinate system. With CSS Animations and CSS Transitions, these static placements can change over a given period of time. Both kind of animations are powerful to express transitions in time but not suitable to describe transitions of location of an object over time.

This specification allows authors to specify an motion path. The object can be transitioned along this motion path over a given period of time. The time may be static if no animation was specified.

In the following example, a schematic of an air plane is animated along a motion path. The plane faces in the direction of the motion path at each position on the path.

Example Motion Path

A black plane at different positions on a blue dotted motion path, rotated in the direction of the path.

A motion path may consist of a <basic-shape> like <circle()>, <inset()> or <polygon()>. To allow authors to specify curves and sub-paths, this specification adds the <path()> function in addition to the existing <basic-shape> functions. The <path()> function takes an SVG Path string as input [SVG2]. As a third option, authors may reference an SVG shape element by <url> which is used as the motion path.

2. Module interactions

This specification defines a set of CSS properties that affect the visual rendering of elements to which those properties are applied. These effects are applied after elements have been sized and positioned according to the Visual formatting model from [CSS21]. Some values of these properties result in the creation of a stacking context.

Some CSS properties in this specification manipulate the user coordinate system of the element by transformations. These transformations are pre-multiplied to transformations specified by the transform property or deriving properties.

The term object bounding box follows the definition in SVG 1.1 [SVG11].

3. Values

This specification follows the CSS property definition conventions from [CSS21]. Basic shapes are defined in CSS Shapes Module Level 1 [CSS-SHAPES]. Value types not defined in these specifications are defined in CSS Values and Units Module Level 3 [CSS3VAL]. Basic shapes are extended by the <path()> basic shape function.

In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept CSS-wide keywords such as inherit as their property value [CSS3VAL]. For readability it has not been repeated explicitly.

4. Motion Paths

Add more details and examples.

4.1. Motion path: The motion-path property

Name: motion-path
Value: <url> | [ <basic-shape> | <path()> ] || <geometry-box> | none
Initial: none
Applies to: All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements
Inherited: no
Percentages: n/a
Media: visual
Computed value: as specified
Animatable: no

Specifies the motion path the element gets positioned at. The exact element’s position on the motion path is determined by the motion-offset property. A motion path is either a specified path with one or multiple sub-paths or the geometry of a not styled basic shape. Each shape or path must define an initial position for the computed value of "0" for motion-offset and an initial direction which specifies the rotation of the object on the initial position.

In this specification a direction (or rotation) of 0 degree is equivalent to the direction of the positive x-axis in the object’s local coordinate system. E.g a rotation of 0 degree points to the right side of the UA if the object and its ancestors have no transformation applied.

Values have the following meanings:

<basic-shape>
The motion path is a basic shape as specified in CSS Shapes [CSS-SHAPES]. The initial position and the initial direction for basic shapes are defined as follows:
<circle()>
<ellipse()>
The initial position is defined by the point where a virtual tangent to the circle/ellipse would reach the top vertical position. The initial direction is 0 degree.
<inset()>
The initial position is defined by the left top corner of the rectangle. The initial direction is 0 degree.
<polygon()>
The initial position is defined by the first coordinate pair of the polygon. The initial direction is defined by the vector connecting the initial position with the next following coordinate pair that isn’t equal to the initial position. If there is no such unequal coordinate pair, the initial direction is defined with 0 degree.
path() = path([ <fill-rule> ,]? <string>)

The <string> represents an SVG Path data string. The path data string must be conform to the grammar and parsing rules of SVG 1.1 [SVG11]. The initial position is defined by the first “move to” argument in the path string. For the initial direction follow SVG 1.1 [SVG11].

<fill-rule> - The filling rule used to determine the interior of the path. See fill-rule property in SVG for details. Possible values are nonzero or evenodd. Default value when omitted is nonzero.

<url>
References an SVG shape element and uses its geometry as motion path. See SVG 1.1 for more information about the initial position and initial direction [SVG11].
none
No motion path gets created.

A computed value of other than none results in the creation of a stacking context [CSS21] the same way that CSS opacity [CSS3COLOR] does for values other than 1, unless the element is an SVG element with out an associated CSS layout box.

A reference that fails to download, is not a reference to an SVG shape element element, or is non-existent is ignored. No motion path and no stacking context are created.

See the section “Motion processing” for how to process a motion path.

For SVG elements without associated CSS layout box, the used value for content-box, padding-box, border-box and margin-box is fill-box.

For elements with associated CSS layout box, the used value for fill-box, stroke-box and view-box is border-box.

4.2. Position on motion path: The motion-offset property

Name: motion-offset
Value: <length> | <percentage>
Initial: 0
Applies to: All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements
Inherited: no
Percentages: refer to the total path length
Media: visual
Computed value: as specified
Animatable: yes

A distance that describes the position along the specified motion path.

<percentage>
<length>
The distance from the initial position of the shape or path to the position of the element. Percentages are relative to the total path length including all sub-paths.

See the section “Motion processing” for how to process a motion position.

4.3. Rotation at point: The motion-rotation property

Name: motion-rotation
Value: [ auto | reverse ] && <angle>
Initial: auto
Applies to: All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements
Inherited: no
Percentages: n/a
Media: visual
Computed value: as specified
Animatable: yes

Defines the direction of the element while positioning along the motion path.

Values have the following meanings:

auto
Indicates that the object is rotated (over time if motion-offset is animated) by the angle of the direction (i.e., directional tangent vector) of the motion path. If specified in combination with <angle>, the computed value of <angle> is added to the computed value of auto.
reverse

Indicates that the object is rotated (over time if motion-offset is animated) by the angle of the direction (i.e., directional tangent vector) of the motion path plus 180 degrees. If specified in combination with <angle>, the computed value of <angle> is added to the computed value of reverse.

This is the same as specifying auto 180deg.

<angle>
Indicates that the element has a constant rotation transformation applied to it by the specified rotation angle. See definitions of auto or reverse if specified in combination with either one of the keywords. For the purpose of this argument, 0deg points to the right side in the direction of the positive x-axis, and positive angles represent clockwise rotation, so 90deg point toward the bottom.

Note: The rotation described here does not override or replace any rotation defined by the transform property.

The following three examples use the shape of a plane. The red dot in the middle of the shape indicates the origin of the shape.
Shape with its origin

A red dot in the middle of a plane shape indicates the shape’s origin.

In the first example, the motion-rotation property is set to auto. The shape’s point of origin is placed at different positions along the motion path. The shape is rotated based on the gradient at the current position and faces the direction of the motion path at this position.

Motion Path with auto rotation

A black plane at different positions on a blue dotted motion path, rotated in the direction of the path.

In this example, the motion-rotation property is set to reverse. The plane faces the opposite direction of the motion path at each position on the motion path.

Motion Path with reverse auto rotation

A black plane at different positions on a blue dotted motion path, rotated in the opposite direction of the path.

The last example sets the motion-rotation property to -45deg. The shape is rotated by -45 degree once and keeps the rotation at each position on the motion path.

Motion Path with fixed rotation

A black plane at different positions on a blue dotted path, rotated by a fixed amount of degree.

More natural names requested for auto and reverse.

See the section “Motion processing” for how to process a motion rotation.

4.4. Motion shorthand: The motion property

Name: motion
Value: <motion-path> && <motion-offset> && <motion-rotation>
Initial: see individual properties
Applies to: All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements
Inherited: no
Percentages: see individual properties
Media: visual
Computed value: see individual properties
Animatable: see individual properties

This is a shorthand property for setting motion-path, motion-offset and motion-rotation. Omitted values are set to their initial values.

4.5. Motion processing

4.5.1. Calculating the computed distance along a path

Processing the distance along a path operates differently depending upon whether the path is open or closed:

To determine the computed distance for a given path and distance:

  1. Let the total length be the total length of path with all sub-paths.

  2. If distance is a length:

    Let upper bound be equal to the total length.

    Otherwise:

    Let upper bound be equal to 100%.

  3. If path is a closed path:

    Let computed distance be equal to distance modulus upper bound.

    Otherwise:

    Let computed distance be equal to distance clamped by 0 and upper bound.

4.5.2. Calculating the path transform

  1. Let path be the geometry of the specified basic shape, path or SVG shape element reference.

  2. Let distance be the computed value of motion-offset.

  3. If path is a valid path:

    1. Determine the computed distance by invoking the process for Calculating the computed distance along a path on path and distance.

    2. Let position be the coordinate pair at computed distance along path.

    3. Create the supplemental transformation matrix transform to the local coordinate system of the element.

    4. Translate transform by position.

    5. Let rotate be the computed value of motion-rotation.

    6. Post-multiply the rotation rotate to transform.

    7. Post-multiply transform to the local coordinate system of the element.

Do we need to say how to get the position in more detail?

There needs to be a process for converting rotate to an angle.

Do we need to specify an origin of the element in motion so that it can be positioned accordingly before the motion? Something like motion-origin? Should we reuse transform-origin? (Probably not since the z coordinate doesn’t make any sense.)

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words "for example" or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word "Note" and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet
A CSS style sheet.
renderer
A UA that interprets the semantics of a style sheet and renders documents that use them.
authoring tool
A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

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

Experimental implementations

To avoid clashes with future CSS features, the CSS2.1 specification reserves a prefixed syntax for proprietary and experimental extensions to CSS.

Prior to a specification reaching the Candidate Recommendation stage in the W3C process, all implementations of a CSS feature are considered experimental. The CSS Working Group recommends that implementations use a vendor-prefixed syntax for such features, including those in W3C Working Drafts. This avoids incompatibilities with future changes in the draft.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

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.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[CSS-SHAPES]
Vincent Hardy; Rossen Atanassov; Alan Stearns. CSS Shapes Module Level 1. 20 June 2013. W3C Working Draft. URL: http://www.w3.org/TR/2013/WD-css-shapes-1-20130620/
[CSS21]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 7 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-CSS2-20110607
[CSS3VAL]
Håkon Wium Lie; Tab Atkins; Elika J. Etemad. CSS Values and Units Module Level 3. 30 July 2013. W3C Candidate Recommendation. (Work in progress.) URL: http://www.w3.org/TR/2013/CR-css3-values-20130730/
[SVG11]
Erik Dahlström; et al. Scalable Vector Graphics (SVG) 1.1 (Second Edition). 16 August 2011. REC. URL: http://www.w3.org/TR/SVG11/
[SVG2]
Nikos Andronikos; et al. Scalable Vector Graphics (SVG) 2. 11 February 2014. WD. URL: http://www.w3.org/TR/SVG2/
[CSS-CASCADE-4]
CSS Cascading and Inheritance Level 4 URL: http://dev.w3.org/csswg/css-cascade-4/
[CSS-COLOR-4]
CSS Color Module Level 4 URL: http://dev.w3.org/csswg/css-color-4/
[CSS-MASKING-1]
Dirk Schulze; Brian Birtles; Tab Atkins Jr.. CSS Masking Module Level 1. 26 August 2014. CR. URL: http://www.w3.org/TR/css-masking-1/
[CSS-SHAPES-1]
Vincent Hardy; Rossen Atanassov; Alan Stearns. CSS Shapes Module Level 1. 20 March 2014. CR. URL: http://www.w3.org/TR/css-shapes-1/
[CSS-TRANSFORMS-1]
Simon Fraser; et al. CSS Transforms Module Level 1. 26 November 2013. WD. URL: http://www.w3.org/TR/css-transforms-1/
[CSS-VALUES-3]
CSS Values and Units Module Level 3 URL: http://www.w3.org/TR/css3-values/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Informative References

[CSS3COLOR]
Tantek Çelik; Chris Lilley; L. David Baron. CSS Color Module Level 3. 7 June 2011. W3C Recommendation. URL: http://www.w3.org/TR/2011/REC-css3-color-20110607

Property Index

Name Value Initial Applies to Inh. %ages Media Animatable Computed value
motion-path <url> | [ <basic-shape> | <path()> ] || <geometry-box> | none none All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements no n/a visual no as specified
motion-offset <length> | <percentage> 0 All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements no refer to the total path length visual yes as specified
motion-rotation [ auto | reverse ] && <angle> auto All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements no n/a visual yes as specified
motion <motion-path> && <motion-offset> && <motion-rotation> see individual properties All elements. In SVG, it applies to container elements excluding the defs element and all graphics elements no see individual properties visual see individual properties see individual properties

Issues Index

Add more details and examples.
More natural names requested for auto and reverse.
Do we need to say how to get the position in more detail?
There needs to be a process for converting rotate to an angle.
Do we need to specify an origin of the element in motion so that it can be positioned accordingly before the motion? Something like motion-origin? Should we reuse transform-origin? (Probably not since the z coordinate doesn’t make any sense.)