- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 23:06:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-viewport] Is zoom supposed to be non animatable?`, and agreed to the following: * ``RESOLVED: Make `zoom` continuously interpolatable unless implementation difficulties come up`` <details><summary>The full IRC log of that discussion</summary> <bramus> scribe+<br> <bramus> emilio: came up while implementing zoom<br> <bramus> … spec says that its not animatable<br> <bramus> … chrome makes it discrete<br> <bramus> … i think there is no great reason for that<br> <bramus> …zoom is bit special<br> <flackr> q+<br> <bramus> … bc of impl. e.g. affects computed style<br> <bramus> … i think if there are issues like that they should be solvable<br> <bramus> … dont see reason for it not to be animatable<br> <bramus> … only reason not to would be if animating its too easy, its slower than transform<br> <bramus> … e.g. a zoom animation of sth that is abspos<br> <bramus> … transform is faster but no reasons I see other than that<br> <astearns> ack flackr<br> <smfr> q+<br> <bramus> flackr: you mean interpolable?<br> <bramus> emilio: spec says ??<br> <bramus> flackr: wnated to clarify<br> <bramus> … in favor of making them animatable discretely if they dont affect animations<br> <bramus> emilio: right, i think there are two steps here<br> <bramus> … 1/ go to discrete<br> <bramus> … what chrome and firefox do<br> <lea> In terms of language consistency, making it smoothly animatable seems the only reasonable option<br> <bramus> … 2/ animatabable itself<br> <bramus> flackr: agree, similar width and ehgith<br> <bramus> emilio: disagree. zoom does affect things like every other ?? like transform<br> <bramus> flackr: width does also affect transform<br> <bramus> … percentages<br> <bramus> emilio: right<br> <lea> q?<br> <bramus> … then i agree<br> <emilio> s/??/every other length<br> <lea> q+<br> <astearns> ack smfr<br> <emilio> smfr: we specified zoom purely for historical / historical reasons, why are we adding new features<br> <emilio> ... in webkit it's not animatable<br> <emilio> q+<br> <emilio> astearns: we don't have interop right now, so we need to fix something<br> <astearns> ack lea<br> <emilio> lea: Can't comment on the perf concerns<br> <emilio> ... as far as authors are concerned, it's a number-percentage, no reason not to interpolate smoothly<br> <ydaniv> q+<br> <emilio> ... not sure I get the "affects transforms" bit<br> <bramus> emilio: thats a different kind of …<br> <emilio> ... not sure how I'd explain it<br> <emilio> emilio: different kind of inter-property dependency<br> <emilio> lea: I'd push back in the historical artifact<br> <emilio> ... it's a very useful feature<br> <emilio> ... wish we had more interop<br> <emilio> ... e.g. zoom on iframes<br> <emilio> ... don't think authors would animate transforms instead of zoom often<br> <astearns> ack emilio<br> <bramus> emilio: regarding the property dependency thing<br> <bramus> … impl detail<br> <bramus> … i could imagine us being the reason why this not being ???<br> <bramus> … regarding historical artifacts i kinda agree<br> <bramus> … making it consistent if its low effort seems nice<br> <bramus> … for us this change is a one-liner<br> <bramus> … bc zoom already supports interpolation otherwise<br> <smfr> q+<br> <bramus> … only awkardness is that zoom has some magic values<br> <bramus> … e.g. zoom 0 behaves as 1<br> <bramus> … could see authors getting beaten by this<br> <lea> that seems like a separate issue — I wonder how widely zoom: 0 is used<br> <bramus> … making it discrete seems obvious to me<br> <bramus> … no strong opinion<br> <bramus> … dont think its a big deal to make it animatable<br> <astearns> ack ydaniv<br> <emilio> ydaniv: one reason to make something animatable (even discrete) is that sometimes you want to set it during the animation<br> <emilio> ... e.g. put property in the keyframe blocks<br> <emilio> ... you don't want to make that change inside another block<br> <emilio> ... not being able to do that is weird/inconsistent<br> <emilio> ... re. making this interpolatable<br> <emilio> ... I don't see anyone actually scaling stuff using this<br> <emilio> ... you'd use `scale` which is more predictable<br> <emilio> ... but I think discrete animation has its use cases<br> <emilio> q+<br> <astearns> ack smfr<br> <emilio> smfr: one reason I'm a little concern is that one of webkit uses of it (Cmd+) is via the zoom property<br> <emilio> ... it's an implementation detail but we don't want it to start animating<br> <astearns> ack emilio<br> <bramus> emilio: thats obvs something fixables<br> <bramus> … if you put in chrome transition; allow-discrete 1yr it would disable zoom<br> <bramus> … in gecko it is not related to zoom mechanism<br> <bramus> … i am OK with also making it non animatable<br> <bramus> … I dont care<br> <bramus> … but Brian feels strongly about it being apossible to be animatable<br> <bramus> … authors come up with all sorts of use cases<br> <bramus> … given we dont have interop, would you be fine on making it discretely animatable?<br> <bramus> smfr: discretely animatable that it flips at 50%<br> <bramus> … and if you cmd+ and you have a bug<br> <bramus> flackr: but we usually dont transition discrtete props<br> <bramus> emilio: yes, you need to opt in<br> <bramus> smfr: not quite as bad but styll<br> <bramus> s/styll/still<br> <bramus> emilio: should check<br> <bramus> … you need to pick the local and global zoom<br> <bramus> … that seems fixable<br> <bramus> … relatively easily<br> <astearns> q?<br> <bramus> … would you object to resolving on making it discrete?<br> <bramus> smfr: i’m ok with adding discrete<br> <bramus> lea: if both emilio and simon are ok with making it continously animatable then …<br> <bramus> emilio: slight preference for cont. anim. module impl issues<br> <bramus> … if its hard to do, then i’d be happy to ????<br> <bramus> lea: (missed)<br> <bramus> emilio: its not like you can or cant, its more about the effort to improve this legacy feature<br> <bramus> iank_: can start with discrete<br> <bramus> emilio: yes, thats non objectionable bc chrome and firefox do it<br> <bramus> … ??? also seems fine<br> <kizu> Tested with registered custom properties: curiously, still not possible to animate in Chrome and Safari: https://codepen.io/kizu/pen/NPKJVLR?editors=1100<br> <bramus> lea: making it discrete makes those that implements it continously non spec compliant<br> <bramus> iank_: no-one does that right now<br> <lea> PROPOSED RESOLUTION: Make `zoom` continuously interpolatable unless implementation difficulties come up<br> <bramus> astearns: objections?<br> <bramus> RESOLVED: Make `zoom` continuously interpolatable unless implementation difficulties come up<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10872#issuecomment-2628543182 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 January 2025 23:06:18 UTC