17:00:47 RRSAgent has joined #css 17:00:51 logging to https://www.w3.org/2023/02/01-css-irc 17:00:51 RRSAgent, make logs Public 17:00:52 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:01:40 present+ 17:02:28 argyle has joined #css 17:02:50 present+ 17:02:59 present+ 17:03:06 JenStrickland has joined #css 17:03:08 smfr has joined #css 17:03:13 present+ 17:03:15 present+ 17:03:55 github-bot, take up https://github.com/w3c/csswg-drafts/issues/7589 17:03:55 Topic: [web-animations-2] Web animations API for specifying timeline phases in animation options. 17:03:55 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7589. 17:04:01 astearns: first is about timeline phases, assuming rob is going tot ake this one 17:04:10 flackr: lemme make things nice and simple.. 17:04:14 Proposed resolution in https://github.com/w3c/csswg-drafts/issues/7589#issuecomment-1380842759 17:04:24 flackr: there's a proposed resolution int eh comment i linked 17:04:58 s/int eh/in the/ 17:05:20 flackr: this isadding the ability to the web animations API to specify ranged names and offsets whciih we have already specced for css animations 17:05:40 bradk has joined #css 17:05:44 flackr: brian has looked at this proposed and agrees with the current designb, seems fine to add this to the animation options alongside the timeline attribute 17:05:55 flackr: this shoudl allow us to control the same thhings from javascript animations 17:06:04 flackr: any objections to the proposal? 17:06:19 astearns: i'mm looking througgh, we resolved to go with option 2. the propsed shape is? 17:06:40 https://github.com/w3c/csswg-drafts/issues/7589#issuecomment-1380842759 17:06:45 flackr: its all consistentent with the earlier resolution, but it's not going to end delay and start delay because we moved it to it's own property 17:06:49 astearns: its in this comment here? 17:07:00 astearns: yep, this is it 17:07:10 astearns: alright, any opinions, concerns? 17:07:58 kevin ellis: moving from timing otpoins to animation options, would no logner be able to update range start/end updating timing 17:08:00 present+ 17:08:11 kevin ellis: we will need web animation api calls on the a nimation object to be able to get range start/end 17:08:23 kevin ellis: do we have a proposal for getter/setter or function for setting animation range programatically? 17:08:33 flackr: conventionally we'd do the same thing as animation timeline. getter/setter 17:08:39 kevin ellis: i'm in support of that, would like to see resolution 17:08:46 flackr: happy to make that part of the resolution 17:08:59 astearns: any other comments? 17:09:11 astearns: any concern with resolving ono this today? 17:09:32 astearns: proposed is to take the api shape in the linekd comment and add properties to the animation interface along timeline 17:09:37 SGTM 17:09:43 astearns: any objections to the propsoed resolution? 17:09:49 astearns: hearing none, we are resolved 17:10:15 RESOLVE: take the api shape int he linked comments and add properties to the animation interface along timeline 17:10:22 RESOLVEd: take the api shape int he linked comments and add properties to the animation interface along timeline 17:10:25 RESOLVED: take the api shape int he linked comments and add properties to the animation interface along timeline 17:10:47 astearns: anything more on this one? 17:10:57 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8227 17:10:57 Topic: [scroll-animations-1] Allow Anonymous Scroll Progress Timelines to target self 17:10:57 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8227. 17:11:03 astearns: alright, let me… get the next issue in 17:11:14 astearns: anonymous scroll progress 17:11:32 bradk has joined #css 17:11:33 bramus: when you create an anonymous scroll tiemline, you can use a function for that, targets nearest or root. nearest is the nearest ancentor scroll container 17:11:41 bramus: this is limiting in a way, you cant target the scroller itself 17:11:43 present + 17:11:53 present+ 17:11:59 q+ 17:12:02 bramus: you can bypass this by creating a named scroll timeline and then using it as an animation timeline, but not very dev friendly 17:12:30 https://www.irccloud.com/pastebin/yXONpCDN/bram 17:12:40 bramus: looking at the comments, folks like `self` 17:12:44 bramus: that's my recommendation 17:12:44 ack smfr 17:13:22 smfr: Is it using the containing block ancestor chain, or the parent chain? 17:13:24 smfr: what algo is used to detemrine the nearest container scroller? 17:13:35 smfr: answer, containing block. which is appropriate. 17:13:57 astearns: any other comments? 17:14:13 astearns: current workaround is a haslte, but is it enough tomerit another keyword 17:14:29 fantasai: i think it does, people create custom names is not great. makes it hard to reuse the thing you're doing 17:14:42 fantasai: better to have this tool. what happens whent he element in question is not in fact a scroll container. 17:14:47 fantasai: better to have this tool. what happens whent he element in question is not in fact a scroll container? 17:15:15 flackr: we have to answer that question for named scroll timelines right? my [proposal would be that you get a scoll timeline but it has time undefined because the thing being observed is not a scroller. animatoin has no effect. 17:16:12 proposed resolution is to add a `self` keyword, which will used what the scroller is and will be well defined 17:16:18 astearns: proposed resolution is to add a `self` keyword, which will used what the scroller is and will be well defined 17:16:28 astearns: any comments or obejections? we are resolved to add a self keyword. 17:16:35 RESOLVED: add a `self` keyword 17:16:41 github-bot, take up https://github.com/w3c/csswg-drafts/issues/7973 17:16:41 Topic: [scroll-animations-1] Phases for taller than scrollport subjects 17:16:41 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/7973. 17:16:52 astearns: next issue, taller than scrollport stuff. 17:17:37 bramus: essence of this issue boils down to the largest part of the issue, you cant do animations while they scroll into view or not when using the exisrting phases. this onlyu applies to taller than viewport subjects. 17:17:59 https://github.com/w3c/csswg-drafts/issues/7973#issuecomment-1349970567 17:18:02 bramus: fantasai suggests keep current phases but specify two extra phases, linked int his comment 17:18:19 bramus: entry-crossing and exit-crossing, looks at subject itself while it's crossing that edge 17:18:35 bramus: i dont have a visualization for it unfortunately. there's a spec adjustment that describes it 17:19:10 https://github.com/bramus/csswg-drafts/commit/392a4deefdc546591ab48ed899aded52bd698467 17:19:25 bramus: entry crossing would be subject taller than viewport, or any sized item, crosses the bottom 17:19:38 bramus: until it's end edge coincides with the end edge of the scroller 17:19:59 bramus: exit crossing is when the start edge of the subject coincides with the start edge of the scroller, until it moves entirely out of the scroller 17:20:26 flackr: it's basically the other possible option when we decided the way we did to avoid the overlap of phases for trivial cases 17:20:49 astearns: we expect people will still use entry and exit for most cases, but these new ones are for cases where it can be taller 17:20:57 illustration -> https://user-images.githubusercontent.com/213073/198659234-76702d8b-9770-43a0-9ee9-d81723e8c15b.png 17:20:59 bramus: yes, this was a missing thing int he spec, and with this authors can do oanything they want 17:21:06 gtalbot has left #css 17:21:28 SGTM 17:21:33 astearns: any comments or concerns about adding more keywords? 17:21:35 SGTM 17:21:37 sgtm 17:21:39 +1 17:22:02 RESOLVED: add `entry-crossing` and `exit-crossing` to handle things which could be taller than the scrollport 17:22:20 ack fantasai 17:22:20 fantasai, you wanted to discuss follow-up question 17:22:41 fantasai: we had discussed having the name of ranges be enter an exit or entry and exit. given we have entry-crossing, we should go with entry and exit. 17:22:54 astearns: they should match 17:23:05 fantasai: this new keyword tips things in the direction of entry being more appropriate 17:23:15 flackr: i was going to say i dont love the names, but i dont have alternatives 17:23:20 note the current draft uses 'entry' 17:23:28 there's a issue asking if it should be 'enter' 17:23:33 flackr: another way to think of this, is whether the element intersects the entry/exit edges of the scroller. but i dont think that helps us get a better name 17:23:47 flackr: i'm fine to change to entry if that makes more sense 17:23:53 fantasai: is it entry, i just want to close that issue 17:24:02 q+ 17:24:17 astearns: resolve on keeping entry as entry 17:24:28 ack bramus 17:24:40 bramus: i found enter to match better, but english isnt my primary language. no scroll feelings 17:24:42 q- 17:24:54 astearns: enter is easier to spell to non english speakers 17:25:05 fantasai: enter is a noun 17:25:11 s/enter/entry/ 17:25:28 astearns: my suggestion is we resolve now on keeping entry for consistency, but like everythihng, if peoeple come up with better ideas we can go ovoer this again in the future 17:25:47 astearns: anyone have concerns with that direction? any objections to keep entry as entry? 17:25:54 RESOLVED: keep entry as entry 17:26:08 astearns: anything else? 17:26:11 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8204 17:26:12 Topic: [scroll-animations-1] Define how the `source` member of a `ScrollTimeline` corresponding to a `scroll()` timeline is updated 17:26:12 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8204. 17:26:13 astearns: next. 17:26:27 astearns: this is brians issue, rob 17:26:30 astearns: this is brians issue, rob? 17:27:00 flackr: so brian pointed out that since we have a programmatic api to access a scroll timeline source, and scroll timelines for that matter, it needs to be well defined when that changes and when it's created 17:27:22 flackr: fantasia suggested having the scroll timeline change everytime the thing that would be the source changes, and having it be unique per source 17:28:00 flackr: i suggested that we follow the current chrome implementation which is more closely aligned to animation objects, where the element holds a scroll timeline entry and internally it points to 17:28:26 flackr: the source and updates that when queried or when generating new times 17:28:33 flackr: as we have implemented right now 17:29:18 fantasai: i'm not 100% clear on this. question is, if i have multiple references to the same scroll container scroll timeline, does that mean each reference is unique and i wouldnt be able to tell if they reference the same thing unless i reference the source values 17:29:23 flackr: correct, have to compare the source. 17:29:43 astearns: wolud you have to do to fiddle with the objects before you do the sourece comparison? 17:30:25 flackr: depends, if we want to mimmick whats happening in computed style, then querying the source will calculate what would be the updated source 17:30:29 flackr: if it's stale 17:30:55 flackr: however, it's a bit odd that makes the sourece inconsistent with the time value, which is intentionally stale. kevin correct me there? 17:31:08 kekvin ellis: timeline time would only be updated once with the frame. if the source changed, it would update to the next frame 17:31:23 flackr: that's a good reason to either revisit the decision or leave the source stale. to be consistent. 17:31:42 astearns: to be consistent with the time, only leave source stale until next frame 17:31:43 flackr: yes 17:32:01 fantasai: i think that makes sense for them to be in sync 17:32:04 flackr: agree 17:32:26 fantasai: not sure about unique identities per reference, but i just dont know which way makes mroe sense. happy to go with what other people think is the right thing to do 17:32:51 flackr: they would be the same if they used a named timeline. but this is anonymous timelines, generated on the fly for that element, and it can change 17:33:18 flackr: there'd be a lot of non trivial ocmplexity updating those if we needed them to be identity functions to the scroller. they'd also need idendity functions with all the args. which… 17:33:34 flackr: and i think animations have set a precedent that is consistent with my proposal 17:33:36 fantasai: ok 17:33:44 astearns: other opinions? 17:34:16 astearns: i'm fine resolving that the source is computed when you ask for it and it's updated at the same time as other data on the object 17:34:24 astearns: any concerns? 17:34:38 astearns: objections? 17:34:49 dino7 has joined #css 17:35:27 Proposed resolution: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime. 17:35:58 RESOLVED: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime. 17:36:14 astearns: next thing we got… 17:36:20 astearns: animation iteration count 17:36:21 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8233 17:36:22 Topic: [scroll-animations-1] Interaction with 'animation-iteration-count' 17:36:22 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8233. 17:36:33 astearns: who takes this one? 17:36:56 kevin ellis: could outline what's in chrome see if that makes sense 17:37:26 kevin ellis: for scroll linked, the duration is 100% so we can workk backwards form auto. starting from 100%, remove start and end delay, take that result divided by iteration count, to get the itnrinsic iteration duration 17:37:45 kevin ellis: this is consistent with time values rather than percentages, working out the effect end time is, then normalizing to match that to 100% 17:37:56 kevin ellis: this makes it easy to switch from scroll linked and time based animations 17:38:24 kevin ellis: int he case of time based, you're working forward to calc the effect end, for scrollbased you're working backwards from end target 100% to the iteration duration needs to be for everything to line up 17:38:45 flackr: this is also paving the way for the web animations 2 proposals for sequence effect to and group effect for those to infer their duration 17:39:02 bradk has joined #css 17:39:06 astearns: any questions about blink's current implementation? 17:39:20 astearns: this address your issue fantasai ? 17:39:23 fantasai: i think so yeah 17:39:46 flackr: we also have to decide wwhat to do about keyframes that have defined they're at a particular point of the timeline 17:39:50 fantasai: yeah, other half of the issue 17:39:51 bradk has joined #css 17:40:13 flackr: my proposal was that we work out their relative proportions and then those proportions repeat. they'll no longer line up with what they declared, b ut many cases this will lmatch author intent 17:40:25 flackr: if you have 2 iterations during enter, it'll repeat that 2 times during the entry phase 17:40:45 fantasai: you assume an interaction count of 1, attach all the frames. that creates something that you scale down when you apply the iteraction count. 17:40:48 fantasai: ok 17:40:50 flackr: ok 17:40:56 fantasai: i liek that, it kinda makes sense 17:41:08 astearns: alright, i think this is beyond my ability to summarize 17:41:16 astearns: what is the proposed resolution? 17:41:19 fantasai: we have 2 right? 17:41:46 fantasai: first, we do apply iteraction count and we divide the duration by the iteration count 17:41:54 -> https://github.com/w3c/csswg-drafts/issues/8233#issuecomment-1375890456 17:42:11 kevin ellis: dividing the active interval by the iteraction count to get the intrinsic iteration duration 17:42:27 astearns: that's the first resolution? 17:42:34 astearns: any objections? 17:43:03 astearns: leave it up to editors to spec terms of theyre just ways to express the resolution 17:43:14 astearns: resolved on that 17:43:26 -> https://www.w3.org/TR/web-animations-1/#the-active-interval 17:43:40 RESOLVED: divide the active interval by the iteration count to get the intrinsic iteration duration 17:43:49 astearns: what else? 17:44:25 flackr: 2nd was, we resolve the named keyframe offsets against the active interval and they will be repeated in these subsequent iterations 17:44:53 RESOLVED: assume an interaction count of 1, attach all the frames. that creates something that you scale down when you apply the iteraction count. 17:45:06 astearns: anything else on this? 17:45:22 astearns: i imagine as you specify this out, there will be a few little details that can be editor discression or we can resolve later 17:45:33 astearns: next issue! 17:45:34 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8298 17:45:34 Topic: [scroll-animations-1] View progress contain of a sticky positioned elements on the edges 17:45:34 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8298. 17:47:30 YehonatanDaniv: when you have a sticky positioned element and this is the subject for the view timeline, it has a top 0 so its effective stack point is both the end of the contained range and the beginning of the exit range 17:47:56 YehonatanDaniv: the main issue was around adding the phase of the stickiness to also be included int he contained range, so this would match expectations 17:48:15 YehonatanDaniv: later rob had a proposal because more issues were raised on the same issue 17:48:33 flackr: so when we were workign out the ranges for all these phases, we rely on the principal box 17:48:57 flackr: proposal is that when we try and work out the end of these ranges, we treat sticky elements as if it has it's max sticky offset, the offset that it would get at the end scrollposition 17:49:10 flackr: similar for the start value, or the minium sticky offset that it would have at the beginning of scroll 17:49:23 flackr: this makes all thephases match the visual expectation of the elements position 17:49:44 flackr: which has a related issue that we shouldnt be observing transforms, like other layout primitives 17:49:52 fantasai: i think that's a separate topic, lets take them one at a time 17:50:04 YehonatanDaniv: also what you wrote, that it's already in the spec, that it was implemented differently 17:50:30 flackr: if we dont do this, the proposal for sticky position doesnt work as well because the sticky offset isnt necessarily the same direction as the scroll if you include the transform 17:50:42 flackr: then thingd are worse if it includes a transform 17:50:47 flackr: should lwe talk about this other thing first? 17:51:00 fantasai: want to resolve we ignore transforms then switch back? 17:51:22 fantasai: proposed resolution is transforms are ignored when caclculating timeline ranges 17:51:34 flackr: major point of frustration, adam and bramus may talk about this as well 17:51:42 astearns: it's a frustration that they have to be ignored? 17:51:49 flackr: no, that's they're currently not ignored 17:51:59 bramus: result now is you get into situations where the entire thing flickers 17:52:15 i had to train myself out of this bug 17:52:30 flackr: if we could ignore the transform position, it makes devs lives easier. makes sticky position easier to reason about 17:52:42 astearns: hearing consensus that we ignore transforms when calculating timeline ranges 17:52:54 RESOLVED: ignore transforms when calculating timeline ranges 17:53:28 flackr: proposal for this is that the start position for view timeline uses the minimum sticky offset or the offset form the start of the scroll, and the end position uses the max sticky offset 17:53:38 astearns: seeing thumbs up, any concerns? 17:53:49 +1 17:53:55 RESOLVED: the start position for view timeline uses the minimum sticky offset or the offset form the start of the scroll, and the end position uses the max sticky offset 17:54:03 Not sure how to spec it, but I think I agree with what we should *try* to spec :) 17:54:12 astearns: anything else on this issue? 17:54:24 YehonatanDaniv: probably better in a separate issue? there were other things 17:54:36 astearns: given fantasai's concerns about how to get it specced, let get the spec text then raise issues on that 17:54:54 fantasai: it's a matter of, do we have the vocab to talk about this? maybe not, and we need the spec to update to provide that 17:55:11 astearns: rob, can you pick something for the remaianing time? 17:55:16 astearns: rob, can you pick something for the remaining time? 17:55:31 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8114 17:55:32 Topic: [scroll-animations-1] [web-animations-2] Clarifying behavior of getCurrentTime(rangeName) 17:55:32 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8114. 17:55:33 flackr: the behavior of get current time 17:55:45 flackr: the behavior of `getCurrentTime` 17:55:55 flackr: kevin want to introducer the issue? 17:56:21 flackr: kevin raised the issue that in the spec getCurrentTime produced values between 0 and 100%, but it does produce times outside of it 17:56:33 flackr: proposal is `getCurrentTime` should just match the internal calculation for the time value 17:56:41 kevin: we're talking about removing the clamping 17:56:56 flackr: we already resolved in a different issue that the current time is not clamped, this updates the spec to be consistent with that 17:57:12 fantasai: and then it seems like if that range is 0, and if youre' outside of it you return infinity 17:57:40 flackr: if you used getCurrentTime and then set this time on anoather animation, returning plus or minus infinity would give you the same effect that that timeline wouuld produce, because you're forcing it into it's before or after phase. so i thought it'd be a good thing to do 17:58:04 fantasai: so we have to return something, and plus or minus infinity for a 0 range is the only reasonable option 17:58:10 flackr: yeah, just to sayyou're before or after that range 17:58:37 astearns: alright, any concerns or comments on this proposal? 17:59:11 RESOLVED: `getCurrentTime` should just match the internal calculation for the time value which is unclamped 17:59:52 topic: end 17:59:57 zakim, end meeting 17:59:57 As of this point the attendees have been tantek, flackr, bramus, argyle, ydaniv, JenStrickland, miriam, smfr 17:59:59 RRSAgent, please draft minutes v2 18:00:00 I have made the request to generate https://www.w3.org/2023/02/01-css-minutes.html Zakim 18:00:07 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 18:00:07 Zakim has left #css 18:00:32 https://github.com/w3c/csswg-drafts/pull/8219 18:00:54 Zakinthos didn’t see me? 18:01:03 Zakim 18:01:42 present+ 18:01:55 https://github.com/w3c/csswg-drafts/pull/8219/files 19:51:32 jensimmons has joined #css 21:37:43 gtalbot has joined #css 21:38:55 gtalbot has left #css 21:59:52 masonf has joined #css 21:59:54 TC has joined #CSS 22:30:24 jensimmons has joined #css 23:22:16 flackr has joined #css 23:51:41 PaulG has joined #css 23:58:30 TabAtkins has changed the topic to: Feb 1 APAC agenda: https://lists.w3.org/Archives/Public/www-style/2023Feb/0000.html 23:58:42 Rossen_ has joined #css 23:59:22 Zakim has joined #css 23:59:32 Zakim, start meeting 23:59:32 RRSAgent, make logs Public 23:59:33 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference