- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 17:50:33 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Script event on new Document for cross-document ViewTransitions`, and agreed to the following: * `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)` <details><summary>The full IRC log of that discussion</summary> <noamr> https://github.com/w3c/csswg-drafts/issues/8805#issuecomment-1637790887<br> <fantasai> noamr: This comment summarizes the issue<br> <fantasai> noamr: Let's say both documents opted into a transition<br> <fantasai> noamr: We are at the state where the new document is ready to present and activate the transition<br> <fantasai> noamr: Some transitions need to be in JS<br> <fantasai> noamr: e.g. animating using WebAnimations API<br> <fantasai> noamr: Another use case is JS wanting to have access to the ViewTransition object<br> <fantasai> noamr: to know when it ends, or to be able to call skipTransition()<br> <fantasai> noamr: This is a problem we're trying to solve<br> <fantasai> noamr: Currently in the draft spec, we invented a new event "reveal"<br> <fantasai> noamr: right before the first frame<br> <fantasai> noamr: Right when the document is unblocked for render<br> <fantasai> noamr: That event will have an optional ViewTransition object<br> <fantasai> noamr: You can sign up to its promises, or skip it<br> <fantasai> noamr: The "reveal" event could be useful to HTML in any case<br> <fantasai> noamr: page visibility events only fire when the document is fully loaded<br> <fantasai> noamr: so this is how it's currently presented in the draft spec<br> <fantasai> noamr: We like it for this purpose, and also because it lets us keep the existing ViewTransition object<br> <fantasai> noamr: One of the design principles is that same-page and cross-page transitions should be as similar as possible wrt API a<br> <fantasai> noamr: Another idea was to only send an event for actual view transitions, not for every reveal<br> <fantasai> noamr: That event would require the ViewTransition object, wouldn't be optional<br> <fantasai> noamr: Another idea was to fire events for when the VT starts, is ready, and finished<br> <fantasai> noamr: This is a little more consistent with touch events etc.<br> <fantasai> noamr: where they have discrete events, rather than register to one event<br> <fantasai> noamr: In all cases, updateCallbackDone promise would be resolved from the beginning, as it's not relevant<br> <fantasai> astearns: My question about reveal event, say it might be useful for other than VT. Did you have examples in mind?<br> <fantasai> noamr: It's a place where you can register for events, e.g. when the first content paints etc.<br> <fantasai> noamr: and also place where you can do last-minute things that affect presentation<br> <fantasai> noamr: e.g. if you think not enough of the document is parsed, so you want to hide some elements<br> <khush> q+<br> <fantasai> 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<br> <astearns> ack khush<br> <fantasai> khush: Concrete use case from WebPerf, if you're adding new resources that you want to block rendering, this event lets you measure that<br> <fantasai> khush: Because it fires right before firstRender, it allows customizing your transition<br> <fantasai> 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 transition<br> <fantasai> 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<br> <fantasai> astearns: Any more comments about the event?<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I don't remember from the spec (even tho i recently read it) - are there events for same-page tranitions?<br> <TabAtkins> fantasai: or was it just promises?<br> <TabAtkins> noamr: promises only<br> <TabAtkins> fantasai: in that case i don't htink we should do the third option (separate events for stages). if we want that we should do it for both<br> <SebastianZ> q+<br> <TabAtkins> fantasai: and if we want it for same-document we should also have it for cross-document<br> <fantasai> noamr: Reason I brought up option 3, if you just want to respond when transition is finished<br> <fantasai> noamr: you have to add an event listener onto the promise. Jump through hoops<br> <fantasai> noamr: but it's a trade-off between that and same-document<br> <fantasai> khush: If you have just one event with the VT object, you have access to everything you need<br> <fantasai> khush: In same-document, you already have the VT<br> <fantasai> khush: [something about customizing]<br> <fantasai> khush: This aspect of reveal event conceptually maps to one of the promises in smae-document case<br> <fantasai> khush: in that case you have your own callback, which sets up the DOM, and then the first promise resolves<br> <fantasai> khush: since no callback setting up the DOM in cross-document case, we need some event to do conceptually what's happening<br> <fantasai> khush: to let you know when that's done<br> <astearns> ack SebastianZ<br> <fantasai> SebastianZ: I think we should still do it for both same-document and cross-document transitions<br> <fantasai> SebastianZ: for consistency<br> <fantasai> 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<br> <fantasai> noamr: What's the proposal exactly?<br> <fantasai> SebastianZ: Maybe start/ready/finished and distinguish by an attribute on the event whether it's cross-origin or same-document<br> <fantasai> [some clarifications on naming]<br> <fantasai> SebastianZ: My point was to have one event that is covering all those cases, and distinguish by the attributes of those document<br> <fantasai> noamr: so also when you have a transition you started yourself?<br> <fantasai> SebastianZ: for consistency<br> <fantasai> astearns: If we have this reveal event, and it fires always before first render<br> <fantasai> astearns: it will fire for every document<br> <fantasai> astearns: when you have a same-origin transition<br> <fantasai> astearns: and you have this event firing, does it contain the VT object even though it's not a cross-origin VT<br> <bramus> fantasai: i think we are getting confused here. There are cross doc and same doc transitions<br> <bramus> … for same docs we have an existing api and proposal<br> <bramus> … in same doc case you create a VT by calling a method<br> <bramus> … you know you created that, because you said so<br> <bramus> … when doing cross-doc, you need to get the VT object which the UA creates automatically<br> <bramus> … for that we need an event, or to add it to the doc somehow<br> <khush> thanks for the excellent summary fantasai!<br> <bramus> … we are alking about 3 options<br> <bramus> … events for phases? yes, we should have them for same-doc as cross doc<br> <bramus> … [missed]<br> <khush> q+<br> <astearns> ack fantasai<br> <astearns> aack khush<br> <astearns> ack khush<br> <fantasai> khush: thanks for the summary<br> <fantasai> khush: My vote is for one event that gives you access to the VT object<br> <fantasai> khush: if we have multiple events, having it for the same document transitions is awkward<br> <fantasai> khush: because we will soon have ability to trigger multiple same-document transitions<br> <fantasai> khush: so if this event is limited to having a cross-document transition<br> <fantasai> khush: [missed]<br> <fantasai> khush: seems much easier to wrap your head around<br> <TabAtkins> fantasai: so i fthe start/ready/finsihed events for samedocumetn doesn't make sense<br> <TabAtkins> fantasai: then we should def go for one of th eother two options<br> <TabAtkins> fantasai: either special event that only fires for a VT or the reveal event<br> <TabAtkins> fantasai: interested in hearing about the perf impls<br> <TabAtkins> fantasai: and wondering hwo html folks feel about reveal more generally<br> <fantasai> astearns: Any thoughts on perf?<br> <fantasai> [silence]<br> <emilio> q+<br> <fantasai> astearns: Have you discussed with HTML folks about new event?<br> <fantasai> noamr: Was discussed in HTML ??<br> <fantasai> noamr: don't think there's any particular perf implications<br> <fantasai> noamr: wanted to understand use case better<br> <fantasai> emilio: isn't the reveal effectively the first request Animation Frame callback?<br> <fantasai> noamr: it's before that<br> <fantasai> noamr: rAF happens [missed]<br> <fantasai> noamr: Reveal happens right when last render-blocking element is unblocked, so when you're about to have your first rAF callback<br> <fantasai> noamr: but before actual rendering<br> <fantasai> 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<br> <fantasai> emilio: so point is you cannot insert new render-blocking stuff then, because those are only parser-inserted?<br> <fantasai> noamr: you have to also listen for HEAD being finished.You can't add more render-blocking at that point<br> <fantasai> emilio: is there use case for exposing this timing, rather than firing right before first rAF callback?<br> <fantasai> emilio: presumably point of reveal event is you might want DOM set up in a particular way<br> <fantasai> emilio: and that's what rAF does<br> <fantasai> emilio: so it would avoid exposing a new timepoint<br> <fantasai> emilio: but I don't feel strongly either way<br> <fantasai> ???: Several reasons to make this appealing<br> <fantasai> ???: First is providing the VT object -- rAF can't provide that<br> <astearns> s/???/vmpstr<br> <emilio> s/???/vmpstr<br> <fantasai> vmpstr: second is back/forward<br> <fantasai> vmpstr: ...<br> <fantasai> [missed something]<br> <fantasai> khush: can discuss at HTML meeting, if there's more thinking about timing can bring with HTML group<br> <fantasai> khush: this is useful for perf measurement<br> <astearns> ack emilio<br> <fantasai> emilio: yes, it seems like something that HTML folks would have an opinion on<br> <fantasai> emilio: but seems like using first request animation frame isn't quite doable ecause of the ?? cache<br> <fantasai> emilio: if we need a new event, as long as it's well-defined when it should fire, seems OK<br> <fantasai> emilio: just feels a bit weird to expose this extra last render-blocking thing<br> <fantasai> emilio: especially because a bunch of stylesheets can be loaded async<br> <fantasai> emilio: authors would observe<br> <fantasai> emilio: so if you have a stylesheet in the memory cache, right now that effectively doesn't block rendering<br> <fantasai> emilio: but from PoV of author, it probably should behave like that<br> <fantasai> emilio: and I think right now what we do is fire load event<br> <fantasai> emilio: so timing details is worth raising with HTML folks<br> <fantasai> emilio: but need it to happen before page is presented<br> <fantasai> emilio: so can't do rAF or synchornously when last stylesheet loads etc.<br> <astearns> ack fantasai<br> <emilio> fantasai: it sounds we could resolve we want a single event with the vt object attached<br> <emilio> ... not sure we want it to be fired only for vt or something more generic<br> <emilio> ... is that what we're landing<br> <emilio> khush: also emilio's question about when this is fired<br> <emilio> fantasai: which might depend on which of those two we land on<br> <emilio> fantasai: in that case we should resolve on that and then discuss further with the html folks?<br> <fantasai> astearns: So let's resolve to have a single event to carry the VT object<br> <fantasai> astearns: and work with HTML folks to define exact timing and whether it's a vT-specific event or generic<br> <fantasai> astearns: any objections?<br> <fantasai> 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)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8805#issuecomment-1640688426 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 17:50:35 UTC