Meeting minutes
<astearns> github-bot, take up w3c/
[web-animations-2] Web animations API for specifying timeline phases in animation options.
<github-bot> OK, I'll post this discussion to https://
astearns: first is about timeline phases, assuming rob is going tot ake this one
flackr: lemme make things nice and simple..
<flackr> Proposed resolution in w3c/
flackr: there's a proposed resolution in the comment i linked
flackr: this isadding the ability to the web animations API to specify ranged names and offsets whciih we have already specced for css animations
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
flackr: this shoudl allow us to control the same thhings from javascript animations
flackr: any objections to the proposal?
astearns: i'mm looking througgh, we resolved to go with option 2. the propsed shape is?
<astearns> w3c/
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
astearns: its in this comment here?
astearns: yep, this is it
astearns: alright, any opinions, concerns?
kevin ellis: moving from timing otpoins to animation options, would no logner be able to update range start/end updating timing
kevin ellis: we will need web animation api calls on the a nimation object to be able to get range start/end
kevin ellis: do we have a proposal for getter/setter or function for setting animation range programatically?
flackr: conventionally we'd do the same thing as animation timeline. getter/setter
kevin ellis: i'm in support of that, would like to see resolution
flackr: happy to make that part of the resolution
astearns: any other comments?
astearns: any concern with resolving ono this today?
astearns: proposed is to take the api shape in the linekd comment and add properties to the animation interface along timeline
<bramus> SGTM
astearns: any objections to the propsoed resolution?
astearns: hearing none, we are resolved
RESOLVE: take the api shape int he linked comments and add properties to the animation interface along timeline
RESOLUTION: take the api shape int he linked comments and add properties to the animation interface along timeline
RESOLUTION: take the api shape int he linked comments and add properties to the animation interface along timeline
astearns: anything more on this one?
<astearns> github-bot, take up w3c/
[scroll-animations-1] Allow Anonymous Scroll Progress Timelines to target self
<github-bot> OK, I'll post this discussion to https://
astearns: alright, let me… get the next issue in
astearns: anonymous scroll progress
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
bramus: this is limiting in a way, you cant target the scroller itself
bramus: you can bypass this by creating a named scroll timeline and then using it as an animation timeline, but not very dev friendly
https://
bramus: looking at the comments, folks like `self`
bramus: that's my recommendation
<fantasai> smfr: Is it using the containing block ancestor chain, or the parent chain?
smfr: what algo is used to detemrine the nearest container scroller?
smfr: answer, containing block. which is appropriate.
astearns: any other comments?
astearns: current workaround is a haslte, but is it enough tomerit another keyword
fantasai: i think it does, people create custom names is not great. makes it hard to reuse the thing you're doing
fantasai: better to have this tool. what happens whent he element in question is not in fact a scroll container.
fantasai: better to have this tool. what happens whent he element in question is not in fact a scroll container?
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.
proposed resolution is to add a `self` keyword, which will used what the scroller is and will be well defined
astearns: proposed resolution is to add a `self` keyword, which will used what the scroller is and will be well defined
astearns: any comments or obejections? we are resolved to add a self keyword.
RESOLUTION: add a `self` keyword
<astearns> github-bot, take up w3c/
[scroll-animations-1] Phases for taller than scrollport subjects
<github-bot> OK, I'll post this discussion to https://
astearns: next issue, taller than scrollport stuff.
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.
<bramus> w3c/
bramus: fantasai suggests keep current phases but specify two extra phases, linked int his comment
bramus: entry-crossing and exit-crossing, looks at subject itself while it's crossing that edge
bramus: i dont have a visualization for it unfortunately. there's a spec adjustment that describes it
<astearns> https://
bramus: entry crossing would be subject taller than viewport, or any sized item, crosses the bottom
bramus: until it's end edge coincides with the end edge of the scroller
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
flackr: it's basically the other possible option when we decided the way we did to avoid the overlap of phases for trivial cases
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
<fantasai> illustration
bramus: yes, this was a missing thing int he spec, and with this authors can do oanything they want
<ydaniv> SGTM
astearns: any comments or concerns about adding more keywords?
<flackr> SGTM
sgtm
<fantasai> +1
RESOLUTION: add `entry-crossing` and `exit-crossing` to handle things which could be taller than the scrollport
<Zakim> fantasai, you wanted to discuss follow-up question
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.
astearns: they should match
fantasai: this new keyword tips things in the direction of entry being more appropriate
flackr: i was going to say i dont love the names, but i dont have alternatives
<fantasai> note the current draft uses 'entry'
<fantasai> there's a issue asking if it should be 'enter'
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
flackr: i'm fine to change to entry if that makes more sense
fantasai: is it entry, i just want to close that issue
astearns: resolve on keeping entry as entry
bramus: i found enter to match better, but english isnt my primary language. no scroll feelings
astearns: enter is easier to spell to non english speakers
fantasai: entry is a noun
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
astearns: anyone have concerns with that direction? any objections to keep entry as entry?
RESOLUTION: keep entry as entry
astearns: anything else?
<astearns> github-bot, take up w3c/
[scroll-animations-1] Define how the `source` member of a `ScrollTimeline` corresponding to a `scroll()` timeline is updated
<github-bot> OK, I'll post this discussion to https://
astearns: next.
astearns: this is brians issue, rob
astearns: this is brians issue, rob?
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
flackr: fantasia suggested having the scroll timeline change everytime the thing that would be the source changes, and having it be unique per source
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
flackr: the source and updates that when queried or when generating new times
flackr: as we have implemented right now
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
flackr: correct, have to compare the source.
astearns: wolud you have to do to fiddle with the objects before you do the sourece comparison?
flackr: depends, if we want to mimmick whats happening in computed style, then querying the source will calculate what would be the updated source
flackr: if it's stale
flackr: however, it's a bit odd that makes the sourece inconsistent with the time value, which is intentionally stale. kevin correct me there?
kekvin ellis: timeline time would only be updated once with the frame. if the source changed, it would update to the next frame
flackr: that's a good reason to either revisit the decision or leave the source stale. to be consistent.
astearns: to be consistent with the time, only leave source stale until next frame
flackr: yes
fantasai: i think that makes sense for them to be in sync
flackr: agree
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
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
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…
flackr: and i think animations have set a precedent that is consistent with my proposal
fantasai: ok
astearns: other opinions?
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
astearns: any concerns?
astearns: objections?
<flackr> Proposed resolution: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime.
RESOLUTION: Each anonymous scroll timeline is a different object. The source is updated at the same time as the currentTime.
astearns: next thing we got…
astearns: animation iteration count
<astearns> github-bot, take up w3c/
[scroll-animations-1] Interaction with 'animation-iteration-count'
<github-bot> OK, I'll post this discussion to https://
astearns: who takes this one?
kevin ellis: could outline what's in chrome see if that makes sense
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
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%
kevin ellis: this makes it easy to switch from scroll linked and time based animations
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
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
astearns: any questions about blink's current implementation?
astearns: this address your issue fantasai ?
fantasai: i think so yeah
flackr: we also have to decide wwhat to do about keyframes that have defined they're at a particular point of the timeline
fantasai: yeah, other half of the issue
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
flackr: if you have 2 iterations during enter, it'll repeat that 2 times during the entry phase
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.
fantasai: ok
flackr: ok
fantasai: i liek that, it kinda makes sense
astearns: alright, i think this is beyond my ability to summarize
astearns: what is the proposed resolution?
fantasai: we have 2 right?
fantasai: first, we do apply iteraction count and we divide the duration by the iteration count
<fantasai> w3c/
kevin ellis: dividing the active interval by the iteraction count to get the intrinsic iteration duration
astearns: that's the first resolution?
astearns: any objections?
astearns: leave it up to editors to spec terms of theyre just ways to express the resolution
astearns: resolved on that
<fantasai> https://
RESOLUTION: divide the active interval by the iteration count to get the intrinsic iteration duration
astearns: what else?
flackr: 2nd was, we resolve the named keyframe offsets against the active interval and they will be repeated in these subsequent iterations
RESOLUTION: assume an interaction count of 1, attach all the frames. that creates something that you scale down when you apply the iteraction count.
astearns: anything else on this?
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
astearns: next issue!
<astearns> github-bot, take up w3c/
[scroll-animations-1] View progress contain of a sticky positioned elements on the edges
<github-bot> OK, I'll post this discussion to https://
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
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
YehonatanDaniv: later rob had a proposal because more issues were raised on the same issue
flackr: so when we were workign out the ranges for all these phases, we rely on the principal box
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
flackr: similar for the start value, or the minium sticky offset that it would have at the beginning of scroll
flackr: this makes all thephases match the visual expectation of the elements position
flackr: which has a related issue that we shouldnt be observing transforms, like other layout primitives
fantasai: i think that's a separate topic, lets take them one at a time
YehonatanDaniv: also what you wrote, that it's already in the spec, that it was implemented differently
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
flackr: then thingd are worse if it includes a transform
flackr: should lwe talk about this other thing first?
fantasai: want to resolve we ignore transforms then switch back?
fantasai: proposed resolution is transforms are ignored when caclculating timeline ranges
flackr: major point of frustration, adam and bramus may talk about this as well
astearns: it's a frustration that they have to be ignored?
flackr: no, that's they're currently not ignored
bramus: result now is you get into situations where the entire thing flickers
i had to train myself out of this bug
flackr: if we could ignore the transform position, it makes devs lives easier. makes sticky position easier to reason about
astearns: hearing consensus that we ignore transforms when calculating timeline ranges
RESOLUTION: ignore transforms when calculating timeline ranges
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
astearns: seeing thumbs up, any concerns?
<fantasai> +1
RESOLUTION: 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
<fantasai> Not sure how to spec it, but I think I agree with what we should *try* to spec :)
astearns: anything else on this issue?
YehonatanDaniv: probably better in a separate issue? there were other things
astearns: given fantasai's concerns about how to get it specced, let get the spec text then raise issues on that
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
astearns: rob, can you pick something for the remaianing time?
astearns: rob, can you pick something for the remaining time?
<astearns> github-bot, take up w3c/
[scroll-animations-1] [web-animations-2] Clarifying behavior of getCurrentTime(rangeName)
<github-bot> OK, I'll post this discussion to https://
flackr: the behavior of get current time
flackr: the behavior of `getCurrentTime`
flackr: kevin want to introducer the issue?
flackr: kevin raised the issue that in the spec getCurrentTime produced values between 0 and 100%, but it does produce times outside of it
flackr: proposal is `getCurrentTime` should just match the internal calculation for the time value
kevin: we're talking about removing the clamping
flackr: we already resolved in a different issue that the current time is not clamped, this updates the spec to be consistent with that
fantasai: and then it seems like if that range is 0, and if youre' outside of it you return infinity
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
fantasai: so we have to return something, and plus or minus infinity for a 0 range is the only reasonable option
flackr: yeah, just to sayyou're before or after that range
astearns: alright, any concerns or comments on this proposal?
RESOLUTION: `getCurrentTime` should just match the internal calculation for the time value which is unclamped