- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 9 Dec 2022 18:35:28 -0500
- To: 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
-----------------
- RESOLVED: Accept the proposal in
https://github.com/w3c/csswg-drafts/issues/5653#issuecomment-1271689506
(Issue #5653: Order of pause, setTimeline) [proposal:
set the timeline first, then pause, as the pause being
applied in the same update as the new animation-timeline
implies to me that it is meant to pause in the new
timeline]
- RESOLVED: Animation events fire for scroll linked animations as
defined by web animations spec (Issue #4324: Should
animation events fire every time active range is left/
reentered?)
- RESOLVED: Add auto as default value (Issue #6530: Should the
initial value for animation-duration be auto?)
- RESOLVED: Have parsing with fixed order of name and axis (Issue
#7627: `scroll-timeline` and `view-timeline` shorthand
syntax)
- RESOLVED: Animation range and animation delay are separate things
that compound (Issue #7901: What's the point of
animation-range?)
- RESOLVED: Add length % to animation-range to be used as offsets
(Issue #7575: Bring back Scroll Offsets)
- RESOLVED: Scroll animation is inactive when denominator is 0
(Issue #7778: currentTime when scroll range is 0 (again))
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Dec/0005.html
Present:
Rossen Atanassov
Tab Atkins
Brian Birtles
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Dael Jackson
Cameron McCormick
Florian Rivoal
Miriam Suzanne
Bramus Van Damme
Chair: Rossen
Scribe: dael
Agenda Setting
==============
Rossen: Before we get going, do we have any changes of order for the
agenda?
fantasai: Did we want to go through my drafted agenda list or yours?
Rossen: Oh there's more in yours
fantasai: Do we want to timebox some of the straightforward issues?
Scroll Animations
=================
Order of pause, setTimeline
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/5653
<Rossen> https://github.com/w3c/csswg-drafts/issues/5653#issuecomment-1271689506
Rossen: There's a link to the proposal ^
flackr: If you're using scroll linked animations with css it's
possible to switch timeline and change place date in same
update. Need a well defined order
flackr: Chrome and Gecko both set timeline first and then apply
paused play state which is observable so what to define that
way
Rossen: Any feedback?
Rossen: I see Boris from Gecko seemed to have same preference
flackr: I also think it's more dev friendly because play state
change feels it should be related to new timeline
Rossen: Objections?
RESOLVED: Accept the proposal in
https://github.com/w3c/csswg-drafts/issues/5653#issuecomment-1271689506
Should animation events fire every time active range is left/reentered?
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4324
<fantasai> Proposal:
https://github.com/w3c/csswg-drafts/issues/4324#issuecomment-1325707643
flackr: An open question we had lingering about with a scroll linked
animation you can repeatedly enter before or after phase by
scrolling. As defined this fires animation events. Should it?
flackr: birtles and I chatted and we think it seems reasonable to
fire events as define. Proposal is events fire for scroll
linked animations as specified
flackr: Second part we can take up separately
Rossen: I see some back and forth on this. Anyone want to express
other opinions?
Rossen: Taking the silence as no additional opinions
flackr: Animation events fire for scroll linked animations as
defined by web animations spec
Rossen: Objections?
RESOLVED: Animation events fire for scroll linked animations as
defined by web animations spec
flackr: Second part, CSS animations have an animationstart event.
Web animations have a ready promise which is not quite the
same. Ready would resolve once.
flackr: Would it be useful to add a start event that developers
could use to trigger on same condition. Every time you go
from before animation is active to when it's active
birtles: I think you need something if it's possible to finish and
then go unfinished; good for authors to detect. Don't know
it's a start event because that would relate to the delay.
Maybe just an active event. Need to define some way for
authors to know it goes from finished to not finished
flackr: Sounds like something we should come up with ideas and bring
back.
flackr: Let's stick with first resolution and move on
bramus: Wondering how that would work with various phases. I'm okay
if we come up with some ideas to discuss
Should the initial value for animation-duration be auto?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6530
<Rossen> https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1308954151
flackr: css animations spec the initial value to be 0sec but times
don't make sense for scroll linked animations. In web
default was auto
flackr: First is we should support auto in css animations because
that's what we use to map to a range of scroll or view
timeline
<bramus> +1
birtles: For background I think we added auto to web animations
because we anticipated group effects where duration
stretches to fill the group
heycam: What is the effect of specifying animation duration of some
other value?
flackr: Currently have spec that if all durations are time based we
convert to relative proportions of animation. This doesn't
work for 0
flackr: And this is in web animations 2 spec
flackr: Not sure if we want to keep that or remove, but hope is most
devs use auto which we convert to timeline specific
heycam: Yeah was just wondering if it's sensible to use specific
time values. It's something authors will want to do and in
that case is 0 sec useful. Sounds like no for 0
flackr: Right, 0 is not really something that should produce an
effect
ydaniv: Did you also consider allowing length and duration?
flackr: There is a separate issue filed for this.
ydaniv: But it's not colliding?
ydaniv: There's no collision between using auto as the initial
flackr: No, there should be no issue with using initial if we do
length. Computed value of auto is 0 if they're not part of a
group so we would just be saying computed value is whatever
makes sense for a scroll linked animation
flackr: Proposal is that's 100%
Rossen: Other opinions?
flackr: Two proposals, one is add auto. auto as initial is separate
proposal
flackr: I would like both
bramus: I would like auto to be the default because if you set an
animation timeline you need to change animation duration to
1 sec or non-0 for animation timeline to work which is weird
for author. For auto you don't need that
flackr: That's exactly why I want auto as initial
Rossen: Proposal: Add auto as default value
Rossen: Objections?
RESOLVED: Add auto as default value
`scroll-timeline` and `view-timeline` shorthand syntax
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7627
Rossen: Who can summarize?
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7627
bramus: I can. In the spec there's a difference between scroll- and
view-timeline argument order.
bramus: Proposal was to have them use same syntax
<fantasai> scroll/animation-timeline: <name> || <axis>
<fantasai> scroll/animation-timeline: <name> <axis>?
fantasai: Other point you raised is timeline name and axis are in
same namespace. I put this on agenda to ask WG if we
should require an order and require name always? We could
change the current syntax
fantasai: Other ways to disambiguate but asking if this is what we
want to do or something different
bramus: One question on proposed new is there is no slash separator
but container queries requires one after the name. Seems
like a difference
miriam: Likely because you can have multiple names
bramus: Don't think we want to allow multiple names on scroll
timeline, do we?
fantasai: Do it with a comma separated syntax and axises are listed
with name. Container property doesn't have that; doesn't
tie two properties with lists. Only one type of containment
fantasai: Here we have a list of timelines that have their own
properties
flackr: I'm in favor of fixing the order
<bramus> +1
Rossen: Any opposing opinions?
Rossen: Proposal: Have parsing with fixed order of name and axis
Rossen: Objections?
RESOLVED: Have parsing with fixed order of name and axis
Rossen: fantasai anything else on this?
fantasai: nope
Bring back Scroll Offsets
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/7575
Rossen: This is a fairly long issue
<Rossen> Initial Proposals Summary:
https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1207786782
Key follow-up comments:
https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1209635142
https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1253314529
Second Proposals Summary:
https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1306103577
Key follow-up comments:
https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1320748822
https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1321310196
Rossen: You can follow initial proposals and key follow-ups from
there ^
bramus: With the previous iteration of scroll linked animations that
use scroll linked timelines and this is not in the re-write
bramus: A few suggestions, 8 Nov comment from fantasai summaries.
Add a length % for animation-delay and animation-duration.
That way you can drive scroll linked animation over
specified distance
Rossen: On this side of the pond the comment is on Nov 7
birtles: I'm not opposed to adding the different units to delay.
Concern I raised is architectural. From API PoV there's 3
pieces, timeline, animations, effects. In css animations it
is blurred where delay is part of effect.
birtles: Architecturally would like effect separate so you can reuse
it. That was the initial idea for the API.
birtles: I was a little concerned about putting in a delay because
that's part of effect and makes it harder to reuse
birtles: One thought I just had there is another issue about overlap
between animation range and delay. Was wondering if there's
a possibility to use animation range for this and have
animation range apply to animation and animation delay
apply to the effect. If we could satisfy the use case
though that. Just a thought
bramus: That would still allow % for length but not delay
birtles: I wondered if it applies to animation not effect would be
architecturally more suitable
flackr: I think this does make use cases possible. I don't have any
objection to it. Only concern is that delay does have units
and it's time and they don't convert to the timelines of the
effects. Have architectural breakage no matter which way we
go. Not opposed, but don't think can avoid mixing units
birtles: I think % have slightly different case to vh units. If you
can have effects defined in terms of % that's more
reusable. If you have an effect that interpolates between
these values over a range in the abstract and than
animation maps to concrete.
birtles: % units and the general case of lengths I'm not opposed.
Nice if authors can achieve this without painting into a
corner where they can't reuse the effect
fantasai: Two comments. 1 in terms of % I think % and absolute units
need to be mixed. Sometimes you want absolute shift and
sometimes you want relative and we combine. I don't think
only % would work
fantasai: I think before we resolve we should jump to next issue,
discuss, and then bring those decisions to this
flackr: You were concerned about reusability. The length values when
used on a time-based timeline compute to 0 so the value are
as effective as if they're in separate property. I think
it's as reusable either way except you can't have a separate
time-based delay
flackr: Also think delay is times so we will have to support % and
times. It's hard to have a single unit world
birtles: With regards to fantasai point of absolute and relative I
agree. We have absolute and relative times if we have %
birtles: Regards to reusability, on the original proposal there were
3 suggestions put forward. The third you can see the
keyframes is unaffected. I guess that's an example of what
I mean by reusable. It's only the second where keyframes
change so maybe not important
bramus: In the 3rd example that uses animation timeline offsets?
<bramus> https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1207786782
birtles: Yes
birtles: I was saying it's possible to use a % on an effect and an
absolute unit on the mapping at the animation level so you
can have lengths, 90 vh on the animation, and then map to %
on effect so you can combine absolute units with % without
introducing diff length types
flackr: In a previous breakout session and then with the group we
resolved to have range-based offsets in keyframes which is
also a modification to keyframe spec that is incompat with a
time-based animation
flackr: Based on a strong dev demand to have animation with entry
and exit effect that are dynamic calc of points in scroll
flackr: Feel like that ship has sailed a bit to keep everything as %
flackr: I think for simple animations you will be able to reuse
them. For things linked to position on length-based timeline
it's not portable
birtles: Yeah, maybe ship has sailed. Would be nice to have
animation tied to mapping, but maybe too late
birtles: Other thing is was thinking with this use case we could
realize without going further. But maybe say that's how
things work now. Fair enough
fantasai: My suggestion is pause the conversation, switch to next
topic. I think a couple of these ideas are linked to next
topic
Rossen: We can do that unless everyone feels we're getting toward
resolution
Rossen: I see birtles moved himself along
birtles: If next issue is related we should do that first
What's the point of animation-range?
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7901
<Rossen> https://github.com/w3c/csswg-drafts/issues/7901#issuecomment-1325538928
fantasai: When we were trying to figure out how to attach an
animation to different ranges, named ranges in the
timeline. Entry phase, exit phase, and the like and want
to attach to some
fantasai: We allowed keyframes to take a named range as well a % to
represent progress into the range to be able to built
animation that crosses ranges.
fantasai: Also wanted to take existing keyframes and attach to a
range
fantasai: Did that with animation-delay as a way of indicating where
we wanted to attach it. Could give a named range and %
into the range as delay
fantasai: That has weird ergonomics for author. Want to attach to
entry phase and set animation delay to entry. Reason why
we have animation range property is to make it feel less
odd
fantasai: Becomes a question if we think about interaction what
makes the most sense. flackr comment has several ways to
make them intersect or have different responsibilities
flackr: I can present options 1 & 2. Option 1 is keeping things
close to today. animation-delay only specifies start delay.
Proposal is turn that into a shorthand for start and end
delay. preserve single value for compat
flackr: It was accept timeline-range in each. animation-range is for
the case you want to cover a complete range.
animation-range: enter sets it to enter 0% enter 100%
flackr: Option 2 is closer to preserve existing delay as is and
introduce animation range where you can spec a range, range
start, range end and it maps to internal values. Effectively
makes animation-delay somewhat of a legacy property because
only specs start and range is everything delay does
fantasai: Third option is animation-delay and animation-range take
effect at same time. Range set the range and delay is an
inset into that time
fantasai: animation-range:entry and animation-delay:<value> I start
that value into the range.
fantasai: I think that has an advantage that it keeps delay simple
and reasonable interaction between delay and range.
fantasai: I think those are the proposals on the issue
fantasai: My preference is 3rd
flackr: I prefer 3rd as well
birtles: I think we should think about why introduced group effects.
Animation delay is relative to parent effect where if you
have a sequence and delay b it'll offset start relative to
a. Then what would an absolute delay mean? Or a range? We
should think about that
birtles: Maybe we would decide they should be separate and delay is
effect and range is animation as a whole
bramus: To make sure I understand, proposal is to set an
animation-range to entry and then set an animation-delay to
25% 75%. Is that correct?
birtles: That sounds like what it would be. Animation-range applies
first and puts on timeline
flackr: Slight correction. You probably didn't mean 75% end delay.
Animation-delay:end is same meaning where it's amount of
time after effect. 25% 25% would do what you expect
<bramus> Got it
fantasai: Suppose in future have named, time based ranges. And you
say you want to animation this during window. Express the
delay in ms and you can do start and end and ms cut into
it. If we add length-based you could also cut in with a
length
fantasai: I think we still want to allow range to be entry 10% or
whatever so you would add up %. If doing time + % it
points to the point you've described. You add additional
padding with the delay
Rossen: I'm trying to make sense of the silence. Looks like "okay"
silence
flackr: I think option 3 sounds good and might be better for
previous issue
Rossen: Proposal?
fantasai: Animation range and animation delay are separate things
that compound
Rossen: Additional opinions or objections?
RESOLVED: Animation range and animation delay are separate things
that compound
Bring back Scroll Offsets
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/7575
Rossen: Let's see if we can resolve on this one
flackr: Given that animation-range specifies the range the animation
runs in, if we add length as well I think it solves use case
and don't need lengths added to delay
birtles: I think that's good. Good to push it down the road and
consider how it interacts with group effects
fantasai: Proposal: Add length % to animation-range to be used as
offsets
Rossen: Objections?
RESOLVED: Add length % to animation-range to be used as offsets
<birtles> ("Pushing it down the road" here refers to adding lengths
to animation-delay)
currentTime when scroll range is 0 (again)
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7778
<Rossen> https://github.com/w3c/csswg-drafts/issues/7778#issuecomment-1313875566
flackr: Previously we defined scroll timeline to be inactive when
scroll range was 0 to avoid divide by 0. This is a slight
amendment because many cases where you don't end up with
division by 0. Examples in proposal
flackr: Let's define calc and say animation is inactive if
denominator is 0.
Rossen: Thoughts or objections on this one? Scroll animation is
inactive when denominator is 0
RESOLVED: Scroll animation is inactive when denominator is 0
Rossen: Still 3 issues on this agenda. More to discuss but this was
great progress. Thank you all for joining, thank you
fantasai for organizing the agenda.
Rossen: Have a great day, everyone.
Received on Friday, 9 December 2022 23:36:09 UTC