- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 14:33:54 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `entry/exit transitions for view timeline effects`, and agreed to the following: * `RESOLVED: Accept all of fantasai's bullet points from her summary, except for the keyword+% in @keyframes` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: entry/exit transitions for view timeline effects<br> <fantasai> Summary at https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1175722383<br> <TabAtkins> TabAtkins: ah yeah i was at this breakout, i agree with the conclusions<br> <TabAtkins> [multiple people were in this breakout, including smfr from apple who's not at this meeting]<br> <TabAtkins> astearns: Anyone at the meeting who have any concerns about the line items?<br> <TabAtkins> astearns: my inclination is to take the bullets unless someone has a concern<br> <TabAtkins> ydaniv: regarding changing the @keyframes rule, adding the keyword+%<br> <flackr> qq+<br> <TabAtkins> ydaniv: imho, this would be a mistake becuase these are timing options<br> <bramus> Link: https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1144946715<br> <TabAtkins> ydaniv: what we have in keyframes are offsets<br> <TabAtkins> ydaniv: mixing these are wrong<br> <TabAtkins> ydaniv: would be later confusing, as we might have some of these in keyframes, and some define din the animation itself, and which would win?<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to flackr<br> <TabAtkins> flackr: the way these are resolved, they resolve to offsets<br> <TabAtkins> flackr: it's basically a calculation that becomes a normal keyframe offset, based on your timeline<br> <TabAtkins> astearns: so this is authoring convenience?<br> <TabAtkins> flackr: yes<br> <TabAtkins> ydaniv: but like, exit/contain/enter map to seconds in a normal timeline<br> <TabAtkins> ydaniv: so those look like timing options<br> <TabAtkins> flackr: It doesn't affect the times of those durations<br> <TabAtkins> flackr: it maps to the offset in your animation that is the timeline progress<br> <bramus> See visualization (from the breakout): https://excalidraw.com/#room=59388d327d8f3aa8ddb2,6FU4m3Fw4huQ-JGyP23o5A<br> <TabAtkins> flackr: if that's outside your animation's duration, that's fine, it's like specifying a keyframe of -50% or 150%<br> <TabAtkins> astearns: does that address you concern, yehonatan?<br> <bramus> q+<br> <TabAtkins> ydaniv: not really convinced, but if rob is sure this is okay<br> <TabAtkins> astearns: i see two ways forward for this line item. this one seems separable, so we could resolve to do everything but this, and open a separate issue for it; or we could resolve to do it all, and you raise an issue to question it.<br> <TabAtkins> flackr: confirm that it's separable<br> <TabAtkins> ydaniv: yeah let's open a separate issue and continue discussion there<br> <TabAtkins> ydaniv: if we could defer this issue it would be nice<br> <TabAtkins> astearns: okay, any discussion on the rest?<br> <TabAtkins> bramus: the syntax that rob came up with seems fairly reasonable and logical if you think of the phases<br> <TabAtkins> bramus: and their %s<br> <TabAtkins> bramus: It's very understandable for authors, I think it makes sense<br> <TabAtkins> bramus: i don't see why we shouldn't move this forward<br> <TabAtkins> bramus: there have been some back and forths on what to do, and this seems very reasonable<br> <TabAtkins> astearns: right, not moving this out with prejudice<br> <TabAtkins> astearns: just want to make sure we make progress on the rest first<br> <TabAtkins> ack bramus<br> <TabAtkins> astearns: any concerns with anything else?<br> <TabAtkins> astearns: bramus you had two extra notes, is that part?<br> <TabAtkins> bramus: No, they're part of the thing we just sliced off<br> <TabAtkins> astearns: So proposed resolution is to accept all the bullet points from fantasai's summary, except for the keyword+% in @keyframes; we'll separate that to another issue<br> <TabAtkins> fantasai: That is the core part of this issue<br> <TabAtkins> astearns: rob mentioned this is just author convenience<br> <TabAtkins> flackr: You can bind to a specific phase<br> <TabAtkins> flackr: this give syou the ability to more conveniently say, within a @keyframes, follow these phases<br> <TabAtkins> flackr: it does mean you can't do one single animation that's an entry/exit, you ahve to split it up<br> <TabAtkins> fantasai: right it's not awesome<br> <TabAtkins> fantasai: you frequently want to ahve one animation<br> <TabAtkins> fantasai: i'm totally okay with resolving on it all and then discussing it<br> <TabAtkins> fantasai: but i don't think leaving it out is closing the issue properly<br> <TabAtkins> bramus: I follow elika on this one<br> <TabAtkins> astearns: so proposed resolution is [repeated from last time]<br> <TabAtkins> astearns: continue the discussion on the omitted point in this issue<br> <TabAtkins> astearns: Objections?<br> <flackr> I agree this is a really valuable addition to the issue<br> <TabAtkins> RESOLVED: Accept all of fantasai's bullet points from her summary, except for the keyword+% in @keyframes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7044#issuecomment-1204032112 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 14:33:56 UTC