W3C home > Mailing lists > Public > www-style@w3.org > October 2022

[CSSWG] Minutes Telecon 2022-10-05 [css-backgrounds] [css-shared-element-transitions] [css-view-transitions] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 6 Oct 2022 18:25:33 -0400
Message-ID: <CADhPm3tZpfJs0zamALxKMctRH885wihGDhwX+b55JcxNRR9T7Q@mail.gmail.com>
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.
=========================================


CSS Backgrounds
---------------

  - RESOLVED: Always ignore transforms on backgrounds of the root
              element (Issue #6683: Are the rules for interactions of
              transforms and backgrounds on the root element what we
              want?)
  - RESOLVED: Always ignore transforms on backgrounds that propagate to
              canvas (Issue #6683)

Shared Element Transitions
--------------------------

  - RESOLVED: Use css-view-transitions as the shortname (Issue #7788:
              Renaming and brevity)
  - There was not consensus on the call the final name the pseudo
      element currently called view-transitions-images (Issue #7788).
      - Naming it view-transitions-set or view-transitions-group was
          considered too generic but view-transitions-images was
          strange because it is a plural and because some folks felt
          that images evoked a different concept.
      - Just as the timebox ended there was a suggestion of being more
          verbose in the name since we don't expect it to be a commonly
          used property.
      - Discussion on naming will continue on github.

  - RESOLVED: Only consider animations using document timeline for
              determining when the end of a view transition has come
              (Issue #7785: Define "active animation" used to signal
              end of transition)
  - RESOLVED: View animations are still active if there are running or
              paused view transition animations or any events in the
              pending event queue associated with animations on these
              pseudos (Issue #7785)

  - RESOLVED: Rendering suppression uses render blocking to pause
              update the rendering loop during a view transition (Issue
              #7784: Define how rendering is suppressed between DOM
              changes)

CSS Align
---------

  - RESOLVED: Left to left and right to right (Issue #7775: Fallback
              alignment groups with orthogonal items)

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2022Oct/0001.html

Present:
  Tab Atkins
  David Baron
  Daniel Clark
  Yehonatan Daniv
  Elika Etemad
  Megan Gardner
  Daniel Holbert
  Dael Jackson
  Vladimir Levin
  Peter Linss
  Florian Rivoal
  Khushal Sagar
  Miriam Suzanne
  Alan Stearns
  Lea Verou
  Matt Woodrow

Regrets:
  Robert Flack
  Chris Harrelson
  Jonathan Kew
  Bramus Van Damme

Chair: astearns

Scribe: dael

Agenda Setting & Housekeeping
=============================

  iank: Is there a reason why the baseline was dropped from the agenda?
  astearns: I remember removing one and there's a bunch labeled TPAC
            that needs to get retagged
  <iank> https://github.com/w3c/csswg-drafts/issues/7775#issuecomment-1267250581
  astearns: I do not recall [looks it up]
  astearns: fantasai said it wasn't super high priority
  fantasai: Compared to others
  iank: It effects a lot of WPT tests
  astearns: Let's take that after shared element transitions issues?
  fantasai: I think it should be straight-forward to resolve. Unless
            other opinions can go with behavior in issue
  astearns: Any other updates to the agenda?

  astearns: Housekeeping. Lot of chatter around Nesting with a new
            proposal. Everyone with an opinion please give a look
  astearns: Also getting implementation feedback
  astearns: Next week we should have a couple of Nesting issues on the
            agenda
  lea: To offer background had a breakout today to discuss how to
       resolve Nesting issues. That's where the proposal and related
       issues came from. Current syntax is being implemented right now
  astearns: That info is in the issues so please take a look.

CSS Backgrounds
===============

Are the rules for interactions of transforms and backgrounds on the
    root element what we want?
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6683

  mattwoodrow: Looks like discussed last year, resolved to wait for
               filter spec
  mattwoodrow: I would like to continue discussion and make a decision.
               No strong opinions
  astearns: Can you get us up to speed with what has been discussed?
  mattwoodrow: Current state is inconsistent between impl and spec is
               unclear which path. Pretty open. Slight diff in if
               background is fixed.
  astearns: Anyone with opinions?

  smfr: Any websites where this matters?
  mattwoodrow: No one has found any. Possibly because it's so different
               between browsers. I think Gecko never transforms, WebKit
               always, Chrome for scrolled but not fixed. No interop
  smfr: I would argue to do easiest to implement
  astearns: Naive guess is that's never transform?
  smfr: I think ignoring transform is easiest
  fantasai: Could make sense because if you're transforming the whole
            root you could want a background behind it and don't want
            that to transform with the page. Should be something behind
            it.
  fantasai: If you want background to transform with page you attach it
            to the page and get the behavior
  smfr: Makes sense to me. I think only background that propagates to
        canvas?
  fantasai: Yeah
  smfr: I would say they never transform. If they want transform but
        background on the body

  astearns: Anyone want to argue for paying attention to transforms on
            root element background?
  <TabAtkins> This seems confusing in general, but I think the proposal
              makes sense
  astearns: Proposal: Always ignore transforms on backgrounds of the
            root element
  astearns: Is that sufficient resolution?
  mattwoodrow: That's sufficient
  smfr: That's both background attachment fixed and scroll I think. But
        what you said should be sufficient
  astearns: Objections?

  RESOLVED: Always ignore transforms on backgrounds of the root element

  florian: Question - do we mean background on the root or background
           that prop to the canvas? Do we mean those two?
  fantasai: Yes. Anything propagates to the canvas doesn't get impacted
  fantasai: There's no transforms on canvas
  astearns: Always ignore transforms on background that get propagated
            to canvas
  smfr: Transforms applied to elements. If it's propagating to canvas
        background not effected
  fantasai: once propagates to the canvas it's not impacted by any
            transforms
  astearns: BG that are propagated to canvas have any transforms taken
            away
  smfr: Render as if originating element had no transform
  florian: We're clear enough. Let editors write
  astearns: Current resolution + discussion or amend the resolution?
  florian: Another.
  astearns: Always ignore transforms on backgrounds that propagate to
            canvas
  <florian> +1

  RESOLVED: Always ignore transforms on backgrounds that propagate to
            canvas

Shared Element Transitions
==========================

Renaming and brevity
--------------------
  github: https://github.com/w3c/csswg-drafts/issues/7788

  vmpstr: I can introduce. We want to rename structure to something
          more meaningful
  vmpstr: I would hope can resolve on feature name so can move to FPWD
          with a URL that's fixed
  vmpstr: JakeA proposed view-transition prefix to most things.
  vmpstr: Has been activity today discussing details
  astearns: Note we can pick a fixed URL and then change syntax. We've
            done it before. Shouldn't look at short URL as unchangable
            thing.

  fantasai: But shared-element-transitions is not the name we want. Do
            we use view-transitions or css-view-transitions as the URL
            short name?
  <khush> +1 for css-view-transitions
  florian: Seems reasonable. Might want to change later, but not clear
           we will.
  astearns: Anyone argue against view-transitions?
  astearns: Could resolve on css-view-transitions as the short spec
            name. Can also resolve to change all draft syntax.
  <TabAtkins> Fine with the shortname. Still not particularly happy
              with the syntax options, yeah
  fantasai: Can we do shortname first before we dive to everything else?
  astearns: Proposal: Use css-view-transitions as the shortname
  astearns: Objections?

  RESOLVED: Use css-view-transitions as the shortname

  khush: Limit discussion to spec name or also touch on names for
         pseudo elements? Got a good bunch of options there
  astearns: Are you looking to have the discussion on call or continue
            on issue when there has been a little more async discussion?
  vmpstr: If we can timebox discussion? Want a sense of uncertainty. I
          think JakeA's proposed names are pretty reasonable. I feel
          like close to resolution
  astearns: Let's spend 10 min

  <vmpstr>
  vmpstr: In Jake's proposal ^
  vmpstr: All the pseudo elements have view-transition prefix. The
          property to tag elements with an id is view-transition-name.
          Pseudos are view-transition-root. view-transition-images and
          old and new are sub-pseudo elements.
  vmpstr: fantasai proposed view-transition-set which makes sense. Also
          proposal to drop root from view-transition-root but that got
          pushback
  <TabAtkins> I prefer -images fwiw. The "set" doesn't mean anything
              afaict
  astearns: images vs set. Let's discuss
  astearns: fantasai can you say why good to change to set?
  <khush> i'm ok with set. it's smaller. :)
  fantasai: It's representing 2 images that correspond. It's not a
            selector that represents each image but represents the set
            that correspond. Captures it's a container
  astearns: If this is just [missed]. If you can duplicate on old and
            new and get same result why set?
  fantasai: There's a wrapper for a reason. If we were being really
            verbose with image-wrapper we could, but I think I prefer
            succinct. I like using transition-set on the wrapper for 2
            images
  vmpstr: It's images which is also not singular which makes it weird
          so set is good

  TabAtkins: I like images, the plural makes it clear that it's a set.
             I find set to be so content-less I have no clue what it
             means. This structure can be various levels. Don't know
             why call one a set. I vote images
  <vmpstr> we also discussed -image-group
  fantasai: Other thing about images is we're getting into, I don't
            know, the fact that it is an image we should know that but
            what we're representing is a snapshot of older and newer
            version
  fantasai: Feels different than an image that is a replaced element
  TabAtkins: The fact that it's an image in browser is important
  fantasai: Images pseudo-element is not an image, it's a wrapper
            around 2. Since old and new doesn't have work 'image'
            having 'image' in wrapper is confusing
  <iank> effect-group?

  astearns: Agree set is vague and images isn't great since it's a
            plural. Can someone describe what this is used for?
  vmpstr: It's a wrapper that sets up isolation for blending of 2
          images. Not a replaced element, but container of 2 images
          being blended together.
  astearns: What are you going to use this pseudo element for?
  vmpstr: Not sure I understand. The opacity and blend modes of images
          will interact in it without effecting other things because
          it's isolated
  fantasai: I think astearns is asking how an author is likely to use
            this pseudo element
  <iank> its similar to various cross-fade effects
  vmpstr: I see. I don't think there's a particularly good guidance on
          how to use. Typically dev wants to customize container above
          this, the parent of wrapper, or the opacity blend of images.
  vmpstr: Are some use cases where dev would want to shift container up
          or down. It moves left to right and container rises from below
  khush: Saw a demo where someone added a small animation to give a pop
         effect. Not what we anticipated for usage. We did it for cross
         fade, but that's a way we've seen devs using it.
  astearns: Given this is something that we don't have explicit use
            cases but we know people will use it. Not crucial, though.
            Could go a longer name like view-transition-effect-group or
            -image-set
  fantasai: If you're going for long view-transition-old-new-set. I
            think it's good to not use image because not really an image
  <TabAtkins> (it is really an image)
  <fantasai> sorry, I meant conceptually
  <fantasai> it is implemented as an image
  <TabAtkins> I mean conceptually too

  khush: One of the earlier suggestions was view-transition-group. Is
         that a good compromise? Maybe view is better than set.
  astearns: TabAtkins, objection to group?
  TabAtkins: It's just as generic and non-meaningful. If it's not high
             use I would say make it longer with a name for its purpose.
  TabAtkins: Where we expect style have shorter names like old new
  astearns: I suggest we take this back to the issue. Let's continue
            with this open and come back after a bit more discussion.
  astearns: I was going to suggest breaking it out, but there's good
            discussion so continue there

  <fantasai> khush, I think wrt group, since in e.g. SVG and vector
             editing, groups are a hierarchical concept
  <fantasai> khush, I think it's better not to use it for the
             image-pair-wrapper
  <fantasai> khush, seems more appropriate for the higher-level
             construct that you can nest other things inside

Define "active animation" used to signal end of transition
----------------------------------------------------------

  github: https://github.com/w3c/csswg-drafts/issues/7785

  khush: The background for this issue is that the pseudo elements we
         just discussed generated for a transition are meant to be
         temporary. need to decide when it's torn down
  khush: We use declarative elements to decide. web animations,
         animations, transitions. raff-based are excluded because
         browser doesn't know when we're done. For these want to
         auto-detect done
  khush: Wanted precise def for what state animations are in for active
  khush: Issue leaned to rely on animation state. Go through all pseudo
         elements and check for idle, running, paused

  <TabAtkins> Kind of a point of order for this
  TabAtkins: The entire point of the issue I wrote is it's supposed to
             abort if any other shared element transition are running,
             not any other animation. I never intended for web or css
             animations to be part of it. When I wrote spec I presumed
             only 1 running shared element transition at a time and
             need to check.
  khush: I think might be confusing different part of feature. This is
         have a single transition going and need to know when it ends.
         That relies on the pseudo elements generated for the transition
  TabAtkins: Possibly. I don't recall writing that but okay
  <TabAtkins> Okay yes, I was misreading
  <TabAtkins> Ignore me. 😅

  khush: Clarify exact point. Started a transition and have detected
         shared elements. Constructed full pseudo element tree. UA
         animations applied. Now want to detect when tree can be torn
         down. We keep checking animations on all pseudo elements. Need
         to define when animation is active for this transition
  khush: On issue, conclusion is check for any animation in running or
         paused. If yes, it's still active. Then check pending
         animation event queue if there's something in there that's a
         pending event. Use case for that is chaining and we want to
         make sure all events chained
  khush: Hoping to resolve on that
  khush: Second is animation timeline. Animation uses doc timeline and
         we know timeline will progress. If you have a scroll timeline
         the timeline progress depends on if there's a scroll gesture.
  khush: Proposal is ignore those for now because couldn't narrow down.
         When we decide a solution for raff we can handle similar or
         decide when have more idea of use
  vmpstr: Even with doc timeline you can set up animation that loops so
          can get same situation
  khush: True, but in that case it is easier to tell. With scroll
         timeline it's ambiguous since user gesture might never happen

  astearns: Sounded like 2 things to resolve. Timeline first?
  khush: Sure. Proposal: Only consider animations using the document
         timeline in the active animation set
  astearns: Opinions? Questions?
  astearns: As I understand, only consider animations using doc
            timeline for determining when the end of a view transition
            has come
  astearns: Concerns?
  astearns: Objections?

  RESOLVED: Only consider animations using document timeline for
            determining when the end of a view transition has come

  <ydaniv> only paused and running too, right?
  astearns: Second
  khush: Second For the animations we consider we consider them active
         if there's in running or paused and when there are not
         animations in the pending event queue
  astearns: Can be animations on things other than view transform
            pseudos
  khush: Right.
  khush: No animations on the pending event queue that correspond to
         these pseudos
  <ydaniv> that's cool

  astearns: Proposal: View animations are still active if there are
            running or paused animations in the pending event queue
            associated with these pseudos
  astearns: I imagine I may have something wrong
  khush: View animations are still active if they are in running or
         paused state and if there are any events in the pending event
         queue associated with them
  <ydaniv> * View transition animations
  <khush> View animations are still active if there are running or
          paused animations or any events in the pending event queue
          associated with animations on these pseudos
  astearns: More discussion on this?
  astearns: Objections?
  astearns: One amendment. View animations are still active if there
            are running or paused view transition animations
  khush: View animations means animations on any of these pseudo
         elements
  astearns: Objections?

  RESOLVED: View animations are still active if there are running or
            paused view transition animations or any events in the
            pending event queue associated with animations on these
            pseudos

  astearns: I see a comment in github while we discussed. He's asking
            about timelines to current document.
  astearns: Is the comment something we can decide on or should we go
            back to the issue?
  <astearns> https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1269109950
  astearns: Comment ^
  khush: I need to read on this more. Okay coming back for this

Define how rendering is suppressed between DOM changes
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7784

  khush: This issue was about one aspect of feature where when
         switching doc from state a to b we allow dev to asynchronously
         update dom without presenting to user.
  khush: We had these use cases in wild where you have a frame that you
         render and flips back to snapshot state. You get intermediate
         frames before animation
  khush: Question on how to suppress. One is render blocking that draws
         on HTML spec. Browser suppresses rendering opportunities
  khush: When you call script API to start, we snapshot and then
         suppress rendering opportunities
  khush: Other is we keep running lifecycle but browser doesn't present
         them. That could be confusing so proposing we do the render
         blocking
  khush: We are planning scoped transitions where it runs on a dom
         subtree and then we can't do render blocking. I've linked to a
         proposal there for how we want to manage the rendering with
         scoped transitions. It's using a cached snapshot but keep
         running the process and returning the cache
  khush: Would cause a difference between transition types
  khush: Proposal is go with render blocking behavior for same document
         and cross document cases

  smfr: With render blocking, is all JS paused?
  khush: No, not at all. Just the update rendering lop is paused
  smfr: Would set timeout fire?
  khush: Yes. Request animation won't
  smfr: Seems weird to turn off some callbacks but not others
  khush: Steps that are part of update rendering loop are paused.
         Similar to if document is not visible
  <TabAtkins> +1, this seems reasonable to me
  smfr: If you did call request animation frame you'd get the callback
        after render blocking is off
  khush: Correct. Similar to render blocking for a new page doc. Whole
         loop doesn't run until resources fetched

  astearns: Is there a definition of what does and does not work when
            document is not visible? I'm wondering if it's similar or
            exactly like
  khush: Best would be render blocking in the HTML spec. Points to
         rendering opportunities and says browser pauses
  khush: Clear definition of what is meant to be fired in render loop
         so gives precise definition
  <vmpstr> update the rendering, for reference:
           https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering

  smfr: Remind me what triggers unblocking?
  khush: Script API you call a function with a callback. Asynchronous
         callback where dev does all DOM mutations. Promise from that
         unblocks
  smfr: Are there other transitions/animations that can run?
  khush: All animations pause
  smfr: Completion doesn't require an animation to render
  khush: Aim of this callback is for you to do min network work you
         have to do
  khush: There is no risk of deadlock because dev callback should be
         waiting on anything dispatched during this

  <ydaniv> will that freeze video playback as well?
  khush: Video playback will freeze
  khush: One of the main reasons is the one frame that runs if you
         don't pause you get a weird flick where you draw more frames
         but then anything animated flips back to cached state
  smfr: Pausing video might be tricky for WK
  khush: I think we impl by the parts of stack running animations not
         giving them resync
  smfr: We offload some to OS. You're in the middle of a
        transform...what happens to timeline of animations for render
        blocking?
  khush: Time proceeds. Timeline will progress forward. Similar to
         visibility where a tab is backgrounded you don't draw but when
         you come back animation draws at current time
  khush: I can see implementing being tough. Motivating factor is this
         weird flick where you go forward a bit and then back in time
         when you move to cached snapshots
  astearns: Sounds like you have concerns smfr. You okay resolving to
            use render blocking and then open issues as you impl?
  smfr: Yeah, I think so

  astearns: Other opinions on using render blocking?
  astearns: ydaniv is the freezing video what you were looking for?
  ydaniv: Just look weird, same as animations stopping. I guess it will
          be necessary
  khush: Proposal: Rendering suppression uses render blocking to pause
         update the rendering loop during a view transition
  astearns: Objections?

  RESOLVED: Rendering suppression uses render blocking to pause update
            the rendering loop during a view transition

CSS Align 3
===========

Fallback alignment groups with orthogonal items
-----------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/7775

  iank: Basically, when inside a flexbox or grid. Column flexbox and
        align by baseline need an orthogonal WM. Vertical rl go in one
        group, vertical lr go in another.
  iank: Spec places orthogonal in vertical lr. fantasai prop to switch
        based on direction. If direction rtl go in vrl group
  fantasai: That's the proposal
  iank: This is an edge case. Need to pick a group. Fine with proposal.
        5 or 6 WPT to change. vlr always has 20 changes. Tests are
        inconsistent here
  fantasai: Switching based on direction makes logical sense. Somewhat
            symmetric.
  astearns: Proposal: left to left and right to right?
  iank: Left groups always on left and right groups always on right
  astearns: Concerns?
  astearns: Objections?

  RESOLVED: Left to left and right to right

  astearns: iank are you updating tests?
  iank: Yes, I have a patch in the issue

  astearns: Out of time. Please look at nesting discussion in several
            issues. If I can convince Rossen we'll start there next week
Received on Thursday, 6 October 2022 22:26:15 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:21 UTC