[cssom-view-1] Scroll methods in Element and Window return Promises

[mustaqahmed]

Switch the return type for the scroll methods from undefined to Promise<undefined> as per the discussion and resolution in #1562 (comment).

Fixed: #1562.

[flackr]

In the discussion we talked about the argument to the promise being an object which would tell the developer the result of the scroll, e.g. to know if it was cancelled / interrupted as was brought up a few times as a common thing to need to know.

[mustaqahmed]

In the discussion we talked about the argument to the promise being an object which would tell the developer the result of the scroll, e.g. to know if it was cancelled / interrupted as was brought up a few times as a common thing to need to know.

That's correct. The problem is that it not yet defined how the promise would be resolved to mark scroll completion vs interruption. I can update this PR to resolve with a true to mark completion and false "otherwise" but I am hesitant because of a few reasons:

1. It is perhaps not okay to add normative things w/o discussion, right? E.g. we don't know if we should use a Boolean here vs an enum.

2. What does that "otherwise" mean to be precise? Does one programmatic scroll request interrupt all pending promises? Or only the pending ones for the same scroller?

3. We may need additional text in the current scroll algorithms to "collect" pending scrolling requests. To me a follow-up PR after this one seems cleaner.

I am proposing to land this PR as "closing" #1562, staring a new spec issue to discuss 1+2 above, and then hash out 3 in the PR for that new issue.

[flackr]

In the discussion we talked about the argument to the promise being an object which would tell the developer the result of the scroll, e.g. to know if it was cancelled / interrupted as was brought up a few times as a common thing to need to know.

That's correct. The problem is that it not yet defined how the promise would be resolved to mark scroll completion vs interruption. I can update this PR to resolve with a true to mark completion and false "otherwise"

I would suggest that it not resolve with a boolean but rather with an object, e.g. define a ScrollResult, that we can add to if we later discover that we want to pass additional information. That said, having a boolean there and opening an issue for whether we should change it is a good thing.

but I am hesitant because of a few reasons:

1. It is perhaps not okay to add normative things w/o discussion, right? E.g. we don't know if we should use a Boolean here vs an enum.

This is normal, the resolution we have is effectively to pursue specifying and prototyping the feature. It's fully expected that in the process of doing this the implementor may make some opinionated decisions in writing the spec and bring those decisions back to the working group. Having something implemented will make it easier to have examples where we can show how the value would be used.

2. What does that "otherwise" mean to be precise? Does one programmatic scroll request interrupt all pending promises? Or only the pending ones for the same scroller?

It would be valuable to define this to mean what we think makes the most sense. IMO this is anything that prevents completing the original scroll request. A programmatic scroll request on an unrelated scroller probably should not interrupt it. A scroll on the same scroller would mean that we are no longer actively scrolling to the originally requested location.

3. We may need additional text in the current scroll algorithms to "collect" pending scrolling requests. To me a follow-up PR after this one seems cleaner.

I am proposing to land this PR as "closing" #1562, staring a new spec issue to discuss 1+2 above, and then hash out 3 in the PR for that new issue.

It is better to have the boolean there and to add an inline issue in the spec that says we need to agree on the type and when it is successful / unsuccessful. This shows spec readers that the API is likely to change, demonstrates the use case and can even point to the issue for people to add their feedback. Here's an example from css-images-5:

csswg-drafts/css-images-5/Overview.bs

Line 55 in b5312ce

ISSUE: Make sure behavior is <a href="https://github.com/w3c/csswg-drafts/issues/7058#issuecomment-1057553833">properly consistent for SVG</a>.