[scroll-animation-1] Define scroll linked animation behavior in printing documents

[hiikezoe]

What most of users expect in printing documents is, I think, printing out the document as it is when the user printed out.

So basically any scroll linked animations should be output as it is, other then animations tied to the root scroll container in the top level document because there's not scroll position for the root scroller I think.

That's said, it's just my opinion. The spec needs to clarify it.

[bramus]

When printing I would assume there is no scroll estate, so the logic from #7778 (comment) would apply in that case.

[hiikezoe]

@bramus what do you mean by "no scroll estate"? IIRC Chrome does preserve each scroll position for sub scroll containers in printing document.

[hiikezoe]

I suppose you meant for the root scroll container cases?

[bramus]

I suppose you meant for the root scroll container cases?

Definitely for the root scroller as printing is paged media without a viewport.

For non-root scrollers I hadn’t really checked what printing does. In Chrome it prints the contents at the current scroll position like you mentioned. With that given, it makes sense to print the scroll-linked element at a certain position.

Maybe the progression of the animation could be snapshotted and then be re-applied when printing? E.g. say you’ve scrolled halfway and the scroll-linked animation is at 50% because of that. When printing, then use that 50% as the animation progress instead of trying to recalc the whole lot based on the printed box’s size.

[flackr]

I think the most natural thing to do is treat the root as a scroller that is fully in view with no overscroll, and inner scrollers as their current position, which is the original position put forward by @hiikezoe and clarified by @bramus for what that means #8226 (comment)

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animation-1] Define scroll linked animation behavior in printing documents, and agreed to the following:

• RESOLVED: for printing/paged, root is considered fully in view (scroll timelines on it are inactive)

The full IRC log of that discussion

<TabAtkins> flackr: When you print a doc, we need to define what the animation value from SLA is
<TabAtkins> flackr: I think there's two possible choices.
<TabAtkins> flackr: I think makes the most sense is to treat the root as a scroller that's fully in view - scrollport is size of scrollable area
<TabAtkins> flackr: This means many animatinos wouldn't have a time value, so they'd be skipped
<florian> q+
<TabAtkins> flackr: Other option is we treat one page as the scrollport, and presumably the scroll position is zero
<astearns> ack florian
<TabAtkins> florian: I'm not on top of things wrt animations, but wanted to point out that while it's not common, print and paged can be different - you can have scrollable things in a page in ebook, for example
<fantasai> TabAtkins: I think this question is for the root scroller though
<fantasai> TabAtkins: which is basically the same problem for paged and print
<TabAtkins> flackr: other scrollers are fine, they can compute their time. this is just the root scroller
<TabAtkins> flackr: it just doesn't really have a scroll position
<TabAtkins> fantasai: Can you explain more? say i have a root backgroudn animation from green to red as it goes 0%-100%. what happens when I print?
<TabAtkins> flackr: The scroll animation is considered inactive since there is no scrollable overflow, so it's not applied.
<TabAtkins> fantasai: That makes sense, I think that's the right thing to do.
<TabAtkins> astearns: So proposed resolution is that, for printing/paged purposes, we treat root as fully in view with no scrollable overflow
<TabAtkins> fantasai: scroll timeline is inactive on the root, maybe clearer to state directly
<TabAtkins> RESOLVED: for printing/paged, root is considered fully in view (scroll timelines on it are inactive)