Noam Rosenthal

Yea it's a problematic feature for the open web. Extensions that are constrained to a list of URLs can probably provide something like this though without exposing your identity to *all* the websites out there.

Yea also the other browsers kind of went in that direction. The thinking right now is to have everything available at a lower level like ElementInternals and let these "behaves like (button/input/img/...)" mixins emerge from user land libs.

It's probably a matter of playing with cw/ccw and large/small to choose between the 4 possible arcs from A to B.

But it has a PWA as well... I have both installed for comparison.

Awesome, seems like you're all sorted!

It's a question of whether tick should mean "ASAP, but definitely after all the microtasks, but definitely before the next paint" vs. "as late as possible, but before next paint, but ASAP if painting is suppressed for some reason"

I am not well versed in Svelte enough to say what's "better" :)

Of course, but the comment says "in almost all cases requestAnimationFrame will fire first" which is incorrect.

This would mean that you would now often have multiple ticks in the same frame in the normal (no view transition) case.

rAF wouldn't always beat setTimeout(f, 0). you can get multiple timeout calls in the same frame.

If you were using rAF up until now then the difference won't be concrete/noticeable I guess.

... also, we take feedback from web developers and framework authors very seriously, so please keep at it!

Ah yes, makes sense.

I would suggest calling scheduler.yield() there in case you are waiting on a VT callback, falling back to setTimeout if that's not supported in the browser.

Well we detect that the transition timed out, not necessarily due to a deadlock... I think the animation panel gives some indication when that happens? I'll check with the team.

Interesting... not trivial though!
Knowing that this is a deadlock requires static analysis that predicts that the promise resolution has some kind of dependency on the rAF. There could be legit use cases for calling rAF in the callback as long as the promise resolution doesn't depend on it.

Racing - Is this in order to have some sort of time limit for the callback? Can you expand on the use case and perhaps this has some other avenue?

I totally emphasize with the annoyance, a few things in view transitions are not trivial, some for a good reason. This one specifically is unavoidable.

... But ordinary non-rendering tasks continue as normal, so setTimeout callbacks are still called.

It's by design and in the spec.
When we await the callback promise, rendering is paused until the new state of the DOM is settled, and so are rAFs. Having no frames (and thus no rAF) between view transition "start" and "active" ensures that the animation starts at the old state.

Yea there was a common theme of feedback during the last year or so about the "frozen middle bit" of a cross-document view transition

(For now just trying it out in chromium to see if the resulting UX is nice)

Yes, you got it right!

I think the root of the problem is that there is no good way in the platform to access/define these UI elements when their lifecycle originates from style/layout (e.g. columns and scroll-markers).

I've made some attempt for an alternative model in github.com/w3c/csswg-dr... but it's not simple.

What Can We Actually Do With corner-shape? | CSS-Tricks When I first started messing around with code, rounded corners required five background images or an image sprite likely created in Photoshop, so when

Yay another corner-shape article! Keep them coming!

What Can We Actually Do With corner-shape? | CSS-Tricks share.google/sTQD2Jh8vvzE...

corner-shape examples should show notification when the feature is not supported · Issue #41113 · mdn/content MDN URL https://developer.mozilla.org/en-US/docs/Web/CSS/corner-shape What specific section or headline is this issue about? corner-shape What information was incorrect, unhelpful, or incomplete? T...

Yea, there might already be a standard like this.
Anyway, I've opened github.com/mdn/content/... to address this.

... But it's worth trying out all this stuff to make sure the various cases are covered.

If you use shadow DOM for encapsulation and the view transition is inside the shadow you might not need tag containment, as the shadow boundary already does that.

Thanks, good point! I will report it so that it's corrected.

What happened is that we've made view-transition names shadow-scoped at some point, so after that you couldn't make document-scoped view-transition that pierce shadow roots, and have to use ::part for that.

But if the whole view-transition is scoped inside the shadow you should be fine methinks.

By design they should "just work" with the view-transition-name matching working only within the scope.

I haven't tested this myself though.

corner-shape - CSS | MDN The corner-shape shorthand CSS property specifies the shape of a box's corners, within the area specified by its border-radius property value.

corner-shape documentation is now available on mdn!
developer.mozilla.org/en-US/docs/W...

If you thought we were done with View Transitions, guess again!

A feature Chrome is working on, is “Scoped View Transitions”, which allow you to scope a VT to a subtree of the DOM.

This unlocks things like concurrent transitions and prevents layering issues.

developer.chrome.com/blog/scoped-...

Specifically some of these are presented in order to show why routing makes more sense as an HTML primitive than a CSS primitive, even though the first deliverable is more CSS oriented.