[CSSWG] Minutes Telecon 2023-04-12 [scroll-animations] [web-animations] [css-animations] [css-view-transitions] [css-contain] [css-values]

  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: Change getCurrentTime() parameter to a dict to satisfy
              Brian's/the TAG's concerns (Issue #8201:
              Animation.getCurrentTime is easily confused with

Web Animations

  - RESOLVED: Times in a non-time-based timeline are converted to
              their relative percents (Issue #7749: Prefer phase based
              start / end delays over converting time based delays)
  - RESOLVED: Once group effects are added, also add percent-based
              delays/durations (Issue #7749)


  - RESOLVED: Draft up proposal for time-based keyframe selectors in
              Animations 2 (Issue #4907: Proposal: Time-based Keyframe

View Transitions

  - RESOLVED: Define "snapshot CB" as the current snapshot root rect,
              give it ICB behaviors so it captures all elements
              (preventing them from going higher) (Issue #8505:
              Enforce ::view-transition to be fixed position)
  - RESOLVED: isolation/blending-mode properties are added
              conditionally, as stated in current spec (Issue #7814:
              Should isolation and plus-lighter blending be applied

CSS Contain

  - Issue #8542 (content-visibility: auto visibility check timing
      needs details) needs more consideration around handling of
      ResizeObserver and so discussion will continue on github.

CSS Values

  - RESOLVED: Leave the values in Level 5 (Issue #1603: Define
              crossorigin, preload and async URL modifiers)


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Apr/0006.html

  Rachel Andrew
  Jake Archibald
  Tab Atkins
  David Baron
  Emilio Cobos Álvarez
  Tantek Çelik
  Yehonatan Daniv
  Elika Etemad
  Robert Flack
  Simon Fraser
  Paul Grenier
  Daniel Holbert
  Jonathan Kew
  Vladimir Levin
  Peter Linss
  Eric Meyer
  Khushal Sagar
  Jen Simmons
  Alan Stearns
  Miriam Suzanne
  Bramus Van Damme
  Sebastian Zartner

  Brian Birtles

Chair: astearns

Scribe: TabAtkins
Scribe's scribe: emeyer

Upcoming F2F

  astearns: Two housekeeping
  astearns: Survey out on people's reqs for a possible July meeting
  astearns: If you haven't already responded, please do so
  astearns: We're looking for sponsors
  astearns: If you can sponsor, even for a part, say so in survey or
            talk to us in the private list
  <fantasai> ->

Scroll Animations

Animation.getCurrentTime is easily confused with Animation.currentTime
  github: https://github.com/w3c/csswg-drafts/issues/8201

  astearns: Previously decided on using getCurrentTime() with a
            position parameter
  astearns: Comments since have noted that the tag prefers property
  astearns: And the person who objects to the name would be okay with
            property bag instead of positional arg
  astearns: So proposal is to change the previous resolution to use a
            property bag instead
  astearns: Comments?
  <TabAtkins> `getCurrentTime({ range: "cover" })` looks fine to me
  astearns: Objections?

  RESOLVED: Change getCurrentTime() parameter to a dict to satisfy
            Brian's/the TAG's concerns.

Web Animations

Prefer phase based start / end delays over converting time based delays
  github: https://github.com/w3c/csswg-drafts/issues/7749

  flackr: We defined a Web Animations 2 feature for converting
          time-based to run on non time-based timelines
  flackr: So they'd "just work", continuing to use percents
  flackr: Another idea came up to simplify, treating time-based
          durations and delays as their initial value (as if they're
  flackr: This works for simple cases, but concern if you have a
          time-based group or sequence effect, the delays between
          effects are very important for relative timing
  flackr: You couldn't take one of those and switch it to a different
          timeline if we didn't preserve those delays
  flackr: So two options, one is continue to convert all times to
          relative percentages when running a time animation on a
          non-time timeline
  flackr: This ensures relative timing between effects stays
  flackr: Other is we use initial values, but allow specifying
          percent-based durations/delays, which let you define the
          relation of different effects in a non-time-based way
  flackr: I think first is simpler, and what we already agreed on, but
          wanted to confirm.

  TabAtkins: Locking ourselves into non-time-based with a weird
             syntax; if that's not the case, fine
  flackr: We'll still want to define a percent delay for these
          non-time things, but this wouldn't be required for existing
  flackr: Something raised is it should be possible to take a
          time-based animation and switch it to a non-time timeline,
          and have it pick up where it left off
  flackr: Which #1 will do

  fantasai: So is proposed resolution that we'll auto-convert
            time-based delays, and *also* add percent delays?
  flackr: that sounds good to me
  flackr: Group and sequence effects aren't implemented currently, so
          I think we should add percent delays at some point before/as
          we implement group/sequences.
  fantasai: If the main thing you're using the delay for is to create
            overlapping effects, in a time-based system are you able
            to specify you animations in a way that's easy and
            comfortable, given you're combining %s and times
  fantasai: Feels like that can be a little awkward, two different
  flackr: I think the way author would use percents is they'd define a
          duration for the overall group or sequence, and the effects
          within would be percent-based
  flackr: They could mix-and-match but it would get confusing.

  fantasai: Tangential, do we want to introduce frs as a keyframe
            offset mechanism? Then you don't have to reshuffle all
            your percents if you insert some frames.
  <TabAtkins> (probably good to bring up as a separate issue)
  astearns: Should raise separately
  fantasai: Will do, just wanted to think about it in context

  astearns: Other opinions? Rob, can you summarize resolution?
  flackr: When running an animation with defined times in a
          non-time-based timeline, we convert those times to their
          relative %s of the overall effect.
  <TabAtkins> +1
  astearns: Concerns? Objections?

  RESOLVED: Times in a non-time-based timeline are converted to their
            relative %s.

  flackr: Should we also resolve to add percent-based delays?
  fantasai: If that's only needed for groups/seqs, we should add it
            when we do those.
  fantasai: but we should resolve now
  fantasai: because having time-based delays that get auto-converted
            to lengths be the only way to sequence group affects on a
            scroll animation is just too weird
  astearns: So proposed resolution is to add % delays once we add
            group effects?
  flackr: I'm good with that proposed resolution
  astearns: Objections?

  RESOLVED: Once group effects are added, also add %-based delays/


Proposal: Time-based Keyframe Animations
  github: https://github.com/w3c/csswg-drafts/issues/4907

  astearns: Unsure why 4907 is put on?
  fantasai: Just wanted to see if we wanted to do this
  astearns: Anyone want to propose something for this, or just
            continue discussing in an issue?
  fantasai: If we want to do, we can draft. If we're not sure, we can
            figure out the scope

  miriam: I've heard lots of requests for this
  TabAtkins: I presume it work in a way similar to what we just
  fantasai: Right, I think we have to think about these two together.
  fantasai: So if we want to do this we can resolve it and figure out
            the issues together
  miriam: Is 100% the final time?
  fantasai: That question is also relevant for the previous issue.
  TabAtkins: Is it the duration, or is it the duration plus the delay?
             Is that the question?
  miriam: Or final keyframe

  flackr: I think this is similar to range-based keyframes
  flackr: Where they're converted to percents of the animation
  flackr: The precedent we set is they don't set the range of the
          animation itself, they can go before beginning and after end
  flackr: I can see if you use duration:auto if picks up the greatest
          duration specified in keyframes
  TabAtkins: That would make sense if we ever do things like
             spring-timing functions
  flackr: Yeah
  flackr: But otherwise the default model should be the span is the
          animation duration, time values before/after that are clipped
  <TabAtkins> +1
  fantasai: That's different from... well what happens when you
  fantasai: [missed]
  flackr: Think it's consistent with range-based keyframes
  flackr: They convert as if you have one iteration, and you shorten
  fantasai: We'd do that here?
  flackr: Yeah, don't think you want subsequent iterations to be
          different form earlier ones
  fantasai: Feel like something's not clicking but not sure.
  fantasai: But if we want to see this we should resolve on it and
            draft it, and see how all these keyframe types work
            together to make sure they're consistent

  astearns: Anyone think we shouldn't work on it?
  astearns: So options are (1) continue to work on details in the
            issue, or (2) put a draft in Animations 2
  astearns: Anyone prefer leaving it in issue?
  astearns: Anyone object to starting work on this in Animations 2?

  RESOLVED: Draft up proposal for time-based keyframe selectors in
            Animations 2

View Transitions

Enforce ::view-transition to be fixed position
  github: https://github.com/w3c/csswg-drafts/issues/8505

  vmpstr: We currently have a ::view-transition pseudo, the root of
          the whole VT pseudo-tree.
  vmpstr: It has fixpos, and uses snapshot root as the containing block
  vmpstr: We'd like to make fixpos unchangeable, via UA !important
  vmpstr: Because we want the root pseudo to be a containing block to
          all other pseudos
  vmpstr: If we don't have that, and author can change it, we'd have
          to figure out what the VT pseudos *should* use. Haven't
          found any use-case for it, so propose to enforce it

  emilio: I think it's fine, but do you also want to ensure you're a
          containing block for other fixpos children?
  vmpstr: Does fixpos not contain fixpos?
  TabAtkins: No
  vmpstr: Okay then we'd also like it to be a fixpos containing block
          for its descendants.
  emilio: Okay can do that in a few ways, or with magic. Like a no-op
  emilio: Maybe just say it happens.
  vmpstr: I'd say UA magic is fine, the structure of the tree is also

  fantasai: Would it make sense, instead, to define that the
            view-transition tree is contained by the snapshot root?
  fantasai: In the same way the rest of the doc is contained by the
  fantasai: Like, you can't position anything based on higher than the
            ICB, we can say the same for the snapshot root for VT
  fantasai: So if you change the position of view-transition, it'll
            still be laid out in the snapshot root, and children will
            still use the snapshot root as well, as normal
  fantasai: So it basically lives in its own layout tree
  vmpstr: I think.... that's fine. We basically just want to avoid
          going to the ICB in some cases
  vmpstr: But as long as the CB chain stops at the snapshot root,
          that's fine
  fantasai: That's my suggestion then, I might call it the "snapshot
            containing block" and define it similarly to ICB
            (capturing abspos, fixpos, etc)
  astearns: Then we're not saying anything particular about the
            position value for the top view-transition pseudo?
  fantasai: Right
  fantasai: If you position:static, it'll be laid out as a block
            inside the snapshot CB

  astearns: So proposed resolution is we define "snapshot containing
            block" for the view-transition pseudo-elements, to get the
            effect we're looking for in this issue.
  vmpstr: Defining it to be the snapshot root
  fantasai: Yeah, rename "snapshot root" to snapshot CB and clarify it
            behaves as the ICB.
  astearns: Objections?
  <TabAtkins> +1

  khush: Right now spec defines snapshot root to be "the rect that the
         viewport would be if all retractable UI is hidden"
  TabAtkins: Containing block is already a rectangle
  TabAtkins: You can literally say this is the CB
  khush: So when we snapshot the root, we'll capture that rect as the
         snapshot CB

  RESOLVED: Define "snapshot CB" as the current snapshot root rect,
            give it ICB behaviors so it captures all elements (
            preventing them from going higher)

Should isolation and plus-lighter blending be applied conditionally
  github: https://github.com/w3c/csswg-drafts/issues/7814

  khush: There's some styles in the UA CSS that are applied when you
         have both old and new image
  khush: One is isolation on the image pair, the other is blend mode
         on the images, plus-lighter
  khush: This means if the two pixels you're blending are same value
         it's a no-op
  khush: You only really need the isolation to get this two-image
         crossfade though
  khush: If you have only an incoming or outgoing, just fading in/out,
         you don't need this complex blending
  khush: As an engine you can detect this and optimize
  khush: We weren't sure - authors might add a background to things
         and force us to the offscreen-blending like with two images,
         authors might not realize they're falling off to a slow path
  khush: So proposal is only apply these styles when both images are
         present. When only one is, don't apply isolation or blending
  khush: Just like in a custom-authored webpage, you'd only add what
         you need. If authors do need some complex blending they can
         add it themselves.
  <fantasai> This seems fine...

  TabAtkins: My only potential concern is isolation has
             containing-block effects
  TabAtkins: But I'm not certain if that's an important effect or not
  khush: the image pair element already has abspos, it'll have the
         same CB effect
  TabAtkins: In most cases, you aren't positioning the images
  TabAtkins: If there's an issue, it's in a funky corner case I'm not
             concerned with
  khush: The size flows through the group, the image pair uses the
         group as its CB so it sees that size. That's why we added
         abspos to make sure the CB hierarchy happens regardless of
  TabAtkins: There's a few things that will skip abspos but won't skip
  TabAtkins: so I think that's fine

  astearns: So are we resolving to just accept the current spec?
  khush: Yes.
  astearns: Objections to accepting Khushal's edits?

  RESOLVED: isolation/blending-mode properties are added
            conditionally, as stated in current spec

CSS Contain

content-visibility: auto visibility check timing needs details
  github: https://github.com/w3c/csswg-drafts/issues/8542#issuecomment-1485776304

  vmpstr: emilio raised that the language in the current Contain spec
          is hard to implement
  vmpstr: specifically, the behavior of content-visibility:auto
          elements when determining visibility
  vmpstr: intended behavior is that the very first time we determine
          visibility, that determination happens sync, and if it
          changes the state of the visibility, the style/layout pass
          happen sync with it so the first frame is consistent and
  vmpstr: Adding content-visibility:auto on an element already in the
          viewport would otherwise cause a flash of blank, because the
          typical (non-first) determination of visibility is deferred
          to next frame
  vmpstr: In my last comment in issue, I tried to propose spec changes
          to capture this rigorously
  vmpstr: Proposal is to adopt that text
  emilio: I agenda+'d before you added that comment, thanks for
          writing it
  emilio: Specifics of timing are observable in different ways
  emilio: If I understand correctly, the way chrome does it fires
          right before ResizeObserver
  emilio: scroll events, anchoring, etc all see this
  emilio: I'd love if someone from WK could go over this and confirm
          it's fine
  emilio: I'm not opposed to doing this just before RO, just want to
          make sure it's interop
  emilio: I find it a bit unfortunate we can't just use an IO to
          explain how this behavior, but I understand the use-case of

  <flackr> https://github.com/w3c/csswg-drafts/issues/8694 is also
  flackr: I linked a related issue for scroll animations, the
          determination of frames can depend on layout and we don't
          want the flash either
  flackr: We should think through before/after ResizeObserver for that
          other use-case too. I specifically put it *after* because
          the user-defined sizing might affect things we want to
          respond to
  flackr: But for content-visibility I'm concerned it might go both
          ways. An ResizeObserver might make something visible, but
          also people might want ResizeObserver positioning to rely on
          correct content-visibility.
  emilio: Right, and in Chrome right now if you append a
          content-visibility:auto element within an ResizeObserver, it
          just won't work, right?

  vmpstr: If you make a new element in an ResizeObserver callback it
          works in the same way, it hits the ResizeObserver for that
          call in the same loop
  vmpstr: The ResizeObserver itself causes a flash of rendering, so if
          it changes things we do sync run style/layout
  emilio: Oh so this also happens if you gBCR() on the element, you
          get new size?
  vmpstr: I don't.... believe so? At least not per spec
  vmpstr: To address why we wanted it before, we just don't really
          want to add a lot of script determining visibility/
          rendering. But if you put ResizeObserver before, you get
          script running that can observe it.
  emilio: It feels like this needs a bit more care. Maybe done along
          the ResizeObserver loop somehow?
  emilio: From what you wrote, I understood - in particular the
          second-to-last sentence you wrote "this always happens in
          lifecycle before ResizeObserver steps", it sounded like a
          new lifecycle step, but it seems you're not doing that if
          appending an el in an ResizeObserver causes this to run

  astearns: Take back to the issue, then?
  emilio: Think that's fine, and again if someone from WK could look
          it would be great
  smfr: I saw it. Agree that the interactions are hard to understand,
        maybe just have to implement to see what's happening.
  smaug: I agree that using IO in a way that differs from the web
         version is weird - makes me question why authors can't get a
         non-flashing IO too?
  emilio: that's fair
  astearns: Let's close discussion and take it back to the issue,
            please add comments on what you'd like to see changed

CSS Values
  scribe: emeyer

Define crossorigin, preload and async URL modifiers
  github: https://github.com/w3c/csswg-drafts/issues/1603

  TabAtkins: We agreed to add additional URL modifiers
  TabAtkins: All the things you can do with Fetch or with HTML links
  TabAtkins: We never defined them, put them off to another level
  TabAtkins: Noam went ahead and defined three of them [missed the
  TabAtkins: The mechanics are reasonable and match up with what you'd
             do in HTML
  TabAtkins: Does anyone have any objections to these, and are they
             fine for Values 4 or do they need to wait for Values 5?

  emilio: What do preload and async do?
  emilio: Preloading in the context of CSS values doesn't make a lot
          of sense to me
  TabAtkins: Noam added crossorigin, integrity, and referrer
  <TabAtkins> https://w3c.github.io/csswg-drafts/css-values-5/#request-url-modifiers
  emilio: I'm curious about the integrity string, is that a function?
  TabAtkins: Yep, takes a string that is the hash
  emilio: Seems fine to me

  fantasai: I'd prefer to leave them in Level 5 because they're
            already drafted there
  fantasai: I'd also like to get L4 to CR by closing out issues
  astearns: Anyone want to argue for L4?
  TabAtkins: L4 holds some things that aren't implemented, so we
             should kick those out; these are stable and appropriate
  TabAtkins: I don't want to kick these out for arbitrary reasons
  <tantek> +1 to consistent methodology for level 4 vs 5, ok with
           dropping things from L4 that have zero implementations.
           probably a good move before CR

  emilio: I just realized we force crossorigin to be anonymous for CSS
  emilio: We need to define whether you can override it; I don't think
          you should be able to
  emilio: Masks, for example, require anonymous crossorigin loads
  emilio: So we should define that
  TabAtkins: I don't think they're defined in a way that hooks into
             these, so we need to review that
  astearns: We should resolve to leave these in L5; any objections?

  RESOLVED: Leave the values in Level 5

Received on Wednesday, 12 April 2023 23:38:09 UTC