- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 23 May 2023 01:33:45 -0400
- To: W3C style mailing list <www-style@w3.org>
=========================================
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
https://github.com/w3c/csswg-drafts/issues/7589
- RESOLVED: take the API shape in the linked comments and add
properties to the animation interface along timeline
See
https://github.com/w3c/csswg-drafts/issues/7589#issuecomment-1380842759
Allow Anonymous Scroll Progress Timelines to target self
https://github.com/w3c/csswg-drafts/issues/8227
- RESOLVED: Add 'self' keyword to ''scroll()''
Phases for taller-than-scrollport subjects
https://github.com/w3c/csswg-drafts/issues/7973
- 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
https://github.com/w3c/csswg-drafts/issues/8204
- 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'
https://github.com/w3c/csswg-drafts/issues/8233
- 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
https://github.com/w3c/csswg-drafts/issues/8298.
- 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)
https://github.com/w3c/csswg-drafts/issues/8114.
- RESOLVED: `getCurrentTime` should match the internal calculation
for the time value, which is unclamped
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jan/0013.html
Logs: https://www.w3.org/2023/02/01-css-irc
Present:
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
https://github.com/w3c/csswg-drafts/issues/7589#issuecomment-1380842759
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
animations
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
animations
flackr: any objections to the proposal?
astearns: I'm looking through, we resolved to go with option 2.
the proposed shape is?
<astearns>
https://github.com/w3c/csswg-drafts/issues/7589#issuecomment-1380842759
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.
getter/setter
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
itself
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
chain?
...
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>
https://github.com/w3c/csswg-drafts/issues/7973#issuecomment-1349970567
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
<astearns>
https://github.com/bramus/csswg-drafts/commit/392a4deefdc546591ab48ed899aded52bd698467
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 ->
https://user-images.githubusercontent.com/213073/198659234-76702d8b-9770-43a0-9ee9-d81723e8c15b.png
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
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 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> ->
https://github.com/w3c/csswg-drafts/issues/8233#issuecomment-1375890456
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
iterations
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
flickers
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
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 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
https://www.w3.org/2023/02/01-css-minutes.html
<fantasai> https://github.com/w3c/csswg-drafts/pull/8219
Received on Tuesday, 23 May 2023 05:33:55 UTC