The spec says that if a ScrollTimeline's scrollSource is not specified, "the document element is used".

We need to specify which document's document element is used, and when that determination is made (e.g. getter call time, constructor time, ...).

The spec doesn't say anything about what should happen if the document of a ScrollTimeline's scrollSource changes. It should.

I posted a question about this spec to Twitter, and @rogerjohansson replied with a good suggestion.

All examples should wrap the code in prefers-reduced-motion: no-preference.

I think that's a terrific idea. I know it'd add extra lines of code to the spec, while adding no value to the spec writers or implementors, but it would go a long way in emphasizing to the web industry that they shouldn't deliver scroll-driven animations to people who don't want them / can't handle them — and that doing so is very simple.

This question came up during the Chromium implementation of ScrollTimeline. The definition of orientation states:

"auto
If only one direction is scrollable, selects that direction. Otherwise selects the direction along the block axis."

The definition of 'scrollable', however, is causing some disagreement. I had initially assumed that it meant that the CSS overflow property in the given axis is non-visible, however per the CSS3 box spec it is not possible to have one axis be visible and the other non-visible:

"The computed values of ‘overflow-x’ and ‘overflow-y’ are the same as their specified values, except that some combinations with ‘visible’ are not possible: if one is specified as ‘visible’ and the other is ‘scroll’ or ‘auto’, then ‘visible’ is set to ‘auto’."

What is the intended definition of 'scrollable' here?

The spec doesn't say anything about what should happen if a ScrollTimeline's scrollSource is removed from its document. It should.

Consider this testcase:

<script>
  document.documentElement.remove();
  var x = new ScrollTimeline();
  alert(x.scrollSource);
</script>

what should get alerted? Spec says "the document element of the active document for the current browsing context, as determined at the time the ScrollTimeline is constructed", but that's null in this case. But the scrollSource attribute claims its value is never null.

The spec currently says, "If any animation directly associated with the timeline has a target effect end of infinity, the behavior is unspecified."

In https://bugzilla.mozilla.org/show_bug.cgi?id=1321428#c71, Brian suggested specifying that in such a case, the timeline's effective time range is zero.

Currently the spec for scrollSource says (https://wicg.github.io/scroll-animations/#dom-scrolltimeline-scrollsource):

"If this is not specified, the document element of the active document for the current browsing context, as determined at the time the ScrollTimeline is constructed, is used."

It seems to me like this should probably fall back to document.scrollingElement (https://drafts.csswg.org/cssom-view/#dom-document-scrollingelement) instead?

The spec doesn't say anything about what should happen if a ScrollTimeline's scrollSource stops being a scroll container. It should.

Currently vertical and horizontal are specified as:

horizontal
    Selects the horizontal direction.
vertical
    Selects the vertical direction

When writing-mode and direction are specified however, this can cause the beginning edges of an overflow region to be at the right/bottom.

It is not clear from the spec whether in these cases the orientation vector should also start from the right/bottom, or should stick with the physical top/left. The naive thinking is yes it should, but that only works if one is animating logical properties - consider what might happen if you animate transform: translateX(...). (The logical/physical issue is sort of a larger meta issue which I will file another issue about. This particular issue is about the fact that the spec doesn't make it clear what the horizontal/vertical directions are in the face of rtl.)

For an example, see https://output.jsbin.com/ruterik . This can be run in Chrome M71 (currently Canary) with the Experimental Web Platform Features flag on. It will show that we currently do follow the writing direction for horizontal/vertical, but it's not clear whether this is correct by the spec.

I used the GitHub issues link at the top of the spec to file an issue, but csswg-drafts is probably not the right repro for these issues ;-)

The properties of the ScrollTimeline interface correspond to the constructor arguments, but the spec doesn't actually say that the properties return the values passed in the constructor. It needs to, if that's the intended behaviour.

The following JS example https://wicg.github.io/scroll-animations/#timeline-examples uses trigger options property and ScrollTrigger interface which are not documented anywhere and my understanding is they won't be implemented.

it'd be good to outline another solution using the most current & polyfilled API syntax.

The spec currently makes it so that the end offset produces unresolved time. See current time algorithm.

If current scroll offset is greater than or equal to endScrollOffset, return an unresolved time value if fill is none or backwards, or the effective time range otherwise.

This seems like an non-intuitive choice to me. In particular, if the user doesn't specify start, and end values then the interval becomes the whole scroll range. With current specified behavior at the max scroll offset the effect will become in-active unless it has a fill forwards value.

Also AFAICT web-animation active interval is inclusive of both start and end. So it feels like ScrollTimeline behavior should be altered to match that.

https://wicg.github.io/scroll-animations/#dom-scrolltimeline-scrollsource says:

If this is not specified, the document element of the active document for the current browsing context, as determined at the time the ScrollTimeline is constructed, is used.

But the document element of the active document of whatever may not even be same-origin with the code constructing the ScrollTimeline. So hooking up the ScrollTimeline to it looks to me like a cross-origin information leak.

This question came up during the Chromium implementation of ScrollTimeline. The definition of orientation states:

"auto
If only one direction is scrollable, selects that direction. Otherwise selects the direction along the block axis."

However it isn't explicit about when this direction should be selected. If a ScrollTimeline is constructed as follows:

var timeline = new ScrollTrigger({ scrollSource: scroller, orientation: "auto" })

When should the orientation = 'auto' be resolved - at construction time, or every time currentTime is called? (Possibly changing from block to inline in the latter case, e.g. if the scroller content changes).

Depending on exactly how your interpret it, the avoiding cycles section implies that scrolling may need to block on JavaScript / layout.

For blink (and probably also at least Edge) that is a non-starter. Ensuring scrolling never blocks on the main thread has been our #1 scroll performance effort for several years, we're unwilling to allow that without an explicit scary-sounding opt-in API and a mitigation strategy (eg. "intervention" that applies on sites whose performance isn't good enough to permit a reasonable user experience on low end phones).

Is there agreement on this non-blocking design constraint for scroll animations? If so, perhaps it's worth mentioning in the introduction somewhere?

/cc @majido @flackr @shans

It is possible to have start and end offset that are equal. This can lead to a division by zero when calculating currentTime. The spec should explicitly call this out and return early before trying to compute current time. I think a sensible option is to return undefined in this case.

(current scroll offset - startScrollOffset) / (endScrollOffset - startScrollOffset) × effective time range

It seems like this has moved to CSSWG: https://drafts.csswg.org/scroll-animations-1/

/cc @stephenmcgruer @graouts @theres-waldo @birtles

The spec doesn't actually say anything about the behaviour of the ScrollTimeline constructor. It should.

https://wicg.github.io/scroll-animations/#dom-scrolltimeline-scrollsource talks about "active document for the current browsing context". What is a "current browsing context"? The link is to the definition of "browsing context", but what does "current" mean in this context?

There are concepts like "current Realm", "current settings object", and "current global object" defined at https://html.spec.whatwg.org/multipage/webappapis.html#current but none of those are defining "current browsing context".