|
| 1 | +<h1>CSS Will Change Module Level 1</h1> |
| 2 | + |
| 3 | +<pre class='metadata'> |
| 4 | +Shortname: css-will-change |
| 5 | +Level: 1 |
| 6 | +Status: FPWD |
| 7 | +Group: CSSWG |
| 8 | +ED: http://tabatkins.github.io/specs/css-will-change/ |
| 9 | +Abstract: This document defines the 'will-change' CSS property, which allows an author to inform the UA ahead of time of what kinds of changes they are likely to make to an element. This allows the UA to optimize how they handle the element ahead of time, performing potentially-expensive work preparing for an animation before the animation actually begins. |
| 10 | +Editor: Tab Atkins Jr., Google Inc., http://xanthir.com/contact/ |
| 11 | +Link Defaults: css-transforms-1 (property) transform |
| 12 | +</pre> |
| 13 | + |
| 14 | +<h2 id='intro'> |
| 15 | +Introduction</h2> |
| 16 | + |
| 17 | + Modern CSS renderers perform a number of complex optimizations in order to render webpages quickly and efficiently. |
| 18 | + Unfortunately, employing these optimizations often has a non-trivial start-up cost, |
| 19 | + which can have a negative impact on the responsiveness of a page. |
| 20 | + |
| 21 | + <div class='example'> |
| 22 | + For example, when using CSS 3D Transforms to move an element around the screen, |
| 23 | + the element and its contents might be promoted to a “layer”, |
| 24 | + where they can render independently from the rest of the page and be composited in later. |
| 25 | + This isolates the rendering of the content so that the rest of the page doesn't have to be rerendered |
| 26 | + if the element’s transform is the only thing that changes between frames, |
| 27 | + and often provides significant speed benefits. |
| 28 | + |
| 29 | + However, setting up the element in a fresh layer is a relatively expensive operation, |
| 30 | + which can delay the start of a 'transform' animation by a noticeable fraction of a second. |
| 31 | + </div> |
| 32 | + |
| 33 | + The 'will-change' property defined in this specification allows an author to declare ahead-of-time what properties are likely to change in the future, |
| 34 | + so the UA can set up the appropriate optimizations some time before they're needed. |
| 35 | + This way, when the actual change happens, |
| 36 | + the page updates in a snappy manner. |
| 37 | + |
| 38 | +<h2 id='will-change'> |
| 39 | +Hinting at Future Behavior: the 'will-change' property</h2> |
| 40 | + |
| 41 | + <pre class='propdef'> |
| 42 | + Name: will-change |
| 43 | + Value: auto | <<animateable-feature>># |
| 44 | + Initial: auto |
| 45 | + Applies to: all elements |
| 46 | + Inherited: no |
| 47 | + Percentages: n/a |
| 48 | + Media: all |
| 49 | + Computed value: specified value |
| 50 | + </pre> |
| 51 | + |
| 52 | + <pre class='prod'><dfn><animateable-feature></dfn> = scroll-position | contents | <<custom-ident>></pre> |
| 53 | + |
| 54 | + The 'will-change' property provides a rendering hint to the user agent, |
| 55 | + stating what kinds of changes the author expects to perform on the element. |
| 56 | + This allows the user agent to perform ahead-of-time any optimizations necessary for rendering those changes smoothly, |
| 57 | + avoiding “jank” when the author does begin changing or animating that feature. |
| 58 | + |
| 59 | + Values have the following meanings: |
| 60 | + |
| 61 | + <dl dfn-for="will-change" dfn-type="value"> |
| 62 | + <dt><dfn>auto</dfn> |
| 63 | + <dd> |
| 64 | + Expresses no particular intent; |
| 65 | + the user agent should apply whatever heuristics and optimizations it normally does. |
| 66 | + |
| 67 | + <dt><dfn>scroll-position</dfn> |
| 68 | + <dd> |
| 69 | + Indicates that the author expects to animate or change the scroll position of the element in the near future. |
| 70 | + |
| 71 | + <p class='example'> |
| 72 | + For example, browsers often only render the content in the "scroll window" on a scrollable element, |
| 73 | + and some of the content past that window, |
| 74 | + balancing memory and time savings from the skipped rendering against making scrolling look nice. |
| 75 | + A browser might take this value as a signal to expand the range of content around the scroll window that is rendered, |
| 76 | + so that longer/faster scrolls can be done smoothly. |
| 77 | + |
| 78 | + <dt><dfn>contents</dfn> |
| 79 | + <dd> |
| 80 | + Indicates that the author expects to animate or change something about the element's contents in the near future. |
| 81 | + |
| 82 | + <p class='example'> |
| 83 | + For example, browsers often “cache” rendering of elements over time, |
| 84 | + because most things don't change very often, |
| 85 | + or only change their position. |
| 86 | + However, if an element *does* change its contents regularly, |
| 87 | + producing and maintaining this cache is a waste of time. |
| 88 | + A browser might take this value as a signal to cache less aggressively on the element, |
| 89 | + or avoid caching at all and just continually re-render the element from scratch. |
| 90 | + |
| 91 | + <dt><dfn><<custom-ident>></dfn> |
| 92 | + <dd> |
| 93 | + Indicates that the author expects to animate or change the property with the given name on the element in the near future. |
| 94 | + |
| 95 | + The <<custom-ident>> production used here excludes the keywords ''will-change'', ''none'', ''all'', ''auto'', ''scroll-position'', and ''contents'', |
| 96 | + in addition to the keywords normally excluded from <<custom-ident>>. |
| 97 | + |
| 98 | + Note: Note that most properties will have no effect when specified, |
| 99 | + as the user agent doesn't perform any special optimizations for changes in most properties. |
| 100 | + It is still <em>safe</em> to specify them, though; |
| 101 | + it'll simply have no effect. |
| 102 | + |
| 103 | + If any non-initial value of a property would create a stacking context on the element, |
| 104 | + specifying that property in 'will-change' must create a stacking context on the element. |
| 105 | + |
| 106 | + If any non-initial value of a property would cause the element to generate a containing block for fixed-position elements, |
| 107 | + specifying that property in 'will-change' must cause the element to generate a containing block for fixed-position elements. |
| 108 | + |
| 109 | + If a non-initial value of a property would cause rendering differences on the element |
| 110 | + (such as using a different anti-aliasing strategy for text), |
| 111 | + the user agent should use that alternate rendering when the property is specified in 'will-change', |
| 112 | + to avoid sudden rendering differences when the property is eventually changed. |
| 113 | + |
| 114 | + <p class='example'> |
| 115 | + For example, browsers often handle elements with 'transform' set to a non-initial value very differently from normal elements, |
| 116 | + perhaps rendering them to their own “GPU layer” |
| 117 | + or using other mechanisms to make it easier to quickly make the sort of transformations that 'transform' can produce. |
| 118 | + A browser might take a value of 'transform' as a signal |
| 119 | + that it should go ahead and promote the element to its own layer immediately, |
| 120 | + before the element starts to be transformed, |
| 121 | + to avoid any delay involved in rerendering the old and new layers. |
| 122 | + </dl> |
| 123 | + |
| 124 | + |
| 125 | + <div class='example'> |
| 126 | + For example, setting 'opacity' to any value other than ''1'' creates a stacking context on the element. |
| 127 | + Thus, setting ''will-change: opacity'' also creates a stacking context, |
| 128 | + even if 'opacity' is <em>currently</em> still equal to ''1''. |
| 129 | + </div> |
| 130 | + |
| 131 | + The 'will-change' property has no <em>direct</em> effect on the element it is specified on, |
| 132 | + beyond the creation of stacking contexts and containing blocks as specified above. |
| 133 | + It is solely a rendering hint to the user agent, |
| 134 | + allowing it set up potentially-expensive optimizations for certain types of changes |
| 135 | + before the changes actually start occurring. |
| 136 | + |
| 137 | + <div class='note'> |
| 138 | + Different browsers can use the information from 'will-change' in different ways, |
| 139 | + and even a single browser might use it in different ways at different time. |
| 140 | + For example, a browser that promotes elements to their own “GPU layer” |
| 141 | + when they have ''will-change: transform'' specified |
| 142 | + might avoid doing that when there are <em>too many</em> elements declaring that, |
| 143 | + to avoid exhausting GPU memory. |
| 144 | + |
| 145 | + Authors should avoid overusing this property, |
| 146 | + and shouldn't apply it to an element unless it is known (or expected) |
| 147 | + that the element will change in the indicated way soon. |
| 148 | + For example, applying 'will-change' to an element from a static CSS stylesheet |
| 149 | + is probably an error; |
| 150 | + most of the time, |
| 151 | + 'will-change' should be applied by scripting, |
| 152 | + some time shortly before starting an animation or other change, |
| 153 | + and should be promptly reset to its initial value of ''auto'' |
| 154 | + when the element stops changing. |
| 155 | + </div> |
0 commit comments