[CSSWG] Minutes Cupertino F2F 2023-07-18 Part II: View Transitions Continued [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 (Continued)

  - RESOLVED: Add a single event to carry the cross-document VT
              object. Work with HTML folks to define exact timing,
              and whether it's a VT-specific event or generic (always
              fired) (Issue #8805: Script event on new Document for
              cross-document ViewTransitions)
  - RESOLVED: Reloads don't trigger view transitions by default
              (Issue #8784: Should ViewTransitions be triggered for
  - Investigation will continue in issue #8784 to determine if there
      are other cases that should not by default trigger view
  - RESOLVED: Leave these cases explicitly undefined in the spec
              (Issue #8783: Should ViewTransitions be triggered for
              browser initiated navigations)
  - RESOLVED: Have some way to assign a name to a VT and style
              differently based on it, details tbd (Issue #8960:
              Components participating in the transition need to leak
              info to embedding context)
  - RESOLVED: Document security and privacy concerns into the spec,
              encourage more reviews (Issue #8889: security/privacy
              considerations with cross-origin css)
  - RESOLVED: UAs may discard author transitions if they are
              providing their own (Issue #8953: Cross-document View
              Transition when there is a UA transition)


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

Scribe: fantasai

View Transitions (Continued)

Script event on new Document for cross-document ViewTransitions
  github: https://github.com/w3c/csswg-drafts/issues/8805

  <noamr> https://github.com/w3c/csswg-drafts/issues/8805#issuecomment-1637790887
  noamr: This comment summarizes the issue
  noamr: Let's say both documents opted into a transition
  noamr: We are at the state where the new document is ready to
         present and activate the transition
  noamr: Some transitions need to be in JS
  noamr: e.g. animating using WebAnimations API
  noamr: Another use case is JS wanting to have access to the
         ViewTransition object
  noamr: to know when it ends, or to be able to call skipTransition()
  noamr: This is a problem we're trying to solve

  noamr: Currently in the draft spec, we invented a new event "reveal"
  noamr: right before the first frame
  noamr: Right when the document is unblocked for render
  noamr: That event will have an optional ViewTransition object
  noamr: You can sign up to its promises, or skip it
  noamr: The "reveal" event could be useful to HTML in any case
  noamr: page visibility events only fire when the document is fully
  noamr: so this is how it's currently presented in the draft spec

  noamr: We like it for this purpose, and also because it lets us
         keep the existing ViewTransition object
  noamr: One of the design principles is that same-page and
         cross-page transitions should be as similar as possible wrt
  noamr: Another idea was to only send an event for actual view
         transitions, not for every reveal
  noamr: That event would require the ViewTransition object, wouldn't
         be optional
  noamr: Another idea was to fire events for when the VT starts, is
         ready, and finished
  noamr: This is a little more consistent with touch events etc.
  noamr: where they have discrete events, rather than register to one
  noamr: In all cases, updateCallbackDone promise would be resolved
         from the beginning, as it's not relevant

  astearns: My question about reveal event, say it might be useful
            for other than VT. Did you have examples in mind?
  noamr: It's a place where you can register for events, e.g. when
         the first content paints etc.
  noamr: and also place where you can do last-minute things that
         affect presentation
  noamr: e.g. if you think not enough of the document is parsed, so
         you want to hide some elements
  noamr: Other use cases have not been explored much, but it felt
         like this is a new lifecycle point that we should expose
         rather than only expose the one use case for VT

  khush: Concrete use case from WebPerf, if you're adding new
         resources that you want to block rendering, this event lets
         you measure that
  khush: Because it fires right before firstRender, it allows
         customizing your transition
  khush: E.g. if you're going from one page to another, but the image
         hasn't been fetched yet, you might choose to do a different
  astearns: In addition to testing blocking things, you could use it
            to test blocking in general. Since if blocking, would
            affect when this event fires

  astearns: Any more comments about the event?
  fantasai: I don't remember from the spec (even though I recently
            read it) - are there events for same-page transitions?
  fantasai: or was it just promises?
  noamr: Promises only
  fantasai: In that case I don't think we should do the third option
            (separate events for stages). If we want that we should
            do it for both
  fantasai: and if we want it for same-document we should also have
            it for cross-document
  noamr: Reason I brought up option 3, if you just want to respond
         when transition is finished
  noamr: you have to add an event listener onto the promise. Jump
         through hoops
  noamr: but it's a trade-off between that and same-document
  khush: If you have just one event with the VT object, you have
         access to everything you need
  khush: In same-document, you already have the VT
  khush: [something about customizing]
  khush: This aspect of reveal event conceptually maps to one of the
         promises in same-document case
  khush: in that case you have your own callback, which sets up the
         DOM, and then the first promise resolves
  khush: since no callback setting up the DOM in cross-document case,
         we need some event to do conceptually what's happening
  khush: to let you know when that's done

  SebastianZ: I think we should still do it for both same-document
              and cross-document transitions
  SebastianZ: for consistency
  SebastianZ: I would have one event for them and then you could have
              an attribute on those events to distinguish which kind
              of transition it actually is
  noamr: What's the proposal exactly?
  SebastianZ: Maybe start/ready/finished and distinguish by an
              attribute on the event whether it's cross-origin or
  [some clarifications on naming]
  SebastianZ: My point was to have one event that is covering all
              those cases, and distinguish by the attributes of those
  noamr: So also when you have a transition you started yourself?
  SebastianZ: For consistency
  astearns: If we have this reveal event, and it fires always before
            first render
  astearns: it will fire for every document
  astearns: When you have a same-origin transition
  astearns: and you have this event firing, does it contain the VT
            object even though it's not a cross-origin VT

  fantasai: I think we are getting confused here. There are cross doc
            and same doc transitions
  fantasai: [don't confuse with same-origin and cross-origin
            transitions, which are both cross-document]
  fantasai: for same docs we have an existing api and proposal
  fantasai: In same doc case you create a VT by calling a method,
            which returns the VT object
  fantasai: You know you created that, because you said so
  fantasai: When doing cross-doc, you need to get the VT object which
            the UA creates automatically
  fantasai: For that we need an event, or to add it to the doc somehow
  <khush> thanks for the excellent summary fantasai!
  fantasai: We are talking about 3 options
  fantasai: Events for phases? if yes, we should have them for
            same-doc as cross doc
  fantasai: [missed]

  khush: Thanks for the summary
  khush: My vote is for one event that gives you access to the VT
  khush: If we have multiple events, having it for the same document
         transitions is awkward
  khush: because we will soon have ability to trigger multiple
         same-document transitions
  khush: so if this event is limited to having a cross-document
  khush: [missed]
  khush: seems much easier to wrap your head around
  fantasai: So if the start/ready/finished events for same document
            doesn't make sense
  fantasai: then we should def go for one of the other two options
  fantasai: either special event that only fires for a VT or the
            reveal event
  fantasai: Interested in hearing about the perf impls
  fantasai: and wondering how html folks feel about reveal more

  astearns: Any thoughts on perf?
  astearns: Have you discussed with HTML folks about new event?
  noamr: Was discussed in HTML ??
  noamr: Don't think there's any particular perf implications
  noamr: Wanted to understand use case better
  emilio: Isn't the reveal effectively the first request Animation
          Frame callback?
  noamr: It's before that
  noamr: rAF happens [missed]
  noamr: Reveal happens right when last render-blocking element is
         unblocked, so when you're about to have your first rAF
  noamr: but before actual rendering
  noamr: If you write polyfill code today, you would check all your
         render-blocking styles and scripts, and wait until all
         loaded, and then fire an event
  emilio: So point is you cannot insert new render-blocking stuff
          then, because those are only parser-inserted?
  noamr: You have to also listen for HEAD being finished. You can't
         add more render-blocking at that point

  emilio: Is there use case for exposing this timing, rather than
          firing right before first rAF callback?
  emilio: Presumably point of reveal event is you might want DOM set
          up in a particular way
  emilio: and that's what rAF does
  emilio: so it would avoid exposing a new timepoint
  emilio: but I don't feel strongly either way
  vmpstr: Several reasons to make this appealing
  vmpstr: First is providing the VT object -- rAF can't provide that
  vmpstr: second is back/forward
  vmpstr: ... [missed something]
  khush: Can discuss at HTML meeting, if there's more thinking about
         timing can bring with HTML group
  khush: this is useful for perf measurement

  emilio: Yes, it seems like something that HTML folks would have an
          opinion on
  emilio: but seems like using first request animation frame isn't
          quite doable because of the ?? cache
  emilio: If we need a new event, as long as it's well-defined when
          it should fire, seems OK
  emilio: just feels a bit weird to expose this extra last
          render-blocking thing
  emilio: especially because a bunch of stylesheets can be loaded
  emilio: Authors would observe
  emilio: So if you have a stylesheet in the memory cache, right now
          that effectively doesn't block rendering
  emilio: but from PoV of author, it probably should behave like that
  emilio: and I think right now what we do is fire load event
  emilio: So timing details is worth raising with HTML folks
  emilio: but need it to happen before page is presented
  emilio: So can't do rAF or synchronously when last stylesheet
          loads etc.

  fantasai: It sounds we could resolve we want a single event with
            the VT object attached
  fantasai: not sure we want it to be fired only for vt or something
            more generic
  fantasai: is that what we're landing
  khush: Also emilio's question about when this is fired
  fantasai: Which might depend on which of those two we land on
  fantasai: In that case we should resolve on that and then discuss
            further with the html folks?
  astearns: So let's resolve to have a single event to carry the VT
  astearns: and work with HTML folks to define exact timing and
            whether it's a VT-specific event or generic
  astearns: Any objections?

  RESOLVED: Add a single event to carry the cross-document VT object.
            Work with HTML folks to define exact timing, and whether
            it's a VT-specific event or generic (always fired)

Should ViewTransitions be triggered for reloads?
  github: https://github.com/w3c/csswg-drafts/issues/8784

  noamr: This is about reloads, came up by people using the current
         experiment we have with cross-document transitions
  noamr: question is what should happen on reloads
  noamr: By default, currently, the transition happens because
         it's just a same-origin navigation where both pages opt in!
  noamr: but developers find this confusing
  noamr: In the future we might want opting in or customizing
         specifically the reload transition
  noamr: which is something we wanted to add to the opt in
  noamr: but wanted to say that they're disabled for now
  noamr: because more confusing that useful
  <astearns> +1 to disabling on reload (by default)
  noamr: Also thinking about reloads, reloading from cache, things
         are not always fast when you reload
  noamr: Also you probably went from some state to same state
  noamr: Right now is disable by default, opt in if need arises
  <khush> +1

  fantasai: 100% agree about disabling
  fantasai: Also this is something to think about when designing the

  emilio: Wanted to ask about reloads, or navigating to the same URI
  emilio: e.g. if you click to the same URI
  noamr: Related is history
  noamr: I think that navigating to the same URI is also like posting
         a form, for example
  noamr: in which case transitions could be useful?
  emilio: I'm fine with special-casing reloads
  emilio: but seems like other cases to consider
  emilio: e.g. click on GitHub logo from the GitHub homepage. Seems
          weird to navigate around
  <dbaron> my intuition is that special-casing reloads makes more
           sense than special-casing same-uri navigation

  khush: With regards to navigation, two types, replacing current
         entry or adding a new entry
  khush: so if you have a link to the same page, retrieve that as a
         new navigation
  khush: but if replacing the current entry, then that shouldn't do a
  emilio: So are you proposing to do reload, or all replacement
  emilio: I think we all agree that reloads shouldn't trigger VT
  emilio: but are there other cases?
  emilio: e.g. [lists examples: clicking on the same page (not a
          replaced load), explicit replace load via script, ...]
  emilio: Question is what specific concepts to use here, though we
          all seem to agree on disabling reload by default
  noamr: [too quiet]
  noamr: Might be a good starting point
  noamr: Redirect, like meta refresh
  noamr: is that also a replace?
  noamr: Client-side redirects
  noamr: are also replace
  noamr: [missed]

  fantasai: It seems we all agree on reloads
  fantasai:  but we need more exploration for which other cases
             shouldn't trigger a transition
  fantasai:  e.g. clicking on a fragment adds to history but probably
             shouldn't transition
  <khush> Unless it's cross-doc, we won't do a transition.
  fantasai: So should we resolve on reloads not doing transitions and
            investigating other issues in the issue?
  astearns: Proposed resolution is reloads don't trigger VT by
            default, any objections?

  RESOLVED: Reloads don't trigger view transitions by default

  ACTION: Investigate other cases that shouldn't trigger view
  <RRSAgent> records action 2

  astearns: If we disable a bunch of stuff, re-enabling things might
            be tricky, so need to be careful when categorizing the
            set of things
  astearns: but let's move on

Should ViewTransitions be triggered for browser initiated navigations
  github: https://github.com/w3c/csswg-drafts/issues/8783

  vmpstr: Same spirit, but about browser-initiated navigation
  vmpstr: It is a navigation, but should that do a transition?
  vmpstr: Reason it's a question is that the page might not expect
          that route to be animatable
  vmpstr: but at the same time, if it's supported, could do a
  noamr: Regardless of address bar, we do support for back/forward in
  noamr: but that could also create unexpected routes
  noamr: Address bar is a special case of something general, but many
         things that we do want to support
  noamr: e.g. jump in history

  khush: My take on this is that it's hard to figure out all the
         cases where we can say this navigation was intentional from
         the author
  khush: Easier to say that it's all same-origin
  khush: and give some knobs for controlling which navigations trigger
  khush: right now you would need some scrijpt
  khush: but there are proposals for making that declarative
  vmpstr: At least as a user, when I type into the URL bar, I'm
          beginning a new experience
  vmpstr: I don't expect there to be anything to persist my cognitive
  vmpstr: so in that case a transition doesn't help me
  vmpstr: So good point about back/forward, can also jump multiple
  vmpstr: I would argue again that you're breaking your experience
  vmpstr: so non-transition animation is good
  <bramus> seems reasonable
  vmpstr: Happy to be convinced otherwise, but don't think we should
          try to do transition in every possible place
  vmpstr: but rather for cases where devs expect
  khush: You mean user
  vmpstr: No I mean developer
  khush: If the user copies URL form a link and pastes...
  vmpstr: I would still argue it's still a new thing
  <dbaron> (I think I agree with vmpstr.)
  <astearns> (I think I also agree with vmpstr - no transitions for
             browser-initiated navigations)

  nicole: When you go from one page to another, and the other origin
          doesn't expect it either, isn't this also unexpected
  nicole: for cross-origin, second page did not set up that
          navigation transition
  vmpstr: Agree, that's why we didn't pursue cross-origin originally
  vmpstr: it's harder problem to work out
  nicole: I think it would not be good experience if they have to say
          exactly which pages they want, could have thousands
  nicole: so should be easy to opt in or out of having transitions

  khush: Phrasing is interesting wrt user vs dev expectations
  khush: If I have transition from A to B, and I paste in the URL
  khush: As a developer I would expect the transition
  khush: I wouldn't know how the navigation is triggered
  khush: As a user, type in the new URL, the transition keeps the
         visual context
  khush: As a user I think the animation would line up with what I
         expect to see
  khush: but yes, I'm curious about what web developers think
  khush: We're not sure if how navigation was triggered changes things

  fantasai: Need more information from authors and users, next steps
            to collect more expectations?
  astearns: Anyone else with an opinion?
  astearns: It sounds like just in the room, between khush and vlad
            we've got 2 different opinions
  noamr: "browser-initiated navigation" isn't specified, and there
         are lots of types
  noamr: I'm not sure this needs to be interoperable because not
         exactly web-visible
  astearns: Seems like we should just keep this issue open and see if
            we get a better sense of author and user expectations

  nicole: I'm curious what percent of users modify the URL in the
          navigation bar
  nicole: Seems like a nerdy power-user thing to do
  nicole: so maybe not something to resolve on
  hober: I think the simple answer is that enough of them do that it
  khush: Out of all the navigation, figure out how many same-origin
         cross-document navigations happen, if the number is low
         enough take the easier option
  khush: jumping multiple steps in history is also power user
  myles: They are not rare. Typing into the URL bar is not power user
  khush: for a same-origin cross-document navigation... it seems like
         cross-origin is more common for typing

  fantasai: I suggest we leave these cases explicitly undefined in
            the spec
  fantasai: and revisit later if we end up with a definite opinion
  astearns: so proposed resolution is to leave undefined

  RESOLVED: Leave these cases explicitly undefined in the spec

Components in transition need to leak info to embedding context
  github: https://github.com/w3c/csswg-drafts/issues/8960

  khush: We've seen use cases where authors want to change view
         transitions based on state of the DOM
  khush: Some tutorials suggest setting up a class on the root element
  khush: to get custom transitions
  khush: Is this the most optimal way?
  khush: Or should we allow startViewTransition() to pass in a keyword
  khush: which then gets propagated to e.g. a media query
  khush: I don't know that it's worth making a custom feature for
         this, rather than just recommending using class names on the

  ydaniv: The issue started as a perf problem, and then changed to a
          ?? API
  ydaniv: We have state that's under the HTML object. In order to
          lift that so that the DOM tree for the transition can be
          styled based on that state
  ydaniv: using the :has() selector
  ydaniv: but that's a big perf no-no
  ydaniv: Putting that aside, maybe even if browsers can optimize
          that it's only styling the pseudo-tree for transitions
  ydaniv: but aside from preferred way, after DOM callback, to set
          attributes or ?
  ydaniv: there was also a thought for maybe on the next level,
          expose the state

scribe: TabAtkins

  fantasai: I think it would be pretty straightforward to create this
            kind of tag in the arguments of the startViewTransition()
  fantasai: Easy way to expose it would be with ::view-transition(foo)
  fantasai: Modifying the dom to pass arguments is awkward even if
            it's performant
  fantasai: So if we can pass a name to startViewTransition() then
            select based on that name, it seems nicer
  fantasai: I think people would probably also want it for
            cross-document stuff
  fantasai: from urls A to urls B it's X class of transition

  bramus: I was going to propose something similar
  bramus: the flag or label in JS which you can read in CSS
  bramus: In addition to that maybe a MQ
  fantasai: You can't do an MQ because you might have multiple VTs
  bramus: A CQ maybe?
  fantasai: That's why I think having it be an argument in
  vmpstr: Problem with that is all the nested elements are accessed
          via the root element directly, so it's unclear to me how to
          limit a style to a group to only apply in this case
  fantasai: Might be able to just pass that directly in as a second
  <TabAtkins> (or define that ::view-transition-group() is *also*
              accessible under ::view-transition ?)
  vmpstr: I'm also ok with MQs but agree it could be confusing with
          multiples VTs running
  fantasai: With Tab's idea, nice thing is if Nesting allowed pseudos
            you could open up brackets and put them all inside of
  khush: We didn't want to have to express the entire pseudo tree,
         how would you target something deep?
  vmpstr: You just put them under the ::view-transition, it's like
          having them come off of html

  fantasai: Let's talk about this on the break
  fantasai: Does anyone think we should *not* make this work, and
            rely just on class names?
  ydaniv: I think it's very good to pass to the startViewTransition
          and recognize somehow in CSS, yeah
  fantasai: Ok great let's try to come up with a proposal in this
  noamr: We have to think how this applies cross-document too
  fantasai: I think this gives you more options cross-origin, yeah,
            you don't have to try and modify the destination dom

  khush: I want to make sure I understand the reason for not using MQ
  khush: MQ is nice because you can configure what things get a vt
         name based on type
  khush: But using a ::view-transition() would only let you hit the
  fantasai: You said earlier that you plan to have the ability to have
            multiple simultaneous VTs. How does that work?
  khush: If you have different VTs, each will have different
         originating elements
  khush: So rather than html::view-* you'll have .foo::view-*
  khush: so that's how it's different
  fantasai: But the MQ can't match based on element...
  <TabAtkins> Okay so they *would* all match in the MQ at once (and
              you'd use the selector to actually target the right
  bramus: So if you have multiple transitions going on, the name you
          attach to each would have to be different
  khush: I just want to have the MQ syntax on the table to discuss
  fantasai: Confusing bit is just if you start two transitions, they
            both set the VT name, and they set it in the same subtree,
            it can get confused with each other
  vmpstr: Right MQ is global, these subtrees are very local. mixing
          the two seems prone to weird conflicts
  khush: Okay, seems fine
  khush: You can always toggle some class names at the same time as
         you call startVT() with a name, sure
  astearns: So should we resolve that we want a solution, and continue
            in the issue?
  khush: Yeah
  astearns: Objections?

  RESOLVED: Have some way to assign a name to a VT and style
            differently based on it, details tbd

security/privacy considerations with cross-origin css
  github: https://github.com/w3c/csswg-drafts/issues/8889
  scribe: fantasai

  noamr: This goes back to ? and raised bigger question
  noamr: Basically allows a third-party CSS to ? opt into transitions
  noamr: If we add MQ that decides things based on incoming URLs,
         which not proposed yet, but it's cooking
  noamr: It could allow the third-party CSS to know things about the
         incoming URL
  noamr: and it was a general issue about how do we view third-party
         CSS in terms of security
  noamr: It does seem it's not safe, but safety is not a boolean
  noamr: I opened this issue to get some guidance on it

  astearns: Anyone with guidance to share?
  khush: Fwiw we got a comment from security review which is that it's
         OK, since author is opting in to loading the third-party CSS
  khush: Already some amount of trust there
  astearns: Author of the page that you're navigating to is opting
            into loading third-party CSS by saying view transitions
            are OK?
  khush: If opt-in is in CSS, and you're embedding a third-party
         stylesheet, could become an issue
  khush: e.g. third-party transition could opt you into having
  <TabAtkins> I agree with the security person's comment - if we
              continue to respect existing Referer policy then what's
              left is fine

  fantasai: You probably have to trust a lot for a bunch of other
            things if you are loading third-party CSS
  fantasai: e.g. third-party CSS can make you load fonts that you
            wouldn't otherwise load
  noamr: Allows third-party CSS to know things that they didn't know
  khush: e.g. could load resources based on what page you were
         navigating from
  khush: even if same-origin
  khush: so I don't think you're going to learn new information
  khush: Question was if you load third-party CSS, do you expose
         things that the third party wouldn't have been able to know.

  TabAtkins: I agree with the security comment, as long as we respect
             existing referrer policy and don't expose to the new page
  TabAtkins: then what's left is fine
  TabAtkins: If you're allowing something that allows running @rules
             from third-party, already allowing them to p0wn your page
  astearns: We should document this in the Security section of VT spec
  astearns: I think proposed resolution is to document security/
            privacy concerns and continue getting reviews

  RESOLVED: Document security and privacy concerns into the spec,
            encourage more reviews

Cross-document View Transition when there is a UA transition
  github: https://github.com/w3c/csswg-drafts/issues/8953

  khush: This was about, some browsers have transition as part of
         browser UX while navigating
  khush: e.g. in Safari and Chrome today, if you swipe between pages
         you get default transition from UA
  khush: Proposal is that if the UA does its own transition, don't do
         the author transition
  khush: If there's a use case where authors want to customize, could
         allow that somehow
  khush: but don't run both
  hober: I think that sounds good.
  hober: I think the main case you identified on mobile is history
  hober: It would be bad if having two animations, so if spec allows
         browsers to skip transition in those cases seems fine
  hober: There was a related issue wrt disabling browser animation,
         and I have concerns about that
  astearns: Should we be more permissive and say that the UA can
            either skip the transition if providing their own, or
            somehow accommodate
  hober: That would work for me too
  astearns: Other opinions?
  astearns: Proposed resolution is that UAs may discard author view
            transitions if they are providing their own
  astearns: Objections?

  RESOLVED: UAs may discard author transitions if they are providing
            their own


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