Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-29 Thread Noam Rosenthal 
On Fri, Mar 29, 2024 at 1:23 PM Mike Taylor  wrote:

> On 3/28/24 5:19 PM, Noam Rosenthal wrote:
>
>
> On Thu, Mar 28, 2024 at 9:07 PM Mike Taylor 
> wrote:
>
>> On 3/28/24 5:04 PM, Noam Rosenthal wrote:
>>
>> On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor 
>> wrote:
>>
>>> Hey Vlad - thanks for the update.
>>>
>>> Do we know if Mozilla is similarly positive on this change? Any input
>>> from the WebKit team?
>>>
>>
>> Yes, this was thoroughly discussed in the CSSWG meetings, with active
>> participation from both.
>>
>> Cool - got a link to minutes?
>>
> Sure!
> The whole thing was discussed over several WG meetings.
> Posting a few related resolutions, with comments (in minutes/issues) from
> Elika and Tim (Apple) and Emilio (Mozilla):
> https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-2009980134
> https://github.com/w3c/csswg-drafts/issues/9542#issuecomment-1994829341
> https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450
>
> Thanks - appreciate the links. From my perspective, you don't need new
> LGTMs. It might be good to update the WebKit standards position thread with
> the new changes since the original request for a position - even with Tim
> and Elika participating in CSSWG discussion. Maybe that will encourage them
> to give an answer one way or another.
>

Added a comment on the webkit position. Thanks!

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZ8r8FnEAn6jXEtcX72vL69YY_XfavgEJPVGNdhHMuNeQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-29 Thread Mike Taylor 

On 3/28/24 5:19 PM, Noam Rosenthal wrote:



On Thu, Mar 28, 2024 at 9:07 PM Mike Taylor  
wrote:


On 3/28/24 5:04 PM, Noam Rosenthal wrote:


On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor
 wrote:

Hey Vlad - thanks for the update.

Do we know if Mozilla is similarly positive on this change?
Any input from the WebKit team?


Yes, this was thoroughly discussed in the CSSWG meetings, with
active participation from both.

Cool - got a link to minutes?

Sure!
The whole thing was discussed over several WG meetings.
Posting a few related resolutions, with comments (in minutes/issues) 
from Elika and Tim (Apple) and Emilio (Mozilla):

https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-2009980134
https://github.com/w3c/csswg-drafts/issues/9542#issuecomment-1994829341
https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450


Thanks - appreciate the links. From my perspective, you don't need new 
LGTMs. It might be good to update the WebKit standards position thread 
with the new changes since the original request for a position - even 
with Tim and Elika participating in CSSWG discussion. Maybe that will 
encourage them to give an answer one way or another.


--
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6c85e5b8-f59c-4c8b-8f83-26c4979fe57d%40chromium.org.

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-28 Thread Noam Rosenthal 
On Thu, Mar 28, 2024 at 9:07 PM Mike Taylor  wrote:

> On 3/28/24 5:04 PM, Noam Rosenthal wrote:
>
> On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor 
> wrote:
>
>> Hey Vlad - thanks for the update.
>>
>> Do we know if Mozilla is similarly positive on this change? Any input
>> from the WebKit team?
>>
>
> Yes, this was thoroughly discussed in the CSSWG meetings, with active
> participation from both.
>
> Cool - got a link to minutes?
>
Sure!
The whole thing was discussed over several WG meetings.
Posting a few related resolutions, with comments (in minutes/issues) from
Elika and Tim (Apple) and Emilio (Mozilla):
https://github.com/w3c/csswg-drafts/issues/10070#issuecomment-2009980134
https://github.com/w3c/csswg-drafts/issues/9542#issuecomment-1994829341
https://github.com/w3c/csswg-drafts/issues/10114#issuecomment-2023217450

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYb%2BKaYcEWXuFWy7F9si7L-ocOedZgGQ_rUr3gppjmoeKw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-28 Thread Mike Taylor 

On 3/28/24 5:04 PM, Noam Rosenthal wrote:

On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor  
wrote:


Hey Vlad - thanks for the update.

Do we know if Mozilla is similarly positive on this change? Any
input from the WebKit team?


Yes, this was thoroughly discussed in the CSSWG meetings, with active 
participation from both.

Cool - got a link to minutes?

--
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f003b2ce-a16f-4cf0-acb6-aba2b3fab702%40chromium.org.

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-28 Thread Noam Rosenthal 
On Thu, Mar 28, 2024 at 9:02 PM Mike Taylor  wrote:

> Hey Vlad - thanks for the update.
>
> Do we know if Mozilla is similarly positive on this change? Any input from
> the WebKit team?
>

Yes, this was thoroughly discussed in the CSSWG meetings, with active
participation from both.

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYZrDoi8ySeqgpSK_9ZruVcZpu_rYWRU2s%2BaUinoWiOTGQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-28 Thread Mike Taylor 

Hey Vlad - thanks for the update.

Do we know if Mozilla is similarly positive on this change? Any input 
from the WebKit team?


thanks,
Mike

On 3/28/24 4:36 PM, Vladimir Levin wrote:

Hey all,

After receiving the LGTMs, we decided to postpone the feature until 
another component of it is discussed and resolved at the CSSWG.


This has been done, and one major change from the initial feature is 
that we will now allow mutable types on the ViewTransition object.
This is implemented and is documented in the latest version of the 
spec: https://drafts.csswg.org/css-view-transitions-2/#selective-vt


Please let me know if I need to do anything more wrt the intent 
process, or whether the existing LGTMs still stand for us to ship this 
feature.


Thank you,
Vlad



‪On Tue, Nov 28, 2023 at 4:16 PM ‫احمد عسيري‬‎  
wrote:‬




في الثلاثاء، ٢٨ نوفمبر ٢٠٢٣, ٩:٥٧ ص Rick Byers
 كتب:

LGTM3

On Thu, Nov 23, 2023 at 1:44 AM Mike Taylor
 wrote:

LGTM2

On 11/22/23 11:15 AM, Yoav Weiss wrote:

LGTM1

On Thursday, November 9, 2023 at 7:05:57 PM UTC+1
Vladimir Levin wrote:



On Thu, Nov 9, 2023, 12:54 Mike Taylor
 wrote:

On 11/8/23 3:53 PM, Vladimir Levin wrote:


Contact emails vmp...@chromium.org,
nrosent...@chromium.org


Explainer

https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-types.md




Specification

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo



Summary

This feature allows View transition API use to
be customized for different types of
transitions. Specifically, this adds an ability
to add "types" to `startViewTransition` call
which will identify the types of the transition.
As well, it will match a pseudo-class, called
`:active-view-transitions(...)` with a parameter
matching the type for the duration of the view
transition. Combined these two features provide
a way for the author to declare several view
transitions once and only trigger one at a time.
See example usage in the spec:

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo




Blink component Blink>ViewTransitions>SPA



TAG review
https://github.com/w3ctag/design-reviews/issues/908



TAG review status Pending

Risks


Interoperability and Compatibility

There are minimal interop and copmat risks. This
feature is an extension to the View Transitions
API that makes it more ergonomic to specify
multiple transitions declaratively, while
triggering only one of them at a time.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/905
)



Gecko are now positive!



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

/Web developers/: No (strong) signals, the
feature request came from a web developer:
https://github.com/w3c/csswg-drafts/issues/8960


/Other signals/:

Ergonomics

This feature would be used with the View
Transitions API to be able to easier maintain a
declarative set of multiple transitions that can
be triggered. This solution uses a descendant
combinator heavily to selectively style elements
in the DOM, but this is not any different from
the

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2024-03-28 Thread Vladimir Levin 
Hey all,

After receiving the LGTMs, we decided to postpone the feature until another
component of it is discussed and resolved at the CSSWG.

This has been done, and one major change from the initial feature is that
we will now allow mutable types on the ViewTransition object.
This is implemented and is documented in the latest version of the spec:
https://drafts.csswg.org/css-view-transitions-2/#selective-vt

Please let me know if I need to do anything more wrt the intent process, or
whether the existing LGTMs still stand for us to ship this feature.

Thank you,
Vlad



‪On Tue, Nov 28, 2023 at 4:16 PM ‫احمد عسيري‬‎  wrote:‬

>
>
> في الثلاثاء، ٢٨ نوفمبر ٢٠٢٣, ٩:٥٧ ص Rick Byers  كتب:
>
>> LGTM3
>>
>> On Thu, Nov 23, 2023 at 1:44 AM Mike Taylor 
>> wrote:
>>
>>> LGTM2
>>> On 11/22/23 11:15 AM, Yoav Weiss wrote:
>>>
>>> LGTM1
>>>
>>> On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote:
>>>
>>>
>>>
>>> On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:
>>>
>>> On 11/8/23 3:53 PM, Vladimir Levin wrote:
>>>
>>> Contact emails vmp...@chromium.org, nrosent...@chromium.org
>>>
>>> Explainer https://github.com/vmpstr/web-proposals/blob/main/
>>> explainers/view-transition-types.md
>>>
>>> Specification https://drafts.csswg.org/css-view-transitions-2/#the-
>>> active-view-transition-pseudo
>>>
>>> Summary
>>>
>>> This feature allows View transition API use to be customized for
>>> different types of transitions. Specifically, this adds an ability to add
>>> "types" to `startViewTransition` call which will identify the types of the
>>> transition. As well, it will match a pseudo-class, called
>>> `:active-view-transitions(...)` with a parameter matching the type for
>>> the duration of the view transition. Combined these two features provide a
>>> way for the author to declare several view transitions once and only
>>> trigger one at a time. See example usage in the spec:
>>> https://drafts.csswg.org/css-view-transitions-2/#the-
>>> active-view-transition-pseudo
>>>
>>> Blink component Blink>ViewTransitions>SPA
>>> 
>>>
>>> TAG review https://github.com/w3ctag/design-reviews/issues/908
>>>
>>> TAG review status Pending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There are minimal interop and copmat risks. This feature is an extension
>>> to the View Transitions API that makes it more ergonomic to specify
>>> multiple transitions declaratively, while triggering only one of them at a
>>> time.
>>>
>>>
>>> *Gecko*: No signal (https://github.com/mozilla/
>>> standards-positions/issues/905)
>>>
>>>
>>> Gecko are now positive!
>>>
>>>
>>> *WebKit*: No signal (https://github.com/WebKit/
>>> standards-positions/issues/266)
>>>
>>> *Web developers*: No (strong) signals, the feature request came from a
>>> web developer: https://github.com/w3c/csswg-drafts/issues/8960
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> This feature would be used with the View Transitions API to be able to
>>> easier maintain a declarative set of multiple transitions that can be
>>> triggered. This solution uses a descendant combinator heavily to
>>> selectively style elements in the DOM, but this is not any different from
>>> the polyfill approach of toggling a class on :root.
>>>
>>>
>>> Activation
>>>
>>> This feature can be used directly and fairly easily.
>>>
>>>
>>> Security
>>>
>>> There are no additional security considerations over the View
>>> Transitions API.
>>>
>>>
>>> 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 feature is debuggable in the same way as the View Transitions API,
>>> and also in the same way as other CSS properties.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)? Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? No
>>>
>>> Any reason why?
>>>
>>>
>>> Oops, that should say "Yes". I'll update chromestatus
>>>
>>>
>>> Flag name on chrome://flags ViewTransitionTypes
>>>
>>> Finch feature name ViewTransitionTypes
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=
>>> 1466251
>>>
>>> Estimated milestones Shipping on desktop 121 Shipping on Android 121 
>>> Shipping
>>> on WebView 121
>>>
>>> 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

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2023-11-27 Thread Rick Byers 
LGTM3

On Thu, Nov 23, 2023 at 1:44 AM Mike Taylor  wrote:

> LGTM2
> On 11/22/23 11:15 AM, Yoav Weiss wrote:
>
> LGTM1
>
> On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote:
>
>
>
> On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:
>
> On 11/8/23 3:53 PM, Vladimir Levin wrote:
>
> Contact emails vmp...@chromium.org, nrosent...@chromium.org
>
> Explainer https://github.com/vmpstr/web-proposals/blob/main/
> explainers/view-transition-types.md
>
> Specification https://drafts.csswg.org/css-view-transitions-2/#the-
> active-view-transition-pseudo
>
> Summary
>
> This feature allows View transition API use to be customized for different
> types of transitions. Specifically, this adds an ability to add "types" to
> `startViewTransition` call which will identify the types of the transition.
> As well, it will match a pseudo-class, called `:active-view-transitions(...)`
> with a parameter matching the type for the duration of the view transition.
> Combined these two features provide a way for the author to declare several
> view transitions once and only trigger one at a time. See example usage in
> the spec: https://drafts.csswg.org/css-view-transitions-2/#the-
> active-view-transition-pseudo
>
> Blink component Blink>ViewTransitions>SPA
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/908
>
> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> There are minimal interop and copmat risks. This feature is an extension
> to the View Transitions API that makes it more ergonomic to specify
> multiple transitions declaratively, while triggering only one of them at a
> time.
>
>
> *Gecko*: No signal (https://github.com/mozilla/
> standards-positions/issues/905)
>
>
> Gecko are now positive!
>
>
> *WebKit*: No signal (https://github.com/WebKit/
> standards-positions/issues/266)
>
> *Web developers*: No (strong) signals, the feature request came from a
> web developer: https://github.com/w3c/csswg-drafts/issues/8960
>
> *Other signals*:
>
> Ergonomics
>
> This feature would be used with the View Transitions API to be able to
> easier maintain a declarative set of multiple transitions that can be
> triggered. This solution uses a descendant combinator heavily to
> selectively style elements in the DOM, but this is not any different from
> the polyfill approach of toggling a class on :root.
>
>
> Activation
>
> This feature can be used directly and fairly easily.
>
>
> Security
>
> There are no additional security considerations over the View Transitions
> API.
>
>
> 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 feature is debuggable in the same way as the View Transitions API,
> and also in the same way as other CSS properties.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> Any reason why?
>
>
> Oops, that should say "Yes". I'll update chromestatus
>
>
> Flag name on chrome://flags ViewTransitionTypes
>
> Finch feature name ViewTransitionTypes
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1466251
>
> Estimated milestones Shipping on desktop 121 Shipping on Android 121 Shipping
> on WebView 121
>
> 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/5089552511533056
>
> Links to previous Intent discussions Intent to prototype: https://groups.
> google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NjgR_%2BTbJbU5O%
> 2BiyhnqxypDAUh7LWHUCWy%3DNnaBCY%2B1g%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status
> .
> --
> 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 on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CADsXd2PckO%3DXSq8HDCy4foC_
> Xj3Nh3dBxzSCkZ5GEyD%2BjdMcFQ%40mail.gmail.com
>

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2023-11-22 Thread Mike Taylor 

LGTM2

On 11/22/23 11:15 AM, Yoav Weiss wrote:

LGTM1

On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote:



On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:

On 11/8/23 3:53 PM, Vladimir Levin wrote:


Contact emails vmp...@chromium.org, nrosent...@chromium.org


Explainer

https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-types.md




Specification

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo



Summary

This feature allows View transition API use to be customized
for different types of transitions. Specifically, this adds
an ability to add "types" to `startViewTransition` call which
will identify the types of the transition. As well, it will
match a pseudo-class, called `:active-view-transitions(...)`
with a parameter matching the type for the duration of the
view transition. Combined these two features provide a way
for the author to declare several view transitions once and
only trigger one at a time. See example usage in the spec:

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo




Blink component Blink>ViewTransitions>SPA



TAG review
https://github.com/w3ctag/design-reviews/issues/908


TAG review status Pending

Risks


Interoperability and Compatibility

There are minimal interop and copmat risks. This feature is
an extension to the View Transitions API that makes it more
ergonomic to specify multiple transitions declaratively,
while triggering only one of them at a time.



/Gecko/: No signal
(https://github.com/mozilla/standards-positions/issues/905
)



Gecko are now positive!



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

/Web developers/: No (strong) signals, the feature request
came from a web developer:
https://github.com/w3c/csswg-drafts/issues/8960


/Other signals/:

Ergonomics

This feature would be used with the View Transitions API to
be able to easier maintain a declarative set of multiple
transitions that can be triggered. This solution uses a
descendant combinator heavily to selectively style elements
in the DOM, but this is not any different from the polyfill
approach of toggling a class on :root.



Activation

This feature can be used directly and fairly easily.



Security

There are no additional security considerations over the View
Transitions API.



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 feature is debuggable in the same way as the View
Transitions API, and also in the same way as other CSS
properties.



Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)? Yes

Is this feature fully tested by web-platform-tests

?
No

Any reason why?


Oops, that should say "Yes". I'll update chromestatus



Flag name on chrome://flags ViewTransitionTypes

Finch feature name ViewTransitionTypes

Requires code in //chrome? False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1466251


Estimated milestones Shipping on desktop 121 Shipping on
Android 121 Shipping on WebView 121

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

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2023-11-22 Thread Yoav Weiss 
LGTM1

On Thursday, November 9, 2023 at 7:05:57 PM UTC+1 Vladimir Levin wrote:



On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:

On 11/8/23 3:53 PM, Vladimir Levin wrote:

Contact emails vmp...@chromium.org, nrosent...@chromium.org

Explainer https://github.com/vmpstr/web-proposals/blob/main/
explainers/view-transition-types.md 

Specification https://drafts.csswg.org/css-view-transitions-2/#the-
active-view-transition-pseudo

Summary 

This feature allows View transition API use to be customized for different 
types of transitions. Specifically, this adds an ability to add "types" to 
`startViewTransition` call which will identify the types of the transition. 
As well, it will match a pseudo-class, called `:active-view-transitions(...)` 
with a parameter matching the type for the duration of the view transition. 
Combined these two features provide a way for the author to declare several 
view transitions once and only trigger one at a time. See example usage in 
the spec: https://drafts.csswg.org/css-view-transitions-2/#the-
active-view-transition-pseudo

Blink component Blink>ViewTransitions>SPA 


TAG review https://github.com/w3ctag/design-reviews/issues/908 

TAG review status Pending

Risks 


Interoperability and Compatibility 

There are minimal interop and copmat risks. This feature is an extension to 
the View Transitions API that makes it more ergonomic to specify multiple 
transitions declaratively, while triggering only one of them at a time.


*Gecko*: No signal (https://github.com/mozilla/
standards-positions/issues/905)


Gecko are now positive! 


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

*Web developers*: No (strong) signals, the feature request came from a web 
developer: https://github.com/w3c/csswg-drafts/issues/8960

*Other signals*:

Ergonomics 

This feature would be used with the View Transitions API to be able to 
easier maintain a declarative set of multiple transitions that can be 
triggered. This solution uses a descendant combinator heavily to 
selectively style elements in the DOM, but this is not any different from 
the polyfill approach of toggling a class on :root. 


Activation 

This feature can be used directly and fairly easily.


Security 

There are no additional security considerations over the View Transitions 
API.


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 feature is debuggable in the same way as the View Transitions API, and 
also in the same way as other CSS properties.


Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)? Yes

Is this feature fully tested by web-platform-tests 

? No

Any reason why?


Oops, that should say "Yes". I'll update chromestatus


Flag name on chrome://flags ViewTransitionTypes

Finch feature name ViewTransitionTypes

Requires code in //chrome? False

Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1466251

Estimated milestones Shipping on desktop 121 Shipping on Android 121 Shipping 
on WebView 121 

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/5089552511533056

Links to previous Intent discussions Intent to prototype: https://groups.
google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NjgR_%2BTbJbU5O%
2BiyhnqxypDAUh7LWHUCWy%3DNnaBCY%2B1g%40mail.gmail.com

This intent message was generated by Chrome Platform Status 
.
-- 
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 on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/CADsXd2PckO%3DXSq8HDCy4foC_
Xj3Nh3dBxzSCkZ5GEyD%2BjdMcFQ%40mail.gmail.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 on the web visit

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2023-11-09 Thread Vladimir Levin 
On Thu, Nov 9, 2023, 12:54 Mike Taylor  wrote:

> On 11/8/23 3:53 PM, Vladimir Levin wrote:
>
> Contact emails vmp...@chromium.org, nrosent...@chromium.org
>
> Explainer
> https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-types.md
>
> Specification
> https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo
>
> Summary
>
> This feature allows View transition API use to be customized for different
> types of transitions. Specifically, this adds an ability to add "types" to
> `startViewTransition` call which will identify the types of the transition.
> As well, it will match a pseudo-class, called
> `:active-view-transitions(...)` with a parameter matching the type for the
> duration of the view transition. Combined these two features provide a way
> for the author to declare several view transitions once and only trigger
> one at a time. See example usage in the spec:
> https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo
>
> Blink component Blink>ViewTransitions>SPA
> 
>
> TAG review https://github.com/w3ctag/design-reviews/issues/908
>
> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
> There are minimal interop and copmat risks. This feature is an extension
> to the View Transitions API that makes it more ergonomic to specify
> multiple transitions declaratively, while triggering only one of them at a
> time.
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/905)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/266)
>
> *Web developers*: No (strong) signals, the feature request came from a
> web developer: https://github.com/w3c/csswg-drafts/issues/8960
>
> *Other signals*:
>
> Ergonomics
>
> This feature would be used with the View Transitions API to be able to
> easier maintain a declarative set of multiple transitions that can be
> triggered. This solution uses a descendant combinator heavily to
> selectively style elements in the DOM, but this is not any different from
> the polyfill approach of toggling a class on :root.
>
>
> Activation
>
> This feature can be used directly and fairly easily.
>
>
> Security
>
> There are no additional security considerations over the View Transitions
> API.
>
>
> 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 feature is debuggable in the same way as the View Transitions API,
> and also in the same way as other CSS properties.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> Any reason why?
>

Oops, that should say "Yes". I'll update chromestatus

>
> Flag name on chrome://flags ViewTransitionTypes
>
> Finch feature name ViewTransitionTypes
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1466251
>
> Estimated milestones
> Shipping on desktop 121
> Shipping on Android 121
> Shipping on WebView 121
>
> 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/5089552511533056
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NjgR_%2BTbJbU5O%2BiyhnqxypDAUh7LWHUCWy%3DNnaBCY%2B1g%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status
> .
> --
> 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 on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PckO%3DXSq8HDCy4foC_Xj3Nh3dBxzSCkZ5GEyD%2BjdMcFQ%40mail.gmail.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

Re: [blink-dev] Intent to Ship: View Transitions: transition types

2023-11-09 Thread Mike Taylor 

On 11/8/23 3:53 PM, Vladimir Levin wrote:



Contact emails

vmp...@chromium.org, nrosent...@chromium.org


Explainer

https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-types.md 




Specification

https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo


Summary

This feature allows View transition API use to be customized for 
different types of transitions. Specifically, this adds an ability to 
add "types" to `startViewTransition` call which will identify the 
types of the transition. As well, it will match a pseudo-class, called 
`:active-view-transitions(...)` with a parameter matching the type for 
the duration of the view transition. Combined these two features 
provide a way for the author to declare several view transitions once 
and only trigger one at a time. See example usage in the spec: 
https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo



Blink component

Blink>ViewTransitions>SPA 




TAG review

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


TAG review status

Pending


Risks



Interoperability and Compatibility

There are minimal interop and copmat risks. This feature is an 
extension to the View Transitions API that makes it more ergonomic to 
specify multiple transitions declaratively, while triggering only one 
of them at a time.




/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/905)


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


/Web developers/: No (strong) signals, the feature request came from a 
web developer: https://github.com/w3c/csswg-drafts/issues/8960


/Other signals/:


Ergonomics

This feature would be used with the View Transitions API to be able to 
easier maintain a declarative set of multiple transitions that can be 
triggered. This solution uses a descendant combinator heavily to 
selectively style elements in the DOM, but this is not any different 
from the polyfill approach of toggling a class on :root.




Activation

This feature can be used directly and fairly easily.



Security

There are no additional security considerations over the View 
Transitions API.




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 feature is debuggable in the same way as the View Transitions 
API, and also in the same way as other CSS properties.




Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests

?

No

Any reason why?



Flag name on chrome://flags

ViewTransitionTypes


Finch feature name

ViewTransitionTypes


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1466251


Estimated milestones

Shipping on desktop 121

Shipping on Android 121

Shipping on WebView 121



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/5089552511533056


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NjgR_%2BTbJbU5O%2BiyhnqxypDAUh7LWHUCWy%3DNnaBCY%2B1g%40mail.gmail.com


This intent message was generated by Chrome Platform Status 
.

--
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PckO%3DXSq8HDCy4foC_Xj3Nh3dBxzSCkZ5GEyD%2BjdMcFQ%40mail.gmail.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

[blink-dev] Intent to Ship: View Transitions: transition types

2023-11-08 Thread Vladimir Levin 
Contact emailsvmp...@chromium.org, nrosent...@chromium.org

Explainer
https://github.com/vmpstr/web-proposals/blob/main/explainers/view-transition-types.md

Specification
https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo

Summary

This feature allows View transition API use to be customized for different
types of transitions. Specifically, this adds an ability to add "types" to
`startViewTransition` call which will identify the types of the transition.
As well, it will match a pseudo-class, called
`:active-view-transitions(...)` with a parameter matching the type for the
duration of the view transition. Combined these two features provide a way
for the author to declare several view transitions once and only trigger
one at a time. See example usage in the spec:
https://drafts.csswg.org/css-view-transitions-2/#the-active-view-transition-pseudo

Blink componentBlink>ViewTransitions>SPA


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/908

TAG review statusPending

Risks


Interoperability and Compatibility

There are minimal interop and copmat risks. This feature is an extension to
the View Transitions API that makes it more ergonomic to specify multiple
transitions declaratively, while triggering only one of them at a time.


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/905)

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

*Web developers*: No (strong) signals, the feature request came from a web
developer: https://github.com/w3c/csswg-drafts/issues/8960

*Other signals*:

Ergonomics

This feature would be used with the View Transitions API to be able to
easier maintain a declarative set of multiple transitions that can be
triggered. This solution uses a descendant combinator heavily to
selectively style elements in the DOM, but this is not any different from
the polyfill approach of toggling a class on :root.


Activation

This feature can be used directly and fairly easily.


Security

There are no additional security considerations over the View Transitions
API.


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 feature is debuggable in the same way as the View Transitions API, and
also in the same way as other CSS properties.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsViewTransitionTypes

Finch feature nameViewTransitionTypes

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1466251

Estimated milestones
Shipping on desktop 121
Shipping on Android 121
Shipping on WebView 121

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/5089552511533056

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NjgR_%2BTbJbU5O%2BiyhnqxypDAUh7LWHUCWy%3DNnaBCY%2B1g%40mail.gmail.com

This intent message was generated by Chrome Platform Status
.

-- 
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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PckO%3DXSq8HDCy4foC_Xj3Nh3dBxzSCkZ5GEyD%2BjdMcFQ%40mail.gmail.com.