- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 7 Jun 2023 20:51:23 -0400
- 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: Defer on getCurrentTime for L1 (Issue #8765:
getCurrentTime is self-inconsistent wrt representing
time)
- RESOLVED: No change (Issue #8672: Three-value `animation-range`
shorthand notation)
- RESOLVED: Allow a list of nones (Issue #8843: Should `none` be
part of the list in scroll/view-timeline-name?)
CSS Transitions
---------------
- RESOLVED: Pick option 2 (Make a new longhand
transition-property-mode which is an auto-extended list)
with name to be bikeshed (Issue #8857: Put discrete
transitions behind new syntax for compatibility)
- In addition to bikeshedding the name for the new longhand in issue
#8857, discussion will continue on Github to determine if
there's a need for a magic value which would only transition of
the property is discrete.
CSS Animations
--------------
- RESOLVED: getComputedStyle of animation-duration on a time-based
animation with a duration of auto returns 0sec for
compat reasons (Issue #6530: Should the initial value
for animation-duration be auto?)
Upcoming F2F
------------
- Working group members were encouraged to being thinking of topics
that would benefit from the extended time for discussions
available at the upcoming F2F.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Jun/0000.html
Present:
Rossen Atanassov
Tantek Çelik
Boris Chiou
Elika Etemad
Robert Flack
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Peter Linss
ChangSeok Oh
Florian Rivoal
Regrets:
Rachel Andrew
Tab Atkins
Oriol Brufau
Yehonatan Daniv
Chris Harrelson
Jonathan Kew
Jennifer Strickland
Miriam Suzanne
Bramus Van Damme
Lea Verou
Chair: Rossen
Scribe: dael
Scroll Animations
=================
getCurrentTime is self-inconsistent wrt representing time
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8765
flackr: We've had a bunch of debate about best way getCurrentTime on
a timeline should work, if needed, what are use cases.
Resolved to add progress to animation to handle common use
case
flackr: With that, think we should remove getCurrentTime from the
API and re-add when we have clearer sense of use cases
fantasai: I'm fine with deferring. It means there is no real way to
figure out where you are in a timeline range. So you don't
know when unless you make an animation and measure
progress. We don't have API to say how ranges relate to
rest of timeline
fantasai: But I'm fine with deferring. Not a problem
Rossen: Anyone else?
Rossen: Objections to defer on getCurrentTime
RESOLVED: Defer on getCurrentTime for L1
Rossen: I'm assuming bramus is on same page as you? I don't see us
doing a disservice for any commenter
CSS Transitions
===============
Put discrete transitions behind new syntax for compatibility
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8857
flackr: When we were trying to ship support for discrete transitions
one common case overlooked is common properties that are
sometimes discrete and sometimes continuous.
flackr: This has broken a few sites as shown in issue. Think we need
a new syntax to opt in to discrete transitions
flackr: A bunch of proposals in the issue
flackr: Two with most support are having a long hand transition
property similar to duration and easing that spec per
transition if it should start on discrete property changes
(option 2)
flackr: Other is option 4 from fantasai having a separate property
that's a switch for if you do discrete transitions
fantasai: That proposal would have allow/don't allow/all for these
properties and it cascades independently.
fantasai: I'm not saying it's better, but a different approach
flackr: Two ways of looking at this. Yours is better for site-wide
switch, other is better for property by property.
flackr: In both you can say you want discrete everywhere. Harder to
specify in option 2
Rossen: If I'm reading the emoji vote, 6 for #2 and 4 for #1?
flackr: To be fair, #4 was added later
Rossen: Should we be discounting #1? It's a smaller population
fantasai: I think that option 2 was better than 1. It should come
down to 2 vs 4. We could do both
fantasai: Initial value of the transition mode is an auto value that
looks up another property
flackr: Maybe consider one as a starting point and we could add the
other?
fantasai: One thing that makes it tricky is if we think it could be
both have to think about how to name them
Rossen: Can we live with 2 or 4 only?
flackr and fantasai: Yeah
fantasai: Tricky is what is the pattern of use and what will be
easier to use in most cases. You can mostly do most of it
with either
flackr: Either let you global opt in. Option 2 if you don't want all
you have to go transition by transition. Option 4 is by
property
fantasai: I think option 2 is better. It's more powerful
flackr: More configurable. And more consistent with other transition
longhands
fantasai: Agree
Rossen: 4 is additive?
fantasai: Could add if we want to
Rossen: Sounds like fantasai you're leaning toward #2?
fantasai: Yeah
Rossen: I think we have a clear winner
Rossen: Want to hear from the rest of folks on the call
smfr: Does this make a non-discrete animating property animate in
discrete way?
flackr: No
flackr: Some properties are sometimes discrete. Their discrete
interpolations start with this
smfr: Transition list was opacity and display are you forced to
supply a value for opacity if you want discrete on display?
flackr: No downside to discrete on opacity
smfr: Could be confusing for author
flackr: It is auto expanding list
smfr: Could also expect discrete on opacity to split to by 50%
flackr: That's why I had a bunch of options on names. I proposed
'animatable'
fantasai: Non-animatable properties are quite exceptional I don't
think should name based on that
flackr: It's what the spec says so suggested that
fantasai: True, but most people don't read spec. Need to think about
best way to suggest this to authors
flackr: Maybe 'all' is value to include discrete
fantasai: Thinking transition-discrete: all|none|magic value that
says if it's discrete you can animate and if it's not it
doesn't animate. That way you can throw it on your site
and transition discrete properties
fantasai: If you're not using the all you can set it on whole site
and no effect
smfr: High level comment, discrete is probably hard for non-native
speakers
fantasai: Yeah. not sure what else. transition-non-interoperable
flackr: I think we're good with option 2
fantasai: Yeah, need to figure out what to call it and values
Rossen: Let's take a decision and bikeshed name on the issue
Rossen: Objections to pick option 2 with name to be bikeshed
RESOLVED: Pick option 2 with name to be bikeshed
fantasai: Do we want a magic value that says transition this
property only if it is discrete or interoperable. Don't
transition if it's a property that has a non-discrete
flackr: Could be UA default since possibly not breaking
fantasai: Yeah, could be
Rossen: Do we need to resolve on something?
fantasai: Question is do we add the value or not
flackr: And what would we call it?
fantasai: 'magic' for now. bikeshed later
flackr: If this was not initial value I'd say it's additive
fantasai: But it could be initial value
Rossen: I think we can work this out on the issue
Rossen: And hear more from Bramus, Tab, Brian, and other folks who
have been engaged
flackr: Sounds reasonable
Scroll Animations Continued
===========================
Three-value `animation-range` shorthand notation
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8672
fantasai: We have an animation-range shorthand for start and end.
Can take keyword, length, % or both one after the other.
Means you can do 2 or 3 component values
<fantasai> animation-range: 10% entry 90%;
<fantasai> animation-range: contain 10% 90%;
fantasai: Question was what's best way to interpret a 3 component
value. Examples ^
fantasai: Could do exactly as specified. Another is make these
invalid. Third is duplicate the keyword which feels a
little odd in the first example.
fantasai: flackr had another approach though?
flackr: It was that no spec range would refer to max-range of the
timeline. So it's larger than the cover range for view
timelines
fantasai: That feels independent from how to assign 3 value
flackr: It is, but gives meaningful value to things without range
fantasai: Animation-range 10% 90% currently goes from 10-90% of cover
flackr: Then I think we shouldn't do magic with range names in 3
value
Rossen: Does that leave us no change?
fantasai: I think that is current state
fantasai: First option, assign long hand values as specified
florian: When you have % keyword % is it unambiguous by ordering?
fantasai: Yes. animation-range requires keyword first
florian: Good
Rossen: Do we need a resolution?
flackr: Resolve to keep as is?
Rossen: No change
Rossen: Objections?
RESOLVED: No change
fantasai: I brought this because we hadn't talked about the 3-value
option so needed to cover
Should `none` be part of the list in scroll/view-timeline-name?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8843
fantasai: This issue was brought because right now the way values
are spec, scroll-timeline name is none or a list of comma
spec idents. But background-image and the like is a list
of nones or whatever so can have a list of nones.
fantasai: Question here is shorthand drafted as inconsistent. Do we
want pattern to have a list of nones or make that
explicitly not possible
fantasai: Seem to be leaning toward a list of nones for consistency
and it allows an author to turn off a timeline without
taking out definition from all properties you can flip it
to none
flackr: I support allowing a list of nones
fantasai: Prop: Allow list of nones
Rossen: Any opinions?
florian: Seems reasonable. No strong opinion.
Rossen: Objections?
RESOLVED: Allow a list of nones
CSS Animations
==============
Should the initial value for animation-duration be auto?
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1562390274
flackr: We allowed specifying animation-duration:auto and make it
the initial value which matches web animations API. Having
computed style return auto breaks some libraries. It can't
handle the NaN from parsing auto
flackr: Proposal is to return the resolved duration. When you have
default it's 0sec today. May be a time in the future
flackr: For scroll timelines, technically resolved value should be a
percent but we don't support those on animation-duration. We
could but if we don't would have to return auto in that case
Rossen: What happens when you round trip the auto?
flackr: Won't alter behavior because computes to same resolved value
flackr: Only risk of returning auto is if we want to change in
future to percent it's possible people would start relying
on auto. It would be people relying on scroll driven
animations
Rossen: If percent introduces auto wouldn't be the same?
flackr: No, not that
Rossen: Sounds like open to changes/additions decision. Not
preventing anything with auto. Or am I misunderstanding?
flackr: This shows up in computed style. If we want to return
percent it could break people expecting auto. I don't think
that would happen, usage will be low for a while since it's
new
Rossen: Opinions from the group?
flackr: Further clarification, we're returning auto right now
because can't pass a percent to animation-duration right now
Rossen: So tomorrow we introduce percent it will have breaking effect
flackr: Yep
Rossen: This is the part I'm hung up on. Wanted to probe for other
opinions
fantasai: One thing to think about is what do we want this to do in
the future. Do we want it to return actual value of
duration in general or do we want it to return something
like computed value and this is a compat exception
flackr: Good point. Could see argument it's 0sec for compat and auto
is fine in the future
fantasai: Effected APIs are GCS and getComputedTiming?
flackr: Computed timing on animation already returns 0sec. It's just
getComputedStyle
<fantasai> https://github.com/w3c/csswg-drafts/issues/6530#issuecomment-1575146984
fantasai: Not sure I understand this comment ^
flackr: This is the thing VueJS is using.
fantasai: Plan is to...getComputedTiming returns active duration and
actual thing. getComputedStyle will return 0sec for compat
reasons and if at some point we have group effects where
auto would result in something else, it will return auto
flackr: Sounds reasonable as just a compat thing. That makes me feel
much better
Rossen: I'm sold as well. Other opinions? Objections?
Prop: getComputedStyle of animation-duration on a time-based
animation with a duration of auto returns 0sec for compat reasons
Rossen: Objections?
RESOLVED: getComputedStyle of animation-duration on a time-based
animation with a duration of auto returns 0sec for compat
reasons
<fantasai> and this doesn't apply if it doesn't actually resolve to
0sec :)
<fantasai> (which in the future, it might not)
CSS Fonts
=========
Add "font-synthesis: super"
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/7441
florian: I've got some opinions, but I can add them to github
[agenda wrangling]
Scroll Animations
=================
blocking effects of timeline-scope
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8915
fantasai: I think it would be good to have a few more people here
[more agenda and attendance wrangling]
Rossen: Let's call it early and get back 10 minutes
Rossen: We'll chat again next week
fantasai: People should think about topics for the F2F. Not just a
pile of backlog issues, but what topics would benefit from
F2F time or topics that haven't had engagement because
they're not concrete enough for a telecon but would
benefit from conversation in a more informal context
Rossen: Good call, thank you
Rossen: That's everything for today. Thank you all!
Received on Thursday, 8 June 2023 00:51:56 UTC