[CSSWG] Minutes Cupertino F2F 2023-07-18 Part I: View Transitions [css-view-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.
=========================================


View Transitions
----------------

  - RESOLVED: Close no change (Issue #9057: Size animation should use
              logical properties)
  - RESOLVED: Close no change (Issue #8886: top/left vs block-start/
              inline-start)
  - RESOLVED: Copy text-orientation from the dom node, along with the
              existing writing-mode/direction (Issue #8230: How do the
              writing-mode and direction properties affect the
              view-transition pseudo-elements?)
  - RESOLVED: Add mix-blend-mode to list of properties copied from the
              element to the group pseudo (Issue #8962: Handling
              mix-blend-mode on elements captured for a transition)
  - A note will be added to the spec explaining the motivation for the
      copied properties, being because they cannot be captured in the
      snapshot.
  - RESOLVED: Use an at-rule (of some kind) to control cross-document
              VT transitions, syntax tbd (Issue #8048: Declarative
              opt-in for cross-document navigations)

===== FULL MEETING MINUTES ======

Agenda: https://github.com/w3c/csswg-drafts/projects/38

Present:
  Rachel Andrew, Google
  Tab Atkins, Google
  David Baron, Google
  Oriol Brufau, Igalia
  Federico Bucchi, Apple
  Stephen Chenney, Igalia
  Mu-An Chiou, Ministry of Digital Affairs, Taiwan
  Emilio Cobos, Mozilla
  Yehonatan Daniv, Wix
  Matthieu Dubet, Apple
  Elika Etemad, Apple
  Rob Flack, Google
  Megan Gardner, Apple
  Sammy Gill, Apple
  Daniel Holbert, Mozilla
  Brian Kardell, Igalia
  Jonathan Kew, Mozilla
  Ian Kilpatrick, Google
  Una Kravets, Google
  Vladimir Levin, Google
  Peter Linss, Invited Expert
  Theresa O'Connor, Apple
  ChangSeok Oh, ByteDance
  Fran├žois Remy, Invited Expert
  Florian Rivoal, Invited Expert
  Cassondra Roberts, Adobe
  Vitor Roriz, Apple
  Noam Rosenthal, Google
  Khushal Sagar, Google
  Jen Simmons, Apple
  Alan Stearns, Adobe
  Miriam Suzanne, Invited Expert
  Bramus Van Damme, Google
  Sebastian Zartner, Invited Expert

Scribe: TabAtkins
Scribe's scribe: fantasai

View Transitions
================

Size animation should use logical properties
--------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/9057

  vmpstr: This is about animating width and height
  vmpstr: We currently animate those two props of the
          ::view-transition-group pseudo
  vmpstr: question was if we should be animating in inline/block-size
          instead
  vmpstr: I don't think it matters, since we're always animating both
  vmpstr: And they should map to each other
  vmpstr: So proposal is close no change, but happy to hear other
          opinions

  emilio: It does matter if authors can override
  vmpstr: The override you specify will override that property, but
          the default animation doesn't matter since they're both
          animated.
  vmpstr: I don't see how the dimension you're overriding changes if
          we're overriding logical vs physical
  emilio: If they're also animating writing-mode...
  emilio: But I agree that since you're doing both it probably doesn't
          really matter.
  emilio: let's say you animate to width:50px and height:100px
  emilio: If you said vertical writing-mode, the width and height
          won't change meaning, but what you have on your rule, which
          may be logical, does
  vmpstr: True, what you override is observable, but...
  emilio: Right. I think animating physical props are fine though.
  khush: We are copying the writing mode over from the element
         actually doing the animation, fwiw. If you flip the writing
         mode it'll flip the pseudo's writing mode too.
  TabAtkins: Animating writing-mode is weird to do in the first place
  <fremy> +1
  emilio: I think a lot of these animations use transforms, which are
          physical anyway, so I think it's okay to match.
  fantasai: I also think overall using width/height makes more sense,
            you're less likely to run into writing-mode issues
  astearns: Any other opinions?
  * fantasai notes that writing-mode is not animatable

  RESOLVED: Close no change

  [dbaron says something about the microphones)

top/left vs block-start/inline-start
------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/8886

  vmpstr: This is similar to the last
  vmpstr: We're using top/left to position the view-transition pseudo.
          Question is if we should use block/inline-start
  vmpstr: This is, I feel a little more strongly we should use top/
          left. We're using a transform here and it uses physical
          coordinates, we don't want to recompute based on writing
          mode.
  vmpstr: So I again propose closing no change.
  astearns: fantasai was the one arguing against you but she's getting
            the door for someone

  noamr: I'd say the pseudos are not "really" laid out.
  noamr: In general using margins/etc isn't really common, they don't
         interact in that way.
  noamr: They're just in the scene graph and positioned with
         transform, so I think logical props make less sense.

  vmpstr: It's also unclear to me what it means to lay out using one
          anchor point and then transform using another.
  vmpstr: So like suppose you anchor to one of the corners. If you use
          block/inline insets the corner changes based on writing
          mode, but then the transform has to change to use that
          corner as well. That's what we want to avoid.

  fantasai: I'm just trying to think through the implications if,
            like, the element is larger...
  TabAtkins: Since this is positioning, it'll overflow badly anyway
  vmpstr: This is for the group element specifically, too. The
          replaced elements that actually have an image use logical
          coordinates, they'll overflow correctly for the writing
          mode. But the group is just transformed into place, so I'm
          not sure what it would be overflowing

  khush: I guess the real awkwardness is that transforms are only
         physical; if we had logical transforms we could use logical
         position too.
  khush: But for now having one half be logical and the other physical
         is awkward.
  fantasai: I guess it's probably fine since the box we're positioning
            into is visible, it's not overflowing. So if we're laying
            out with regards to that it works
  khush: The reference box is the snapshot containing block, basically
         the viewport.
  fantasai: I think it's fine for now, we can fix it in the future if
            we need.
  astearns: So proposed resolution is to close no change

  RESOLVED: Close no change

writing-mode and direction on view-transition pseudo-elements?
------------------------------===-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/8230

  khush: This also came up in i18n review
  khush: This is one case where directionality matters
  khush: When you're animating an element, morphing from one shape to
         another...
  khush: The animation tries to make it so if the aspect-ratio of the
         box changes, in the inline direction the snapshot stretches
         to match the final size
  khush: And the block matches the aspect ratio
  khush: so whether it gets cover or contain behavior depends on
         snapshot aspect-ratio
  khush: To make it work this way, we have the group animate width and
         height
  khush: And the element inside use inset-block-start: 0,
         inline-size:100%, and block-size:auto
  khush: for this setup to work, there has to be a writing mode, we
         copy those from the dom element to the group
  khush: Are these two properties enough? do we need text-orientation
         as well?
  khush: It seems like the effect of text-orientation is baked into
         the snapshot, so we don't need it for this animation to work

  khush: fantasai had a point about how it interacts with cascade
  fantasai: Yeah text-orientation can change which logical and
            physical map to each other
  fantasai: It won't affect the properties we are setting in the spec,
            but it can have an impact on what the author sets
  fantasai: So to get that correct we should copy over all three props
  khush: I'm fine with copying over all three. Our defaults aren't
         affected, so if it helps authors it sounds okay
  astearns: So proposed resolution is to add text-orientation to the
            writing-mode/direction properties that we copy from the
            dom element

  RESOLVED: Copy text-orientation from the dom node, along with the
            existing writing-mode/direction.

Handling mix-blend-mode on elements captured for a transition
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/8962

  khush: When we're doing any kind of animation, we try to bake as
         many things as possible into the snapshot itself
  khush: but some just can't be done, like mix-blend-mode
  khush: Right now it just gets dropped on the floor
  khush: so if you want the pseudo-dom to reflect the real dom's
         rendering, the best way to handle mix-blend-mode is to copy
         it over to group pseudo
  khush: And more generally, for other properties that can't be baked
         into the snapshot, we propose to copy them over to the group
         pseudo

  noamr: If it's copied to the group, what happens if the two states
         have different mix-blend-mode
  khush: It doesn't interpolate so it'll flip immediately to the new
         value

  emilio: Do we have a list of which properties are meant to be baked
          into the image than the group?
  noamr: It's in the spec
  khush: opacity/filter/etc are baked into the snapshot, and the list
         of copied properties are very explicit
  khush: There's a "capture these properties" step in the algo
  khush: So if there are more properties to be copied we'll bring
         those in another issue
  emilio: It feels a little weird to special-case some props vs
          others, but yeah
  <emilio> noamr: Where is the list of copied properties in the spec?

  astearns: Do we run the risk of having this list continue to be
            expanded?
  SebastianZ: Maybe we have to put these special properties in some
              defined group
  SebastianZ: I saw some more properties that are on the snapshot,
              like clip-path. Are mask in that group?
  khush: All of those are baked into the snapshot itself
  khush: The set of properties that are copied as properties is in the
         spec here...
  <khush> https://drafts.csswg.org/css-view-transitions-1/#captured-elements

  vmpstr: Basically what we copy are things that interact with other
          content, not just the subtree
  vmpstr: So opacity/clip-path only affect the element, but
          mix-blend-mode interacts with something else and we can't
          capture that statically
  vmpstr: I was thinking backdrop-filter might be one of those props,
          but I'm not sure how it works
  TabAtkins: backdrop-filter lives in a similar space to mix-blend-mode

  vmpstr: I just don't know if the topology is important for the tree
  vmpstr: The element being affected is in a pseudo-element that is a
          pseudo-child of the root...
  khush: It does matter
  khush: There's a feature extension of view transition that will let
         you not lift the view transition pseudo up to the root
  khush: So that'll be necessary to get backdrop-filter to work
         correctly

  astearns: I think some prose explaining why this list exists would
            be good in the spec, that these are not effects that can
            be captured in the snapshot
  khush: Good idea, I'll add a note with motivation

  ACTION: khush to add a note about the motivation for the copied
          properties
  <RRSAgent> records action 1

  emilio: Are the snapshots we take semi-transparent? or do we
          composite with the background?
  khush: The base can be semi-transparent
  khush: it's composited just as part of being rendered in the pseudo
  vmpstr: The view-transition-name causes a stacking context
  TabAtkins: I think the conclusion is that while backdrop-filter is
             in the right spot for this, it's not usable with VT atm
  emilio: So that means mix-blend-mode works okay so that's fine
  emilio: Still seems weird to special-case some properties, but
          better than dropping it on the floor
  astearns: So proposed res is to add mix-blend-mode to the list of
            properties
  SebastianZ: and opacity/clip-path/mask?
  <fantasai> [various other properties mentioned are baked into the
             snapshot]
  astearns: They're already captured in the snapshot

  RESOLVED: Add mix-blend-mode to list of properties copied from the
            element to the group pseudo

  astearns: The list is a little weird but we do need to have this
            behavior captured
  astearns: and as people use VT and notice things being dropped from
            the snapshot, people should have an idea of where to fix
            it, so the note will be good

Declarative opt-in for cross-document navigations
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/8048

  noamr: VT2 is currently an ED
  noamr: VT2 adds cross-document transitions
  noamr: This involves two added capabilities to same-doc transitions
  noamr: One is the declarative opt-in, which is this issue
  noamr: So instead of starting the transition using JS, both
         transitions need to have an opt-in in CSS
  noamr: If both documents approve, the transition happens, as if we'd
         called a startViewTransition()
  noamr: Here's the spec, and here's the issue comment
  <noamr> https://drafts.csswg.org/css-view-transitions-2/
  <noamr> https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1637806513

  noamr: So the current idea is to have a new at-rule, currently
         called @auto-view-transition
  noamr: At first we'd have only one property in it, which is
         'same-origin: enable | disable'
  noamr: while we have only one value to do right now, we expect to
         need to extend this in the future so we're going with a
         declaration design
  noamr: Welcome bikeshedding
  noamr: In the future we want to be able to nest this inside of MQ/
         conditionals
  noamr: So you can, for example, guard it by (prefers-reduced-motion)
  noamr: also might want an opt-in to disable same-document view
         transitions
  noamr: At the moment I think we could probably only want to have
         this affect automatic VTs, let JS deal with the rest

  emilio: This is the kind of thing we've generally fixed via meta
          tags, like color-scheme, viewport, etc
  emilio: It seems like the main point of putting this in CSS is to
          use MQs, but <meta media> exists
  emilio: Has that been considered and discarded? If so, why?
  noamr: It has been.
  noamr: The original proposal was meta tags
  noamr: It's mainly around keeping the styling all in css

  TabAtkins: Part of the reason why it's not quite as necessary in meta
  TabAtkins: We do that for other things so you have it as early in
             loading as possible
  TabAtkins: Given you need enough styling to render the page,
             delaying the permission for cross-document transition
             doesn't hurt you at all
  TabAtkins: You don't need to be early
  TabAtkins: You might have to hold onto the first page a little longer
  TabAtkins: but waiting until all style comes in to turn on is fine,
             because you need all that style to render to create a VT
             anyway
  SebastianZ: Having such an at-rule would also mean having it high in
              the stylesheet
  SebastianZ: it would need to be near the top near @import, right
  TabAtkins: You have to read the whole stylesheet to render the VT
             anyway, so doesn't matter where you put it
  astearns: If the first page opts in, then we are spending time
            reading CSS for the second page even if it is opt-out

  khush: From impl perspective, right now we want to avoid having to
         parse stuff in the new page before capturing new
  khush: Right now, since both are from the same site, if the start
         page opts in it's likely the end page will also opt in so we
         eagerly capture the start page's elements
  khush: There's also some concept in HTML about render-blocking
         stylesheets. Hopefully we can get authors to get the rule in
         those stylesheets
  khush: We might be holding onto the start page a little longer, but
         the chance of discarding is pretty low. We think it's worth
         going for what's most ergonomic for webdevs

  emilio: Do we want to make this work eventually for cross-origin?
  emilio: If both pages opt in, it seems like it could work...
          (barring security constraints)
  khush: We have some use-cases right now for same-site, but not
         strong ones for cross-site
  khush: and similarly in same-site it's likely both will opt in

  vmpstr: And still, doing a little bit of extra work that's
          potentially wasted, it doesn't really affect how much of the
          end page you have to parse before you know.
  vmpstr: Even if it was in meta tags we'd still have to eagerly
          capture the old page
  emilio: so you have to wait for things to load and you have to delay
          rendering the new page until things are loaded
  emilio: So if you define it's a meta tag that's read, you can start
          rendering the new page earlier, as we do now
  khush: We're not trying to delay rendering just because there's a
         transition. There's already render-blocking in html
  khush: We have to fetch enough of the dom and stylesheets before
         first render anyway
  khush: So there will be some amount of CSS we have to block first
         frame on anyway
  khush: They can put these rules into the same stylesheets and not
         delay rendering further than what it needs to
  emilio: If you only have one dev that knows how to do this, sure,
          but that's not true generally
  khush: The author has to think about it anyway
  khush: So much CSS has to be parsed before you do first render
         anyway to make the animation work
  emilio: VT doesn't wait, then? It does first render asap and relies
          on render blocking?
  emilio: My understanding was we have to wait for the page to be
          fully loaded
  khush: Right. In same-document you get a callback so you can block
         until ready.
  khush: In cross-document we're relying on render blocking for
         the same
  emilio: So if the stylesheets in the head are loaded we can start
          rendering before content is loaded
  khush: There's an html issue where render blocking today is just
         stylesheets, but we are proposing extending it to content too
  khush: So you can detail which elements need to exist before render
         starts. and a timeout does some fallback
  emilio: So an important part of why specifying it in css is fine or
          not. [not sure what this sentence meant]

  emilio: with meta the order is clear
  emilio: with an at-rule, then we need to define how they cascade
  khush: I think that problem needs to be solved anyway.
  khush: We have a feature request to have it apply only for some
         navigation - between certain urls, only on reloads, etc
  khush: So author will need settings for these kinds of things
  emilio: So if you have that, how they interact needs to be defined
  noamr: We'll be using the same ordering that other at-rules use,
         stylesheet order
  emilio: Layers too
  noamr: Right, including all of that
  <TabAtkins> (they'll cascade atomically, like most at-rules)
  khush: Just to give a concrete example
  khush: for same-site, going from foo.bar.com to baz.bar.com, you can
         say "I'm okay with most transitions, but veto this one url"
  khush: so you'll specify two of these rules, one generally and one
         specialized to that path
  khush: so we'll need to make sure authors can specify a default
         behavior but override in special cases

  bramus: I'm very in favor of doing this in CSS
  bramus: Was wondering about the name - auto-view-transition
  bramus: Could it be more generic? @config? to cater to more
          descriptors in the future beyond VT
  bramus: Also curious how this interacts with the cascade
  bramus: Think I saw Tab saying no
  <TabAtkins> (correct)
  hober: I think it would be a mistake to rename to generic.
  hober: We don't have use-cases for non-VT cases right now. Having a
         generic name would be an attractive nuisance, I'd prefer it
         be purpose-built
  <khush> +1 to keep it VT specific. We can make the pattern generic
          if needed.
  <TabAtkins> (agree strongly, plus it does have some VT-specific
              things it needs in filtering/etc)
  <emilio> +1 to hober's comment, at-rules like this are relatively
           inexpensive

  fantasai: Strongly agree to keep it in CSS, using meta is awful.
            styling should be in css if at all possible, external
            stylesheets that can be re-used across pages are great
  fantasai: With multiple of these rules, you probably want them to
            cascade together? If the last rule says you want to
            disable cross-origin transitions, you don't want it to
            break the rest of the settings.
  fantasai: So we might want it to cascade individual descriptors,
            which some at-rules do
  <bramus> +1 to that
  <TabAtkins> (currently, only the ones that apply things to
              element-like stuff, I think?)
  fantasai: Can you say same-origin:disable;cross-origin:enable?
            that's weird. Would be good to explore the full space of
            likely descriptors first to make sure they're coherent
            together
  fantasai: Think there was some discussion about different classes of
            transitions depending on page you're going to/from
  fantasai: Might not be the first thing we do, but should be explored
            to make sure the shape of the at-rule is good.
  fantasai: So overall I agree with the direction of this, using an
            at-rule rather than meta unless there's a good mechanical
            reason.
  fantasai: but I think before we can understand if the syntax is good
            we need to explore the spaces we're expecting to extend
            into first

  SebastianZ: An idea from Bramus was to put the detection into a
              media feature
  <bramus> Link:
https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1551535268
  <bramus> (second bullet)
  SebastianZ: With that we could put everything that needs to be
              transitioned into that rule
  astearns: He's proposing to put into the @media rule
  bramus: I immediately discarded that idea in the next comment, it
          doesn't allow setting the choice
  bramus: An MQ could complement the setting
  emilio: Wouldn't that create cycles
  TabAtkins: Make it possible to change styling when VT is happening
  TabAtkins: you might want different styles for the page in that case
  <khush> https://github.com/w3c/csswg-drafts/issues/8925 is related
          to media queries for setting state based on where you're
          navigating to.

  astearns: I'm not convinced yet that we won't need the meta tag
  astearns: But I think we could start with the at-rule and if we find
            there is a perf reason to have the meta as the opt-in, we
            can add later
  astearns: the at-rule would still be necessary for other settings
            besides the bare opt-in
  emilio: As long as there's a concrete point in time where the
          at-rule needs to be seen
  emilio: then I don't object to an at-rule
  emilio: I just don't want to introduce unnecessary style updates to
          look up this config

  noamr: In reverse order
  noamr: We're not adding new style updates, just parsing the
         stylesheet to capture the rules. No need for a full cascade
  noamr: For MQs, that's a separate feature, possibly an enhancement
         for later
  noamr: wrt fantasai wanting more examples for the future, I think
         that's a fair request
  noamr: Something that's already come up is the ability to use this
         opt-in to disable same-document VTs.
  noamr: So you can disable all VTs under prefers-reduced-motion
  noamr: So that's one use-case we've already seen
  noamr: Another was same-site or first-party-set
  noamr: Another was having declarative same-document transitions,
         like allowing Navigation API to trigger VTs.

  khush: One thing emilio brought up was having a defined point where
         this is queried
  khush: We have to have a defined point where browser captures
         everything anyway
  khush: so our thinking was to use the same point as when you set up
         styles and states for the navigation, should be the same
         point we set the opt-in
  khush: I also pasted 8925 which is related to this
  khush: There's an idea of adding MQs to allow setting state based on
         old and new url
  khush: This opt-in might play with that
  khush: so you can use that MQ to set this at-rule to disable certain
         paths
  khush: So we can come back with more information on this

  emilio: Re noam's comment, you don't need to update dom styles but
          you still need to go through all the stylesheets and make sure
          it's sorted correctly
  emilio: Adding a fast path for this doesn't seem appealing to me
  emilio: In blink/wk terminology, this needs to "update the active
          stylesheets" and that still shows up considerably during
          page load
  emilio: and I don't want to do that until all stylesheets are loaded
  emilio: I'd rather make sure that on the page you're navigating to
          you don't need to do unnecessary work to hook this up
  emilio: so ideally the point where you determine the VT doesn't
          involve synchronously updating the active stylesheets

  vmpstr: I think the way we're structuring this is we're using other
          properties, such as render blocking and proposed additions
          to that, to control when the document will render
  vmpstr: and defining VT to say "at the point when the doc will
          render, you have know the opt-in/out'
  vmpstr: So no extra work, but giving the dev a little more control
          over first render timing
  vmpstr: And on the meta tag, we've discussed a double opt-in - a
          simple meta that can indicate whether the VT is even
          possible, and then use the at-rule for all the actual options
  vmpstr: I'm not opposed to that, but think we still want the css
          at-rule for more detailed config
  emilio: Using the initial frame for this makes sense and satisfies
          my constraint
  khush: Okay then the spec currently says that's when we should be
         checking the opt-in

  astearns: For this issue can we have a resolution to use the at-rule
            initially?
  emilio: Seems fine
  noamr: Also to start with an at-rule, but bring more examples of
         future usage to determine exact syntax
  fantasai: Yeah we can resolve *an* at-rule, not necessarily this
            exact shape
  astearns: So proposed resolution is to use an at-rule for
            cross-document VT transitions
  noamr: And gather examples before we decide on final syntax

  RESOLVED: Use an at-rule (of some kind) to control cross-document VT
            transitions, syntax tbd

  fantasai: Note it's not just examples of what's already there, it's
            looking at what should be possible, and defining syntax
            for it

  <br dur=30min>

Received on Sunday, 10 September 2023 15:10:00 UTC