Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Jake Archibald]

An important part of this for us was to ensure that we didn't 'design 
ourselves in a corner'. A part of this, we sketched out many additional 
features we want to add to ensure the current design is future-compatible:

   - 
   https://github.com/WICG/view-transitions/blob/main/scoped-transitions.md
   - 
   https://github.com/WICG/view-transitions/blob/main/explainer.md#future-work
   - 
   
https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-view-transitions-2
   
I'm confident we can ship this stuff step-by-step. A lot of developers are 
more excited about the cross-document stuff, me included, but I don't think 
we need to delay the same-document stuff.

On Tuesday, January 24, 2023 at 10:06:12 AM UTC Mike West wrote:

> LGTM2.
>
> That said, I'd note Mozilla's desire in the standards position thread to 
> couple this with the multi-page transition work. I agree with your position 
> that the two can be decoupled, and I don't see anything that screams 
> back-compat risk skimming through the followup issues that the TAG created. 
> I likewise don't see anything that jumps out at me as locking us into any 
> particular design for a declarative version of this mechanism as our 
> friends in the TAG have pointed towards.
>
> Shipping this as an iterative step sounds like it satisfies some developer 
> interest, and give us valuable implementation experience that can inform 
> further development. Good luck landing it!
>
> -mike
>
>
> On Mon, Jan 23, 2023 at 10:19 PM Mike Taylor  
> wrote:
>
>> LGTM1
>>
>> On 1/23/23 2:26 PM, Khushal Sagar wrote:
>>
>>
>>
>> On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor  
>> wrote:
>>
>>> Hi Khushal,
>>>
>>> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>>>
>>> Contact emails
>>> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org, 
>>> khushalsa...@chromium.org, vmp...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/WICG/view-transitions/blob/main/explainer.md 
>>> 
>>>
>>> Specification 
>>>
>>> https://www.w3.org/TR/css-view-transitions-1
>>>
>>> Summary 
>>>
>>> View Transitions 
>>>  is 
>>> an API that enables the creation of polished transitions. Web developers 
>>> only need minimal effort to make transitions look nice. They can choose to 
>>> use some default animation properties, or they can customize their own 
>>> transition effects to achieve a desired transition experience.
>>>
>>> This is accomplished by leveraging user-agents’ ability to persist 
>>> visual representations of rendered output (i.e. snapshots) and blend them 
>>> with the live DOM state’s rendered output. The API also allows these 
>>> animations to be customized via standard CSS animation properties.
>>>
>>> Note that while this intent is limited to shipping an API for 
>>> same-document transitions (i.e. by using document.startViewTransition, as 
>>> outlined in the spec), there is ongoing work to provide this feature for 
>>> same-origin, cross-document navigations (MPA). MPA support will be added as 
>>> a follow up via a separate intent to ship.
>>>
>>> Blink component 
>>>
>>> Blink>ViewTransitions 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/748
>>>
>>> Can you confirm that all the follow-up issues 
>>> 
>>>  
>>> filed in response to feedback in this review are backwards-compatible with 
>>> what you propose to ship now?
>>>
>>
>> Yes, most follow-up issues filed based on TAG feedback are about 
>> transitions initiated from navigations. This is part of the MPA work which 
>> we plan to ship as a follow up and it can be shipped independently of the 
>> same-document transitions covered by this intent.
>>
>> The only issue on that review which concerns same-document transitions is 
>> #8319 , a syntax which 
>> would allow selecting a subset of generated pseudo-elements. This syntax 
>> addition can be made in a backwards-compatible way.
>>
>> Thanks, SGTM.
>>
>>
>>> TAG review status 
>>>
>>> Pending
>>>
>>> Risks 
>>> Interoperability and Compatibility 
>>>
>>> Low. As a new feature, the primary risk is that other browsers do not 
>>> implement it. But since this is a progressive enhancement, sites should be 
>>> able to feature-detect and drop usage of the feature easily in browsers 
>>> where it is not supported without breaking any site functionality.
>>>
>>> This feature can be feature-detected by checking the existence of the 
>>> document.startViewTransition function:
>>>
>>> ```js
>>>
>>> if (!document.startViewTransition) {
>>>
>>>   /* feature is not available */
>>>
>>> } else {
>>>
>>>   /* start transition */
>>>
>>> }
>>>
>>> ```

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Yoav Weiss]

LGTM3

Super excited about this work and solving those critical use cases (for
both SPA and MPA). Thanks for tackling this!!

On Tue, Jan 24, 2023, 11:06 Mike West  wrote:

> LGTM2.
>
> That said, I'd note Mozilla's desire in the standards position thread to
> couple this with the multi-page transition work. I agree with your position
> that the two can be decoupled, and I don't see anything that screams
> back-compat risk skimming through the followup issues that the TAG created.
> I likewise don't see anything that jumps out at me as locking us into any
> particular design for a declarative version of this mechanism as our
> friends in the TAG have pointed towards.
>
> Shipping this as an iterative step sounds like it satisfies some developer
> interest, and give us valuable implementation experience that can inform
> further development. Good luck landing it!
>
> -mike
>
>
> On Mon, Jan 23, 2023 at 10:19 PM Mike Taylor 
> wrote:
>
>> LGTM1
>>
>> On 1/23/23 2:26 PM, Khushal Sagar wrote:
>>
>>
>>
>> On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor 
>> wrote:
>>
>>> Hi Khushal,
>>>
>>> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>>>
>>> Contact emails
>>> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
>>> khushalsa...@chromium.org, vmp...@chromium.org
>>>
>>> Explainer
>>>
>>> https://github.com/WICG/view-transitions/blob/main/explainer.md
>>> 
>>>
>>> Specification
>>>
>>> https://www.w3.org/TR/css-view-transitions-1
>>>
>>> Summary
>>>
>>> View Transitions
>>>  is
>>> an API that enables the creation of polished transitions. Web developers
>>> only need minimal effort to make transitions look nice. They can choose to
>>> use some default animation properties, or they can customize their own
>>> transition effects to achieve a desired transition experience.
>>>
>>> This is accomplished by leveraging user-agents’ ability to persist
>>> visual representations of rendered output (i.e. snapshots) and blend them
>>> with the live DOM state’s rendered output. The API also allows these
>>> animations to be customized via standard CSS animation properties.
>>>
>>> Note that while this intent is limited to shipping an API for
>>> same-document transitions (i.e. by using document.startViewTransition, as
>>> outlined in the spec), there is ongoing work to provide this feature for
>>> same-origin, cross-document navigations (MPA). MPA support will be added as
>>> a follow up via a separate intent to ship.
>>>
>>> Blink component
>>>
>>> Blink>ViewTransitions
>>> 
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/748
>>>
>>> Can you confirm that all the follow-up issues
>>> 
>>> filed in response to feedback in this review are backwards-compatible with
>>> what you propose to ship now?
>>>
>>
>> Yes, most follow-up issues filed based on TAG feedback are about
>> transitions initiated from navigations. This is part of the MPA work which
>> we plan to ship as a follow up and it can be shipped independently of the
>> same-document transitions covered by this intent.
>>
>> The only issue on that review which concerns same-document transitions is
>> #8319 , a syntax which
>> would allow selecting a subset of generated pseudo-elements. This syntax
>> addition can be made in a backwards-compatible way.
>>
>> Thanks, SGTM.
>>
>>
>>> TAG review status
>>>
>>> Pending
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Low. As a new feature, the primary risk is that other browsers do not
>>> implement it. But since this is a progressive enhancement, sites should be
>>> able to feature-detect and drop usage of the feature easily in browsers
>>> where it is not supported without breaking any site functionality.
>>>
>>> This feature can be feature-detected by checking the existence of the
>>> document.startViewTransition function:
>>>
>>> ```js
>>>
>>> if (!document.startViewTransition) {
>>>
>>>   /* feature is not available */
>>>
>>> } else {
>>>
>>>   /* start transition */
>>>
>>> }
>>>
>>> ```
>>>
>>> Gecko: Under consideration (
>>> https://github.com/mozilla/standards-positions/issues/677)
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/48)
>>>
>>> Web developers: Strongly positive interest in and developer
>>> experimentation with the API:
>>>
>>>-
>>>
>>>Updated developer.chrome article (Twitter)
>>>
>>>-
>>>
>>>News about the new SET API (Twitter)
>>>
>>>-
>>>
>>>Dev-built demo using SET (Twitter)
>>>

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Mike West]

LGTM2.

That said, I'd note Mozilla's desire in the standards position thread to
couple this with the multi-page transition work. I agree with your position
that the two can be decoupled, and I don't see anything that screams
back-compat risk skimming through the followup issues that the TAG created.
I likewise don't see anything that jumps out at me as locking us into any
particular design for a declarative version of this mechanism as our
friends in the TAG have pointed towards.

Shipping this as an iterative step sounds like it satisfies some developer
interest, and give us valuable implementation experience that can inform
further development. Good luck landing it!

-mike


On Mon, Jan 23, 2023 at 10:19 PM Mike Taylor  wrote:

> LGTM1
>
> On 1/23/23 2:26 PM, Khushal Sagar wrote:
>
>
>
> On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor 
> wrote:
>
>> Hi Khushal,
>>
>> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>>
>> Contact emails
>> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
>> khushalsa...@chromium.org, vmp...@chromium.org
>>
>> Explainer
>>
>> https://github.com/WICG/view-transitions/blob/main/explainer.md
>> 
>>
>> Specification
>>
>> https://www.w3.org/TR/css-view-transitions-1
>>
>> Summary
>>
>> View Transitions
>>  is an
>> API that enables the creation of polished transitions. Web developers only
>> need minimal effort to make transitions look nice. They can choose to use
>> some default animation properties, or they can customize their own
>> transition effects to achieve a desired transition experience.
>>
>> This is accomplished by leveraging user-agents’ ability to persist visual
>> representations of rendered output (i.e. snapshots) and blend them with the
>> live DOM state’s rendered output. The API also allows these animations to
>> be customized via standard CSS animation properties.
>>
>> Note that while this intent is limited to shipping an API for
>> same-document transitions (i.e. by using document.startViewTransition, as
>> outlined in the spec), there is ongoing work to provide this feature for
>> same-origin, cross-document navigations (MPA). MPA support will be added as
>> a follow up via a separate intent to ship.
>>
>> Blink component
>>
>> Blink>ViewTransitions
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/748
>>
>> Can you confirm that all the follow-up issues
>> 
>> filed in response to feedback in this review are backwards-compatible with
>> what you propose to ship now?
>>
>
> Yes, most follow-up issues filed based on TAG feedback are about
> transitions initiated from navigations. This is part of the MPA work which
> we plan to ship as a follow up and it can be shipped independently of the
> same-document transitions covered by this intent.
>
> The only issue on that review which concerns same-document transitions is
> #8319 , a syntax which
> would allow selecting a subset of generated pseudo-elements. This syntax
> addition can be made in a backwards-compatible way.
>
> Thanks, SGTM.
>
>
>> TAG review status
>>
>> Pending
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Low. As a new feature, the primary risk is that other browsers do not
>> implement it. But since this is a progressive enhancement, sites should be
>> able to feature-detect and drop usage of the feature easily in browsers
>> where it is not supported without breaking any site functionality.
>>
>> This feature can be feature-detected by checking the existence of the
>> document.startViewTransition function:
>>
>> ```js
>>
>> if (!document.startViewTransition) {
>>
>>   /* feature is not available */
>>
>> } else {
>>
>>   /* start transition */
>>
>> }
>>
>> ```
>>
>> Gecko: Under consideration (
>> https://github.com/mozilla/standards-positions/issues/677)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/48)
>>
>> Web developers: Strongly positive interest in and developer
>> experimentation with the API:
>>
>>-
>>
>>Updated developer.chrome article (Twitter)
>>
>>-
>>
>>News about the new SET API (Twitter)
>>
>>-
>>
>>Dev-built demo using SET (Twitter)
>>
>>-
>>
>>I/O Session (Youtube )
>>-
>>
>>Dev-built demo using SET (Reddit)
>>
>> 
>>
>>-
>>
>>Dev-built demo using SET (Twitter)

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Mike Taylor]

LGTM1

On 1/23/23 2:26 PM, Khushal Sagar wrote:



On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor  
wrote:


Hi Khushal,

On 1/19/23 3:12 PM, Khushal Sagar wrote:


Contact emails

bo...@chromium.org, hvanops...@chromium.org,
jakearchib...@chromium.org, khushalsa...@chromium.org,
vmp...@chromium.org


Explainer

https://github.com/WICG/view-transitions/blob/main/explainer.md



Specification

https://www.w3.org/TR/css-view-transitions-1



Summary

View Transitions
is
an API that enables the creation of polished transitions. Web
developers only need minimal effort to make transitions look
nice. They can choose to use some default animation properties,
or they can customize their own transition effects to achieve a
desired transition experience.


This is accomplished by leveraging user-agents’ ability to
persist visual representations of rendered output (i.e.
snapshots) and blend them with the live DOM state’s rendered
output. The API also allows these animations to be customized via
standard CSS animation properties.

Note that while this intent is limited to shipping an API for
same-document transitions (i.e. by using
document.startViewTransition, as outlined in the spec), there is
ongoing work to provide this feature for same-origin,
cross-document navigations (MPA). MPA support will be added as a
follow up via a separate intent to ship.


Blink component

Blink>ViewTransitions




TAG review

https://github.com/w3ctag/design-reviews/issues/748



Can you confirm that all the follow-up issues


filed in response to feedback in this review are
backwards-compatible with what you propose to ship now?


Yes, most follow-up issues filed based on TAG feedback are about 
transitions initiated from navigations. This is part of the MPA work 
which we plan to ship as a follow up and it can be shipped 
independently of the same-document transitions covered by this intent.


The only issue on that review which concerns same-document transitions 
is #8319 , a syntax 
which would allow selecting a subset of generated pseudo-elements. 
This syntax addition can be made in a backwards-compatible way.


Thanks, SGTM.



TAG review status

Pending


Risks


Interoperability and Compatibility

Low. As a new feature, the primary risk is that other browsers do
not implement it. But since this is a progressive enhancement,
sites should be able to feature-detect and drop usage of the
feature easily in browsers where it is not supported without
breaking any site functionality.


This feature can be feature-detected by checking the existence of
the document.startViewTransition function:

```js

if (!document.startViewTransition) {

  /* feature is not available */

} else {

  /* start transition */

}

```

Gecko: Under consideration
(https://github.com/mozilla/standards-positions/issues/677
)


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/48
)


Web developers: Strongly positive interest in and developer
experimentation with the API:

 *

Updated developer.chrome article (Twitter)


 *

News about the new SET API (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

I/O Session (Youtube
)

 *

Dev-built demo using SET (Reddit)



 *

Dev-built demo using SET (Twitter)



 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Khushal Sagar]

On Mon, Jan 23, 2023 at 1:55 PM Mike Taylor  wrote:

> Hi Khushal,
>
> On 1/19/23 3:12 PM, Khushal Sagar wrote:
>
> Contact emails
> bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
> khushalsa...@chromium.org, vmp...@chromium.org
>
> Explainer
>
> https://github.com/WICG/view-transitions/blob/main/explainer.md
> 
>
> Specification
>
> https://www.w3.org/TR/css-view-transitions-1
>
> Summary
>
> View Transitions
>  is an
> API that enables the creation of polished transitions. Web developers only
> need minimal effort to make transitions look nice. They can choose to use
> some default animation properties, or they can customize their own
> transition effects to achieve a desired transition experience.
>
> This is accomplished by leveraging user-agents’ ability to persist visual
> representations of rendered output (i.e. snapshots) and blend them with the
> live DOM state’s rendered output. The API also allows these animations to
> be customized via standard CSS animation properties.
>
> Note that while this intent is limited to shipping an API for
> same-document transitions (i.e. by using document.startViewTransition, as
> outlined in the spec), there is ongoing work to provide this feature for
> same-origin, cross-document navigations (MPA). MPA support will be added as
> a follow up via a separate intent to ship.
>
> Blink component
>
> Blink>ViewTransitions
> 
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/748
>
> Can you confirm that all the follow-up issues
> 
> filed in response to feedback in this review are backwards-compatible with
> what you propose to ship now?
>

Yes, most follow-up issues filed based on TAG feedback are about
transitions initiated from navigations. This is part of the MPA work which
we plan to ship as a follow up and it can be shipped independently of the
same-document transitions covered by this intent.

The only issue on that review which concerns same-document transitions is
#8319 , a syntax which
would allow selecting a subset of generated pseudo-elements. This syntax
addition can be made in a backwards-compatible way.

>
> TAG review status
>
> Pending
>
> Risks
> Interoperability and Compatibility
>
> Low. As a new feature, the primary risk is that other browsers do not
> implement it. But since this is a progressive enhancement, sites should be
> able to feature-detect and drop usage of the feature easily in browsers
> where it is not supported without breaking any site functionality.
>
> This feature can be feature-detected by checking the existence of the
> document.startViewTransition function:
>
> ```js
>
> if (!document.startViewTransition) {
>
>   /* feature is not available */
>
> } else {
>
>   /* start transition */
>
> }
>
> ```
>
> Gecko: Under consideration (
> https://github.com/mozilla/standards-positions/issues/677)
>
> WebKit: No signal (https://github.com/WebKit/standards-positions/issues/48
> )
>
> Web developers: Strongly positive interest in and developer
> experimentation with the API:
>
>-
>
>Updated developer.chrome article (Twitter)
>
>-
>
>News about the new SET API (Twitter)
>
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>I/O Session (Youtube )
>-
>
>Dev-built demo using SET (Reddit)
>
> 
>
>-
>
>Dev-built demo using SET (Twitter)
>
> 
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>Dev-built demo using SET (Twitter)
>
>-
>
>https://twitter.com/dannymoerkerke/status/1597187172783693824
>-
>
>The Shared Element Transition API is Flipping Cool | Chris Coyier
>
> 
>-
>
>Every Transition is a Page Transition? | OddBird
>
>-
>
>https://twitter.com/derSchepp/status/1590709783807791104
>-
>
>Astro stands to benefit highly from View Transitions | Chris 

Re: [blink-dev] Intent to Ship: View Transitions: single-page apps

[Mike Taylor]

Hi Khushal,

On 1/19/23 3:12 PM, Khushal Sagar wrote:


Contact emails

bo...@chromium.org, hvanops...@chromium.org, 
jakearchib...@chromium.org, khushalsa...@chromium.org, vmp...@chromium.org



Explainer

https://github.com/WICG/view-transitions/blob/main/explainer.md 




Specification

https://www.w3.org/TR/css-view-transitions-1 




Summary

View Transitions 
is 
an API that enables the creation of polished transitions. Web 
developers only need minimal effort to make transitions look nice. 
They can choose to use some default animation properties, or they can 
customize their own transition effects to achieve a desired transition 
experience.



This is accomplished by leveraging user-agents’ ability to persist 
visual representations of rendered output (i.e. snapshots) and blend 
them with the live DOM state’s rendered output. The API also allows 
these animations to be customized via standard CSS animation properties.


Note that while this intent is limited to shipping an API for 
same-document transitions (i.e. by using document.startViewTransition, 
as outlined in the spec), there is ongoing work to provide this 
feature for same-origin, cross-document navigations (MPA). MPA support 
will be added as a follow up via a separate intent to ship.



Blink component

Blink>ViewTransitions 




TAG review

https://github.com/w3ctag/design-reviews/issues/748 



Can you confirm that all the follow-up issues 
 
filed in response to feedback in this review are backwards-compatible 
with what you propose to ship now?



TAG review status

Pending


Risks


Interoperability and Compatibility

Low. As a new feature, the primary risk is that other browsers do not 
implement it. But since this is a progressive enhancement, sites 
should be able to feature-detect and drop usage of the feature easily 
in browsers where it is not supported without breaking any site 
functionality.



This feature can be feature-detected by checking the existence of the 
document.startViewTransition function:


```js

if (!document.startViewTransition) {

  /* feature is not available */

} else {

  /* start transition */

}

```

Gecko: Under consideration 
(https://github.com/mozilla/standards-positions/issues/677 
)



WebKit: No signal 
(https://github.com/WebKit/standards-positions/issues/48 
)



Web developers: Strongly positive interest in and developer 
experimentation with the API:


 *

Updated developer.chrome article (Twitter)


 *

News about the new SET API (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

I/O Session (Youtube )

 *

Dev-built demo using SET (Reddit)



 *

Dev-built demo using SET (Twitter)



 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

Dev-built demo using SET (Twitter)


 *

https://twitter.com/dannymoerkerke/status/1597187172783693824


 *

The Shared Element Transition API is Flipping Cool | Chris Coyier



 *

Every Transition is a Page Transition? | OddBird


 *

https://twitter.com/derSchepp/status/1590709783807791104


 *

Astro stands to benefit highly from View Transitions | Chris
Coyier



 *

Shared Element Transitions API Part 1 | Smashing Magazine




Ergonomics

None.


Activation

   Low.


As with interop/compat 

[blink-dev] Intent to Ship: View Transitions: single-page apps

[Khushal Sagar]

Contact emails
bo...@chromium.org, hvanops...@chromium.org,  jakearchib...@chromium.org,
khushalsa...@chromium.org, vmp...@chromium.org

Explainer

https://github.com/WICG/view-transitions/blob/main/explainer.md


Specification

https://www.w3.org/TR/css-view-transitions-1

Summary

View Transitions
 is an
API that enables the creation of polished transitions. Web developers only
need minimal effort to make transitions look nice. They can choose to use
some default animation properties, or they can customize their own
transition effects to achieve a desired transition experience.

This is accomplished by leveraging user-agents’ ability to persist visual
representations of rendered output (i.e. snapshots) and blend them with the
live DOM state’s rendered output. The API also allows these animations to
be customized via standard CSS animation properties.


Note that while this intent is limited to shipping an API for same-document
transitions (i.e. by using document.startViewTransition, as outlined in the
spec), there is ongoing work to provide this feature for same-origin,
cross-document navigations (MPA). MPA support will be added as a follow up
via a separate intent to ship.

Blink component

Blink>ViewTransitions


TAG review

https://github.com/w3ctag/design-reviews/issues/748

TAG review status

Pending

Risks
Interoperability and Compatibility

Low. As a new feature, the primary risk is that other browsers do not
implement it. But since this is a progressive enhancement, sites should be
able to feature-detect and drop usage of the feature easily in browsers
where it is not supported without breaking any site functionality.

This feature can be feature-detected by checking the existence of the
document.startViewTransition function:

```js

if (!document.startViewTransition) {

  /* feature is not available */

} else {

  /* start transition */

}

```

Gecko: Under consideration (
https://github.com/mozilla/standards-positions/issues/677)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/48)

Web developers: Strongly positive interest in and developer experimentation
with the API:

   -

   Updated developer.chrome article (Twitter)
   
   -

   News about the new SET API (Twitter)
   
   -

   Dev-built demo using SET (Twitter)
   
   -

   I/O Session (Youtube )
   -

   Dev-built demo using SET (Reddit)
   


   -

   Dev-built demo using SET (Twitter)
   

   -

   Dev-built demo using SET (Twitter)
   
   -

   Dev-built demo using SET (Twitter)
   
   -

   Dev-built demo using SET (Twitter)
   
   -

   https://twitter.com/dannymoerkerke/status/1597187172783693824
   -

   The Shared Element Transition API is Flipping Cool | Chris Coyier
   

   -

   Every Transition is a Page Transition? | OddBird
   
   -

   https://twitter.com/derSchepp/status/1590709783807791104
   -

   Astro stands to benefit highly from View Transitions | Chris Coyier
   


   -

   Shared Element Transitions API Part 1 | Smashing Magazine
   



Ergonomics

None.

Activation

   Low.

As with interop/compat risks, the difficulty stems from this being a new
feature without support in other browsers. A polyfill for the SPA case
would be beneficial. That said, this feature is a progressive enhancement
for sites; they can easily use the API and  still function correctly on
browsers that do not support the feature.

Security

The primary security constraint is ensuring isolation of graphics resources
from multiple origins. The design achieves that by using Chromium's Viz
process, similar to site isolation for iframes.

See also the security and privacy self-review questionnaire that was
completed as part of the TAG review process:
https://github.com/WICG/view-transitions/blob/main/security-privacy-questionnaire.md

The following issues track review from security/privacy WGs: