On Thu, Oct 30, 2014 at 4:06 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Fri, Oct 31, 2014 at 12:02 PM, Jonas Sicking <jo...@sicking.cc> wrote:
>>
>> Couldn't we simply change the defined behavior of element.scrollBy({
>> top: 50, behavior: "smooth" }) such that it sends the delta
>> coordinates to the composition thread, and adds the current scroll
>> position there instead of on the main thread?
>
>
> OK, we should allow that.
>
> We'd still need the "async" behavior for your other use-cases.
Which use-case do you need "async" for?
The "Adjust the scroll position down by 10 pixels atomically with the
next reflow since I just added a 10 pixel element at the top of the
page" use case could be supported using
element.scrollBy({ top: 10, behavior: "instant" });
as long as the spec is clearly defined to apply that at the time of
the next reflow. Again, the main thing lacking is spec text rather
than API.
At least assuming we don't run into problems with ability to feature
detection. But I don't think "async" helps with that.
There is the drag'n'drop case though. I don't have a mental model for
how to solve that. Maybe "async" could help with that, but I don't
quite understand it's proposal.
/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
