diff --git a/scroll-animations-1/EXPLAINER.md b/scroll-animations-1/EXPLAINER.md index 7fdeb9d13d61..dc83520a1b41 100644 --- a/scroll-animations-1/EXPLAINER.md +++ b/scroll-animations-1/EXPLAINER.md @@ -1,27 +1,24 @@ -# Scroll-linked Animations Explainer - -Note: This document follows the [w3ctag best-practice](https://w3ctag.github.io/explainers) for -explainers. +# Scroll-driven Animations Explainer ## Participate -[Issue tracker](https://github.com/w3c/csswg-drafts/labels/scroll-animations) +[Issue tracker](https://github.com/w3c/csswg-drafts/labels/scroll-animations-1) ## Introduction -Scroll-linked animations are a common UX pattern on the web. We are proposing a new API that works +Scroll-driven animations are a common UX pattern on the web. We are proposing a new API that works in conjunction with existing [Web Animations](https://drafts.csswg.org/web-animations/) and [CSS -Animations](https://drafts.csswg.org/css-animations/) APIs to enable declarative scroll-linked -animations to improve their smoothness and ergonomics. In Web Animations, an +Animations](https://drafts.csswg.org/css-animations/) APIs to enable declarative scroll driven +animations to improve their smoothness and ergonomics. In Web Animations, an [AnimationTimeline](https://drafts.csswg.org/web-animations/#timelines) is the source of time -progress that drives the animations. ScrollTimeline is a new timeline whose function is to +progress that drives the animations. ScrollTimeline and ViewTimeline are new timelines whose function is to translate “changes in scroll position” of an element into “changes in time”. This allows animations to be driven by scrolling as opposed to by wall clock thus taking advantage of all existing animation machinery on the web. ## Motivating Use Cases and Goals -Scroll-linked animated effect are common in web design: +Scroll-driven animated effect are common in web design: * Parallax Effects * Reveal/Unreveal effects * Image Zoom effects @@ -36,14 +33,14 @@ means that these animations have to run on the main thread which leads to two ma asynchronously. 2. Main thread animations are subject to jank. -These make creating performant scroll-linked animations that are in-sync with +These make creating performant scroll driven animations that are in-sync with scrolling impossible or [very difficult](https://developers.google.com/web/updates/2016/12/performant-parallaxing). -Our primary goal is to enable declarative scroll-linked animations that can be easily moved off +Our primary goal is to enable declarative scroll-driven animations that can be easily moved off main thread similar to existing time-based web animations. Our secondary goal is to bring -scroll-linked animation under the existing common web-animation model allowing them to be created, +scroll-driven animation under the existing common web-animation model allowing them to be created, inspected, controlled via a common animations API. ### Non-goals @@ -52,8 +49,8 @@ inspected, controlled via a common animations API. These are a class of animation whose progress is driven by time but whose activation may be triggered when scrolling past a certain position or into a given scroll range. These are also -common on the web but they don't suffer from main thread jank and synchronous scrolling lad in the -same way that scroll-linked animations do. This is because only their activation is tied to scroll +common on the web but they don't suffer from main thread jank and synchronous scrolling lag in the +same way that scroll-driven animations do. This is because only their activation is tied to scroll position and not their progress. However, we found that in the vast majority of cases where a web author would want to do this, they @@ -71,53 +68,71 @@ At the moment, the current best practice is to use IntersectionObserver to kick- which seems sufficient. Other alternative ideas (`:ever-been-visible` pseudo class or generic animation-trigger) have been proposed [here](https://github.com/w3c/csswg-drafts/issues/4339#issuecomment-499666491) that the current -ScrollTimeline proposal does not prohibit. The design space for triggering animations is still open -and we welcome input on this subject for future revisions in this specification. +scroll-driven animations proposal does not prohibit. +The design space for triggering animations is still open and we welcome input on this subject for future revisions in this specification. -#### Stateful scripted scroll driven animations +#### Stateful scripted scroll-driven animations -Some scroll-linked animations may not fit well within declarative animations such as those that +Some scroll-driven animations may not fit well within declarative animations such as those that depend on scroll velocity, or direction, or have custom per frame logic. We believe these can continue to be solved using rAF (and in future be made more efficient with [Houdini Animation -Worklet](https://drafts.css-houdini.org/css-animationworklet/)). ScrollTimeline may be used in -conjunction with these. +Worklet](https://drafts.css-houdini.org/css-animationworklet/)). ScrollTimeline and ViewTimeline +may be used in conjunction with these. ## New APIs -The [Scroll-linked Animations](https://drafts.csswg.org/scroll-animations-1/) spec introduces one -new concept: ScrollTimeline +The [Scroll-driven Animations](https://drafts.csswg.org/scroll-animations-1/) spec introduces two +new timelines: ScrollTimeline and ViewTimeline + +These timelines can be constructed via Javascript or declared via CSS, +being implicitly constructed and used as the timeline for CSS animations. -### Scroll Timeline +The [Web Animations](https://www.w3.org/TR/web-animations-1/) spec has been updated to support +the use of progress-based "time" values as the input from which to derive the animation local +time. + +### ScrollTimeline A [ScrollTimeline](https://drafts.csswg.org/scroll-animations-1/#scrolltimeline-interface) is an [AnimationTimeline](https://drafts.csswg.org/web-animations-1/#the-animationtimeline-interface) -whose time values are determined not by wall-clock time, but by the progress of scrolling in a +whose time values are determined by the progress of scrolling in a [scroll container](https://drafts.csswg.org/css-overflow-3/#scroll-container). A ScrollTimeline -converts a position in a scroll range to a time value. The goal is to integrate into the [Web -Animations](https://www.w3.org/TR/web-animations-1/) spec which is built around time. The time -value it produces is determined by the following algorithm: +converts a position in a scroll range to a progress. +The time value a ScrollTimeline produces is determined by the following algorithm: ``` -Timeline current time = ((current scroll offset - start) / - (end - start)) * effective time range +Timeline current time = (current scroll offset) / (scrollable overflow size - scroll container size) ``` -A ScrollTimeline is specified by a number of parameters: +A ScrollTimeline is specified by two parameters: * **[source](https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-source)**: The - scrollable element whose scrolling triggers the activation and drives the progress of the - timeline. -* **[orientation](https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-orientation)**: - Determines the scrolling orientation which triggers the activation and drives the progress of the - trigger. -* **[start](https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-start)**: A scroll - offset, in the direction specified by orientation, which constitutes the beginning of the range - in which the timeline is active. -* **[end](https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-end)**: A scroll offset, - in the direction specified by orientation, which constitutes the end of the range in which the - trigger is activated. -* **[timeRange](https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-timerange)**: A - time duration that maps from the fraction-of-scroll that ScrollTimeline calculates, to the time - value that the Web Animations spec needs. + scrollable element whose scrolling drives the progress of the timeline. +* **[axis](https://drafts.csswg.org/scroll-animations-1/#dom-scrolltimeline-axis)**: + Determines the scrolling orientation which triggers the activation and drives the progress of the trigger. + +### ViewTimeline + +A [ViewTimeline](https://drafts.csswg.org/scroll-animations-1/#viewtimeline-interface) is an +[AnimationTimeline](https://drafts.csswg.org/web-animations-1/#the-animationtimeline-interface) +whose time values are determined by the relative progress of a particular element +scrolling through its [scroll container](https://drafts.csswg.org/css-overflow-3/#scroll-container). +The time value a ViewTimeline produces is determined by the following algorithm: + +``` +Timeline current time = (current scroll offset - start offset) / (end offset - start offset) +``` + +Where: +* `start offset` is the scroll offset at which the start border edge of the element's principal box + coincides with the end edge of the scroll port (reduced by insets). +* `end offset` is the scroll offset at which the end border edge of the element's principal box + coincides with the start edge of the scroll port (reduced by insets). + +Note: These offsets are not clamped and thus may be less than 0 or beyond the scrollable range of the scrollport. + +A ViewTimeline extends ScrollTimeline and adding one additional parameter: +* **[subject](https://drafts.csswg.org/scroll-animations-1/#dom-viewtimeline-subject)**: + The element whose principal box’s visibility in the scrollport defines the progress of the timeline. #### JavaScript APIs @@ -128,15 +143,11 @@ A ScrollTimeline is specified by a number of parameters: @@ -144,36 +155,34 @@ A ScrollTimeline is specified by a number of parameters: #### CSS syntax -We are introducing a new `@scroll-timeline` rule similar to the existing `@keyframes` rule. This will allow -scroll-linked animation to be specified in CSS. +The spec introduces `scroll-timeline` and `view-timeline` shorthands with appropriate longhand properties for defining timelines, +`scroll()` and `view()` functions for defining anonymous timelines, +as well as `animation-range` and `animation-timeline` properties on animation targets to link to timelines which +allow scroll-drive animation to be entirely specified in CSS. -Here is an example to demonstrate this which fades the target as `#scroller` scroll from zero to -max. +Here is an example to demonstrate this which fades the target +as its nearest ancestor scroller scrolls from zero to its scroll range. ```css #target { - animation: 1s fade; + animation: fade; + animation-timeline: scroll(); } @keyframes fade { from { opacity: 1 } to { opacity: 0 } } - -@scroll-timeline fade { - source: selector(#scroller); -} ``` -It is possible to use a timeline name that is different from the animation name and use the -`animation-timeline` property to associate a single timeline with multiple animations. Here is a -more complex example of colliding circles that demonstrates this: +It is possible to define and use a timeline name to associate a single timeline with multiple animations. +Here is a more complex example of colliding circles that demonstrates this: ```css div.circle { - animation-duration: 1s; animation-timing-function: linear; animation-fill-mode: forwards; + animation-range: 200px 300px; } #left-circle { animation-name: left-circle; @@ -185,21 +194,12 @@ div.circle { } #union-circle { animation-name: union-circle; - animation-timeline: union-timeline; -} - -@scroll-timeline collision-timeline { - source: selector(#container); - direction: block; - start: 200px; - end: 300px; + animation-timeline: collision-timeline; + animation-range: 250px 300px; } -@scroll-timeline union-timeline { - source: selector(#container); - direction: block; - start: 250px; - end: 300px; +#container { + scroll-timeline-name: collision-timeline; } @keyframes left-circle { @@ -213,47 +213,37 @@ div.circle { } ``` -#### Element-based start/end offsets +#### View timeline animations A very common usage pattern for scroll timeline is that the animation is not based on the absolute scroll position, but instead based on the location of an element within the scroller. Most commonly -this is when the element enters the scroller viewport and the element in question is usually the -one which is being animated and the scroller is usually the document viewport. To address this, we -are allowing scroll timeline's start and end offsets to be declared in terms of elements on the -page. More accurately as a single intersection threshold (with a similar semantic as -IntersectionObserver) between the scroll timeline's scroll source and another element. - +this is when the element enters the scroller viewport. View timelines provide a means to address +these use cases by defining animations in terms of the relative progress of an element through its +nearest ancestor scrollport. Here is a simple example that shows how this can be used to fade-in an element as it enters the -viewport until it becomes fully visible. This is a WIP proposal and has not been fully specified. -See [here](https://github.com/w3c/csswg-drafts/issues/4337) for more examples and details. +viewport until it becomes fully visible. ```javascript -const scroller = document.getElementById("scroller"); const image = document.getElementById("image"); -const revealTimeline = new ScrollTimeline({ - // Timeline starts at the offset that corresponds with image starting - // to enter scrollport (i.e., 0% intersect with scroller at its “end” edge). - start: { target: image, edge: 'end', threshold: 0 }, - - // Timeline ends at the offset that corresponds with image becoming - // fully visible (i.e., 100% intersect with scroller at its “end” edge). - end: { target: image, edge: 'end', threshold: 1 }, -}); +const revealTimeline = new ViewTimeline({subject: image}); -const animation = new Animation( - new KeyframeEffect( - image, - { opacity: [0, 1]}, - { duration: 1000, fill: both } - ), - revealTimeline +const animation = image.animate( + { opacity: [0, 1] }, + { + timeline: revealTimeline, + fill: 'both', + // The animation starts at the offset that corresponds with image starting + // to enter scrollport (i.e., 0% intersect with scroller at its “end” edge). + rangeStart: 'entry 0%', + // The animation ends at the offset that corresponds with image becoming + // fully visible (i.e., 100% intersect with scroller at its “end” edge). + rangeEnd: 'entry 100%' + } ); - -animation.play(); ``` ## Key scenarios @@ -264,7 +254,7 @@ polyfill](https://flackr.github.io/scroll-timeline/demo/parallax/index.html). ### Scenario 1 - Parallax -Parallax is one of the most popular scroll-linked effects on the web today. See Android 10 launch +Parallax is one of the most popular scroll-driven effects on the web today. See Android 10 launch [site](https://www.android.com/android-10/) for an example of this.  @@ -276,7 +266,6 @@ let header = document.querySelector('.header'); document.querySelector('.header > .background').animate({ transform: ['none', 'translateY(30%)']}, { fill: 'both', - duration: 1000, // leaving options empty default using root scroller // for its entire scroll range. timeline: new ScrollTimeline() @@ -287,7 +276,7 @@ document.querySelector('.header > .background').animate({ ### Scenario 2 - Reveal/Unreveal In this UX pattern an element fades in/out or swipes in/out as user scrolls the page. These are -often used to create interactive stories. For example see how New York Times applies scroll-linked +often used to create interactive stories. For example see how New York Times applies scroll-driven animations for creative [storytelling](http://www.nytimes.com/projects/2013/tomato-can-blues/index.html). @@ -295,24 +284,20 @@ animations for creative Here is a simple example where we reveal each header as they enters the viewport. This example uses -the still unspecified element-based offset syntax. +the ViewTimeline API. ```js const headers = document.querySelectorAll('h2, h3'); for (let i = 0; i < headers.length; i++) { - const scrollTimeline = new ScrollTimeline({ - start: {target: headers[i], edge: 'end', rootMargin: '-20px'}, - end: {target: headers[i], edge: 'end', threshold: 1, rootMargin: '-20px'}, - }); - headers[i].animate([ {transform: 'translateX(-10px)', opacity: 0}, {transform: 'none', opacity: 1}], { - duration: 10000, + rangeStart: 'entry 0%', + rangeEnd: 'entry 100%', fill: 'both', - timeline: scrollTimeline + timeline: new ViewTimeline({subject: headers[i]}) } ); } @@ -331,12 +316,9 @@ document. ``` js document.querySelector('#progressbar').animate({ - width: [0', '100vw']}, { - duration: 10000, + width: ['0', '100vw']}, { fill: 'both', - timeline: new ScrollTimeline({ - source: document.scrollingElement - }) + timeline: new ScrollTimeline() }); ``` @@ -355,12 +337,10 @@ from the element that is used to specify the scroll timeline bounds. const container = document.querySelector('#zoom'); document.querySelector('#zoom > div').animate({ transform: ['scale(3) translateX(10%)', 'scale(1)']}, { - duration: 10000, fill: 'both', - timeline: new ScrollTimeline({ - start: {target: container, edge: 'end', threshold: 1}, - end: {target: container, edge: 'start', threshold: 1}, - }) + rangeStart: 'contain 0%', + rangeEnd: 'contain 100%', + timeline: new ViewTimeline({subject: container}) }); } ``` @@ -376,28 +356,22 @@ controlled, and inspected with existing methods. Some of the complexities that come from this decision are: * **Time vs Scroll Offset**: The concept of **time value** (exposed in - Milliseconds units) are central to the Web Animation model. This is why - ScrollTimeline needs `timeRange` to map scroll units into time units. This - feels odd and artificial. There is a `timeRange: auto` value to help alleviate - some of this but it is not perfect (see - [1](https://github.com/w3c/csswg-drafts/issues/4346) and - [2](https://github.com/w3c/csswg-drafts/issues/4353)). A more principled - solution has been proposed in the form of Progress-based Animations which - addresses this issue among other benefits. + Milliseconds units) were central to the Web Animation model. Adding + ScrollTimeline requires updating the animation timing model to allow + for other unit types. We decided to go with percentages as they had a + clean direct mapping to animation progress (which is already a proportion). * **Exclusive end ranges**: In Web Animations, ranges have exclusive ends to help make it easier to use overlapping ranges such as putting multiple animations in a sequence. ScrollTimeline scroll range also has exclusive ends to match this. However this is problematic for a common case where scroll range is full size. Our solution was to [special - case](https://github.com/w3c/csswg-drafts/issues/4341) this one. + case](https://github.com/w3c/csswg-drafts/issues/5223) this one. * **Dynamic Scrollability**: It is possible for a scroller to no longer - overflow (`overflow: auto`). It is not clear how best to model this behavior. - One option is to model this as an idle timeline. One current limitation of web - animation is that when a timeline goes from playing to idle, its attached - animations need to be explicitly played again (call to `animation.play()`). We - are still working on finding the best solution here to avoid this need. + overflow (`overflow: auto`). We mapped this to the web animations model + by having the timeline become idle in these situations where a time cannot + be worked out. ### Avoiding Layout Cycle @@ -412,19 +386,25 @@ scrolling in response to input events has taken place, but before `requestAnimat callbacks are run. If the sampling of such an animation causes a change to a scroll offset, the animation will not be re-sampled to reflect the new offset until the next frame. - +However, newly declared CSS scroll timelines and view timelines are not detected until after style and layout. +If we did not sample these the user would see a single frame where the animation effect was not applied. +For this we have taken an [approach](https://github.com/w3c/csswg-drafts/issues/5261) similar to ResizeObserver, +where once per frame if we have identified new scroll driven timelines we repeat style and layout +to ensure those new timelines have an initial time. -Note that this ensures the output of scroll-linked animation is always up-to-date when the user is + + +Note that this ensures the output of scroll-driven animation is always up-to-date when the user is scrolling and avoids layout cycle. But it also means that in some situations the rendered scroll offset may not be consistent with the output of scroll-driven animations. For example when the -scroll-linked animation itself is indirectly causing the scroll offset to change. We believe this +scroll-driven animation itself is indirectly causing the scroll offset to change. We believe this is rare and often not actually desired by authors. Another thing to note is that if one updates scroll offsets in a `requestAnimationFrame` callback -it is not reflected in scroll-linked animations in the same frame. This is because +it is not reflected in scroll-driven animations in the same frame. This is because `requestAnimationFrame` callback are specified to run after updating web animations step which includes -scroll-linked animations. +scroll-driven animations. ### Accommodate Asynchronous Scrolling @@ -433,44 +413,35 @@ asynchronously](https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the- smoothness and responsiveness to user actions. In other words the majority of scrolling is handled off main-thread. We have opted for the following model to ensure that is not affected: -1. The scroll-linked effects are expressed declaratively similar to other +1. The scroll-driven effects are expressed declaratively similar to other web-animations and may be sampled asynchronously. -2. The user-agent is allowed to sample scroll-linked animations more often than main +2. The user-agent is allowed to sample scroll-driven animations more often than main thread animation frames. -3. The user-agent is allowed to sample the scroll-linked effects on main-thread once +3. The user-agent is allowed to sample the scroll-driven effects on main-thread once per main-thread animation frame and use the last known scroll offset. -(1) and (2) mean that scroll-linked animation can potentially run off-main thread and in sync with +(1) and (2) mean that scroll-driven animation can potentially run off-main thread and in sync with asynchronous scrolling that happens off thread. (3) ensures they can also run on main-thread -without forcing scrolling itself to be on main thread. Together they guarantee that scroll-linked +without forcing scrolling itself to be on main thread. Together they guarantee that scroll-driven animations would render as often as the current existing approach of using scroll events while also enabling user-agents to optimize such animations to potentially run off-thread and in sync with asynchronous scrolling. -### Progress-Based Animations - -As mentioned before we like to eliminate the need for `ScrollTimeline.timeRange` to map scroll -units into time units. One approach we are exploring is the addition of progress-based animations -to Web Animations. This will allow the scroll timeline to produce a “progress” value which can -drive animations without a need for durations. Progress-based animations will have other value -beside scroll linked-animations. This is a work-in-progress and there is an ongoing discussion -around it [here](https://github.com/w3c/csswg-drafts/issues/4862). - ### Access top-level window scroll in iframes -It is desirable to perhaps allow scroll-linked animations to respond to the top-level window +It is desirable to perhaps allow scroll-driven animations to respond to the top-level window viewport in an iframe. The current specification does not allow this as we are not sure of the -security impact of enabling this in cross-origin iframes. But in terms of API it may be just as -simple of allowing empty source attributes to mean top-level window scroller. More discussion on +security impact of enabling this in cross-origin iframes. But in terms of API it may be just +allowing empty source attributes to mean top-level window scroller. More discussion on the use case and possible solutions are [here](https://github.com/w3c/csswg-drafts/issues/4344) ### Logical Scrolling vs Animation of Physical properties -This is not an issue directly related to Scroll-linked animation but one that gets exposed more +This is not an issue directly related to Scroll-driven animation but one that gets exposed more clearly with it. The issue is that many CSS properties, most predominantly transform, are physical -but ScrollTimeline orientation is logical in that it can be affected by writing-mode). So authors -have to be careful to use physical orientation with a scroll timeline if they intend to use it to +but scroll-driven timeline orientation is logical (in that it can be affected by writing-mode). +So authors have to be careful to use physical orientation with a scroll timeline if they intend to use it to animate physical properties. More details on this [issue here](https://github.com/w3c/csswg-drafts/issues/4350#issue-495584798). Long-term, perhaps we should consider [logical transforms](https://github.com/w3c/fxtf-drafts/issues/311) (also @@ -479,18 +450,15 @@ should consider [logical transforms](https://github.com/w3c/fxtf-drafts/issues/3 ## Considered alternatives ### CSS Syntax Alternatives -We have considered alternatives function based css syntax but decided to go with a @scroll-timeline -rule instead. See additional CSSWG discussion -[here](https://github.com/w3c/csswg-drafts/issues/4338). - +We have gone back and forth on the particular CSS syntax for declaring timelines. +We [originally considered function based css syntax but decided to go with a @scroll-timeline rule instead](https://github.com/w3c/csswg-drafts/issues/4338). +Subsequently there was a [proposal to rethink the syntax](https://github.com/w3c/csswg-drafts/issues/6674) +which resulted in the syntax we have in the specification today. ### Element-based start/end Offsets Alternatives -A common usage pattern for scroll-linked animation is to start animation when an element enters -scrollport (or viewport) until it leaves viewport. The current proposal achieves this by allowing -start/end offset to be declared in terms of intersection of the scroller and one of its -descendants. This is still a work-in-progress but most of the details are spelled out -[here](https://github.com/w3c/csswg-drafts/issues/4337). +A common usage pattern for scroll-driven animation is to start animation when an element enters scrollport (or viewport) until it leaves viewport. +The current proposal achieves this with ViewTimelines which observe a particular element's progress through the scrollport. Below are alternatives we have considered: @@ -507,6 +475,11 @@ Below are alternatives we have considered: viewport which are more naturally expressed as intersections as opposed to alignments. However this is open to debate and feedback is welcome. +3. Allowing element based start/end offsets to be declared in terms of intersection with the + scroller. This was [designed and prototyped](https://github.com/w3c/csswg-drafts/issues/4337) with + minor concerns around the ergonomics of the element based offsets. The main concern was the heavy + reliance on element ids. + ## CSS animation-timebase This is an [idea](https://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html) that most @@ -521,14 +494,14 @@ This is an idea that was first proposed in Compositor Worker and then was explor Animation Worklet](https://github.com/w3c/css-houdini-drafts/tree/master/css-animationworklet). The idea was to simply expose scroll offset to special JS based `animate()` callbacks that can run off thread. We believe ScrollTimeline can be used in conjunction with Houdini Animation Worklet thus -there is no need to expose scroll offsets directly. This can enable more complex scroll-linked +there is no need to expose scroll offsets directly. This can enable more complex scroll-driven animations using Animation Worklet while also making it easy to create fully declarative animations for common simpler use cases via Web Animations. Another [take on this idea](https://github.com/w3c/csswg-drafts/issues/2493) was to change Web Animations time value to no longer be scalar but value could be a bag of values which may be scroll positions, touch position etc. This combined with custom js animation callback, such as Animation -Worklet, could allow very sophisticated scroll-linked animations but this was also scrapped as we +Worklet, could allow very sophisticated scroll-driven animations but this was also scrapped as we believed this may not be compatible with the Web Animation model. @@ -546,5 +519,4 @@ Additional links Many thanks for valuable contributions, feedback and advice from: * All current and former specification editors. * CSSWG members for valuable feedback on this proposal. - * Yi Gu for contributing to this explainer.