- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Dec 2023 19:54:55 -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: Add 'all' keyword to 'timeline-scope', equivalent to
specifying all possible names (Issue #9158: Add a way for
timeline-scope to pull up all contained timelines)
- RESOLVED: Add 'scroll' named range to view timelines, represents
entire scroll range, bikeshed keyword in issue (Issue
#9367: Range for entire scroll range)
- RESOLVED: Any position within the overlarge snap area is a valid
snap position, as defined in the (clarified) spec (Issue
#6863: Difficult to use snap areas which are larger than
the scrollport)
CSS Images & Grid
-----------------
- RESOLVED: fr values in stripes() convert to max(0, 100% -
sum-of-percents - sum-of-fixed) * flex value / max(1,
sum-of-flexes) (a <length-percentage>) when needed for
interpolation (Issue #8622: Allow transitions between
different types within `stripes()`)
CSS Animations
--------------
- RESOLVED: Draft up this proposal into css-animations-2, come back
to WG for review (Issue #8942: Add animation-trigger for
triggering animations when an element is in a timeline's
range)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0002.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Stephen Chenney
Yehonatan Daniv
Elika Etemad
Robert Flack
Jonathan Kew
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Chair: astearns
Scribe: fantasai
Scribe's scribe: TabAtkins
Scroll Animations
=================
Add a way for timeline-scope to pull up all contained timelines
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9158
bramus: This issue is about declaring many animation timelines and
using broader scope
bramus: This issue is about using "all" for hoisting them up
bramus: Allow also anchor name for hoisting up using anchor scope
flackr: Can a timeline be pulled up with multiple scope?
fantasai: No.
fantasai: The 'all' keyword traps all the keywords, just like
individual keywords trap those keywords
fantasai: might be useful if you want to encapsulate
flackr: ok
Rossen: Any other concerns?
bramus: Proposed to add "all" which will pull up all timelines
<fantasai> (It's basically the same as specifying all possible names)
<schenney> The concern raised by flackr is already in the issue,
raised by
https://github.com/w3c/csswg-drafts/issues/9158#issuecomment-1742797028
YehonatanDaniv: If I name something in a descendant, and then specify
all in an ancestor, what happens?
flackr: The lower scope captures that name, it won't be pulled
higher up
RESOLVED: Add 'all' keyword to 'timeline-scope', equivalent to
specifying all possible names
CSS Images & Grid
=================
Allow transitions between different types within `stripes()`
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8622
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/8622#issuecomment-1758136484
TabAtkins: Currently, in stripes() you can write widths as length,
percentage, or flex
TabAtkins: We didn't have interpolation behavior for between flex and
lengths
TabAtkins: but in this context, the flex definition is very
straightforward and can be expressed in terms of
percentages and lengths
TabAtkins: So my proposal was that each flex in a stripes function
will compute to a particular expression
TabAtkins: which makes it into a <length-percentage>
<TabAtkins> max(0, 100% - sum-of-percents - sum-of-fixed) * flex
value / max(1, sum-of-flexes)
TabAtkins: and then you can transition that with all the other
length-percentages just fine
fantasai: Makes sense. Do we store fr as computed value?
fantasai: Or do we compute through to <length-percentage> only when
interpolating
TabAtkins: It's best for authors to leave fr's as they are, unless
they need to convert for an interpolation
<flackr> +1
<fantasai> +1
TabAtkins: [explains the formula]
flackr: I like converting just-in-time
flackr: We do this with other types when interpolating
RESOLVED: fr values in stripes() convert to max(0, 100% -
sum-of-percents - sum-of-fixed) * flex value / max(1,
sum-of-flexes) (a <length-percentage>) when needed for
interpolation
Scroll Animations Con't
=======================
Range for entire scroll range
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/9367
flackr: We decided that the default range for 'view' timelines is the
'cover' range, because this is a sensible default animation
flackr: for animating as some element goes through the viewport
flackr: but no way to express the total scroll range
flackr: so sometimes might want start of scroll to some position in
view range
flackr: or view range position to end of scroll
flackr: simplest think we could do is add a named range that refers
to the full scroll range, so we can refer to it in the
animation-range
flackr: suggestion is "full"
flackr: Also raised issue specifying pixel values as offsets from
cover range
flackr: but might be awkward
flackr: also would be a breaking change
flackr: to change interpretation of values without range name
flackr: because default animation range for view timelines is 'cover'
bramus: If you specify 3 values, if you don't specify a range name it
defaults to 'cover' for view timeline and 'full' for scroll
timelines?
flackr: I thought we already resolved 3-value syntax
fantasai: I'm trying to think through this
fantasai: Not sure "full" is actually better than "scroll"
fantasai: View timelines are supposed to be about when the element is
in view, there's different interps of what that might mean,
but that's what it's about
fantasai: Saying "full" timeline is the entire scroll range might be
a little odd
fantasai: If you wanted the full scroll range you should use the
scroll timeline rather than view timeline
fantasai: I can see use-cases for wanting one end or another tied to
the end of the scroll
fantasai: But we should make it clearer you're extending outside the
conceptual range of the view timeline
fantasai: And it definitely shouldn't be the default
flackr: Originally why I proposed 'scroll', full range of view
timeline should be considered to be 'cover'
bramus: If we use 'scroll', then it wouldn't make sense for other
timelines e.g. media playback timelines
flackr: For media timelines, default would be the full playback range
bramus: For scroll timelines, default is the full scroll timeline
schenney: "full" is referring to "full page", might help to clarify
flackr: Not quite, talking about entire scroll range
schenney: Complete scrollable area?
flackr: Yes
Rossen: That excludes the scroll-margin areas?
flackr: I don't think so, it represents offset zero and max offset
Rossen: If I have something in the negative space?
flackr: Yes, that's excluded
Rossen: And something beyond end of range?
flackr: Right
fantasai: Do we want to accept and bikeshed later?
Rossen: Let's pick one of the two names for now, and then go with it
<schenney> content?
Rossen: Let's stick to 'scroll' because then at least one person
doesn't like it, and we can bikeshed to find the right name
Rossen: Proposed to add 'scroll' named range to view timelines,
represents entire scroll range
RESOLVED: Add 'scroll' named range to view timelines, represents
entire scroll range, bikeshed keyword in issue
Difficult to use snap areas which are larger than the scrollport
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6863
flackr: fantasai and Tab both commented that the intention is what I
am asking for
flackr: [describes issue]
flackr: I'm seeing a lot of support for that sentiment in the issue
flackr: I think we're resolving that the updated spec is good, with
expected behavior
[reviewing the comments in the issue]
fantasai: Tab's comment isn't correct, intention of spec was that any
position within the overlarge snap area would be a valid
place to rest
<fantasai> current spec ->
https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow
flackr: I think the current spec is good
PROPOSED: any position within the overlarge snap area is a valid snap
position, as defined in the (clarified) spec
RESOLVED: Any position within the overlarge snap area is a valid snap
position, as defined in the (clarified) spec
CSS Animations
==============
Add animation-trigger for triggering animations when an element is in
a timeline's range
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8942
flackr: Common use case for scroll-based animations
flackr: is to have a time-based animation that starts at a certain
scroll position
flackr: In this issue, proposing a property that controls the
playback of a time-based animation based on the scroll
position
flackr: leveraging the fact that we can define positions in scroll
position using scroll timelines
flackr: so using one timeline (Scroll timeline), control play state
of another animation on another timeline (time)
flackr: We have a proposal that tries to capture the various use cases
flackr: We have a new property, I'm calling 'animation-trigger'
flackr: associated with corresponding animation entry
flackr: Second value is behavior, come back to that later
flackr: then you specify 2 ranges: range in which you activate the
animation, and range in which you de-activate the animation
flackr: Behavior has 3 values, one for one-shot animation
flackr: it never runs again after you trigger
flackr: Alternate is plays when entering, and reverses when you enter
exit range
flackr: Final is cancelled [missed]
flackr: As I say this, I'm realizing that one-shot can be represented
with exit range being the entire scroll range
<bramus> Demos for each range, using a (quick) polyfill:
https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1853045701
fantasai: That might be confusing though
YehonatanDaniv: We started with view timeline, actually
YehonatanDaniv: Scroll is also an option because no limit
YehonatanDaniv: Ranges are against a view timeline of the element
flackr: They're the ranges of the timeline that you specified,
whichever you specified
dbaron: I felt I only sort-of followed the descriptions of 3 values
dbaron: Does one of those values let you do something where as you
scroll down, it plays forward, and if you scroll up it plays
backwards?
flackr: That's the 'alternate' value
flackr: which reverses the value when you leave the range
flackr: I have a demo
bramus: I have a bunch of tests to demo the various behaviors
bramus: Also built some demos for more real-world use cases
bramus: such as stick element that animates as stuff enters/leaves
scrollport
bramus: I could achieve everything I wanted with the options
bramus: but not ergonomic, if you use 'once' you just need to specify
where it triggers
bramus: For alternate need t2, and for repeat you need all 4
bramus: depending on the second value might need 1-4 values
bramus: A bit confusing
fantasai: First comment, I think maybe consider some longhands
fantasai: Second, maybe we want to draft this up so that it's a bit
more clear what the proposal is
YehonatanDaniv: Another keyword that was proposed for toggling play
state of animation
YehonatanDaniv: for animations that play indefinitely
flackr: Yes, one use cases not handled was if you want the animation
to just pause outside the range and continue when you
re-enter the range
Rossen: Do we have a proposed path forward?
flackr: Let's write something up in spec-ese, and come back
PROPOSED: Draft up this proposal into css-animations-2, come back to
WG for review
RESOLVED: Draft up this proposal into css-animations-2, come back to
WG for review
Received on Thursday, 14 December 2023 00:55:28 UTC