- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 May 2023 18:55:00 -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.
=========================================
Selectors
---------
- RESOLVED: Rename `@initial` to `@starting-style` (Issue #8174: Add
syntax to establish before-change style for
css-transitions on new elements)
CSS Logical & Images
--------------------
- Prior to a conclusion on issue #1724 (flow-relative gradients) the
group needs to decide how to remove the backgrounds 4 3-value
syntax in <position> and add logical values.
CSS Display
-----------
- RESOLVED: When an animations produces display none it continues to
run but it still cancels animations within that subtree
(Issue #6429: Why is display listed as not animatable
instead of animation type: discrete?)
Web Animations
--------------
- RESOLVED: Add progress to Animation and make it readonly (Issue
#8799: Progress APIs)
CSS Transitions
---------------
- There was agreement we should allow color control for transitions
and animations for issue #7063 (Add control of colorspace used
for transitioning colors). During discussion on the call an idea
was floated to do something similar as we do with transitions
and list out the properties named which seemed like a good
alternative to the approach in the issue. Discussion will return
to github to discuss details.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0020.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Mike Bremford
Oriol Brufau
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Paul Grenier
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Peter Linss
Alison Maher
Eric Meyer
Fernando Serboncini
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
Florian Rivoal
Miriam Suzanne
Chair: Rossen
Scribe: bramus
Upcoming F2F
===========
<Rossen> https://wiki.csswg.org/planning/cupertino-2023
Rossen: Reminder about F2F
Rossen: Please add your info if you plan to attend, even if virtual
Rossen: Need this for planning
Selectors
=========
Add syntax to establish before-change style for css-transitions on
new elements
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8174
chrishtr: This is the feature specify style in first frame of
transition
chrishtr: previously we resolved to add it but needed to bikeshed
name
chrishtr: Vote was unanimous for `@starting-style`
chrishtr: with 11 votes
<masonf> now 12 votes
Rossen: looking at the folks that voted, there's a strong Google
representation but that's ok
Rossen: Any extra feedback or ideas?
Proposed resolution: rename `@initial` to `@starting-style`
RESOLVED: rename `@initial` to `@starting-style`
CSS Logical & Images
====================
flow-relative gradients
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/1724
TabAtkins: Last week we talked about flow relative gradients
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1724#issuecomment-1551822198
TabAtkins: We need to settle on the keyword we want to use for this
TabAtkins: The version in backgrounds-4 are out of date and have
stuff that we removed from position, but if you update it
to reasonable modern practice and then strip down then
you end up with format linked
TabAtkins: It allows to specifiy a physical axis with a logical
direction, or a fully logical direction
TabAtkins: I believe this reflects what fantasai also wants
TabAtkins: and suggest to take a resolution on it
oriol: This proposal introduces some combinations that are ?? like
you can write start which would be ?? with inline-start
oriol: we should decide if we map the synonymous combos at specified
value time or computed value time
fantasai: Should both variations of the syntax be allowed?
fantasai: Option 1 is to make the synonymous ones not allowed,
option 2 is to make then allowed and compute one to the
other, option 3 is to allow both and have them both have
computed values
fantasai: Don't like option 3
TabAtkins: We already do canonicalization in certain scenarios
TabAtkins: suggestion to do it at the same spot
TabAtkins: Underlying data struct wont recognize the difference
between either one of the values
fantasai: So the rules we have for computed values of position in
background-3 can't use logically generalized values
because you can't map them together at computed value time
fantasai: we have to make it explicit
TabAtkins: I don't understand
TabAtkins: (missed)
TabAtkins: I am talking about the timing of canon. we use the same
timing of other keywords such as `left`
fantasai: There is no percentage here, so canonicalization can't be
same as position
TabAtkins: Doesn't matter, can still use the same rules
<TabAtkins> nothing to think about - the point when we forget the
difference between "left 100%" and "right" is the point
where we'd also forget the difference between "start
start" and "block-start inline-start"
<TabAtkins> I don't understand what Elika is talking about.
<fantasai> TabAtkins, that's actually something we need to decide
<fantasai> It's not a given
<fantasai> because this isn't a <position>
<TabAtkins> fantasai, my point is that there's absolutely no reason
to differ in timing. Making any decision *other* than
"same as position" would be an obvious mistake.
SebastianZ: Editorial point: whether the syntax defined in
background-4 minus special cases like length/percent/
center … with a new datatype or how will we do it? will
it be dropped like suggested in the spec or will there
be a new datatype that we picked up from the position
datatype?
TabAtkins: It is not a position datatype, but a subset of it
TabAtkins: It is not a position, but closely resembles one
intentionally
SebastianZ: So it would basically be aside or corner?
fantasai: I think we all agree that block-start inline-start and
start-start have same computed value
fantasai: Question is we want to make the first one invalid or not?
TabAtkins: If we keep option to express in both ways, we need to
specify when and how it canonicalizes
fantasai: (missed)
oriol: no opinion if we should allow, but if we do, we need to
properly define it
<fantasai> TabAtkins, Afaict you're just agreeing with me
<fantasai> TabAtkins, just objecting the the fact that I raised the
question
<TabAtkins> then stop disagreeing with me ^_^
Rossen: Hearing from tab that there is a facility to the
canonicalization somewhere
Rossen: still hearing doubt about _when_ this is happening?
fantasai: I think we all agree when this happens. question is which
ones are valid + which ones canonicalize to the other
Rossen: Do we have reason for not allowing both of these to be valid?
TabAtkins: Complicates the grammar, especially in the full position
fantasai: Full pos doesn't have block-start and inline-start
TabAtkins: Yet. When we upgrade to logical it will
fantasai: This is the logical version
TabAtkins: It is not
TabAtkins: This was written before we established logical stuff
fantasai: (???) yes you have to have the three value version for bg
position
TabAtkins: anyway, I did propose an updated grammar for position
TabAtkins: fact that you can say left as position, should allow that
you can do block-start as a position
<lea> could someone link to Tab's proposal that he just mentioned?
<TabAtkins> let me find it
<Rossen> https://github.com/w3c/csswg-drafts/issues/549
Rossen: Is this 549?
TabAtkins: I think its a related issue
SebastianZ: I added it to this issue
Rossen: Let's give this some more time, but then maybe take it back
to the issue
TabAtkins: to avoid talking past each other:
TabAtkins: Are you objecting against allowing block-start inline-end
or inline-end block-start
fantasai: Should wait on the bg syntax to settle so that we can
compare
fantasai: Tab was asserting that <position> includes block-start
inline-start keywords, and it doesn't
TabAtkins: If fantasai thinks pos problem isn't settled, then we
should take it back to issue
fantasai: I think we need to spec out … if tab thinks there are
problems in draft then we should fix those.
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/1724#issuecomment-1551809388
is my proposal for a fixed BG4
fantasai: As far as I am concerned the keywords don't exist in
bgposition
Rossen: Let's continue discussion in github issue
SebastianZ: One thing: I still believe that inline-start,
background-start, background-end … but lets discuss in
issue
SebastianZ: Should we allow just start or end as one keyword to mean
start-start or end-end?
SebastianZ: Tab proposed requiring two keywords
TabAtkins: This is discussion that should be consistent with
position and this
TabAtkins: Should be discussed in issue
Rossen: Let's do that
CSS Display
===========
Why is display listed as not animatable instead of animation
type: discrete?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6429
flackr: I'll take this
flackr: We resolved to make display animatable but tried to prevent
two values of none being animated, but there were lot of
edge cases like variables
flackr: also problem with animate content on pseudos
flackr: if you animate content, it destroys the pseudo
flackr: Added something to css-animations-2 that we only cancel
animations if the computed value of display and the value of
display before the animations cascade is none
flackr: If an animations produces display none so it continues to
run instead of restarting
flackr: behaves like developers expect it to work
flackr: also consistent with content animations in firebox
emilio: Not sure is content behavior in firefox is intentional
emilio: How does this interact with nested elements?
emilio: Presumably we want to cancel animations deep in display none
subtrees
flackr: Good question
flackr: I think there is no lifetime issue if we want to cancel
animations in nested elements
flackr: I would be fine with saying that behavior should only look
at the style without local animations and the ancestor style
can include all animated styles
emilio: Not sure if I follow
emilio: When the display value becomes ?? – I think blink also has a
mechanism to clear stuff down the tree?
emilio: presumably we cancel animations then?
flackr: In blink the animations are associated with the element so
we can still remove all of the layout structured associated
with it
flackr: Question is if animations keep on living
flackr: and if their time restarts or not
flackr: We still need to keep computed style for to level display
none element to know it is display none
flackr: so I think that nested elements should just be cancelled to
reduce overhead
emilio: I think we should cancel them, yes
emilio: Need to specify when that happens?
flackr: Spec needs a slight change to reflect that it doesn't apply
to nested elements
flackr: Can do an update
emilio: OK
flackr: Proposed resolution; when an animations produces display
none it continues to run but it still cancels animations
within that subtree
Rossen: Objections? Qs?
RESOLVED: When an animations produces display none it continues to
run but it still cancels animations within that subtree.
Web Animations
==============
Progress APIs
-------------
github: https://github.com/w3c/csswg-drafts/issues/8799
flackr: So WAAPI is very focused on absolute times, but with
scroll-driven animations, developers often just work with
progress instead of time
flackr: seems like a reasonable thing to add, so there is a proposal
to get the current progress which is a calculation between
start and and end time
flackr: also need to specify what should happen for infinite
duration animations
flackr: Proposal is adding currentProgress to Animation
flackr: it is calculated as currentTime / effect endTime
flackr: propose to make it readonly for now
Rossen: Any feedback?
<ydaniv> I proposed "progress" instead of "currentProgress"
<TabAtkins> +1
<TabAtkins> (to the current proposal, no opinion on naming)
Rossen: You are taking into account the feedback from ydaniv?
flackr: Yes, he proposed currentProgress instead of progress
flackr: Don't object to this shorter name and computedTIming value
from the effect is also called progress
Rossen: What about read/write vs readonly?
flackr: Then have to decide how to handle infinite duration animation
Rossen: Starting with readonly gives up path to go forward later
Rossen: Should we formulate as readonly? Not hearing objections from
ydaniv
flackr: Would be happy with that
bramus: Me too
Rossen: Objections to adding as readonly?
Rossen: Not hearing anything
bramus: And the name?
flackr: We said progress
flackr: Proposed resolution: add progress to Animation and make it
readonly
RESOLVED: Add progress to Animation and make it readonly
CSS Transitions
===============
Add control of colorspace used for transitioning colors
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7063
chris: CSS color-4 add something that others spec can reference:
color interpolation method
chris: already used for gradients
chris: Proposal to add same token to animations, transitions, and
web animations
chris: proposal since March without no comments
chris: can't think of other way to do it
<fantasai> wfm
emilio: The idea is to add a transition-interpolation property?
chris: Yes
chris: same for animation-interpolation
emilio: So it needs to be a list?
chris: Yes
emilio: Don't know, maybe this should be in keyframes?
chris: That is part of the proposal
emilio: Feels weird that this is color specific but property name
does not give hint
chris: Can put color in there
emilio: Could be confused otherwise
<bramus> +1
emilio: other than that seems reasonable
chris: Brian also added proposal for web animations in the issue
emilio: Do we expect a lot of people setting this to anything other
than oklab?
chris: That gets us in the whole webcompat issue
chris: Talking about an opt in
chris: oklab and oklch will be obvious choices
<fserb> I think adding color to the name makes sense. (nit: Is it a
problem to add "auto" on the shorthand?)
emilio: If you do color-mix with two oklab colors, they mix in oklab
right?
chris: Yes
emilio: (???)
chris: Doesn't matter how you specify the original colors. You can
mix in other spaces
emilio: Maybe default should be oklab?
chris: Would be nice, but people have existing content
emilio: Maybe auto can do the right thing based on the defined
colors?
chris: auto means that legacy srgb mix in srgb. non-legacy colors
mix in oklab.
<fserb> I think auto already does what emilio wants.
Rossen: In terms of feature itself, do you agree emilio? then can
sweat details.
emilio: Seems reasonable, other than property name
chris: Agree
emilio: Do we want to allow interpolationg different properties
differently?
emilio: eg background-color and color
chris: I understand the requirement
chris: If its about the keyframes, it means it applies to all color
interpolations. A separate value for each one, would need a
ton of new properties
flackr: Could we specify this as part of the color?
chris: We are not going to solve this in 5 minutes
Rossen: Good suggestion
fantasai: So proposal is to add both transition-interpolation and
animation-interpolation, where you can put the last one in
a keyframe too?
chris: Yes
fantasai: We also have suggestion from emilio to do it per property
fantasai: This could be an addition?
flackr: Would affect the syntax
emilio: Need to know if we want this in the future
fantasai: Two possible ways to go about it, is to incorporate it in
the color (cfr. flackr) and another option is to do
something similar as we do with transition, and list out
the properties named e.g. animation-color-interpolation:
oklab color background-color sRGB outline-color, ...;
chris: The latter seems like a better solution
chris: Would like to see it written out
Rossen: Looks like this is expanding beyond original proposal
Rossen: Lets take back to issue
chris: Yes
F2F
===
Rossen: Extra nudge to add yourself to the wiki
Rossen: Ping the locals for places to stay
<fantasai> -> https://wiki.csswg.org/planning/cupertino-2023
Received on Wednesday, 24 May 2023 22:55:33 UTC