[CSSWG] Minutes Telecon 2023-05-24 [css-selectors] [css-logical] [css-images] [css-backgrounds] [css-display] [web-animations] [css-transitions]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - 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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2023May/0020.html

  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

  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


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
  chrishtr: previously we resolved to add it but needed to bikeshed
  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
  TabAtkins: It is not a position datatype, but a subset of it
  TabAtkins: It is not a position, but closely resembles one
  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
  <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
  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
  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
  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
  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
  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
  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

  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
  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
  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
  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


  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