Given that the plan for scoped is to expose this property on the scope element, it seems better to have symmetry between the meanings of element.activeViewTransition and document.activeViewTransition, and I don't think we'll ever want more than one active transition for the same scope.
If there's a need to iterate over all active transitions, let's call that something else? On Mon, Aug 25, 2025 at 2:13 PM Alex Russell <slightly...@chromium.org> wrote: > Is there a reason not to make this an array or iterable now? > > Best, > > Alex > > On Thursday, August 21, 2025 at 6:54:35 AM UTC-7 Vladimir Levin wrote: > >> Here is the spec PR https://github.com/w3c/csswg-drafts/pull/12635 >> >> Re multiple transitions, there is currently only one possible transition >> on the document. You're right that with scoped view transitions there will >> be a possibility of multiple transitions, but only one per scope. We plan >> to add Element.activeViewTransition for this purpose as well. We haven't >> considered exposing all transitions within the document, but it's certainly >> possible via some other property (e.g. activeSubtreeTransitions). I think >> that's somewhat orthogonal and there is still value in getting the specific >> transition that is currently ongoing on the scope as opposed to all >> transitions happening within the document. >> >> Thanks! >> Vlad >> >> On Wed, Aug 20, 2025 at 11:12 AM Alex Russell <slightly...@chromium.org> >> wrote: >> >>> Given the plans for scoped view transitions (which I'm very excited >>> about!), can there be more than one of these? Should it be an array or an >>> interable? >>> >>> Best, >>> >>> Alex >>> >>> On Wednesday, August 20, 2025 at 8:05:19 AM UTC-7 Vladimir Levin wrote: >>> >>>> Yes, there's a resolution on CSSWG >>>> https://github.com/w3c/csswg-drafts/issues/12407#issuecomment-3129024378 >>>> >>>> We're working on the spec PR to add this to the spec >>>> >>>> Thanks, >>>> Vlad >>>> >>>> On Monday, August 4, 2025 at 2:13:21 PM UTC-4 dan...@microsoft.com >>>> wrote: >>>> >>>>> Does this still need to be added to a spec? "activeViewTransition" >>>>> doesn't appear anywhere in >>>>> https://drafts.csswg.org/css-view-transitions-2 or at >>>>> https://dom.spec.whatwg.org/#interface-document. >>>>> >>>>> -- Dan >>>>> >>>>> On Wednesday, July 30, 2025 at 8:31:16 AM UTC-7 vmp...@chromium.org >>>>> wrote: >>>>> >>>>>> Contact emailsvmp...@google.com >>>>>> >>>>> >>>>>> >>>>>> Explainer >>>>>> https://github.com/WICG/view-transitions/blob/main/active-view-transition.md >>>>>> >>>>>> Specificationhttps://drafts.csswg.org/css-view-transitions-2 >>>>>> >>>>>> Summary >>>>>> >>>>>> View Transitions API allows developers to start visual transitions >>>>>> between different states. The primary SPA entry point to this is >>>>>> `startViewTransition()` which returns a transition object. This object >>>>>> contains several promises and functionality to track the transition >>>>>> progress, as well as allow manipulations such as skipping the transition >>>>>> or >>>>>> modifying its types. The proposal here is ergonomic in nature: instead of >>>>>> requiring that users store this object in some sort of way for easy >>>>>> access, >>>>>> provide a `document.activeViewTransition` property that represents this >>>>>> object, or null if there is no transition ongoing. Note this similarly >>>>>> applies to MPA transitions, where the object is only available via >>>>>> `pageswap` and `pagereveal` events. In this proposal >>>>>> `document.activeViewTransition` would be set to this object for the >>>>>> duration of the transition. >>>>>> >>>>>> >>>>>> Blink componentBlink>ViewTransitions>SPA >>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EViewTransitions%3ESPA%22> >>>>>> >>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/1124 >>>>>> >>>>>> TAG review statusPending >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> This is a new addition that doesn't pose interop or compat risks. The >>>>>> availability of this feature is detectable via the presence of the >>>>>> property >>>>>> >>>>>> >>>>>> *Gecko*: No signal ( >>>>>> https://github.com/mozilla/standards-positions/issues/1278) >>>>>> Discussed at https://github.com/w3c/csswg-drafts/issues/12407 >>>>>> >>>>>> *WebKit*: No signal ( >>>>>> https://github.com/WebKit/standards-positions/issues/536) Discussed >>>>>> at https://github.com/w3c/csswg-drafts/issues/12407 >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> Ergonomics >>>>>> >>>>>> This is an ergonomic improvement >>>>>> >>>>>> >>>>>> Activation >>>>>> >>>>>> none >>>>>> >>>>>> >>>>>> Security >>>>>> >>>>>> none >>>>>> >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> This is debuggable via ways similar to other document properties >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ?Yes >>>>>> >>>>>> Will add tests as part of the implementation >>>>>> >>>>>> >>>>>> Flag name on about://flagsNone >>>>>> >>>>>> Finch feature nameDocumentActiveViewTransition >>>>>> >>>>>> Rollout planWill ship enabled for all users >>>>>> >>>>>> Requires code in //chrome?False >>>>>> >>>>>> Tracking bughttps://issues.chromium.org/434949972 >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop 141 >>>>>> Shipping on Android 141 >>>>>> Shipping on WebView 141 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> None >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5067126381215744?gate=5627959184195584 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a66de8b9-d042-496f-972c-9a5696d80dcdn%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a66de8b9-d042-496f-972c-9a5696d80dcdn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5231be74-902b-4697-b54b-63da7097668an%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5231be74-902b-4697-b54b-63da7097668an%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAjAU%3DYHc47%3DX3aiuS1cEmVrCZ4uKSD7TDWM9SUwRLdCDg9c%3DQ%40mail.gmail.com.
