[CSSWG] Minutes Animations Breakout 2023-02-01 [scroll-animations-1][web-animations-2]

   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

Scroll Animations and Web Animations

   Specifying timeline phases in animation options
   - RESOLVED: take the API shape in the linked comments and add
               properties to the animation interface along timeline

    Allow Anonymous Scroll Progress Timelines to target self
    - RESOLVED: Add 'self' keyword to ''scroll()''

    Phases for taller-than-scrollport subjects
    - RESOLVED: Add entry-crossing and exit-crossing phases
    - RESOLVED: Use entry (not enter) and exit as phase keywords

    How `ScrollTimeline.source` of a `scroll()` timeline is updated
    - RESOLVED: Each anonymous scroll timeline is a different object.
                .source is updated at the same time as .currentTime.

    Scroll Animations interaction with 'animation-iteration-count'
    - RESOLVED: divide the active interval by the iteration count to get
                the intrinsic iteration duration
    - RESOLVED: assume an interaction count of 1, attach all the frames.
                That creates something that you scale down when you apply
                the iteration count.

    View progress contain of a sticky positioned elements on the edges
    - RESOLVED: Ignore transforms when calculating timeline ranges.
    - 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.

    Range of getCurrentTime(rangeName)
    - RESOLVED: `getCurrentTime` should match the internal calculation
                for the time value, which is unclamped


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0013.html
Logs: https://www.w3.org/2023/02/01-css-irc

   Adam Argyle
   Tantek Çelik
   Yehonatan Daniv
   Kevin Ellis
   Elika Etemad
   Robert Flack
   Simon Fraser
   Brad Kemper
   Alan Stearns
   Miriam Suzanne
   Jennifer Strickland
   Bramus Van Damme

Scribe: argyle

<jensimmons> Interop 2023! https://wpt.fyi/interop-2023

Web Animations 2

Web animations API for specifying timeline phases in animation options
github: https://github.com/w3c/csswg-drafts/issues/7589

   astearns: first is about timeline phases, assuming rob is going to
             take this one
   flackr: lemme make things nice and simple...
   <flackr> Proposed resolution in
   flackr: there's a proposed resolution in the comment i linked
   flackr: this is adding the ability to the Web Animations API to specify
           ranged names and offsets which we have already specced for CSS
   flackr: brian has looked at this proposed and agrees with the current
           design, seems fine to add this to the animation options
           alongside the timeline attribute
   flackr: this should allow us to control the same things from javascript
   flackr: any objections to the proposal?
   astearns: I'm looking through, we resolved to go with option 2.
             the proposed shape is?
   flackr: its all consistent 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: it's in this comment here?
   astearns: yep, this is it
   astearns: alright, any opinions, concerns?

   kevers: moving from timing options to animation options, would no
           longer be able to update range start/end updating timing
   kevers: we will need web animation API calls on the Animation object
           to be able to get range start/end
   kevers: do we have a proposal for getter/setter or function for setting
           animation range programmatically?
   flackr: conventionally we'd do the same thing as animation timeline.
   kevers: 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 on this today?
   astearns: proposed is to take the API shape in the linked comment and
             add properties to the animation interface along timeline
   <bramus> SGTM
   astearns: any objections to the proposed resolution?
   astearns: hearing none, we are resolved
   RESOLVED: take the API shape in the linked comments and add properties
             to the animation interface along timeline

   astearns: anything more on this one?

Allow Anonymous Scroll Progress Timelines to target self
github: https://github.com/w3c/csswg-drafts/issues/8227

   astearns: alright, let me… get the next issue in
   astearns: anonymous scroll progress
   bramus: when you create an anonymous scroll timeline, you can use a
           function for that, targets nearest or root. `nearest` is the
           nearest ancestor scroll container
   bramus: this is limiting in a way, you can't target the scroller
   bramus: you can bypass this by creating a named scroll timeline and
           then using it as an animation timeline, but not very friendly
   bramus: there were 2 suggestions
           1. relax nearest so it considers the element itself first
           2. add an extra keyword, currently named self
   bramus: looking at the comments, folks like `self`
   bramus: that's my recommendation
   smfr: what algo is used to determine the nearest container scroller?
   smfr: Is it using the containing block ancestor chain, or the parent
   smfr: answer, containing block, is appropriate.

   astearns: any other comments?
   astearns: current workaround is a hassle, but is it enough to merit
             another keyword
   fantasai: I think it does, making people create custom names is not
             great. Makes it hard to reuse the thing you're doing
   fantasai: better to have this tool.

   fantasai: what happens when the 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. Animation therefore has no effect.

   astearns: proposed resolution is to add a `self` keyword, which will
             used to reference the scroller itself.
   astearns: any comments or objections?
   RESOLVED: add a `self` keyword

Phases for taller-than-scrollport subjects
github: https://github.com/w3c/csswg-drafts/issues/7973

   astearns: next issue, taller than scrollport stuff.
   bramus: essence of this issue boils down to the largest part of the
           issue, you can't do animations while they scroll into view
           or not when using the existing phases. this only applies to
           taller than viewport subjects.
   bramus: fantasai suggests keep current phases but specify two extra
           phases, linked in this comment
   bramus: entry-crossing and exit-crossing: looks at subject itself
           while it's crossing that edge
   bramus: I don't have a visualization for it unfortunately. There's a
          spec adjustment that describes it
   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
   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
   <fantasai> illustration -> 
   bramus: yes, this was a missing thing in the spec, and with this
           authors can do anything they want
   astearns: any comments or concerns about adding more keywords?
   <ydaniv> SGTM
   <flackr> SGTM
   <argyle> sgtm
   <fantasai> +1
   RESOLVED: add `entry-crossing` and `exit-crossing` to handle things
             which could be taller than the scrollport

entry vs enter

   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
   <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 don't
           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 isn't 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 everything, if people come up with
             better ideas we can go over this again in the future
   astearns: anyone have concerns with that direction? any objections
             to keep entry as entry?
   RESOLVED: keep entry as entry
   astearns: anything else?

How `ScrollTimeline.source` of a `scroll()` timeline is updated
github: https://github.com/w3c/csswg-drafts/issues/8204

   astearns: next.
   astearns: this is brian's 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: fantasai suggested having the scroll timeline change every
           time 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 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 wouldn't be
             able to tell if they reference the same thing unless I
             reference the source values?
   flackr: correct, have to compare the source.
   astearns: would you have to do to fiddle with the objects before you
             do the source comparison?
   flackr: depends, if we want to mimic whats happening in computed
           style, then querying the source will calculate what would be
           the updated source if it's stale
   flackr: however, it's a bit odd that makes the source inconsistent
            with the time value, which is intentionally stale. kevin
            correct me there?
   kevers: 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
             don't know which way makes more 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 complexity updating those if
           we needed them to be identity functions to the scroller.
           They'd also need identity 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.
   RESOLVED: Each anonymous scroll timeline is a different object.
             The source is updated at the same time as the currentTime.

Scroll Animations interaction with 'animation-iteration-count'
github: https://github.com/w3c/csswg-drafts/issues/8233

   astearns: next thing we got…
   astearns: animation iteration count
   astearns: who takes this one?
   kevers: could outline what's in chrome see if that makes sense

   kevers: for scroll linked, the duration is 100% so we can work
           backwards form auto. Starting from 100%, remove start and
           end delay, take that result divided by iteration count,
           to get the intrinsic iteration duration.
   kevers: this is consistent with time values rather than percentages,
           working out the effect end time is, then normalizing to match
           that to 100%.
   kevers: this makes it easy to switch from scroll linked and time
           based animations

   kevers: in the case of time-based, you're working forward to calculate
           the effect end, for scroll-based 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 what 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, but many cases this will match the
           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: Did I understand correctly?
   flackr: yes
   fantasai: i like 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 iteration-count and we divide the
             duration by the iteration count
   <fantasai> -> 
   kevers: dividing the active interval by the iteration count to get
           the intrinsic iteration duration
   astearns: that's the first resolution?
   * fantasai wonders if "active interval" is a defined term
   * flackr it has a definition in web-animations-1, complex but can be
            simplified as range minus delays
   <fantasai> -> https://www.w3.org/TR/web-animations-1/#the-active-interval
   astearns: any objections?
   astearns: leave it up to editors to spec terms as they're just ways
             to express the resolution
   astearns: resolved on that
   RESOLVED: 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
   RESOLVED: assume an interaction count of 1, attach all the frames.
             That creates something that you scale down when you apply
             the iteration 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 discretion or we can
             resolve later.

   astearns: next issue!

View progress contain of a sticky positioned elements on the edges
github: https://github.com/w3c/csswg-drafts/issues/8298.

   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 working 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 scroll position
   flackr: similar for the start value, or the minium sticky offset that
           it would have at the beginning of scroll
   flackr: this makes all the phases match the visual expectation of the
           elements position

   flackr: which has a related issue that we shouldn't 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 don't do this, the proposal for sticky position doesn't
           work as well because the sticky offset isn't necessarily the
           same direction as the scroll if you include the transform
   flackr: then things are worse if it includes a transform

   flackr: should we talk about this other thing first?
   fantasai: want to resolve we ignore transforms then switch back?
   fantasai: proposed resolution is transforms are ignored when
             calculating 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
   bramus: 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
   RESOLVED: 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
   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
   <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
   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 maybe we need the position spec to update
              to provide that

   astearns: rob, can you pick something for the remaining time?

Clarifying behavior of getCurrentTime(rangeName)
github: https://github.com/w3c/csswg-drafts/issues/8114.

   flackr: the behavior of `getCurrentTime()`
   flackr: kevin want to introduce 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, would be consistent with that resolution
   fantasai: and then it seems like if that range is 0, and if you're
             outside of it you return infinity?
   flackr: if you used getCurrentTime and then set this time on another
           animation, returning plus or minus infinity would give you
           the same effect that that timeline would 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 say you're before or after that range
   astearns: alright, any concerns or comments on this proposal?
   RESOLVED: `getCurrentTime` should just match the internal calculation
             for the time value which is unclamped

Meeting closed.
<RRSAgent> I have made the request to generate 
<fantasai> https://github.com/w3c/csswg-drafts/pull/8219

Received on Tuesday, 23 May 2023 05:33:55 UTC