- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 16:12:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations-1] Scroll and view timelines should be active in non-printed media`, and agreed to the following: * `RESOLVED: close no change (but without prejudice, examples in the future can change it)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: We previously decided that for printing purposes it doesn't make sense to ahve scroll animations be inactive<br> <TabAtkins> flackr: We defined it in a way that it disables for all paged media<br> <TabAtkins> flackr: Wondering if it makes sense to have these still run for paged media that can change its behavior, like a progress bar on an ereader<br> <astearns> +1 for enabling on interactive paged media devices<br> <TabAtkins> flackr: So I propose we support it for paged media generally, just not for printed media<br> <TabAtkins> fantasai: My concern with this is authors are v likely to write scroll anims that don't work if you don't have continuous media<br> <TabAtkins> fantasai: Like a page might be halfway thru an element's progress<br> <TabAtkins> fantasai: So it won't look good<br> <astearns> q+<br> <TabAtkins> fantasai: While an author is more likely to write their page in a way that works if scroll anims don't work at all<br> <TabAtkins> fantasai: Lots of reasons to do that<br> <TabAtkins> fantasai: but writing the page so that it makes sense when you happen to paginate halfway thru an animation, it's not likely<br> <TabAtkins> fantasai: we could define a page timeline for these kinds of things which would have discrete steps<br> <TabAtkins> fantasai: but i'd rather the author have an explicit understanding that it has discrete points, it's not continuous<br> <TabAtkins> astearns: kneejerk reaction to limit features for paged media because people could get it wrong<br> <TabAtkins> astearns: I'd rather allow people to do things for devices that are capable of it, and let them deal with the authoring problems of writing for both continuous and paged<br> <TabAtkins> astearns: There are some things you can do in desktop that look bad in mobile, but we dont' disable them there<br> <TabAtkins> fantasai: When you dont' design for mobile we lay out into a wide viewport because pages *do* break badly<br> <flackr> qq+<br> <astearns> ack astearns<br> <TabAtkins> fantasai: So people don't usually design for print, but it still generally works<br> <TabAtkins> fantasai: But with a scroll anim if you're animating an element halfway into view, and that's where the page break happens, yuo can't see the element<br> <TabAtkins> fantasai: If we have a page timeline, and your animations happen to work for both continouus and discrete, you can just switch your timeline<br> <ydaniv> q+<br> <TabAtkins> fantasai: But if we generally apply a continuous animation to paged it'll usually break, i think<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to emilio<br> <TabAtkins> flackr: It's not arbitrary, it's consistent with a browser<br> <TabAtkins> flackr: I'm curious where you'll get 90% is broken<br> <TabAtkins> fantasai: Not ture, you'll frequently have problems. Imagine a paragraph, page break in there, it's 60% in view<br> <TabAtkins> fantasai: you'll have 60% opacity because it fragmented there<br> <TabAtkins> fantasai: and you can't read it<br> <TabAtkins> fantasai: and that's just opacity, if you do fancy transforms or whatever the interim state can be unreadable<br> <TabAtkins> flackr: I was wondering if people would b eusing view timelines on things that could be fragmented, and i guess the answer is yes<br> <TabAtkins> flackr: my other concern is that having a differen ttype of timeline is simple for scroll timeline, but do we need something else for view timeline or do VT just not make sense in paged media?<br> <TabAtkins> flackr: I think it's easier for authors to turn them off with an MQ if they're likely to break<br> <florian> q+<br> <TabAtkins> fantasai: They're not gonna do that, they're just not gonna think about it<br> <bramus> +1 to fantasai there<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: Usually people don't animate things that are fragmented<br> <TabAtkins> ydaniv: they animate things that they know are gonna stay on the screen as a unit<br> <TabAtkins> ydaniv: in the case of paged media, isn't that closer to having reduced motion?<br> <TabAtkins> ydaniv: If you had something and it was completely disabled, then you end up with something broken<br> <florian> q- later<br> <TabAtkins> astearns: not sure i understood<br> <TabAtkins> ydaniv: If someone made a scroll animation for their page but it's completely disabled on paged media, and the animation was supposed to bring things into view<br> <TabAtkins> ydaniv: so my intuition is that it should behave more like having reduced motion<br> <TabAtkins> astearns: ah so someone might author a scroll animation and they know they shoudl turn it off for reduced motion, and they'll deal with that case, but they won't think about paged media<br> <astearns> ack bramus<br> <TabAtkins> bramus: i agree with fantasai that authors won't think about this<br> <TabAtkins> bramus: i thought her example of animating the opacity was a great example, if you respected that during printing you could end up with what looks like an empty page<br> <TabAtkins> flackr: and that's if you animate something that can fragment as it comes into view<br> <TabAtkins> flackr: I'm okay with leaving it off, i just wanted to bring it up with the WG<br> <TabAtkins> astearns: And we can leave it like this until someone asks for animations on an eink device or something<br> <TabAtkins> fantasai: I think it would be great to have animations on paged media, it would just have to handle the fact that it's paged and discrete<br> <TabAtkins> florian: I was thinking fantasai's earlier analogy with mobile content was good<br> <fantasai> Like, I'm pretty sure a lot of the stuff on NY Times will break if you try to print it, without explicit accommodations for printing. NY Times probably has a print stylesheet, but most websites won't<br> <TabAtkins> florian: it's possible to have a good mobile design but by default it's broken, so we instead render like a desktop by default and let you opt into the good behavior<br> <TabAtkins> florian: So similar here so it's off by default but you can opt into working<br> <flackr> q+<br> <astearns> ack florian<br> <TabAtkins> florian: You mentioned that since it's paginate dit might be too hard to get it right so we just shouldn't do it<br> <TabAtkins> florian: But if people *can* get it right we should let people opt in<br> <TabAtkins> fantasai: I think until we ahve an exapmle, like the NYT has a bunch of animated scrolling articles<br> <TabAtkins> fantasai: If they wrote it naively, what would they get out of it?<br> <TabAtkins> fantasai: I think it woudl be broken<br> <TabAtkins> florian: Right I think it would be broken by default, so turn it off by default<br> <dbaron> amusing historical bug about animation and pagination: https://bugzilla.mozilla.org/show_bug.cgi?id=2586<br> <TabAtkins> florian: so I support it being off by defualt and having an opt-in would be nice. But we can add the opt-in for later<br> <TabAtkins> astearns: there is an example in the NYT with fragmented regions that works great<br> <TabAtkins> fantasai: yeah that's great, but they wrote it specifically for a fragmented context, it wasn't just a continuous media animatio nthat was run thru the paginator<br> <astearns> s/fragmented regions/fragmented regions and hand-coded scroll animations<br> <TabAtkins> flackr: Was thinking about detecting when an animation was declared in an MQ for paged media, and having it carry a flag that lets it work<br> <TabAtkins> I'd really like to avoid that. :(<br> <TabAtkins> flackr: The nice thing is that it's not additional syntax<br> <fantasai> TabAtkins: I would really like to avoid attaching state to something being in a media query<br> <fantasai> TabAtkins: we avoided in the past to avoid media queries implying state<br> <fantasai> TabAtkins: there might be reasons for it<br> <fantasai> TabAtkins: but want to avoid<br> <fantasai> TabAtkins: if we want an opt in, let's have an explicit opt in<br> <fremy> q?<br> <fantasai> TabAtkins: e.g. Opera used to do stuff with paged media and projection<br> <fremy> q+<br> <flackr> ack flackr<br> <fantasai> florian: projection MQ was weird, it made you go full screen or something like that?<br> <myles> +1 to avoiding logic of the form "if this was defined in a media query, take a different behavior"<br> <fantasai> TabAtkins: presence of MQ at least doesn't change your styles<br> <TabAtkins> fremy: do we ahve any paged media that's implemente din any browser?<br> <TabAtkins> fantasai: yeah, when you print<br> <TabAtkins> fremy: Besides that, we already ahve agreement on it not working when we print<br> <TabAtkins> flackr: yeah that was the previous resolution<br> <TabAtkins> astearns: think we're circling a bit, the resolution is to keep it turned off for all paged media, even if it's interactive<br> <TabAtkins> astearns: for now<br> <TabAtkins> astearns: So any objections to clsoing no change?<br> <TabAtkins> RESOLVED: close no change (but without prejudice, examples in the future can change it)<br> <fantasai> fantasai also does not want to figure out the interaction of paging and fragmentation<br> <fantasai> Like as you page, the fragmentation changes, becaus eyou animated the height of something is ... really terrifying<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8688#issuecomment-1645855040 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 16:12:27 UTC